SSPI Handshake Failed in SQL Server (Error 17806)

The client usually sees the vaguer cousin, “Cannot generate SSPI context”, while 17806 is what lands in the server error log. Both mean the same thing: Windows authentication was attempted and the security negotiation between client and server broke before SQL Server ever saw a login. The password is almost never the problem. The plumbing that validates Windows identities is.

The Documented Causes

These are the established causes, in the order worth checking. None of them can be shown on a standalone lab, so treat this as the checklist the references and years of collective incident history agree on:

• Time skew. Kerberos tolerates five minutes of clock difference by default. A VM that drifted or a machine with a dead CMOS battery produces exactly this, and it is the cheapest check on the list: compare w32tm /query /status on client and server.
• SPN problems. A missing SPN degrades to NTLM quietly, which mostly works; a duplicate SPN breaks Kerberos loudly and produces handshake failures. setspn -L and setspn -X (duplicates) answer it.
• A broken machine secure channel. The client machine’s own trust with the domain is stale. Test-ComputerSecureChannel in PowerShell verifies and -Repair fixes.
• Stale DNS or a wrong reverse record, sending the client to negotiate with a name that does not match the SPN it looked up.

What You Can Check From the SQL Side

This half is lab-tested. Ask the server how current connections actually authenticated:

SELECT auth_scheme, net_transport, COUNT(*) AS connections
FROM sys.dm_exec_connections
GROUP BY auth_scheme, net_transport;

On the lab instance this returns NTLM, and that is worth pausing on: a standalone machine, a connection by IP, or a missing SPN all produce NTLM rather than an error. NTLM working is what “Kerberos quietly not working” looks like. SSPI handshake failures are what you get when even that fallback cannot complete, which is why the causes above are all machine-and-domain plumbing rather than SQL Server settings.

The server error log carries the state number and, on the line following 17806, the client IP. State 14 points at the account or channel being unusable; the accompanying Windows Event Log entries on the client fill in the rest.

If an AI assistant is helping you triage, give it the full error log line, state number and client IP included, together with the auth_scheme output above, and ask which of the causes fits both facts; the pairing narrows it much faster than the error text alone. If the assistant has the sqldba MCP server connected it can pull the verified 17806 and 18452 write-ups for itself, instead of answering from memory.

The Fix Path

Fix the specific broken piece found above: sync the clock, repair the secure channel, remove the duplicate SPN (or register the missing one, covered properly in the Kerberos post in this series), and correct DNS. There is no SQL Server configuration that fixes an SSPI handshake failure, because the handshake happens before SQL Server gets a vote.

When It Is Not This

If the message says untrusted domain, that is error 18452, the adjacent post in this series. If authentication completes and a specific database refuses entry, that is error 916. And a connection failing with TLS wording before any authentication is the pre-login handshake error.

Common Questions

Related Scripts

• Kerberos vs NTLM, SPN registration and the fallback mechanics in full
• Untrusted Domain (18452), the softer failure in the same family
• Pre-Login Handshake Error, when the failure is TLS rather than identity
• Login Failed (18456), the family reference