Article ID: 811889 - Last Review: April 30, 2012 - Revision: 23.0 How to troubleshoot the "Cannot generate SSPI context" error message
If you are a Small Business customer, find additional troubleshooting and learning resources at the Support for Small Business (http://smallbusiness.support.microsoft.com) site.Understanding the problemThis section will give you the background information on why the "Cannot generate SSPI context" error message occurs and how to troubleshoot the error. You may receive this error message if the following conditions are true:
Understanding Kerberos terminology and Service Principal NameThe SQL Server driver on a client computer uses integrated security to use the Windows security token of the user account to successfully connect to a computer that is running SQL Server. The Windows security token is delegated from the client to the computer that is running SQL Server. The SQL Server driver performs this delegation when the user's security token is delegated from one computer to another by using one of the following configurations:
The "Cannot generate SSPI context" error is generated when SSPI uses Kerberos authentication to delegate over TCP/IP and Kerberos authentication cannot complete the necessary operations to successfully delegate the user security token to the destination computer that is running SQL Server. Why Security Support Provider Interface uses NTLM or Kerberos authenticationKerberos authentication uses an identifier named "Service Principal Name" (SPN). Consider an SPN as a domain or forest unique identifier of some instance in a server resource. You can have an SPN for a web service, for an SQL service, or for an SMTP service. You can also have multiple web service instances on the same physical computer that has a unique SPN.An SPN for SQL Server is composed of the following elements:
When the SQL Server driver on a client uses integrated security to connect to SQL Server, the driver code on the client tries to resolve the fully qualified DNS of the computer that is running SQL Server by using the WinSock networking APIs. To perform this operation, the driver code calls the gethostbyname and gethostbyaddr WinSock APIs. Even if an IP address or host name is passed as the name of the computer that is running SQL Server, the SQL Server driver tries to resolve the fully qualified DNS of the computer if the computer is using integrated security. When the SQL Server driver on the client resolves the fully qualified DNS of the computer that is running SQL Server, the corresponding DNS is used to form the SPN for this computer. Therefore, any issues about how the IP address or host name is resolved to the fully qualified DNS by WinSock may cause the SQL Server driver to create an invalid SPN for the computer that is running SQL Server. For example, the invalid SPNs that the client-side SQL Server driver can form as resolved fully qualified DNS are as follows:
The key factor that makes Kerberos authentication successful is the valid DNS functionality on the network. You can verify this functionality on the client and the server by using the Ping command prompt utility. On the client computer, run the following command to obtain the IP address of the server that is running SQL Server (where the name of the computer that is running SQL Server is SQLServer1): ping sqlserver1 To see whether the Ping utility resolves the fully qualified DNS of SQLServer1, run the following command:ping -a IPAddress For example: C:\>ping SQLSERVER1
Pinging SQLSERVER1 [123.123.123.123] with 32 bytes of data:
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Ping statistics for 123.123.123.123:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
C:\>ping -a 123.123.123.123
Pinging SQLSERVER1.northamerica.corp.mycompany.com [123.123.123.123] with 32 bytes of data:
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Ping statistics for 123.123.123.123:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
C:\>SQL Server Service Principal Name creationThis is one of the important parts of Kerberos authentication and SQL Server interaction. With SQL Server, you can run the SQL Server service under one of the following: a LocalSystem account, a local user account, or a domain user account. When the SQL Server service instance starts, it tries to register its own SPN in Active Directory by using the DsWriteAccountSpn API call. If the call is not successful, the following warning is logged in Event Viewer:Source: MSSQLServer EventID: 19011 Description: SuperSocket info: (SpnRegister) : Error 8344. For more information about the DsWriteAccountSpn function, go to the following Microsoft website:http://msdn2.microsoft.com/en-us/library/ms676056.aspx
(http://msdn2.microsoft.com/en-us/library/ms676056.aspx)
Simplified explanationIf you run the SQL Server service under the LocalSystem account, the SPN is automatically registered and Kerberos authentication interacts successfully with the computer that is running SQL Server. However, if you run the SQL Server service under a domain account or under a local account, the attempt to create the SPN will fail in most cases because the domain account and the local account do not have the right to set their own SPNs. When the SPN creation is not successful, this means that no SPN is set up for the computer that is running SQL Server. If you test by using a domain administrator account as the SQL Server service account, the SPN is successfully created because the domain administrator-level credentials that you must have to create an SPN are present.Because you might not use a domain administrator account to run the SQL Server service (to prevent security risk), the computer that is running SQL Server cannot create its own SPN. Therefore, you must manually create an SPN for your computer that is running SQL Server if you want to use Kerberos authentication when you connect to a computer that is running SQL Server. This is true if you are running SQL Server under a domain user account or under a local user account. The SPN you create must be assigned to the service account of the SQL Server service on that particular computer. The SPN cannot be assigned to the computer container unless the computer that is running SQL Server starts with the local system account. There must be one and only one SPN, and it must be assigned to the appropriate container. Typically, this is the current SQL Server service account, but this is the computer account container with the local system account. Resolving the problemThis section will help show you the steps to make sure that your computer does not experience any SSPI problems. Verify the domainVerify that the domain to which you log on can communicate with the domain to which the computer that is running SQL Server belongs. There must also be correct name resolution in the domain.
Configure the SQL Server service to create SPNs dynamically for the SQL Server instancesTo configure the SQL Server service to create SPNs dynamically, you must change the account's access control settings in the Active Directory directory service. You must grant the "Read servicePrincipalName" permission and the "Write servicePrincipalName" permission for the SQL Server service account.Warning If you use the Active Directory Service Interfaces (ADSI) Edit snap-in, the LDP utility, or any other LDAP version 3 clients and you incorrectly change the attributes of Active Directory objects, you can cause serious problems. These problems may require you to reinstall Windows Server 2003, Microsoft Windows 2000 Server, Microsoft Exchange Server 2003, Microsoft Exchange 2000 Server, or both Windows and Exchange. We cannot guarantee that problems caused by incorrectly changing the attributes of Active Directory objects can be resolved. Change these attributes at your own risk. Note To grant the appropriate permissions and user rights to the SQL Server startup account, you must be logged on as a domain administrator, or you must ask your domain administrator to do this task. To configure the SQL Server service to create SPNs dynamically, follow these steps:
Verify the server environmentCheck some basic settings on the computer where SQL Server is installed:
Verify the client environmentVerify the following on the client:
Verify the client network utilityThe Client Network Utility (CNU) is delivered together with Microsoft Data Access Components (MDAC) and it is used to configure connectivity to computers that are running SQL Server. You can use the MDAC Cliconfg.exe CNU utility to configure connectivity:
Manually set up a Service Principal Name for SQL ServerFor more information about how to manually set up a Service Principal Name for SQL Server, click the following article number to view the article in the Microsoft Knowledge Base:319723
(http://support.microsoft.com/kb/319723/
)
How to use Kerberos authentication in SQL Server
The Security Support Provider Interface (SSPI) is the interface to Microsoft Windows NT security that is used for Kerberos authentication, and supports the authentication scheme of the NTLM Security Support Provider. Authentication occurs at the operating system level when you log on to a Windows domain. Kerberos authentication is available only on Windows 2000-based computers that have Kerberos authentication enabled and that are using Active Directory. SSPI is only used for TCP/IP connections that are made by using Windows Authentication. Windows Authentication is also known as Trusted Connections or Integrated Security. SSPI is not used by Named Pipes or multi-protocol connections. Therefore, you can avoid the problem by configuring clients to connect from a protocol other than TCP/IP. When a SQL Server client tries to use integrated security over TCP/IP sockets to a remote computer that is running SQL Server, the SQL Server client network library uses the SSPI API to perform security delegation. The SQL Server network client (Dbnetlib.dll) makes a call to the AcquireCredentialsHandle function and passes in "negotiate" for the pszPackage parameter. This notifies the underlying security provider to perform negotiate delegation. In this context, negotiate means to try either Kerberos or NTLM authentication on Windows-based computers. In other words, Windows use Kerberos delegation if the destination computer that is running SQL Server has an associated, configured correctly SPN. Otherwise, Windows use NTLM delegation. Note Verify that you are not using an account named "SYSTEM" to start any of the SQL Server services (MSSQLServer, SQLServerAgent, MSSearch). The keyword SYSTEM may cause conflicts with the Key Distribution Center (KDC). Collect information to open a Microsoft Customer Support (CSS) caseIf you cannot obtain the cause of the problem by using the troubleshooting steps in this article, collect the following information and open a Microsoft Customer Support (CSS) case: For a complete list of Microsoft Customer Support Services telephone numbers and information about support costs, go to the following Microsoft website: http://support.microsoft.com/contactus/?ws=support
(http://support.microsoft.com/contactus/?ws=support)
REFERENCES For more information about how Kerberos authentication and SSPI
security works, click the following article numbers to view the articles in the
Microsoft Knowledge Base:
266080
(http://support.microsoft.com/kb/266080/
)
Answers to frequently asked Kerberos authentication questions
231789
(http://support.microsoft.com/kb/231789/
)
Local logon process for Windows 2000
304161
(http://support.microsoft.com/kb/304161/
)
SSPI mutual authentication is indicated on the client side but not on the server side
232179
(http://support.microsoft.com/kb/232179/
)
Kerberos administration in Windows 2000
230476
(http://support.microsoft.com/kb/230476/
)
Description of common Kerberos-related errors in Windows 2000
262177
(http://support.microsoft.com/kb/262177/
)
How to enable Kerberos event logging
277658
(http://support.microsoft.com/kb/277658/
)
Setspn fails if domain name differs from NetBIOS name where SQL Server SPN is registered
244474
(http://support.microsoft.com/kb/244474/
)
How to force Kerberos to use TCP instead of UDP in Windows Server 2003, in Windows XP, and in Windows 2000
326985
(http://support.microsoft.com/kb/326985/
)
How to troubleshoot Kerberos-related issues in IIS
To see a white paper about Microsoft SQL Server 2000 security, go to the following Microsoft website: http://technet.microsoft.com/en-us/cc984178.aspx
(http://technet.microsoft.com/en-us/cc984178.aspx)
Was this information helpful?
How much effort did you personally put forth to use this article?
Tell us why and what can we do to improve this information Thank you! Your feedback is used to help us improve our support content. For more assistance options, please visit the Help and Support Home Page. | Other Resources Other Support Sites
CommunityArticle Translations |






Windows Live
Facebook
Twitter
Linkedin
Digg it
Yahoo
Delicious
StumbleUpon
Yammer
Reddit
Technorati
FriendFeed
Email
Back to the top