First published on MSDN on Nov 11, 2011
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 :
-
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) :
-
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:
http://support.microsoft.com/kb/319723
http://support.microsoft.com/kb/909801
http://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
