Login Failed: The Login Is From an Untrusted Domain (Error 18452)

August 6, 2026

–

Msg 18452 · Level 14 · State 1

Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication.

⚡Start at the client, not the domain: whoami shows whether it is even a domain account, and an IP in the connection string forces the NTLM path. One failing machine is a client problem; many at once earns the domain call.

The word “domain” sends everyone to the domain admins, and most of the time the domain is fine. What this error actually means is narrower: the client presented Windows credentials that SQL Server’s side of the conversation could not validate. The trust that failed is between the credentials offered and the account database the server can reach, and that failure has several much more ordinary causes than a broken domain trust.

The Usual Causes

In rough order of how often they turn out to be the answer:

The Client Is Not on the DomainMOST COMMON

A laptop, a jump box, or a container trying Integrated authentication with a local Windows account. A local account means nothing to the server’s domain, and this is the exact message it earns.

How you tell

whoami on the failing client comes back with a machine name where a domain name should be, hpai01\peter rather than DOMAIN\peter. Nothing on the server side will fix that.

Connecting by IP AddressCOMMON

Kerberos needs a name to find a service principal, so an IP connection falls back to NTLM, and where NTLM is blocked by policy the attempt surfaces as this error rather than something clearer.

How you tell

That session negotiated NTLM and never KERBEROS, and the address it connected to has no name in it. Check 1 below is where you read the scheme.

Stale Credentials on the ClientCOMMON

A password changed while a session, scheduled task or service kept the old token.

How you tell

One machine fails while every other client connects normally, and signing that account out and back in on the failing machine clears it.

A Genuine Trust or Secure-Channel ProblemLESS COMMON

Possible, and worth checking last unless several machines started failing together. The companion error in that family is the SSPI handshake failure, which has its own post in this series.

How you tell

Checks 2 and 3 below come back clean on more than 1 client, and they all started failing at the same moment. Until that is true, it is one of the 3 above.

Microsoft’s reference covers error 18452 in full, and it lists 2 causes that have nothing to do with Windows: a SQL Server login offered to an instance that only accepts Windows authentication, and a SQL Server login that does not exist. Microsoft notes the same problems can also come back as the less specific 18456. If you were using SQL authentication when you got this, check SERVERPROPERTY('IsIntegratedSecurityOnly') before anything else: 1 means Windows only.

What To Check, In Order

Each of these is a 2-minute check, and they are ordered so the common causes go first:

1. How are successful Windows connections authenticating right now? Run this on the server:

-- Windows connections that ARE working: which scheme did they negotiate?
SELECT auth_scheme, COUNT(*) AS connections
FROM sys.dm_exec_connections
GROUP BY auth_scheme;

A server showing only NTLM where you expect KERBEROS is a standing clue that names and SPNs, not passwords, are where this error comes from. The Kerberos vs NTLM post in this series covers what to do with that result.

2. Is the failing client using a domain account? whoami on the client answers it. A MACHINE\user result instead of DOMAIN\user is the whole diagnosis.

3. Is the connection by name or by IP? Check the connection string. If it is an IP, test the same connection with the server’s DNS name before touching anything else.

4. Did it fail for one client or many at once? One = that client’s account, token or configuration. Many at the same moment = server-side or domain-side, and now the domain conversation is justified.

The Fixes

Match the fix to the cause found above: use a domain account (or SQL authentication, honestly stated, where a machine cannot be domain-joined), connect by name rather than IP, sign the client out and back in to refresh a stale token, and only escalate to the domain team with evidence: which client, which account, name or IP, one machine or many. And for the not-on-the-domain machine you cannot join, there is a working session-level answer: runas /netonly presents domain credentials across the network only, which sidesteps the local-account problem entirely; that post covers it start to finish.

When It Is Not This

If the message names a specific reason (disabled account, expired password) you are in a different, more specific branch of the login-failure family. And if the connection dies before authentication even starts, with TLS or handshake wording, that is the pre-login handshake error rather than anything about trust.

Common Questions

Do I need the domain admins?

Usually not first. One failing client is nearly always that client: a local account, an IP connection string, or a stale token. Many clients failing at the same moment is when the domain conversation earns its place.

Why does connecting by IP matter?

Kerberos identifies services by name, so an IP connection cannot use it and falls back to NTLM. Where policy restricts NTLM, that fallback surfaces as this error instead of working quietly.

Can I just switch to SQL authentication?

It makes the error go away because it stops using Windows identities entirely. That is sometimes the right call for a machine that cannot be domain-joined, but state it honestly as a decision, not a fix.

I am using SQL Server authentication and still got 18452.

Then the Windows-trust reading is a red herring. Microsoft’s page lists 2 non-Windows causes: the instance only accepts Windows authentication, or the SQL login you typed does not exist on it. Run SELECT SERVERPROPERTY('IsIntegratedSecurityOnly'); 1 means mixed mode is off and no SQL login gets in until it is switched on and the instance restarted. If it returns 0, check the login exists in sys.sql_logins.

Related Scripts

Kerberos vs NTLM, why IP connections and missing SPNs change how you authenticate
SSPI Handshake Failed (17806), the harder-broken cousin
Login Failed (18456), when the message gives no reason at all
Check Connection Encryption and Protocol, what your sessions actually negotiate