the problem

The error is never where you start looking.

A Kerberos SPN is one string in Active Directory. When it is wrong, the failure surfaces in the application, the symptom points at the network or the login, and the cause sits in an attribute nobody has opened in years.

what the operator sees

Three symptoms, one attribute.

Cannot generate SSPI context

The client asked the KDC for a ticket to a service principal that the KDC could not find or could not resolve to a single account. The connection string was fine. DNS was fine. The login exists.

login works for some usersand not for others

Kerberos failed and the client fell back to NTLM. Where NTLM is allowed, it works; where it is blocked, or the request has to hop again, it does not. Nothing logs the fallback as an error.

double-hop: Login failed for user'NT AUTHORITY\ANONYMOUS LOGON'

The middle tier authenticated the user with NTLM, so it had no ticket to delegate. The back end sees anonymous. The middle tier's SPN, or its delegation entry, is the actual defect.

three ways the string is wrong

Missing

The service runs as a domain account, but the SPN was never registered on it. Clients ask for MSSQLSvc/sql01.corp.example.com:1433, the KDC has nothing, and the client falls back to NTLM without telling anyone.

Common shapes: the NetBIOS short-name variant is absent; a SQL dynamic port changed on restart; an Always On listener FQDN was never given its own SPN.

# what the KDC has for svc_sqlservicePrincipalName:  (empty)# what the client asks forMSSQLSvc/sql01.corp.example.com:1433   → no match → NTLM

Duplicated

The same SPN sits on two accounts, usually after a service-account migration that added it to the new account and never removed it from the old one. The KDC cannot decide which key to use and returns KRB_ERR_S_PRINCIPAL_UNKNOWN.

The forest-wide duplicate scan exists because this failure is intermittent by nature and invisible from either account on its own.

HTTP/intranet.corp.example.com  on: svc_web_new  on: svc_web_old   ← left behind after the migrationKRB_ERR_S_PRINCIPAL_UNKNOWN

On the wrong account

The SPN is on the machine account, but the service runs as a domain account. The KDC issues a ticket encrypted with the machine key; the service cannot decrypt it. On SQL Server this is a silent NTLM fallback. On a failover cluster instance it is the node account holding what should be on the service account pointing at the cluster network name.

MSSQLSvc/sql01.corp.example.com:1433  registered on: SQL01$  service runs as: CORP\svc_sql# ticket encrypted with SQL01$ key; service holds svc_sql key

why it is hard to see

The fallback is silent, and the tools you reach for first agree with each other.

The client does not log that it fell back. The server accepted the NTLM connection and logged a success. The firewall saw a normal session. SQL Server will tell you the mechanism it actually negotiated, but only if you ask the DMV directly, and only for the session you are in.

That is the gap SpnManager is built around. Its proof harness asks the service what mechanism it saw, before and after, from an independent client. See Proof and evidence →.

the one query that tells the truth (SQL Server)

SELECT auth_schemeFROM   sys.dm_exec_connectionsWHERE  session_id = @@SPID;-- NTLM      ← Kerberos failed somewhere and nothing told you-- KERBEROS  ← the SPN resolved to the right account

what this page does not claim

There are no outage-cost figures or time-to-resolve numbers here because none have been measured for this product. If you have your own, the decision tree → is where to start shortening them.