Home Dashboard Directory Help

Get "Cannot generate SSPI context" error by Jameskla


 as Not Reproducible Help for as Not Reproducible

Sign in
to vote
Type: Bug
ID: 388712
Opened: 12/17/2008 11:56:42 PM
Access Restriction: Public
User(s) can reproduce this bug


When using SSMS client to connect to SQL 2008 server, intermitantly a Cannot generate SSPI context. The work around is to change the connection protocol to named pipes. It is not clear the root cause of this is.
Sign in to post a comment.
Posted by WandaJ on 9/16/2010 at 11:02 AM
Thank you for your post. I changed my SQL configuration manager to enable named pipes, and problem solved.

Posted by Microsoft on 1/5/2009 at 11:53 AM
Dear jameskla,
Thanks for your feedback. "Cannot generate SSPI Context" error messages indicate a problem while trying to authenticate the Windows user logging in to SQL Server, and unfortunately are often hard to troubleshoot. I'll try to provide some step-by-step instructions on some of the most common causes to see if we can get this resolved quickly, and I also have a couple of questions to help narrow down the scenario.

1) Do both the client (SSMS) and the server (SQL Server) machines belong to the same domain? I will assume yes since that is the most common scenario, but let me know if not, since cross-domain connectivity requires some particular settings to be in place to authenticate properly, so we would want to verify those settings if you are connecting across domains.
2) What is the string you specify for the "Server name" field in SSMS? Do you use the ServerName\InstanceName format, ServerName,PortNumber, etc.? If you specify the IP address rather than the server name, then a misconfigured DNS is a very common source of this problem; from the client machines which are getting this error message, try using the nslookup tool, typing the IP Address of the Server in and hitting enter - do this several times and verify you get the same result each time. If you have multiple reverse-DNS entries for the Server, that can lead to this error.

Some more follow-up questions, to help me better understand your scenario. It sounds like you have a group of client machines which are always able to connect fine over TCP, and another group of client machines for which you will reliably get this error message unless you specify Named Pipes. Is that correct? If so, do you know offhand of any significant differences (e.g., network topology, DNS servers used, DC used) between the two groups?

Finally, there is also this rather lengthy KB article on troubleshooting this particular error message which may be helpful to you, if the above suggestions don't turn up the problem: http://support.microsoft.com/kb/811889

Let me know if this is helpful or if I am incorrect in any of the assumptions above. Thanks!

Dan Benediktson
SQL Protocols
Sign in to post a workaround.
Posted by MarcosLeRosa on 3/25/2011 at 10:27 PM
Using named pipes works QuickFix and will not resolve problems for future applications to reach your instance within the network. Check the DC server and fix the SPN (Service Principal Name) for SQL Server service.

For further information on how to fix / register the SPN name visit: http://msdn.microsoft.com/en-us/library/ms191153.aspx

The cause is: When you install SQL using Local Account and exchange to Domain Account the SPN will not be updated and have to be updated manually. (Above link will introduce you to the resolution).

Hope it can help futer folks handling the same problem.
Marcos Rosa