Partager via

Cannot generate SSPi context

  • Article

Pourquoi on rencontre les messages de types:

Cannot generate SSPI context

Longon failed for user ‘NT Authority\ANONYMOUS LOGON’

Les deux messages indiquent un problème Kerberos. Le scenario le plus complexe ou on peut rencontrer ce problème, c’est le double hop.
Voilà les détails de ce scenario :

Scenario:

Ordinateur client se connecte au SQL Server (SQL Server A) – serveur lié ( LinkedServer )->SQL Server( SQL Server B )

L’essence de ce scenario c’est la présence des trois machines physiques
(client->SQL Server A->SQL Server B).

Les étapes à vérifier afin d’avoir la configuration requise :

 A. La délégation :

  1.  
  1. Le logon user  pour instance SQL A ne doit pas avoir cette option côchée dans l’Active Directory:

 "Account is sensitive and cannot be delegated selected"

(La console ActivebDirectory Users and Computers)

2. Le logon user de l’instance SQL A doit avoir la permission Trusted for delegation.

3. Les machines physiques A et B  doivent avoir Trusted for delegation également .

 B. Les SPNs (service principal names) :

  1.  
  1. Un SPN doit être enregistré pour le SQL Server A

Exemple:

setspn -A MSSQLSvc/ServerSQLA.FQDN:port sql_logonuserA

setspn -A MSSQLSvc/ServerSQLA.FQDN sql_logonuserA

(Si l’instance A est clustérisée on a besoin des deux, sinon il suffit la version avec le port)

 

A partir de SQL Server 2008, on a la possibilité d’enregistrer un spn pour le nom de l’instance :

 

setspn -A MSSQLSvc/ServerSQLA.FQDN:nom_d’instance sql_logonuserA

Pour les détails : KB319723.

 

 

2. Un SPN enregistré pour l’instance SQL B :

 

setspn -A MSSQLSvc/
SQLServerB.FQDN:port sql_logonB

setspn -A MSSQLSvc/
SQLServerB.FQDN sql_logonB

 

SQL Server 2008 :

setspn -A MSSQLSvc/
SQLServerB.FQDN:nom_d’instance sql_logonB

 

La possibilité d’enregistrer un SPN pour le nom de l’instance, n’élimine pas le besoin d’un SPN pour le nom du port (observation issue de l’expérience plutôt).

Le besoin d’un SPN pour le port, complique la vie de DBA, car il y a des instances SQL qui fonctionnent en port dynamique (chaque redémarrage de l’instance peut casser les SPNs).

La bonne nouvelle c’est le fait d’avoir des permissions au niveau de l’AD qui peuvent faire en sorte que le service SQL enregistre lui-même le SPN qui lui faut :

  • Read servicePrincipalName
  • Write servicePrincipalName

 

Sachez que l’enregistrement des SPNs est automatisé pour les instances SQL qui tournent sur Local System (le compte de la machine) – qui a ces permissions pour enregistrer le SPN par default.

 L’indicatif pour l’absence des permissions pour inscrire le SPN, c’est le message de type:

 The SQL Network Interface library was unable to register SPN

 lorsqu’on démarre SQL Server.

 Une complication possible avec les enregistrements manuelles – les SPNs en doublon. Le même SPN configure pour plusieurs utilisateurs de logon.

 

La commande qui permets de lister toutes les SPNS pour SQL du domaine:

ldifde -f ldifSQL.txt -j c:\ -t 3268 -d "dc=YourDomain,dc=com" -lserviceprincipalname –r” (serviceprincipalname=MSSQL*)"

 On peut vérifier dans la liste sortante s’il y a des doublons.

 

Documentation suplementaire:

https://support.microsoft.com/kb/319723

https://support.microsoft.com/kb/909801

https://blogs.msdn.com/b/sql_protocols/archive/2005/10/12/479871.aspx

  

 Des outils pour le dépannage :

 ·         Kerbtray (disponible sur le site Microsoft)

 ·          Klist (disponible sur le site Microsoft)

 ·         setspn (disponible sur le site Microsoft)

 (Ces outils permettent de lister et de purger  les tickets Kerberos présents sur la machine)

  

 Marius Saisuc, Support Engineer, Microsoft