Was working with Keith Elmore on one of our internal processes and he was hitting a “Cannot generate SSPI context” when trying to connect from Management Studio. I also saw this come up in a double hop situation (IIS to SQL) when I setup a local repro.
We went through the normal check list for Kerberos Troubleshooting, but really that just consisted of validating the SPN in the case of Management Studio as it was a single hop and we were just trying to do a direct connection without any delegation. The SPN checked out, and there was only one SPN. No duplicates.
We have an internal tool called SSPIClient which will go through the motions of just trying the Windows API calls for Kerberos authentication (IntializeSecurityContext).
2009-12-30 21:11:16.185 Connecting via ODBC to [DRIVER=SQL Server;Server=tcp:passsql\demo;Trusted_Connection=Yes;]
It was saying that the principal was incorrect, but you can see in the output that it is showing sqlservice, which is correct. We had rebooted the SQL Server in question, at which point the SQL Service wouldn’t even start. Keith asked if the password had been changed recently. We took a look, and sure enough, the password was changed yesterday. This happens to be an account that we use for multiple things.
We changed the service account password through SQL Server Configuration Manager and restarted SQL. SQL could start at that point, and the SSPI error disappeared. We were able to successfully connect to SQL at that point.
I’m sure other people have known about this type of condition, but in the years that I’ve been here, along with the number of Kerb issues that I’ve troubleshot in the past, this was the first time I had run across this. Thought I would throw it out there to share with everyone in case they maybe run across something like this that they can’t explain.
If you change your service password, be sure to recycle the SQL Service so that Kerberos can function properly.
Adam W. Saxton | Microsoft SQL Server Escalation Services