http://support.microsoft.com/kb/811889 Cet article explique étape par étape comment résoudre les causes les plus courantes du message d'erreur "Impossible de générer un contexte SSPI". Ce message d'erreur peut s'afficher dans les conditions suivantes : y y y Vous vous connectez à un serveur SQL Server. Vous utilisez la délégation Kerberos. La délégation Kerberos ne délègue pas la sécurité des sockets TCP/IP. Retour au début Compréhension de la te rminologie Kerberos et du nom principal de service Le pilote SQL Server sur un ordinateur client utilise 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 : y NTLM sur Canaux nommés (sans utiliser l'interface SSPI [Security Support Provider Interface]) y y NTLM sur les sockets TCP/IP avec SSPI 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 un jeton de sécurité d'utilisateur en toute sécurité à 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 Kerberos pour la délégation sur TCP/IP et que 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 choisit -elle NTLM ou Kerberos Kerberos utilise un identificateur appelé "Nom principal de service". Considérez un nom principal de service comme un identificateur unique de domaine ou de forêt de quelque instance dans une ressourc e de serveur réseau. Vous pouvez avoir un nom principal de service pour un service Web, pour un service SQL ou pour un service SMTP. Vous pouvez également avoir plusieurs instances de services Web sur le Un nom principal de service pour SQL Server est composé des éléments suivants : y ServiceClass : Identifie la classe générale de service. Lorsque le pilote SQL Server sur le client résout le nom DNS complet de l'ordinateur qui exécute SQL Server.com:1433 MSSQLSvc/SQLSERVER1. le service DNS correspondant est utilisé pour former le nom principal de service pour cet ordinateur. l'authentification Kerberos n'est pas effectuée. Par exemple.northamerica. le code du pilote appelle les API WinSock gethostbyname et gethostbyaddr. Par exemple. Par conséquent.mycompany.mycompany.http://support.dns. À ce moment-là. Il s'agit toujours de MSSQLSvc pour SQL Server.123. L'authentification NTLM (qui ne repose pas sur le nom principal de service) réussit tant que le client utilise l'adresse IP pour contacter le serveur. 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.123. y y Hôte : Il s'agit du nom de domaine complet DNS de l'ordinateur qui exécute SQL Server.microsoft.123:1433 MSSQLSvc/SQLSERVER1. Pour effectuer cette opération.com:1433 Lorsque le pilote SQL Server forme un nom principal de service incorrect. 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.antartica. Si le nom principal de service est introuvable. un nom principal de service typique pour un ordinateur qui exécute SQL Server est : MSSQLSvc/SQLSERVER1.mycompany. 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 nom principal de service incorrect par le pilote SQL Server pour l'ordinateur qui exécute SQL Server. .corp.corp. les noms principaux de service incorrects que le pilote SQL Server côté client peut former en tant que nom DNS complet résolu sont : y y y y MSSQLSvc/SQLSERVER1:1433 MSSQLSvc/123. Port : Il s'agit du numéro de port sur lequel le service écoute. l'authentification peut continuer à fonctionner car l'interface SSPI essaie de chercher dans Active Directory et ne trouve pas le nom principal de service.com:1433 Lorsque le pilote SQL Server sur un client utilise la sécurité intégrée pour se connecter à SQL Server.com/kb/811889 même ordinateur physique ayant un nom principal de service unique. Même si une adresse IP ou un nom d'hôte est passé comme le nom de l'ordinateur qui exécute SQL Server.northamerica.corp. l'interface SSPI bascule en mode d'authentification NTLM. 123.123.northamerica.123.123: bytes=32 time<10ms TTL=128 Reply from 123. Received = 4.123: bytes=32 time<10ms TTL=128 Reply from 123. Approximate round trip times in milli -seconds: Minimum = 0ms.123.123. Maximum = C:\>ping -a 123.123.123: bytes=32 time<10ms TTL=128 Reply from 123.123.123: bytes=32 time<10ms TTL=128 Reply from 123. Maximum = 0ms.mycompany.123.123.123: bytes=32 time<10ms TTL=128 Ping statistics for 123.123: bytes=32 time<10ms TTL=128 Reply from 123.http://support.123.123.123.123. Average = 0ms Pinging SQLSERVER1.123. Average = 0ms C:\> . 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) : pingsqlserver1 Pour savoir si l'utilitaire de ligne de commande ping résout le nom DNS complet de SQLServer1.com [123.123.123.123 0ms.123.corp.123: Packets: Sent = 4.123. exécutez la commande suivante : ping -AAdresse IP Par exemple : C:\>ping SQLSERVER1 Pinging SQLSERVER1 [123.123: bytes=32 time<10ms TTL=128 Ping statistics for 123. Approximate round trip times in milli -seconds: Minimum = 0ms. Lost = 0 (0% loss).123: Packets: Sent = 4.123. Vous pouvez vérifier cette fonctionnalité sur le client et le serveur en utilisant l'utilitaire de ligne de commande Ping. Lost = 0 (0% loss).123. Sur l'ordinateur client.123] with 32 bytes of data: Reply from 123.123: bytes=32 time<10ms TTL=128 Reply from 123.123.123.com/kb/811889 Le facteur clé de la réussite de l'authentification Kerberos est la fonctionnalité DNS correcte sur le réseau.123.123.123] with 32 bytes of data: Reply from 123.microsoft. Received = 4.123.123. Pour plus d'informations sur la fonction DsWriteAccountSpn. la résolution côté client est également réussie. le nom principal de service est correctement créé car les informations d'authentification au niveau de l'administrateur système que vous devez avoir pour créer un nom principal de service sont présentes. Lorsque la création du nom principal de service échoue. la tentative de création du nom principal de service peut échouer. Si l'appel échoue. cela signifie qu'aucun nom principal de service n'est configuré pour l'ordinateur qui exécute SQL Server. Avec SQL Server. l'avertissement suivant est enregistré dans l'Observateur d'événements : Source : MSSQLServer EventID : 19011 Description : SuperSocket info : (SpnRegister) : Erreur 8344. Par conséquent. si vous exécutez le service SQL Server sous un compte de domaine ou un compte local. vous pouvez exécuter le service SQL Server sous : un compte LocalSystem. Retour au début 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.microsoft. vous devez créer un nom principal de service manuellement pour votre serveur SQL Server lorsque vous utilisez le protocole Kerberos. généralement. Parce qu'il se peut 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é). Cependant. le nom principal de service est généralement enregistré et Kerberos interagit correctement avec l'ordinateur qui exécute SQL Server. un compte d'utilisateur local à partir d'un autre ordinateur ou un compte d'utilisateur de domaine. Il faut également que la résolution de nom fonctionne correctement dans le domaine. Retour au début Création de noms principaux de service SQL Server Il s'agit de l'une des parties cruciales de l'interaction de Kerberos et de SQL Server. Si vous testez l'utilisation d'un compte d'administrateur de domaine en tant que compte du service SQL Server.com/kb/811889 Lorsque ping -AAdresse IP résout le nom DNS complet correct de l'ordinateur qui exécute SQL Server. reportez-vous au site Web de Microsoft (en anglais) à l'adresse suivante : DsWriteAccountSpn Explication simplifiée Si vous exécutez le service SQL Server sous le compte LocalSystem. . Lorsque l'ordinateur qui exécute SQL Server démarre. il essaie d'enregistrer son propre nom principal de service dans Active Directory en utilisant l'appel d'API DsWriteAccountSpn. l'ordinateur qui exécute SQL Server ne peut pas créer son propre nom principal de service.http://support. consultez la rubrique "Délégation de comptes de sécurité" de la documentation en ligne de SQL Server 2000. utilisez l'authentification Windows pour ouvrir une session sur SQL Server. cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft : 274438 Impossible d'utiliser les relations d'approbation Kerberos entre deux forêts dans Windows 2000 4. Pour plus d'informations. Pour plus d'informations. 3. Cependant. 2.exe) dans le Kit de ressources Windows 2000. Si votre domaine d'ouverture de session est le même que celui auquel appartient l'ordinateur qui exécute SQL Server. Vérifiez que la résolution de nom fonctionne correctement. Contactez votre administrateur de sécurité ou votre administrateur réseau pour vérifier que le compte de domaine ou le compte Windows dispose des droits appropriés. Cette condition est requise pour que l'interface SSPI fonctionne. Les comptes d'administrateur de domaine Windows 2000 peuvent utiliser l'utilitaire pour contrôler le nom principal de service qui est attribué à un service et à un compte. Utilisez l'utilitaire Manipuler les noms principaux de service pour les comptes (SetSPN. Utilisez l'option Le compte est approuvé pour la délégation dans Utilisateurs et ordinateurs Active Directory lorsque vous démarrez SQL Server. vérifiez la relation d'approbation entre les domaines.com/kb/811889 1. le nom principal de service est automatiquement configuré. WINS. HOSTS et les fichiers LMHOSTS.http://support.microsoft. Vérifiez si le domaine auquel appartient le serveur et le compte de domaine que vous utilisez pour vous connecter sont dans la même forêt ou non. Pour plus . puis vous devez ajouter un nom principal de service valide. vous devez exécuter SetSPN. 5. vous devez résoudre un problème survenu au niveau du compte de domaine ou du compte Windows.exe pour supprimer les noms principaux de service expirés. Les méthodes de résolution de nom peuvent inclure les fichiers DNS. Si votre domaine d'ouverture de session est différent du domaine de l'ordinateur qui exécute SQL Server. Si l'authentification échoue. visitez le site Web de Microsoft (en anglais) à l'adresse suivante : Security Account Delegation Pour plus d'informations sur les Kits de ressources Windows 2000. Pour cela. reportez-vous au site Web de Microsoft (en anglais) à l'adresse suivante : Windows 2000 Resource Kits 6. Si vous démarrez SQL Server alors que vous avez ouvert une session avec le compte LocalSystem. si vous utilisez un compte de domaine pour démarrer SQL Server ou dès que vous changez le compte qui est utilisé pour démarrer SQL Server. suivez les étapes fournies dans l'article suivant dans la Base de connaissances Microsoft : 239885 INF : Comment modifier des comptes de service sur un serveur virtuel SQL . Sur un cluster. cliquez sur le numéro cidessous pour afficher l'article correspondant dans la Base de connaissances Microsoft : 235529 Prise en charge de Kerberos sur les clusters de serveurs Windows 2000 2. 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. cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft : 169790 Résolution des problèmes de base liés au protocole TCP/IP 7. Par conséquent.microsoft.com/kb/811889 d'informations sur les problèmes de résolution de nom et leur dépannage. Pour plus d'informations sur la prise en charge de Kerberos sur les clusters de serveurs Windows 2000. cliquez sur le numéro cidessous pour afficher l'article correspondant dans la Base de connaissances Microsoft : 267588 Affichage du message d'erreur "Impossible de générer un contexte SSPI" lors de la connexion à SQL Server 2000 3. toute tentative d'utilisation de l'authentification SSPI sur une instance en cluster de SQL Server peut échouer.http://support. Vérifiez que le serveur exécute le Service Pack 1 Windows 2000. cliquez sur les numéros ci-dessous pour afficher les articles correspondants dans la Base de connaissances Microsoft : 291382 Forum Aux Questions à propos du DNS Windows 2000 224196 Restriction du trafic de réplication Active Directory sur un port spécifique Retour au début Vérification de l'environnement serveur Vérifiez certains paramètres de base sur l'ordinateur sur lequel SQL Server est installé : 1. si par exemple il utilise un nouveau mot de passe. Kerberos n'est pas pris 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. Pour plus d'informations sur la prise en charge de Kerberos sur les serveurs Windows 2000. Pour plus d'informations sur la résolution des problèmes d'accessibilité et de pare-feu avec Active Directory. http://support.com/kb/811889 4. Si les dates sont trop éloignées. vos certificats peuvent être considérés comme non valides.microsoft. 242356 L'utilisateur ne reçoit pas d'alerte lors de l'ouverture de session avec des informations d'identification mises en cache 3. SSPI utilise un fichier nommé Security. Si une autre application installe un fichier avec ce nom. 4. Si le système d'exploitation sur le client est Microsoft Windows 98.0 2. celui-ci peut être utilisé à la place du fichier SSPI. Vérifiez que les dates sur le client et le serveur sont correctes. 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'authentification cachées. Si vous avez ouvert une session sur le client avec des informations d'authentification cachées. . Vérifiez que le fournisseur de support de sécurité NTLM est correctement installé et activé sur le client. Pour plus d'informations.dll. vous devez installer le composant Client pour les réseaux Microsoft sur le client. cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft : 269541 INF : L'absence de la clé du Registre du fournisseur de support de sécurité Windows NTLM génère le message d'erreur "Impossible de générer un contexte SSPI" lors de la connexion à SQL Server 7. Vérifiez si le compte que vous utilisez pour démarrer SQL Server dispose des droits appropriés. Si vous utilisez un compte qui n'est pas membre du groupe Administrateurs locaux. Déterminez si vous utilisez des informations d'authentification cachées.Le pilote MS ODBC SQL Server ne peut pas initialiser le package SSPI 5. 253577 PROBLÈME : Erreur : 80004005 . consultez la rubrique "Configuration des comptes de services Windows" de la documentation en ligne de SQL Server pour vous procurer une liste détaillée des droits dont ce compte doit disposer : Setting up Windows Services Accounts(site en anglais) Retour au début Vérifier l'environnement client Vérifiez les éléments suivants sur le client : 1. Générez un rapport sqldiag à partir de SQL Server. 3. vous pouvez activer un ou plusieurs protocoles avec un protocole en tête de liste lorsque vous vous connectez à SQL Server.exe MDAC pour configurer la connectivité : 1.com/default. consultez la rubrique "Utilitaire sqldiag" de la documentation en ligne de SQL Server. Lorsque vous effectuez cette tâche. Parce que SSPI s'applique uniquement au protocole TCP/IP. Sur les dernières versions de MDAC. Vous pouvez utiliser l'utilitaire réseau du client Cliconfg. Vous pouvez vérifier cela en supprimant le serveur d'alias pour voir si le comportement change.CNTACTMS 1. 2.[LN]. vous pouvez utiliser un protocole différent. ajoutez l'alias pour le serveur auquel vous vous connectez. la façon dont les protocoles sont définis varie selon la version de MDAC. ainsi que des informations relatives aux frais de support technique. pour éviter cette erreur. 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.microsoft. Avec les versions antérieures de MDAC. vérifiez les paramètres pour savoir comment cet ordinateur est configuré pour se connecter à SQL Server.com/kb/811889 267550 BOGUE : "Échec d'assertion" lors de la connexion à SQL Server via le protocole TCP/IP Retour au début Vérification de l'utilitaire réseau du client L'utilitaire réseau du client est fourni avec Microsoft Data Access Components (MDAC) et il est utilisé pour configurer la connectivité sur les ordinateurs qui exécutent SQL Server.aspx?scid=fh. vous pouvez sélectionner un protocole par "défaut". Sous l'onglet Général. Pour plus d'informations. vous définissez également le protocole explicitement et vous définissez éventuellement l'adresse IP et le port. rassemblez les informations suivantes et ouvrez un cas du Support technique Microsoft : Pour obtenir une liste complète des numéros de téléphone des services de Support technique Microsoft. tel que les Canaux nommés.microsoft. . Retour au début Informations à rassembler pour ouvrir un cas du Support technique Microsoft Si vous ne trouvez pas la cause du problème en utilisant les étapes de résolution de cet article. Si le serveur d'alias n'est pas défini sur l'utilitaire réseau du client. reportez-vous au site Web de Microsoft à l'adresse suivante : http://support.http://support. 4.txt dans le répertoire dans lequel vous exécutez la commande. 11.txt Cette commande génère un fichier nommé Started. Sur le noeud qui ne peut pas se connecter à SQL Server. SQLServerAgent. Retour au début Comment faire pour configurer manuellement un nom principal de service pour SQL Server . 3. Dans un environnement en cluster. tapez la commande suivante à partir de l'invite de commandes : net start > started. 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. vérifiez l'existence de la clé de Registre suivante pour chaque noeud de serveur du cluster : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTLMSsp 7. 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. Voyez si vous pouvez connecter votre ordinateur qui exécute SQL Server à partir du même client en utilisant l'authentification SQL Server.http://support. MSSearch). procurez-vous la valeur de la clé de Registre suivante pour chaque noeud du cluster : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\LMCompatibilityLevel 6. 12. Voyez si vous pouvez vous connecter en utilisant le protocole Canaux nommés.com/kb/811889 2. 10. 9.microsoft. Faites une capture d'écran de l'erreur sur le client. Dans un environnement en cluster. 8. Le professionnel du support doit savoir si SQL Server est configuré pour l'authentification mixte ou pour l'authentification Windows uniquement. 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. Enregistrez le nom des comptes d'utilisateur que vous utilisez pour démarrer chacun des services SQL Server (MSSQLServer. Windows utilise la délégation NTLM. L'authentification Kerberos est uniquement disponible sur les ordinateurs Windows 2000 sur lesquels Kerberos est activé et qui utilisent Active Directory. la bibliothèque réseau du client SQL Server utilise l'API SSPI pour effectuer la délégation de sécurité. vous pouvez éviter le problème en configurant vos clients pour qu'ils se connectent à partir d'un protocole autre que TCP/IP. Le client réseau SQL Server (Dbnetlib. Le mot clé SYSTEM peut entraîner des conflits avec le Centre de distribution de clés. MSSearch). Dans ce contexte. cliquez sur les numéros ci-dessous pour afficher les articles correspondants dans la Base de connaissances Microsoft : 266080 Réponses aux questions fréquentes concernant Kerberos 231789 Processus d'ouverture de session locale pour Windows 2000 304161 232179 230476 262177 277658 L'authentification mutuelle SSPI est indiquée côté client mais pas côté serveur Administration Kerberos dans Windows 2000 Description d'erreurs courantes liées à Kerberos dans Windows 2000 COMMENT FAIRE : Activer l'enregistrement d'événements Kerberos PROBLÈME : Échec de Setspn si le nom de domaine diffère du nom NetBIOS où le nom principal de service SQL Server est enregistré .microsoft. Remarque Vérifiez que vous n'utilisez pas un compte nommé "SYSTEM" pour démarrer les services SQL Server (MSSQLServer. SQLServerAgent. En d'autres termes.com/kb/811889 L'interface SSPI est l'interface de sécurité de Microsoft Windows NT qui est utilisée pour l'authentification Kerberos et prend en charge le schéma d'authentification du fournisseur de support de sécurité NTLM. correctement configuré. 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. Sinon.http://support. SSPI est uniquement utilisée pour les connexions TCP/IP qui sont établies en utilisant l'authentification Windows. Par conséquent. Retour au début Références Pour plus d'informations sur le fonctionnement de la sécurité Kerberos et SSPI.) SSPI n'est pas utilisée par les Canaux nommés ni par les connexions multiprotocoles. L'authentification survient au niveau du système d'exploitation lorsque vous ouvrez une session sur un domaine Windows. négocier signifie qu'il faut essayer l'authentification Kerberos ou NTLM sur les ordinateurs Windows. L'authentification Windows est également appelée Connexions approuvées ou Sécurité intégrée.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. Windows utilise la délégation Kerberos si l'ordinateur de destination qui exécute SQL Server a un nom principal de service associé. microsoft. reportez-vous au site Web de Microsoft à l'adresse suivante : http://msdn.com/kb/811889 244474 Obligation pour Kerberos d'utiliser TCP au lieu de UDP dans Windows 2000 326985 COMMENT FAIRE : Résoudre les problèmes liés à Kerberos dans les services IIS Pour consulter un livre blanc (en anglais) relatif à la sécurité Microsoft SQL Server 2000.asp Retour au début .com/library/default.http://support.asp?url=/library/en-us/dnsql2k/html/sql_security2000.microsoft.
Report "comment resoudre impossible de générer le contexte SSPI"