SSPI Handshake Failed in SQL Server (Error 17806)

Windows authentication reached SQL Server and Windows refused the account before any login was checked. The error log gets 17806, the client usually gets 18452, and no SQL Server setting will fix it.

Read the 17806 Line First

17806 is written to the error log only; the client never receives it. Search the current log, and change the first 0 to 1, 2 and so on for older ones:

EXEC sys.xp_readerrorlog 0, 1, N'SSPI handshake';

Each failed attempt writes 4 lines: the 17806 pair, then an 18452 pair for the same client. The IP in [CLIENT: ...] is the machine that tried to connect.

The hex code is a Windows security status. These are the 3 you will meet, in Windows’ own words from the security error code list on MS Docs:

• 0x8009030c, The logon attempt failed. Windows refused the account: the account cannot log on.
• 0x80090311, No authority could be contacted for authentication. No domain controller answered: the server cannot reach the domain.
• 0x8009030e, No credentials are available in the security package. Nothing usable was presented: start with Kerberos, then the account.

MS Docs has no error page for 17806 and publishes no meaning for its states, so act on the hex code, not the state number.

What the Client Saw

The client gets a different message, and which one tells you where the failure happened:

• Login failed. The login is from an untrusted domain (error 18452). This is the same failure seen from the client: the attempt that wrote the 17806 above got exactly this. The account does not have to come from another domain, the server simply could not validate it, which MS Docs lists as an unrecognized Windows principal. More in Untrusted Domain (18452).
• Cannot generate SSPI context. The client gave up before the server judged anything, so there is no 17806 to find. That is usually an SPN or name resolution problem, covered in Kerberos vs NTLM and the Cannot generate SSPI context guide on MS Docs.
• Login failed for user ‘DOMAIN\name’ (error 18456). Authentication worked and the server has no login for that account. That is Login Failed (18456), not this post.

An application on System.Data.SqlClient gets the same text as a SqlException with Number 18452, Class 14, State 1.

The Account Cannot Log On to the Server

This is what 0x8009030c means: the SQL Server machine was handed an account that Windows would not log on. The usual reasons, documented rather than reproduced here:

• The account’s password is wrong or was changed, or the account is locked out, disabled or expired.
• The account lacks the Access this computer from the network right on the SQL Server machine. Microsoft’s support team worked exactly this 17806 and 18452 pair to that cause and fixed it by granting the right (their write-up on MS Docs).
• The account belongs to a domain the server’s domain does not trust, or to another forest. MS Docs says the same forest is required for SSPI to work.

Windows records which one it was. On the SQL Server machine, open the Security log in Event Viewer, filter on event 4625 at the time of the 17806, and read Status and Sub Status. Failed logons only appear there when logon failure auditing is on.

• 0xC000006A, bad password.
• 0xC0000064, the account name does not exist.
• 0xC0000234, locked out. 0xC0000072, disabled. 0xC0000193, expired.
• 0xC000015B, the logon right is missing.

The Server Cannot Reach the Domain

0x80090311 means no domain controller could be reached to validate the account. Documented, not reproduced here, because this lab has no domain. Run this in Windows PowerShell on the SQL Server machine, then on the client:

Test-ComputerSecureChannel

False means that machine’s own trust with the domain is broken, and MS Docs gives -Repair to restore it. If the client sits in a different domain, check the trust between the two domains next.

Check Kerberos: Clock, SPN and DNS

Documented, not reproduced here, because a machine with no domain never uses Kerberos. Cheapest check first:

• Clock. The default domain policy lets Kerberos tolerate 5 minutes of clock difference. Compare w32tm /query /status on the client and the server.
• Duplicate SPN. setspn -X searches for duplicates and setspn -L <service account> lists what the account holds (setspn on MS Docs). A missing SPN usually falls back to NTLM quietly; a duplicate breaks Kerberos.
• DNS. ping -a <server IP> from the client must return the server’s correct full name. A wrong or stale record sends the client to an SPN that does not match.
• The SQL Server service account. Locked out, or its password changed without the service being restarted. MS Docs names both.

SPN registration in full, and registering a missing one, is in Kerberos vs NTLM.

How Working Connections Authenticate

Ask the server how the connections that did get in authenticated:

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

A machine with no domain shows NTLM for everything, and MS Docs says a connection from the same machine always uses NTLM. NTLM where you expected Kerberos is Kerberos failing quietly. 17806 is the loud version: the server refused the attempt outright.

Asking an AI assistant? Give it the whole 17806 line and this output. With the sqldba MCP server connected it can pull the verified 17806 and 18452 write-ups itself instead of answering from memory.

Frequently Asked Questions