DetailPage-MSS-KB

Base de connaissances

Numéro d'article: 811889 - Dernière mise à jour: mardi 30 juillet 2013 - Version: 10.0

Présentation du problème

Réduire cette imageAgrandir cette image
Cette section vous fournit des informations générales sur les raisons de l'affichage du message d'erreur « Impossible de générer le contexte SSPI » et sur la procédure de suppression de l'erreur. Ce message d'erreur peut s'afficher si les conditions suivantes sont remplies :
  • Vous vous connectez à un serveur Microsoft SQL Server.
  • Vous utilisez la sécurité intégrée.
  • L'authentification Kerberos est utilisée pour effectuer la délégation de sécurité.
Compréhension de la terminologie Kerberos et du nom principal du service
Le pilote SQL Server sur un ordinateur client se sert de la sécurité intégrée pour utiliser le jeton de sécurité Windows du compte utilisateur afin de se connecter à un ordinateur qui exécute SQL Server. Le jeton de sécurité Windows est délégué à partir du client vers l'ordinateur qui exécute SQL Server. Le pilote SQL Server effectue cette délégation lorsque le jeton de sécurité de l'utilisateur est délégué à partir d'un ordinateur vers un autre en utilisant l'une des configurations suivantes :
  • NTLM sur Canaux nommés (sans utiliser l'interface SSPI [Security Support Provider Interface])
  • NTLM sur les sockets TCP/IP avec SSPI
  • Authentification Kerberos sur les sockets TCP/IP avec 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. Par conséquent, elle permet à un ordinateur qui exécute un système d'exploitation Windows de déléguer de manière sûre un jeton de sécurité d'utilisateur à partir d'un ordinateur vers un autre sur n'importe quelle couche de transport pouvant transmettre des octets bruts de données.

L'erreur « Impossible de générer un contexte SSPI » est générée lorsque l'interface SSPI utilise l'authentification Kerberos pour la délégation sur TCP/IP et que l'authentification Kerberos ne peut pas effectuer les opérations nécessaires pour assurer la délégation du jeton de sécurité de l'utilisateur vers l'ordinateur de destination qui exécute SQL Server.
Pourquoi l'interface SSPI utilise-t-elle l'authentification Kerberos ou NTLM
L'authentification Kerberos utilise un identificateur appelé « Nom principal du service » (SPN). Considérez un SPN comme un identificateur unique de domaine ou de forêt de quelque instance dans une ressource de serveur. Vous pouvez avoir un SPN pour un service Web, pour un service SQL ou pour un service SMTP. Vous pouvez également avoir plusieurs instances de service Web sur le même ordinateur physique ayant un SPN unique.

Un SPN pour SQL Server est composé des éléments suivants :
  • ServiceClass : Identifie la classe générale de service. Il s'agit toujours de MSSQLSvc pour SQL Server.
  • Hôte : Il s'agit du nom de domaine complet DNS de l'ordinateur qui exécute SQL Server.
  • Port : Il s'agit du numéro de port sur lequel le service écoute.
Par exemple, un SPN typique pour un ordinateur qui exécute SQL Server est :
MSSQLSvc/SQLSERVER1.northamerica.corp.mycompany.com:1433
Le format d'un SPN pour une instance par défaut et le format d'un SPN 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.

Lorsque le pilote SQL Server sur un client utilise la sécurité intégrée pour se connecter à SQL Server, le code du pilote sur le client essaie de résoudre le nom DNS complet de l'ordinateur qui exécute SQL Server en utilisant les API de mise en réseau WinSock. Pour effectuer cette opération, le code du pilote appelle les API WinSock gethostbyname et gethostbyaddr. Même si une adresse IP ou un nom d'hôte est transmis comme le nom de l'ordinateur qui exécute SQL Server, le pilote SQL Server essaie de résoudre le nom DNS complet de l'ordinateur si celui-ci utilise la sécurité intégrée.

Lorsque le pilote SQL Server sur le client résout le nom DNS complet de l'ordinateur qui exécute SQL Server, le service DNS correspondant est utilisé pour former le SPN pour cet ordinateur. 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 l'ordinateur qui exécute SQL Server.

Par exemple, les SPN incorrects que le pilote SQL Server côté client peut former en tant que nom DNS complet résolu sont les suivants :
  • 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 dans Active Directory et ne trouve pas le SPN. 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 correct, mais n'est pas attribué au conteneur approprié, il essaie d'utiliser le SPN, mais en vain. Cela provoque un message d'erreur « Impossible de générer le contexte SSPI ». 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. Comme l'authentification tente d'utiliser en premier le SPN qu'elle détecte, assurez-vous qu'aucun SPN n'est attribué aux conteneurs inappropriés. En d'autres termes, chaque SPN doit être attribué à un seul et unique conteneur.

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 qui exécute SQL Server est SQLServer1) :
ping sqlserver1
Pour savoir si l'utilitaire Ping résout le nom DNS complet de SQLServer1, exécutez la commande suivante :
ping -aadresse_IP
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 adresse_IP résout le nom DNS complet correct de l'ordinateur qui exécute SQL Server, la résolution côté client est également réussie.
Création d'un nom principal du service SQL Server
Il s'agit de l'une des parties importantes de l'interaction de l'authentification Kerberos et de SQL Server. Avec SQL Server, vous pouvez exécuter le service SQL Server sous : un compte LocalSystem, un compte d'utilisateur local ou un compte d'utilisateur de domaine. Lorsque l'instance du service SQL Server démarre, elle essaie d'enregistrer son propre SPN dans Active Directory en utilisant l'appel d'API DsWriteAccountSpn. Si l'appel échoue, l'avertissement suivant est enregistré dans l'Observateur d'événements :

Source: MSSQLServer EventID: 19011 Description: SuperSocket info: (SpnRegister) : Error 8344.

Pour plus d'informations sur la fonction DsWriteAccountSpn, reportez-vous au site Web de Microsoft à l'adresse suivante :
http://msdn.microsoft.com/fr-fr/library/ms676056.aspx (http://msdn.microsoft.com/fr-fr/library/ms676056.aspx)
Explication simplifiée
Si vous exécutez le service SQL Server sous le compte LocalSystem, le SPN est généralement enregistré et l'authentification Kerberos interagit correctement avec l'ordinateur qui exécute SQL Server. Toutefois, si vous exécutez le service SQL Server sous un compte de domaine ou un compte local, la tentative de création du SPN échoue généralement, car le compte de domaine et le compte local n'ont pas le droit de définir leurs propres SPN. Lorsque la création du SPN échoue, cela signifie qu'aucun SPN n'est configuré pour l'ordinateur qui exécute SQL Server. Si vous testez l'utilisation d'un compte d'administrateur de domaine en tant que compte du service SQL Server, le SPN est correctement créé, car les informations d'identification au niveau de l'administrateur système que vous devez avoir pour créer un SPN sont présentes.

Comme il est possible que vous n'utilisiez pas un compte d'administrateur de domaine pour exécuter le service SQL Server (pour empêcher tout risque lié à la sécurité), l'ordinateur qui exécute SQL Server ne peut pas créer son propre SPN. Par conséquent, vous devez créer manuellement un SPN pour votre ordinateur qui exécute SQL Server si vous voulez utiliser l'authentification Kerberos lorsque vous vous connectez à un ordinateur qui exécute SQL Server. Ceci est vrai si vous exécutez SQL Server sous un compte d'utilisateur de domaine ou un compte d'utilisateur local. Le SPN que vous créez doit être attribué au compte du service SQL Server sur cet ordinateur particulier. Le SPN ne peut pas être attribué au conteneur d'ordinateur, sauf si l'ordinateur qui exécuté SQL Server démarre avec le compte système local. Il ne doit y avoir qu'un seul SPN, et il doit être attribué au conteneur approprié. Par défaut, il s'agit du compte de service SQL Server actuel, mais il s'agit du conteneur de compte d'ordinateur avec le compte système local.
Réduire cette imageAgrandir cette image

Résolution du problème

Réduire cette imageAgrandir cette image
Cette section décrit les étapes permettant de s'assurer que votre ordinateur ne rencontre aucun problème de SSPI.

Vérification du domaine
Vérifiez que le domaine sur lequel vous ouvrez une session peut communiquer avec le domaine auquel appartient l'ordinateur qui exécute SQL Server. La résolution de nom doit également être correcte dans le domaine.
  1. Vous devez vous assurer que vous parvenez à ouvrir une session Windows à l'aide des mêmes compte de domaine et mot de passe que le 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é.
    • Le mot de passe du compte a été modifié. Toutefois, vous ne redémarrez jamais le service SQL Server après que le mot de passe a été modifié.
  2. Si votre domaine d'ouverture de session est différent du domaine de l'ordinateur qui exécute 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 pour que l'interface SSPI fonctionne.
  4. Utilisez l'option Le compte est approuvé pour la délégation dans Utilisateurs et ordinateurs Active Directory lorsque vous démarrez SQL Server.

    Remarque Le droit « Le compte est approuvé pour la délégation » est obligatoire lorsque vous déléguez des informations d'identification du serveur SQL cible vers un serveur SQL distant, comme dans un scénario à deux tronçons, tel que les requêtes distribuées (requêtes de serveur liées) qui utilisent l'authentification Windows.
  5. Employez l'utilitaire de manipulation des noms principaux du service pour les comptes (SetSPN.exe) du Kit de ressources Windows 2000. Les comptes d'administrateur de domaine Windows 2000 ou Windows Server 2003 peuvent se servir de l'utilitaire pour contrôler le SPN qui est attribué à un service et à un compte. Pour SQL Server, il ne doit y avoir qu'un seul SPN. Le SPN doit être attribué au conteneur, au compte de service SQL Server actuel dans la plupart des cas et au compte d'ordinateur appropriés lorsque SQL Server démarre avec le compte système local. Si vous démarrez SQL Server alors que vous avez ouvert une session avec le compte LocalSystem, le SPN est automatiquement configuré. Toutefois, si vous utilisez un compte de domaine pour démarrer SQL Server ou lorsque vous changez le compte qui est utilisé pour démarrer SQL Server, vous devez exécuter SetSPN.exe pour supprimer les SPN expirés, puis vous devez ajouter un SPN valide. Pour plus d'informations, reportez-vous à la rubrique « Délégation de comptes de sécurité » de la documentation en ligne de SQL Server 2000. Pour ce faire, accédez au site Web de Microsoft à l'adresse suivante :
    http://msdn.microsoft.com/fr-fr/library/aa905162(SQL.80).aspx (http://msdn.microsoft.com/fr-fr/library/aa905162(SQL.80).aspx)
    Pour plus d'informations sur les kits de ressources Windows 2000, accédez au site Web de Microsoft à l'adresse suivante :
    http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/default.mspx?mfr=true (http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/default.mspx?mfr=true)
  6. Vérifiez que la résolution de nom fonctionne correctement. 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 nom et leur résolution, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
    169790  (http://support.microsoft.com/kb/169790/fr/ ) Comment faire pour résoudre les problèmes de base liés au protocole TCP/IP
  7. Pour plus d'informations sur la résolution des problèmes d'accessibilité et de pare-feu avec Active Directory, cliquez sur les numéros ci-dessous pour afficher les articles correspondants dans la Base de connaissances Microsoft :
    291382  (http://support.microsoft.com/kb/291382/fr/ ) Forum aux questions concernant le DNS de Windows 2000 et de Windows Server 2003
    224196  (http://support.microsoft.com/kb/224196/fr/ ) Restriction du trafic de réplication Active Directory et du trafic RPC client sur un port spécifique
Configuration du service SQL Server en vue de la création dynamique de SPN pour les instances de SQL Server
Pour configurer le service SQL Server en vue de la création dynamique de SPN, vous devez modifier les paramètres de contrôle d'accès du compte dans le service d'annuaire Active Directory. Vous devez accorder les autorisations de lecture et d'écriture du service PrincipalName au compte de service SQL Server.

Avertissement Si vous utilisez le composant logiciel enfichable Modification ADSI (Active Directory Service Interfaces), l'utilitaire LDP ou tout autre client LDAP version 3 et si vous effectuez une modification incorrecte des attributs d'objets Active Directory, vous risquez de générer des problèmes graves. Ces problèmes peuvent vous obliger à réinstaller Windows Server 2003, Microsoft Windows 2000 Server, Microsoft Exchange Server 2003, Microsoft Exchange 2000 Server ou à la fois Windows et Exchange. Nous ne pouvons pas garantir que les problèmes causés par la modification incorrecte des attributs d'objets Active Directory peuvent être résolus. Si vous modifiez ces attributs, vous devez en assumer les risques.

Remarque Pour accorder les autorisations et les droits d'utilisateur appropriés au compte de démarrage SQL Server, vous devez avoir ouvert une session en tant qu'administrateur de domaine ou vous devez demander à votre administrateur de domaine de le faire.

Pour configurer le service SQL Server en vue de la création dynamique de SPN, procédez comme suit :
  1. Cliquez sur Démarrer, sur Exécuter, tapez Adsiedit.msc, puis cliquez sur OK.
  2. Dans le composant logiciel enfichable Éditeur ADSI, développez Domain [nom_domaine], puis DC= nom_domaine_racine et CN=Users, cliquez avec le bouton droit sur CN= nom_compte, puis cliquez sur Propriétés.

    Remarques
    • L'espace réservé nom_domaine représente le nom du domaine.
    • L'espace réservé nom_domaine_racine représente le nom du domaine racine.
    • L'espace réservé nom_compte représente le compte spécifié pour démarrer le service SQL Server.
    • Si vous spécifiez le compte système local pour démarrer le service SQL Server, nom_compte représente le compte utilisé pour ouvrir une session sur Microsoft Windows.
    • Si vous spécifiez un compte d'utilisateur de domaine pour démarrer le service SQL Server, nom_compte représente le compte d'utilisateur de domaine.
  3. Dans la boîte de dialogue Propriétés de CN= nom_compte, cliquez sur l'onglet Sécurité.
  4. Sous l'onglet Sécurité, cliquez sur Avancé.
  5. Dans la boîte de dialogue Paramètres de sécurité avancés, assurez-vous que SELF est répertorié sous Entrées d'autorisations.

    Si SELF n'est pas répertorié, cliquez sur Ajouter, puis ajoutez SELF.
  6. Sous Entrées d'autorisations, cliquez sur SELF, puis sur Editer.
  7. Dans la boîte de dialogue Entrée d'autorisation, cliquez sur l'onglet Propriétés.
  8. Sous l'onglet Propriétés, cliquez sur Cet objet uniquement dans la liste Appliquer à, puis veillez à ce que les cases à cocher correspondant aux autorisations suivantes soient activées sous Autorisations :
    • Read servicePrincipalName
    • Write servicePrincipalName
  9. Cliquez sur OK à deux reprises, puis fermez le composant logiciel enfichable Éditeur ADSI.
Pour obtenir de l'aide pour cette procédure, contactez le support technique Active Directory et mentionnez cet article de la Base de connaissances Microsoft.

Important Nous vous recommandons de ne pas accorder le droit WriteServicePrincipalName au compte de service SQL lorsque les conditions suivantes sont vraies :
  • Il existe plusieurs contrôleurs de domaine.
  • SQL Server est en clusters.
Dans ce scénario, le SPN pour SQL Server peut être supprimé en raison de la latence de la réplication d'Active Directory. Cela peut entraîner des problèmes de connectivité pour l'instance de SQL Server.

Supposons que vous disposez des éléments suivants :
  • Une instance virtuelle SQL nommée Sqlcluster avec deux nœuds : le nœud A et le nœud B.
  • Le nœud A est authentifié par le contrôleur de domaine A et le noeud B, par le contrôleur de domaine B.


Les résultats suivants peuvent se produire :
  1. L'instance de Sqlcluster est active sur le nœud A et a enregistré le SPN SQL dans le contrôleur de domaine A au démarrage.
  2. L'instance de Sqlcluster bascule vers le nœud B lorsque le nœud A est arrêté normalement.
  3. L'instance de Sqlcluster a annulé l'enregistrement de son SPN à partir du contrôleur de domaine A au cours du processus d'arrêt sur le nœud A.
  4. Le SPN est supprimé du contrôleur de domaine A, mais la modification n'a pas encore été répliquée sur le contrôleur de domaine B.
  5. Au démarrage sur le nœud B, l'instance de Sqlcluster tente d'enregistrer le SPN SQL avec le contrôleur de domaine B. Comme le SPN existe toujours, le nœud B ne l'enregistre pas.
  6. Après un certain temps, le contrôleur de domaine A réplique la suppression du SPN (de l'étape 3) sur le contrôleur de domaine B dans le cadre de la réplication Active Directory. Le résultat final est qu'il n'existe aucun SPN valide pour l'instance de SQL dans le domaine et que vous constatez donc des problèmes de connexion à l'instance de Sqlcluster.

Remarque Ce problème est résolu dans SQL Server 2012.
Vérification de l'environnement de serveur
Vérifiez certains paramètres de base sur l'ordinateur sur lequel SQL Server est installé :
  1. L'authentification Kerberos n'est pas prise en charge sur les ordinateurs Windows 2000 qui exécutent Windows Clustering, à moins que vous ayez appliqué le Service Pack 3 (ou version ultérieure) à Windows 2000. Par conséquent, toute tentative d'utilisation de l'authentification SSPI sur une instance en cluster de SQL Server peut échouer. Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
    235529  (http://support.microsoft.com/kb/235529/fr/ ) Prise en charge de l'authentification Kerberos sur les clusters de serveurs Windows 2000
  2. Vérifiez que le serveur exécute le Windows 2000 Service Pack 1 (SP1). Pour plus d'informations sur la prise en charge de l'authentification Kerberos sur les serveurs Windows 2000, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
    267588  (http://support.microsoft.com/kb/267588/fr/ ) Affichage du message d'erreur « Impossible de générer un contexte SSPI » lors de la connexion à SQL Server 2000
  3. Sur un cluster, si le compte que vous utilisez pour démarrer SQL Server, l'Agent SQL Server ou les services de recherche en texte intégral change, si par exemple il utilise un nouveau mot de passe, suivez les étapes fournies dans l'article suivant de la Base de connaissances Microsoft :
    239885  (http://support.microsoft.com/kb/239885/fr/ ) Comment modifier les comptes de service pour un ordinateur en cluster qui exécute SQL Server
  4. Vérifiez si le compte que vous utilisez pour démarrer SQL Server dispose des autorisations appropriées. Si vous utilisez un compte qui n'est pas membre du groupe Administrateurs locaux, reportez-vous à la rubrique « Configuration des comptes de service Windows » de la documentation en ligne de SQL Server pour vous procurer une liste détaillée des autorisations dont ce compte doit disposer :
    http://msdn.microsoft.com/fr-fr/library/aa176564(SQL.80).aspx (http://msdn.microsoft.com/fr-fr/library/aa176564(SQL.80).aspx)
Vérification de l'environnement client
Vérifiez les éléments suivants sur le client :
  1. Vérifiez que le fournisseur de support de sécurité NTLM est correctement installé et activé sur le client. Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
    269541  (http://support.microsoft.com/kb/269541/fr/ ) Message d'erreur lorsque vous vous connectez à SQL Server si la clé de Registre Windows NT LM Security Support Provider est manquante: « Impossible de générer le contexte SSPI »
  2. Déterminez si vous utilisez des informations d'identification mises en cache. Si vous avez ouvert une session sur le client avec des informations d'identification mises en cache, fermez votre session sur l'ordinateur puis rouvrez-la quand vous pourrez vous connecter à un contrôleur de domaine pour empêcher l'utilisation des informations d'identification mises en cache. Pour plus d'informations sur la façon de déterminer si vous utilisez des informations d'identification mises en cache, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft.
    242536  (http://support.microsoft.com/kb/242536/fr/ ) L'utilisateur n'est pas averti lorsqu'il ouvre une session des informations d'identification de domaine mises en cache
  3. Vérifiez que les dates sur le client et le serveur sont correctes. Si les dates sont trop éloignées, vos certificats peuvent être considérés comme non valides.
  4. SSPI utilise un fichier nommé Security.dll. Si une autre application installe un fichier avec ce nom, celui-ci peut être utilisé à la place du fichier SSPI. Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
    253577  (http://support.microsoft.com/kb/253577/fr/ ) Erreur : 80004005 - Le pilote SQL Server MS ODBC ne peut pas initialiser le package SSPI
  5. Si le système d'exploitation sur le client est Microsoft Windows 98, vous devez installer le composant Client pour les réseaux Microsoft sur le client. Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
    267550  (http://support.microsoft.com/kb/267550/fr/ ) BOGUE : « Échec d'assertion »" lors de la connexion à SQL Server via le protocole TCP/IP
Vérification de l'utilitaire réseau du client
L'utilitaire réseau du client est fourni avec Microsoft Data Access Components (MDAC) et permet de configurer la connectivité sur les ordinateurs qui exécutent SQL Server. Vous pouvez utiliser l'utilitaire réseau du client Cliconfg.exe MDAC pour configurer la connectivité :
  1. Sous l'onglet Général, la façon dont les protocoles sont définis varie selon la version de MDAC. Avec les versions antérieures de MDAC, vous pouvez sélectionner un protocole « par défaut ». Sur les dernières versions de MDAC, vous pouvez activer au moins un protocole avec un protocole en tête de liste lorsque vous vous connectez à SQL Server. Parce que SSPI s'applique uniquement au protocole TCP/IP, vous pouvez utiliser un protocole différent, tel que les Canaux nommés, pour éviter cette erreur.
  2. Consultez l'onglet Alias dans l'utilitaire réseau du client pour vérifier si un alias a été défini pour le serveur auquel vous essayez de vous connecter. Si un alias de serveur a été défini, vérifiez les paramètres pour savoir comment cet ordinateur est configuré pour se connecter à SQL Server. Vous pouvez vérifier cela en supprimant le serveur d'alias pour voir si le comportement change.
  3. Si le serveur d'alias n'est pas défini sur l'utilitaire réseau du client, ajoutez l'alias pour le serveur auquel vous vous connectez. Lorsque vous effectuez cette tâche, vous définissez également le protocole explicitement et vous définissez éventuellement l'adresse IP et le port.
Configuration manuelle d'un nom principal du service pour SQL Server
Pour plus d'informations sur la procédure de configuration d'un nom principal du service pour SQL Server, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft.
319723  (http://support.microsoft.com/kb/319723/fr/ ) Utilisation de l'authentification Kerberos dans SQL Server
L'interface SSPI est l'interface de sécurité de Microsoft Windows NT utilisée pour l'authentification Kerberos et qui prend en charge le schéma d'authentification du fournisseur de support de sécurité NTLM. L'authentification survient au niveau du système d'exploitation lorsque vous ouvrez une session sur un domaine Windows. L'authentification Kerberos n'est disponible que sur les ordinateurs Windows 2000 sur lesquels l'authentification Kerberos est activée et qui utilisent Active Directory.

SSPI n'est utilisée que pour les connexions TCP/IP établies en utilisant l'authentification Windows. L'authentification Windows est également appelée Connexions approuvées ou Sécurité intégrée. L'interface SSPI n'est pas utilisée par les Canaux nommés ni par les connexions multiprotocoles. Par conséquent, vous pouvez éviter le problème en configurant les clients de manière à ce qu'ils se connectent à partir d'un protocole autre que TCP/IP.

Lorsqu'un client SQL Server essaie d'utiliser la sécurité intégrée sur des sockets TCP/IP vers un ordinateur 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 (Dbnetlib.dll) émet un appel vers la fonction AcquireCredentialsHandle et passe à « négocier » pour le paramètre pszPackage. Ceci indique au fournisseur de sécurité sous-jacent d'effectuer la délégation de 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 qui exécute SQL Server a un SPN associé, correctement configuré. Sinon, Windows utilise la délégation NTLM.

Remarque Vérifiez que vous n'utilisez pas un compte nommé « SYSTEM » pour démarrer les services SQL Server (MSSQLServer, SQLServerAgent, MSSearch). Le mot clé SYSTEM peut entraîner des conflits avec le Centre de distribution de clés.
Réduire cette imageAgrandir cette image

Collecte d'informations pour ouvrir un incident auprès du support technique Microsoft (CSS)

Réduire cette imageAgrandir cette image
Si vous ne parvenez pas à détecter la cause du problème à l'aide de la procédure de résolution des problèmes décrite dans cet article, collectez les informations suivantes et ouvrez un incident auprès du support technique Microsoft (CSS).

Pour obtenir la liste complète des numéros de téléphone du support technique Microsoft et des informations sur les frais engendrés, reportez-vous au site Web de Microsoft à l'adresse suivante :
http://support.microsoft.com/contactus/?ln=fr&ws=support (http://support.microsoft.com/contactus/?ln=fr&ws=support)
  1. Générez un rapport sqldiag à partir de SQL Server. Pour plus d'informations, reportez-vous à la rubrique « Utilitaire sqldiag » de la documentation en ligne de SQL Server.
  2. Faites une capture d'écran de l'erreur sur le client.
  3. Ouvrez une invite de commandes sur le noeud qui ne peut pas se connecter à SQL Server et tapez la commande suivante :
    net start > started.txt
    Cette commande génère un fichier nommé Started.txt dans le répertoire dans lequel vous exécutez la commande.
  4. Enregistrez les valeurs pour la clé de Registre sous la clé de Registre suivante sur l'ordinateur client :
    HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\MSSQLSERVER\CLIENT\CONNECTTO
  5. Dans un environnement en cluster, procurez-vous la valeur de la clé de Registre suivante pour chaque nœud du cluster :
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\LMCompatibilityLevel
  6. Dans un environnement en cluster, vérifiez l'existence de la clé de Registre suivante pour chaque nœud de serveur du cluster :
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTLMSsp
  7. Capturez les résultats si vous vous connectez à SQL Server en utilisant un nom UNC (ou le nom de réseau SQL sur un cluster) à partir du client.
  8. Capturez les résultats si vous exécutez la commande ping sur le nom d'ordinateur (ou le nom de réseau SQL sur un cluster) à partir du client.
  9. Enregistrez le nom des comptes d'utilisateur que vous utilisez pour démarrer chacun des services SQL Server (MSSQLServer, SQLServerAgent, MSSearch).
  10. Le professionnel du support doit savoir si SQL Server est configuré pour l'authentification mixte ou pour l'authentification Windows uniquement.
  11. Voyez si vous pouvez connecter votre ordinateur qui exécute SQL Server à partir du même client en utilisant l'authentification SQL Server.
  12. Voyez si vous pouvez vous connecter en utilisant le protocole Canaux nommés.

Références

Pour plus d'informations sur le fonctionnement de l'authentification Kerberos et de la sécurité SSPI, cliquez sur les numéros ci-dessous pour afficher les articles correspondants dans la Base de connaissances Microsoft :
266080  (http://support.microsoft.com/kb/266080/fr/ ) Réponses aux questions fréquentes concernant l'authentification Kerberos
231789  (http://support.microsoft.com/kb/231789/fr/ ) Processus d'ouverture de session locale pour Windows 2000
304161  (http://support.microsoft.com/kb/304161/fr/ ) L'authentification mutuelle SSPI est indiquée côté client mais pas côté serveur
232179  (http://support.microsoft.com/kb/232179/fr/ ) Administration Kerberos dans Windows 2000
230476  (http://support.microsoft.com/kb/230476/fr/ ) Description d'erreurs courantes liées à Kerberos dans Windows 2000
262177  (http://support.microsoft.com/kb/262177/fr/ ) Procédure d'activation de l'enregistrement d'événements Kerberos
277658  (http://support.microsoft.com/kb/277658/fr/ ) Échec de Setspn si le nom de domaine diffère du nom NetBIOS où le SPN SQL Server est enregistré
244474  (http://support.microsoft.com/kb/244474/fr/ ) Comment forcer Kerberos à utiliser le protocole TCP à la place d'UDP dans Windows Server 2003, Windows XP et Windows 2000
Pour consulter un livre blanc relatif à la sécurité de Microsoft SQL Server 2000, reportez-vous au site Web de Microsoft à l'adresse suivante :
http://technet.microsoft.com/fr-fr/cc984178.aspx (http://technet.microsoft.com/fr-fr/cc984178.aspx)
Réduire cette imageAgrandir cette image

Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2000 Standard
  • Microsoft SQL Server 2000 Édition 64 bits
  • Microsoft Windows Server 2003, Standard Edition (32-bit x86)
  • Microsoft SQL Server 2008 Developer
  • Microsoft SQL Server 2008 Enterprise
  • Microsoft SQL Server 2008 Enterprise Evaluation
  • Microsoft SQL Server 2008 Express
  • Microsoft SQL Server 2008 Express with Advanced Services
  • Microsoft SQL Server 2008 R2 Datacenter
  • Microsoft SQL Server 2008 R2 Developer
  • Microsoft SQL Server 2008 R2 Enterprise
  • Microsoft SQL Server 2008 R2 Express
  • Microsoft SQL Server 2008 R2 Express with Advanced Services
  • Microsoft SQL Server 2008 R2 Integration Services
  • Microsoft SQL Server 2008 R2 Standard
  • Microsoft SQL Server 2008 R2 Standard Edition for Small Business
  • Microsoft SQL Server 2008 R2 Web
  • Microsoft SQL Server 2008 R2 Workgroup
  • Microsoft SQL Server 2008 Reporting Services
  • Microsoft SQL Server 2008 Standard
  • Microsoft SQL Server 2008 Standard Edition for Small Business
  • Microsoft SQL Server 2008 Web
  • Microsoft SQL Server 2008 Workgroup
  • Microsoft SQL Server 2012 Developer
  • Microsoft SQL Server 2012 Enterprise
  • Microsoft SQL Server 2012 Express
  • Microsoft SQL Server 2012 Standard
  • Microsoft SQL Server 2012 Web
  • SQL Server 2012 Enterprise Core
Mots-clés : 
kbsqlsetup kbhowtomaster kbhowto KB811889
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.
Partager
Options de support supplémentaire
Forums du support Microsoft Community
Nous contacter directement
Trouver un partenaire Microsoft Certified Partner
Microsoft Store