- Error number
- 18452
- Severity
- 14 (user-correctable error)
- State
- 1
- Product
- Microsoft SQL Server Database Engine
- Versions
- All supported SQL Server versions (2016 to 2025) and Azure SQL Managed Instance with Windows authentication; on Linux only when Active Directory authentication is configured
- Category
- Logins & Permissions
- Last reviewed
- 23 October 2026
On this page
What it means
Error 18452 means SQL Server could not validate the Windows credentials the client presented, typically because the account belongs to a domain the server does not trust or Kerberos and NTLM authentication failed along the way.
With Windows (Integrated) authentication, the client does not send a password: it sends a Kerberos ticket or an NTLM response, and SQL Server asks Windows to validate it. If Windows on the SQL Server machine cannot turn those credentials into a known Windows principal, SQL Server rejects the connection with 18452 at severity 14. The login might be perfectly valid in SQL Server; the failure happens before SQL Server looks at its own logins.
Microsoft lists four explanations: the account comes from a domain that is not trusted by the server's domain, the trust level between domains blocks authentication or hides service principal names (SPNs), the client is not logged on to the domain it thinks it is (for example a workgroup machine or a local account), or, when the connection is really meant to use SQL Server authentication, the instance accepts only Windows authentication or the SQL login does not exist. The less specific error 18456 can come from the same situations.
Common causes
- The client machine or user account is in a workgroup, or in a different forest or domain with no trust to the SQL Server domain.
- Kerberos fails (missing, duplicate or misplaced SPN, clock skew over five minutes, wrong DNS suffix on a NetBIOS name) and the NTLM fallback is also rejected.
- The user is logged on with a local or cached account, or a VPN session has not authenticated to the domain, so Windows sends credentials the server cannot verify.
- The application meant to use SQL Server authentication, but the connection string asks for Integrated Security, or the instance only accepts Windows authentication.
- The Domain Controller cannot be reached from the SQL Server machine, or the Local Security Authority has problems validating the request.
Diagnose it
Read-only These queries only read metadata and dynamic management views. They do not change data, permissions or configuration, so they are safe to run first.
Find the failures and client addresses in the error log
Run as an administrator on the instance (from a connection that works).
EXEC sp_readerrorlog 0, 1, N'untrusted domain';One line per rejected attempt. Note the time and client address to match them with the client machine and user.
Which authentication scheme do working connections use?
SELECT session_id, auth_scheme, net_transport, client_net_address
FROM sys.dm_exec_connections
ORDER BY session_id;KERBEROS for remote domain connections is healthy. NTLM from remote clients often means the SPN is missing or wrong, which is a common precursor of 18452 across domains.
Does the instance accept SQL Server authentication?
SELECT SERVERPROPERTY('IsIntegratedSecurityOnly') AS windows_authentication_only;1 means Windows authentication only, so a client that cannot use a trusted Windows account has no alternative until mixed mode is enabled.
Check the domain, Kerberos ticket and SPN from a command prompt
On the client: whoami (which account), klist (is there a ticket for MSSQLSvc/server.domain.com?), and runas /netonly /user:DOMAIN\user "sqlcmd -S server.domain.com -E" to test another domain account independent of the application. On a domain-joined machine, setspn -L DOMAIN\sqlserviceaccount lists the SPNs and nltest /sc_query:DOMAIN checks the secure channel to the domain. Microsoft suggests setspn and runas to test the trust relationship.
How to fix it
Each fix is labelled with what it changes. Try read-only checks and the least invasive fix first, and test changes outside production.
Log on with an account from a trusted domain
Client or network sideMake sure the client is joined to (or logged on to) a domain that the SQL Server domain trusts. For a one-off connection from a workgroup laptop, start the tool with runas /netonly /user:DOMAIN\user so the network credentials come from the domain.
Fix the SPN and name resolution so Kerberos works
Changes configurationConnect with the fully qualified server name, and have a domain administrator register the missing SPN on the SQL Server service account (or remove a duplicate). Microsoft recommends Kerberos Configuration Manager to find and fix SPN problems.
-- Run by a domain administrator (command prompt, not T-SQL)
setspn -S MSSQLSvc/sqlprod01.contoso.com:1433 CONTOSO\sqlsvc
setspn -S MSSQLSvc/sqlprod01.contoso.com CONTOSO\sqlsvcEstablish or repair the domain trust
Changes configurationCross-domain Windows authentication needs a trust between the domains (and, with selective authentication, permission for the users). This is an Active Directory change for the domain administrators; SQL Server settings cannot work around a missing trust.
Use SQL Server authentication where Windows authentication cannot work
Client or network sideFor clients that can never authenticate to the domain, use a SQL Server login with a strong password over an encrypted connection, provided the instance runs in mixed mode. Do not turn the connection string's Integrated Security on and off by trial; decide which one the application uses.
Examples
A workgroup machine connects with Windows authentication
Shown as documented by Microsoft; not reproduced, because it needs a client outside any trusted domain.
-- From a laptop that is not joined to CONTOSO, logged on with a local account:
-- sqlcmd -S sqlprod01.contoso.com -E
-- SQL Server cannot validate the local account's credentialsLogin failed. The login is from an untrusted domain and cannot be used with Integrated authentication.
How to prevent it
Keep application servers and SQL Server in the same domain or in domains with an explicit trust, register SPNs for every SQL Server service account when it is created (or let the service account register its own), and connect with fully qualified names so Kerberos is used.
Synchronise clocks across domain members, and monitor the error log for bursts of 18452 or 18456 after domain or account changes. See the SQL Server security lesson for choosing between Windows and SQL Server authentication.
Common questions
What causes "The login is from an untrusted domain"?
Windows on the SQL Server machine could not validate the credentials the client sent. Usually the client account is in a workgroup or an untrusted domain, or Kerberos failed (SPN, clock skew, name resolution) and NTLM could not succeed either.
Can I fix error 18452 from inside SQL Server?
Not usually. The problem is in Windows authentication between the client, the domain controllers and the server. SQL Server only changes the outcome if you switch the client to SQL Server authentication on a mixed mode instance.
Why does it work on the server itself but not from my laptop?
Local connections authenticate with NTLM on the same machine, while remote connections need Kerberos or NTLM through the domain. Check that the laptop is logged on to a trusted domain and that the SQL Server SPN is registered.
Learn more on CodeWithSQL
Official documentation
- MSSQLSERVER_18452 (Microsoft Learn)
- Overview of consistent authentication issues in SQL Server (Microsoft Learn)
- Register a service principal name for Kerberos connections
Last technically reviewed 23 October 2026; examples and diagnostics run on SQL Server 2025 (17.0.1145.4). Message text checked against the engine's sys.messages catalogue.