10 March,2011 by Jack Vamvas
Kerberos manages the authentication method on most Windows hosted database server systems I work on . It is a method of authenticating client and server entities.
If Windows Authentication is used, SQL Server exploits Kerberos via the Security Support provider Interface(SSPI) The SSPI accesses a set of Windows APIs – that manage the delegation\authentication of the data transport layer , e.g TCP\IP. From a SQL Server perspective , the SSPI permits the Windows Operating System to delegate the user security token from one server to another .
To view if a current connection uses Kerberos issue the SQL statement:
SELECT auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@spid
The Cannot generate SSPI context error message is triggered by SSPI using Kerberos to delegate over TCP\IP and Kerberos cannot complete the operations to successfully delegate the security token to the destination server. There a number of reasons this can occur
If integrated security is used , the driver will attempt resolve the fully qualified DNS of the target SQL Server . That DNS will be used to form the Service Principal Name (SPN). If issues were discovered while attempting to resolve the ip or hostname by the API will result in an invalid SPN. The key aspect of the SPN is it must be registered with the Active Directory. Post registration the SPN is mapped to the SQL Server service account used for start up.If the registration has failed or some other problem occurs, Windows security cannot determine the account associated with the SPN – this will mean Kerberos will not be used.
I’ve recently been getting a few on a particular server – initially I was rebooting the server – which cleared the problem.
It turns out there was a a DNS issue regarding reverse lookups – all cleared.