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. 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. 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