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 start up account of the SQL Server service.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.

Author: Jack Vamvas (http://www.sqlserver-dba.com)