SQL SERVER – Login Failed. The Login is From an Untrusted Domain and Cannot be Used with Windows Authentication – SPN Issue

During final checks after a deployment, a clustered SQL Server would not fail over to its second node. The cluster log said login failed, untrusted domain. The domain was fine. The problem was a Service Principal Name, and SQL Server had actually been telling us about it in its own ERRORLOG at every start.

Two Logs, One Story

The cluster log showed the resource starting SQL Server, then failing to log in to it:

INFO [RES] SQL Server : [sqsrvres] Service is started. SQL Server pid is 19224
INFO [RES] SQL Server : [sqsrvres] Connect to SQL Server ...
ERR  [RES] SQL Server : [sqsrvres] ODBC Error: [28000] ... Login failed. The login is
     from an untrusted domain and cannot be used with Windows authentication. (18452)
INFO [RES] SQL Server : [sqsrvres] Could not connect to SQL Server (rc -1)

This matters more than it looks. The cluster checks that SQL Server is alive by logging in to it. If that login fails, the cluster decides SQL Server is not healthy and will not bring it online. So an authentication problem becomes a failover problem.

The Windows event log had the clue:

The program sqlservr.exe ... could not authenticate locally by using the target
name MSSQLSvc/SQLNODE001.mydomain.com:1433. The target name used is not valid.

“Target name” is Kerberos language for an SPN. The name MSSQLSvc/SQLNODE001.mydomain.com:1433 was either missing, or registered to the wrong account.

What an SPN Is, in One Paragraph

Kerberos needs to know which account runs the service you are connecting to, so it can hand you a ticket that account can read. An SPN is that label, stored in Active Directory against the service account: “the SQL Server on this host and this port is run by this account.” If the label is missing, Kerberos cannot work and Windows falls back to NTLM. If the label points at the wrong account, the ticket cannot be read, and the login fails outright. That second case is the usual source of the untrusted domain error.

SQL Server Tells You at Every Start

This is the part I wish we had looked at first. SQL Server tries to register its own SPNs when it starts, and writes down whether it managed. Here is my own instance:

EXEC xp_readerrorlog 0, 1, N'Service Principal Name';

SQL Server is attempting to register a Service Principal Name (SPN) for the SQL
Server service. Kerberos authentication will not be possible until a SPN is
registered for the SQL Server service.

The SQL Server Network Interface library could not register the Service Principal
Name (SPN) [ MSSQLSvc/SQLBOX:SQLDEV ] for the SQL Server service.
Windows return code: 0xffffffff, state: 63.

The SQL Server Network Interface library could not register the Service Principal
Name (SPN) [ MSSQLSvc/SQLBOX:1455 ] for the SQL Server service.
Windows return code: 0xffffffff, state: 63.

Two things to notice. SQL Server wants two SPNs: one by instance name and one by port. And it failed on both. On my machine that is expected, because it is not joined to a domain, so there is nowhere to register anything. On a cluster node, the same message means the service account is not allowed to write its own SPN in Active Directory, and somebody has to register it by hand.

Check What Your Connection Is Actually Using

One query tells you whether Kerberos is working for a connection:

SELECT net_transport, auth_scheme
FROM   sys.dm_exec_connections
WHERE  session_id = @@SPID;

On my machine it said NTLM, over shared memory and over TCP alike. That fits the failed registration above. On a domain server with correct SPNs, a TCP connection from another machine should say KERBEROS. If it says NTLM, the SPN is missing. Run it from the machine that connects, not from the server itself, because a local connection proves very little.

The Fix

Register the SPNs against the SQL Server service account, for every name the instance is reached by. On a cluster that is the virtual network name of the SQL Server resource, not the individual node names:

setspn -S MSSQLSvc/SQLVNN.mydomain.com:1433 MYDOMAIN\svc_sqlserver
setspn -S MSSQLSvc/SQLVNN.mydomain.com      MYDOMAIN\svc_sqlserver

Use -S rather than the older -A. -S checks for a duplicate before adding, and a duplicate, the same SPN on two accounts, is one of the most common ways to get exactly this error. To find duplicates across the domain, and to see what an account already has:

setspn -X
setspn -L MYDOMAIN\svc_sqlserver

The -X and -L commands only read, so any domain user can run them. Adding an SPN with -S needs rights to change the service account in Active Directory, which usually means asking the domain team. I could not run any of them here, since my test machine has no domain.

The better long-term fix is to let SQL Server register its own SPNs. That needs the service account to have permission to read and write its own servicePrincipalName attribute. Then the startup messages above turn into success messages, and the SPN follows the service automatically.

At the time I also used Microsoft’s Kerberos Configuration Manager for SQL Server, which finds missing SPNs and writes the setspn commands for you. It helped us get the syntax right. It is an older tool, so check that it supports your version before you rely on it.

One Small Wording Change

The error text has moved on since this happened. On SQL Server 2025, message 18452 reads “cannot be used with Integrated authentication” rather than “Windows authentication”. Same error, same number, same cause. Search for 18452, not for the words.

Error 18452 is not an untrusted domain, it is a service without a name that Kerberos can find.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.