SQL Server Home
Get "Cannot generate SSPI context" error
as Not Reproducible
12/17/2008 11:56:42 PM
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.
SQL Server 2008 - Enterprise Edition
Windows Server 2008
Operating System Language
Steps to Reproduce
Install SQL 2008 Enterprise on Windows 2008 or Windows 2003 and after the install try connecting using SSMS using a Windows Vista Enterprise OS. Some servers return "Cannot generate SSPI context error" when connecting. Changing the protocol to Named pipes corrects the issue but has to be forced on each connect attempt.
Only works over Named Pipes
Connection works on either Named pipes or TCP/IP.
to post a comment.
Please enter a comment.
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.
on 1/5/2009 at 11:53 AM
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!
to post a workaround.
Please enter a workaround.
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.
© 2013 Microsoft