Comments on: Sql Server and SSPI handshake failed error hell

By: Robert L Davis

Robert L Davis — Tue, 29 Jun 2010 17:04:37 +0000

I agree about the reboot. That’s why I check SPN’s before DC/Kerberos errors. An SPN can be fixed without rebooting, but if the issue is DC connection and no one can log in to the SQL Server, you’re down anyway so a reboot shouldn’t be out of the question.

The problem with having a bad SPN configured is that it will cause the connection attempt to fail outright rather than falling back to kerberos. So you don’t have to configure the server for kerberos for kerberos to bite you in the back-end.

Many times, this happens accidentally because Local System has permissions to create its own SPN. If you change the SQL Server service account from local system to a different account via SSCM without stopping the SQL Server service first, it will often not delete the SPN that Local System created. This leaves an invalid SPN in AD. I see this a lot.

By: Allen Kinsel

Allen Kinsel — Tue, 29 Jun 2010 16:24:37 +0000

I guess should have worded that a little differently, in my experience in a lot of environments kerberos isnt used since its not configured, so it always falls back to NTLM, with only NTLM and no Kerberos in the result list, its usually safe to say that SPN’s arent the issue.

I would agree with your troubleshooting steps for Kerb issues, the problem is since many people dont use kerb, its the NTLM SSPI errors that cause the grief, and just reboting a SQL Server outside of the SLA is very nearly impossible (at least in our environment)

By: NULLgarity

NULLgarity — Thu, 24 Jun 2010 17:15:16 +0000

This post should win an award. These SSPI errors have cause me all sorts of trouble over the years and are EXTREMELY difficult to troubleshoot. In my experience, they often went away before I even had a chance to look into them. Thanks for the post!

By: Shawn Melton

Shawn Melton — Thu, 17 Jun 2010 19:41:49 +0000

It’s been a while since I have done SA duties with AD but I would be curious too. I actually have a User Group meeting tonight (06/17/10) with an MCT that teaches AD and will ask him if he can explain that authentication mess.

By: Robert L Davis

Robert L Davis — Thu, 17 Jun 2010 15:35:26 +0000

sys.dm_exec_connections does not tell you what protocol they used to attempt their connection. It tells you which protocol suceeded. Kerberos is ALWAYS tried first and NTLM is used as a failback. So if they show as using NTLM, it’s not because they didn’t attempt to use Kerberos, its because Kerberos wasn’t successful.

In my experience, 98% of all SSPI errors are caused by either an invalid SPN or a failure connecting to the domain controller. The first 2 troubleshooting steps should be:

1. Validate the SPN’s. No SPN’s is fine. Just make sure that any existing SPN’s are valid.
2. Check the System Event Log for Kerberos errors or errors stating failures to contact the DC.

If there are invalid SPN’s delete them. If you have DC/kerberos errors, reboot the SQL Server.