Message d’erreur « Impossible de générer un contexte SSPI » en utilisant l’authentification Windows pour se connecter à SQL Server

S'applique à : SQL Server
Numéro de l’article d’origine dans la base de connaissances : 811889

Note

Avant de commencer à résoudre un problème, nous vous recommandons de consulter les prérequis et de parcourir la liste de vérification.

Lorsque vous utilisez l’authentification Windows pour vous connecter à une instance de SQL Server à distance, le message d’erreur suivant apparaît :

Le principal nom cible est incorrect. Impossible de générer un contexte SSPI.

Forum aux questions

Qu’est-ce que SSPI ?

L’interface SSPI est un ensemble d’API Windows qui permet la délégation et l’authentification mutuelle sur n’importe quelle couche de transport de données générique, telle que les sockets TCP/IP. Un ou plusieurs modules logiciels fournissent les fonctionnalités d’authentification réelles. Chaque module est appelé « fournisseur de support en sécurité » (SSP), puis est implémenté en tant que « bibliothèque de liens dynamiques » (DLL).

Qu’est-ce que Kerberos ?

Le protocole Kerberos v5 est un package de sécurité standard et l’un des trois packages de sécurité utilisés avec les systèmes d’exploitation Windows. Pour plus d’informations, consultez la section Fournisseurs de support en sécurité.

Que signifie le message d’erreur « Impossible de générer un contexte SSPI » ?

Ce message d’erreur signifie que SSPI essaie, sans y arriver, d’utiliser l’authentification Kerberos pour déléguer les identifiants de connexion du client par le biais du protocole TCP/IP ou de canaux nommés à SQL Server. Dans la plupart des cas, c’est un nom de principal de service (SPN) mal configuré qui provoque cette erreur.

Qu’est-ce qu’un SPN ?

Un nom de principal de service (SPN) est un identificateur unique d’une instance de service. Un SPN est utilisé par l’authentification Kerberos pour associer une instance de service à un compte d’ouverture d’une session de service. Ce processus d’association permet à une application cliente de demander au service d’authentifier un compte même si le client n’a pas de nom de compte.

Par exemple, un SPN typique pour un ordinateur exécutant SQL Server est :

MSSQLSvc/SQLSERVER1.northamerica.corp.mycompany.com:1433

Le format d’un SPN pour une instance par défaut ou pour une instance nommée ne sont pas différents. Le numéro de port est ce qui relie le SPN à une instance particulière. Pour plus d’informations sur l’enregistrement d’un SPN sur SQL Server, consultez la section Enregistrer un nom de principal de service pour les connexions Kerberos.

Pourquoi SSPI utilise-t-il l’authentification NTLM ou Kerberos ?

L’authentification Windows est la méthode d’authentification préférée des utilisateurs de SQL Server. Les clients utilisant l’authentification Windows sont authentifiés avec NTLM ou Kerberos.

Lorsqu’un client SQL Server utilise la sécurité intégrée sur des sockets TCP/IP vers un serveur distant qui exécute SQL Server, la bibliothèque réseau du client SQL Server utilise l’API SSPI pour effectuer la délégation de sécurité. Le client réseau SQL Server émet un appel vers la fonction AcquireCredentialsHandle et passe à « négocier » pour le paramètre pszPackage. Ce processus indique au fournisseur de sécurité sous-jacent de déléguer la négociation. Dans ce contexte, « négocier » signifie qu’il faut essayer l’authentification Kerberos ou NTLM sur les ordinateurs Windows. En d’autres termes, Windows utilise la délégation Kerberos si l’ordinateur de destination exécutant SQL Server est associé à un SPN correctement configuré. Sinon, Windows utilise la délégation NTLM. Si le client SQL Server se connecte localement sur la même machine où SQL Server réside, NTLM est toujours utilisé.

Pourquoi la connexion ne bascule-t-elle pas vers NTLM lorsque des problèmes se produisent avec Kerberos ?

Le code du pilote SQL Server du client utilise l’API réseau WinSock pour résoudre le DNS complet du serveur lorsque le pilote utilise l’authentification Windows pour se connecter à SQL Server. Pour effectuer cette opération, le code du pilote appelle les API WinWock gethostbyname et gethostbyaddr. Si la sécurité intégrée est utilisée, le pilote tente de résoudre le DNS complet du serveur, même si une adresse IP ou un nom d’hôte est utilisé comme nom du serveur.

Lorsque le pilote SQL Server du client résout le nom DNS complet du serveur, le service DNS correspondant est utilisé pour former le SPN de ce serveur. Par conséquent, tout problème relatif à la façon dont l’adresse IP ou le nom d’hôte est résolu sur le nom DNS complet par WinSock peut provoquer la création d’un SPN incorrect par le pilote SQL Server pour le serveur.

Par exemple, le pilote SQL Server du client peut être utilisé comme DNS complet pour résoudre les SPN invalides comme suit :

• MSSQLSvc/SQLSERVER1:1433
• MSSQLSvc/123.123.123.123:1433
• MSSQLSvc/SQLSERVER1.antartica.corp.mycompany.com:1433
• MSSQLSvc/SQLSERVER1.dns.northamerica.corp.mycompany.com:1433

Lorsque le pilote SQL Server forme un SPN incorrect, l’authentification peut continuer à fonctionner, car l’interface SSPI essaie de chercher le SPN dans Active Directory. Si l’interface SSPI ne trouve pas le SPN, l’authentification Kerberos ne s’effectue pas. À ce stade, la couche SSPI bascule en mode d’authentification NTLM et la connexion utilise l’authentification NTLM, généralement avec succès. Si le pilote SQL Server forme un SPN valide qui n’est pas affecté au conteneur approprié, le pilote essaie d’utiliser le SPN, mais sans succès. Dans ce cas, le message d’erreur « Impossible de générer un contexte SSPI » peut apparaître. Si le compte de démarrage SQL Server est un compte système local, le conteneur approprié est le nom d’ordinateur. Pour tout autre compte, le conteneur approprié est le compte de démarrage SQL Server. Étant donné que l’authentification utilise le premier SPN trouvé, assurez-vous qu’aucun SPN n’est affecté à des conteneurs incorrects. En d’autres termes, chaque SPN doit être attribué à un seul et unique conteneur.

Comment vérifier la méthode d’authentification de la connexion ?

Pour déterminer la méthode d’authentification d’une connexion, exécutez la requête suivante :

SELECT net_transport, auth_scheme   
FROM sys.dm_exec_connections   
WHERE session_id = @@SPID;  

Pour plus d’informations, consultez Comment déterminer si le type d’authentification est Kerberos.

Comment créer des SPN pour SQL Server ?

Lorsqu’une instance du moteur de base de données de SQL Server démarre, SQL Server tente automatiquement d’enregistrer le SPN pour le service SQL Server à l’aide de l’API DsWriteAccountSpn. Cet appel réussit si le compte de service SQL Server dispose des droits de lecture servicePrincipalName et d’écriture servicePrincipalName dans Active Directory. Sinon, vous aurez besoin de votre administrateur Active Directory pour enregistrer manuellement le bon SPN à l’aide de Microsoft Kerberos Manager pour SQL Server ou de l’outil Setspn intégré. Pour plus d’informations sur la gestion des SPN pour SQL Server, consultez la section Enregistrer un nom de principal de service pour les connexions Kerberos.

Corriger l’erreur avec le Gestionnaire de configuration Kerberos (recommandé)

Note

Cette procédure s’applique uniquement aux situations où vous recevez ces messages d’erreur constamment, et non pas par intermittence.

Il existe différentes raisons pour lesquelles les connexions Kerberos échouent, comme des SPN mal configurés, des problèmes de résolution de noms ou des droits insuffisants pour les comptes de démarage de service de SQL Server. Le Gestionnaire de configuration Microsoft Kerberos (KCM) est un outil qui peut vous aider à vérifier les causes d’erreur. KCM fournit également des options pour résoudre les problèmes identifiés au cours du processus.

Procédez comme suit pour résoudre les erreurs à l’aide de KCM.

1. Sur l’ordinateur concerné par des problèmes de connectivité, téléchargez et installez le Gestionnaire de configuration Kerberos.

2. Démarrez KerberosConfigMgr.exe à partir du dossier %SystemDrive%:\Program Files\Microsoft\Kerberos Configuration Manager. Utilisez ensuite un compte de domaine disposant des autorisations nécessaires pour vous connecter à l’ordinateur SQL Server auquel vous ne pouvez pas vous connecter.

3. Sélectionnez Se connecter, en laissant vides le nom du serveur et les autres détails applicables à votre cas, si vous exécutez KCM sur l’ordinateur SQL Server. Sélectionnez Se connecter pour effectuer l’analyse. Une fois que KCM a terminé de récupérer les informations nécessaires, il bascule automatiquement vers l’onglet SPN et affiche par défaut des informations pour SQL Server, SQL Server Reporting Services, Analysis Services et les écouteurs de groupe de disponibilité. Pour résoudre cette erreur, décochez toutes les cases sauf SQL Server.

4. Examinez le diagnostic de l’outil à l’aide de la colonne État et suivez les étapes nécessaires à la résolution du problème :

   État	Plus d’informations	Action
   Bonne	L’élément vérifié est bien configuré. Vous pouvez passer au prochain élément de la sortie.	Aucune action requise.
   Le SPN requis est manquant.	Cet état est indiqué lorsque le SPN identifié dans la colonne SPN requis manque au compte de démarrage SQL Server dans Active Directory.	1. Sélectionnez Réparer pour examiner les informations dans la boîte de dialogue Avertissement. 2. Sélectionnez Oui pour ajouter le SPN manquant à Active Directory. 3. Si votre compte de domaine dispose des autorisations nécessaires pour mettre à jour Active Directory, le SPN requis est ajouté à Active Directory. 4. Si votre compte de domaine ne dispose pas des autorisations nécessaires pour mettre à jour Active Directory, utilisez les options Générer ou Générer tout pour générer le script qui permettra à l’administrateur Active Directory d’ajouter les SPN manquants. 5. Une fois les SPN ajoutés, exécutez à nouveau le Gestionnaire de configuration Kerberos pour vérifier que les problèmes de SPN sont résolus. 6. En outre, vous pouvez utiliser les commandes suivantes : - Permet SETSPN -Q spnName de localiser le SPN et ses comptes actuels. - Permet SETSPN -D de supprimer le SPN du compte incorrect.
   TCP doit être activé pour utiliser la configuration Kerberos.	Cela se produit lorsque TCP n’est pas activé sur l’ordinateur du client.	Pour activer le protocole TCP/IP pour l’instance SQL Server, procédez comme suit : 1. Dans le Gestionnaire de configuration SQL Server, dans le volet Console, développez Configuration du réseau SQL Server. 2. Dans le volet de la console , sélectionnez Protocoles pour <le nom> de l’instance. 3. Dans le volet Détails, cliquez avec le bouton droit sur TCP/IP, puis sélectionnez Activer. 4. Dans le volet Console, sélectionnez SQL Server Services. 5. Dans le volet d’informations, cliquez avec le bouton droit sur SQL Server (<nom> de l’instance), puis sélectionnez Redémarrer pour arrêter et redémarrer le service SQL Server. Pour plus d’informations, consultez Activer ou désactiver un protocole réseau de serveur.
   Port dynamique	Ce message s’affiche pour les instances nommées qui utilisent des ports dynamiques (configuration par défaut). Dans les environnements où vous devez utiliser Kerberos pour vous connecter à SQL Server, vous devez définir votre instance nommée sur un port statique et utiliser ce port lors de l’enregistrement du SPN.	Pour configurer votre instance de SQL Server afin d’utiliser un port statique, procédez comme suit : 1. Dans Gestionnaire de configuration SQL Server, dans le volet de la console, développez Configuration réseau SQL Server, développez Protocoles pour <le nom> de l’instance, puis double-cliquez sur TCP/IP. 2. Dans la boîte de dialogue Propriétés TCP/IP, examinez le paramètre Écouter tout sous l’onglet Protocole. 3. Si le paramètre Écouter tout est défini sur Oui, basculez vers l’onglet Adresses IP et faites défiler jusqu’au bas de la fenêtre pour trouver le paramètre IPAll. Supprimez la valeur actuelle contenue dans le champ Ports dynamiques TCP et définissez la valeur souhaitée dans le champ Port TCP. Sélectionnez OK et redémarrez l’instance de SQL Server pour que les paramètres prennent effet. 4. Si le paramètre Écouter tout est défini sur Non, basculez vers l’onglet Adresses IP et vérifiez chacune des adresses IP apparaissant dans IP1 et IP2. Pour les adresses IP activées, supprimez la valeur actuelle contenue dans le champ Ports dynamiques TCP puis définissez la valeur souhaitée dans le champ Port TCP. Sélectionnez OK et redémarrez l’instance de SQL Server pour que les paramètres prennent effet. Pour plus d’informations, consultez la section Configurer un serveur pour l’écoute sur un port TCP spécifique.
   SPN dupliqué	Vous pouvez rencontrer une telle situation lorsque le même SPN est enregistré sous différents comptes dans Active Directory.	1. Sélectionnez le bouton Réparer, affichez les informations dans la boîte de dialogue Avertissement, puis sélectionnez Oui si vous pouvez ajouter le SPN manquant à Active Directory. 2. Si votre compte de domaine dispose des autorisations nécessaires pour mettre à jour Active Directory, le SPN incorrect est supprimé. 3. Si votre compte de domaine ne dispose pas des autorisations nécessaires pour mettre à jour Active Directory, cliquez sur le bouton Générer ou Générer tout pour générer le script nécessaire à remettre à votre administrateur Active Directory pour supprimer les noms de SPN en double. Une fois les SPN supprimés, réexécutez KCM pour vérifier que les problèmes de SPN sont résolus.

   Note

   Si le compte de domaine qui démarre KCM ne dispose pas de privilèges nécessaires pour manipuler les SPN dans Active Directory, cliquez sur le bouton Générer ou Générer tout correspondant, sous la colonne Script SPN, pour générer les commandes requises et collaborer avec votre administrateur Active Directory afin de résoudre les problèmes identifiés par KCM.

5. Après avoir résolu tous les problèmes identifiés dans KCM, réexécutez l’outil. Vérifiez qu’aucun autre problème n’est signalé, puis reconnectez-vous. Si l’outil signale toujours des problèmes, répétez la procédure précédente.

Correction d’une erreur sans le Gestionnaire de configuration Kerberos

Si vous ne pouvez pas utiliser KCM, procédez comme suit :

Étape 1 : vérifier la résolution du nom avec la commande ping

Le facteur clé de la réussite de l’authentification Kerberos est la fonctionnalité DNS correcte sur le réseau. Vous pouvez vérifier cette fonctionnalité sur le client et le serveur en utilisant l’utilitaire d’invite de commandes Ping. Sur l’ordinateur client, exécutez la commande suivante pour obtenir l’adresse IP du serveur qui exécute SQL Server (où le nom de l’ordinateur est SQLServer1) :

ping sqlserver1

Pour voir comment l’utilitaire Ping résout le nom DNS complet de SQLServer1, exécutez la commande suivante :

ping -a <IPAddress>

Par exemple :

C:\>ping SQLSERVER1

Pinging SQLSERVER1 [123.123.123.123] with 32 bytes of data:

Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128

Ping statistics for 123.123.123.123:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum =  0ms, Average =  0ms 
C:\>ping -a 123.123.123.123

Pinging SQLSERVER1.northamerica.corp.mycompany.com [123.123.123.123] with 32 bytes of data:

Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Ping statistics for 123.123.123.123:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum =  0ms, Average =  0ms

C:\> 

Lorsque la commande ping -a <IPAddress> résout le nom DNS complet et correct de l’ordinateur qui exécute SQL Server, la résolution côté client est également réussie.

Pour obtenir des diagnostics détaillés, utilisez l’applet de commande Test-NetConnection ou Test-Connection pour tester la connectivité TCP en fonction de la version de PowerShell installée sur l’ordinateur. Pour plus d’informations sur l’applet de commande PowerShell, consultez la section Présentation de l’applet de commande.

Note

Les méthodes de résolution de nom peuvent inclure les fichiers DNS, WINS, Hosts et les fichiers Lmhosts. Pour plus d’informations sur les problèmes de résolution de noms et le dépannage, consultez les liens suivants :

• Résolution des problèmes liés au protocole TCP/IP
• Résolution avancée des problèmes liés au protocole TCP/IP

Vérifiez si des alias correspondant au SQL Server de destination existent dans le Gestionnaire de configuration SQL Server et dans l’utilitaire réseau du client SQL Server. Si un tel alias existe, vérifiez qu’il est correctement configuré en examinant les noms de serveur, le protocole réseau, le numéro de port, etc. Un alias SQL Server peut entraîner la génération d’un SPN inattendu. Cela entraîne des informations d’identification NTLM si le SPN n’est pas trouvé ou si un échec SSPI est détecté, s’il correspond par inadvertance au SPN d’un autre serveur.

Étape 2 : vérifier la communication entre les domaines

Vérifiez que le domaine utilisé pour vous connecter peut communiquer avec le domaine auquel appartient le serveur exécutant SQL Server. La résolution de nom doit également être correcte dans le domaine.

1. Vérifiez que vous pouvez vous connecter à Windows à l’aide des mêmes compte de domaine et mot de passe queceux associés au compte de démarrage du service SQL Server. Par exemple, l’erreur SSPI peut se produire dans l’une des situations suivantes :

   • Le compte de domaine est verrouillé.
   • Vous n’avez pas redémarré le service SQL Server après avoir modifié le mot de passe du compte.

2. Si votre domaine de connexion diffère du domaine du serveur exécutant SQL Server, vérifiez la relation d’approbation entre les domaines.

3. Vérifiez si le domaine auquel le serveur appartient et si le compte de domaine que vous utilisez pour vous connecter sont dans la même forêt ou non. Cette condition est requise au fonctionnement de l’interface SSPI.

Étape 3 : Vérifier les noms de service SQL Server à l’aide des outils SQLCHECK et Setspn

Si vous pouvez vous connecter localement à l’ordinateur SQL Server et disposer d’un accès administrateur, utilisez SQLCHECK. SQLCheck fournit la plupart des informations requises pour résoudre les problèmes d’un fichier. Pour plus d’informations sur l’utilisation de l’outil et les informations qu’il collecte, consultez la page d’accueil de l’outil. Vous pouvez également consulter les prérequis recommandés et la liste de vérification. Une fois le fichier de sortie généré, examinez la configuration du SPN pour votre instance de SQL Server, sous la section Informations sur SQL Server du fichier de sortie.

Exemple de sortie :

Suggested SPN                                               Exists  Status              

----------------------------------------------------------  ------  ------------------- 

MSSQLSvc/testsqlsvr.corp.com:2000                           True    Okay                

MSSQLSvc/testsqlsvr.corp.com                                True    Okay                

MSSQLSvc/testsqlsvr:2000                                    False   SPN does not exist. 

MSSQLSvc/testsqlsvr                                         False   SPN does not exist. 

Utilisez la sortie ci-dessus pour déterminer les prochaines étapes (voir les exemples ci-dessous) et utilisez l’outil Setspn pour prendre les mesures correctives nécessaires afin de résoudre les problèmes de SPN.

Scénario	Action suggérée
Si le SPN n’existe pas :	Ajoutez le ou les SPN nécessaires à votre compte de service SQL Server.
SPN dupliqué(s)	Supprimez le ou les SPN enregistrés pour votre service SQL sous un compte incorrect.
SPN sous un compte incorrect	Supprimez le SPN enregistré pour votre service SQL sous un compte incorrect, puis enregistrez-le sous un compte de service approprié.
Un nom de principal de service incorrect est inscrit	Supprimez le SPN incorrect et inscrivez le spN approprié.

Note

• Vous pouvez consulter la section Informations SQL Server du fichier de sortie de l’outil SQLCHECK pour rechercher le compte de service de votre instance SQL Server.

• Setspn est un outil intégré aux dernières versions de Windows qui vous permet de lire, d’ajouter, de modifier ou de supprimer des SPN dans Active Directory. Vous pouvez utiliser cet outil pour vérifier que la configuration du ou des SPN de SQL Server est conforme au contenu de la section Enregistrer un nom de principal de service pour les connexions Kerberos. Pour plus d’informations, consultez la section sur l’outil Setspn et les exemples d’utilisation.

• Pour plus d’informations sur les scénarios où SQL Server enregistre automatiquement des SPN et où l’enregistrement manuel du SPN est requis, consultez la section Enregistrer un nom de principal de service pour les connexions Kerberos.

Étape 4 : vérifier l’autorisation du compte de démarrage de SQL Server sur le serveur lié

Si vous utilisez Emprunter l’identité comme option d’authentification sur la page Sécurité de votre serveur lié, SQL Server devient nécessaire pour transmettre les identifiants de connexion à un SQL Server distant. Le compte de démarrage de SQL Server, où le serveur lié est défini, doit disposer du droit Compte approuvé pour la délégation qui lui est attribué dans Active Directory. Pour plus d’informations, consultez la section Activer l’ordinateur et les comptes utilisateur approuvés pour la délégation.

Note

Cette étape n’est requise que lorsque vous résolvez les problèmes liés aux requêtes d’un serveur lié.

Voir aussi

• Résoudre les problèmes de connectivité dans SQL Server
• Résolution des problèmes d’authentification constantes
• Outil client SSPI
• Activation de l’enregistrement d’événements dans Kerberos
• Comment obliger Kerberos à utiliser TCP au lieu de UDP dans Windows