c


 

   

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 :

au ous vous connectez à un serveur SQL Server.

au ous utilisez la délégation Kerberos.

au La délégation Kerberos ne délègue pas la sécurité des sockets TCP/IP.

Retour au début

2
 


 
   
 




   

 

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 :

au ºTLM sur Canaux nommés (sans utiliser l'interface SSPI [Security Support Provider

Interface])

au ºTLM sur les sockets TCP/IP avec SSPI

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

r 
  
r
   


 

Kerberos utilise un identificateur appelé "ºom 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 ressource

de serveur réseau. ous pouvez avoir un nom principal de service pour un service Web, pour un service

SQL ou pour un service SMTP. ous pouvez également avoir plusieurs instances de services Web sur le


c


 
   

même ordinateur physique ayant un nom principal de service unique.

Un nom principal de service pour SQL Server est composé des éléments suivants :

au ServiceClass : Identifie la classe générale de service. Il s'agit toujours de MSSQLSvc pour

SQL Server.

au Î
e : Il s'agit du nom de domaine complet DºS de l'ordinateur qui exécute SQL Server.

au r r
: Il s'agit du numéro de port sur lequel le service écoute.

Par exemple, un nom principal de service typique pour un ordinateur qui exécute SQL Server est :

Ñ
 
 
  
 

 


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 DºS 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  
 et   . 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, le pilote SQL Server essaie de résoudre

le nom DºS 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 DºS complet de l'ordinateur qui exécute SQL

Server, le service DºS correspondant est utilisé pour former le nom principal de service 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 DºS 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.

Par exemple, les noms principaux de service incorrects que le pilote SQL Server côté client peut former

en tant que nom DºS complet résolu sont :

au MSSQLSvc/SQLSERER1:1433

au MSSQLSvc/123.123.123.123:1433

au MSSQLSvc/SQLSERER1.antartica.corp.mycompany.com:1433

au MSSQLSvc/SQLSERER1.dns.northamerica.corp.mycompany.com:1433

Lorsque le pilote SQL Server forme un nom principal de service incorrect, l'authentification peut

continuer à fonctionner car l'interface SSPI essaie de chercher dans Active Directory et ne trouve pas le

nom principal de service. Si le nom principal de service est introuvable, l'authentification Kerberos n'est

pas effectuée. À ce moment-là, l'interface SSPI bascule en mode d'authentification ºTLM.

L'authentification ºTLM (qui ne repose pas sur le nom principal de service) réussit tant que le client

utilise l'adresse IP pour contacter le serveur.


c


 
   

Le facteur clé de la réussite de l'authentification Kerberos est la fonctionnalité DºS correcte sur le

réseau. ous pouvez vérifier cette fonctionnalité sur le client et le serveur en utilisant l'utilitaire de ligne

de commande r . 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) :

 sqlserver1

Pour savoir si l'utilitaire de ligne de commande   résout le nom DºS complet de SQLServer1,

exécutez la commande suivante :

 
D resse Ir

Par exemple :

2
  


   


 !"#$%

 
&$  


"#'( )#**' +
&$  


"#'( )#**' +
&$  


"#'( )#**' +
&$  


"#'( )#**' +
 
###$  



,# '-%'-#').)/&##0-
1 2 3% #&&4#%#
Ñ3')#-Ñ23')#-1 ')#

24 



 

 
  
 

 


 !"#
$%
 
&$  


"#'( )#**' +
&$  


"#'( )#**' +
&$  


"#'( )#**' +
&$  


"#'( )#**' +
###$  



,# '-%'-#').)/&##0-
1 2 3% #&&4#%#
Ñ3')#-Ñ23')#-1 ')#

2
  


c


 
   

Lorsque  
D resse Ir résout le nom DºS complet correct de l'ordinateur qui exécute SQL Server, la

résolution côté client est également réussie.

Retour au début

2  



   

 
!


Il s'agit de l'une des parties cruciales de l'interaction de 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

à partir d'un autre ordinateur ou un compte d'utilisateur de domaine. 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 "#  . Si l'appel échoue, l'avertissement suivant est enregistré

dans l'Observateur d'événements :

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

Pour plus d'informations sur la fonction "#  , reportez-vous au site Web de Microsoft

(en anglais) à l'adresse suivante :

DsWriteAccountSpn

$    

  

Si vous exécutez le service SQL Server sous le compte LocalSystem, le nom principal de service est

généralement enregistré et Kerberos interagit correctement avec l'ordinateur qui exécute SQL Server.

Cependant, si vous exécutez le service SQL Server sous un compte de domaine ou un compte local,

généralement, la tentative de création du nom principal de service peut échouer. Lorsque la création du

nom principal de service échoue, cela signifie qu'aucun nom principal de service 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 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. 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é), l'ordinateur qui exécute SQL Server ne peut pas créer son propre nom principal de service. Par

conséquent, vous devez créer un nom principal de service manuellement pour votre serveur SQL Server

lorsque vous utilisez le protocole Kerberos.

Retour au début

%    




érifiez que le domaine sur lequel vous ouvrez une session peut communiquer avec le domaine auquel

appartient l'ordinateur qui exécute SQL Server. Il faut également que la résolution de nom fonctionne

correctement dans le domaine.


c


 
   

1.u Si votre domaine d'ouverture de session est le même que celui auquel appartient

l'ordinateur qui exécute SQL Server, utilisez l'authentification Windows pour ouvrir une

session sur SQL Server. Si l'authentification échoue, vous devez résoudre un problème

survenu au niveau du compte de domaine ou du compte Windows. 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.

2.u 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.u é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. Cette condition est requise pour que

l'interface SSPI fonctionne. Pour plus d'informations, 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.u Utilisez l'option 




 
 

   dans Utilisateurs et

ordinateurs Active Directory lorsque vous démarrez SQL Server.

5.u Utilisez l'utilitaire Manipuler les noms principaux de service pour les comptes (SetSPº.exe)

dans le Kit de ressources Windows 2000. 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. Si vous démarrez SQL Server alors que vous avez

ouvert une session avec le compte LocalSystem, le nom principal de service est

automatiquement configuré. Cependant, 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, vous devez exécuter SetSPº.exe pour supprimer les noms principaux de service

expirés, puis vous devez ajouter un nom principal de service valide. Pour plus

d'informations, consultez la rubrique "Délégation de comptes de sécurité" de la

documentation en ligne de SQL Server 2000. Pour cela, 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, reportez-vous au site

Web de Microsoft (en anglais) à l'adresse suivante :

Windows 2000 Resource Kits

6.u érifiez que la résolution de nom fonctionne correctement. Les méthodes de résolution de

nom peuvent inclure les fichiers DºS, WIºS, HOSTS et les fichiers LMHOSTS. Pour plus


c


 
   

d'informations sur les problèmes de résolution de nom et leur dépannage, 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.u 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 Forum Aux Questions à propos du DºS Windows 2000

224196 Restriction du trafic de réplication Active Directory sur un port spécifique

Retour au début

%    

  



érifiez certains paramètres de base sur l'ordinateur sur lequel SQL Server est installé :

1.u 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. 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 sur la prise en

charge de Kerberos sur les clusters de serveurs Windows 2000, cliquez sur le numéro ci-

dessous 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.u érifiez que le serveur exécute le Service Pack 1 Windows 2000. Pour plus d'informations

sur la prise en charge de 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 Affichage du message d'erreur "Impossible de générer un contexte SSPI" lors de la

connexion à SQL Server 2000

3.u 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 dans la Base de connaissances

Microsoft :

239885 IºF : Comment modifier des comptes de service sur un serveur virtuel SQL


c


 
   

4.u é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, 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

%  
  

 

érifiez les éléments suivants sur le client :

1.u érifiez que le fournisseur de support de sécurité ºTLM 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 IºF : L'absence de la clé du Registre du fournisseur de support de sécurité Windows

ºTLM génère le message d'erreur "Impossible de générer un contexte SSPI" lors de la

connexion à SQL Server 7.0

2.u Déterminez si vous utilisez des informations d'authentification cachées. Si vous avez ouvert

une session sur le client avec des informations d'authentification cachées, 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.

242356 L'utilisateur ne reçoit pas d'alerte lors de l'ouverture de session avec des

informations d'identification mises en cache

3.u é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.u 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.

253577 PROBLÈME : Erreur : 80004005 - Le pilote MS ODBC SQL Server ne peut pas

initialiser le package SSPI

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


c


 
   

267550 BOGUE : "Échec d'assertion" lors de la connexion à SQL Server via le protocole

TCP/IP

Retour au début

%    

   
 

 

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. ous pouvez utiliser

l'utilitaire réseau du client Cliconfg.exe MDAC pour configurer la connectivité :

1.u Sous l'onglet w , 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 un ou plusieurs

protocoles 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.u Consultez l'onglet   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. ous pouvez vérifier cela en supprimant le serveur d'alias pour voir si le

comportement change.

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

Retour au début

 
 
&
 

 
 

 

 
 
   

Si vous ne trouvez pas la cause du problème en utilisant les étapes de résolution de cet article,

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,

ainsi que des informations relatives aux frais de support technique, reportez-vous au site Web de

Microsoft à l'adresse suivante :

http://support.microsoft.com/default.aspx?scid=fh;[Lº];CºTACTMS

1.u Générez un rapport sqldiag à partir de SQL Server. Pour plus d'informations, consultez la

rubrique "Utilitaire sqldiag" de la documentation en ligne de SQL Server.


c


 
   

2.u Faites une capture d'écran de l'erreur sur le client.

3.u Sur le noeud qui ne peut pas se connecter à SQL Server, tapez la commande suivante à

partir de l'invite de commandes :


 
'
 ( 

Cette commande génère un fichier nommé Started.txt dans le répertoire dans lequel vous

exécutez la commande.

4.u Enregistrez les valeurs pour la clé de Registre sous la clé de Registre suivante sur

l'ordinateur client :

HKEY_LOCAL_MACHIºE\SOFTWARE\MICROSOFT\MSSQLSERER\CLIEºT\COººECTTO

5.u Dans un environnement en cluster, procurez-vous la valeur de la clé de Registre suivante

pour chaque noeud du cluster :

HKEY_LOCAL_MACHIºE\SYSTEM\CurrentControlSet\Control\LSA\LMCompatibilityLevel

6.u Dans un environnement en cluster, vérifiez l'existence de la clé de Registre suivante pour

chaque noeud de serveur du cluster :

HKEY_LOCAL_MACHIºE\SYSTEM\CurrentControlSet\Services\ºTLMSsp

7.u Capturez les résultats si vous vous connectez à SQL Server en utilisant un nom UºC (ou le

nom de réseau SQL sur un cluster) à partir du client.

8.u 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.u Enregistrez le nom des comptes d'utilisateur que vous utilisez pour démarrer chacun des

services SQL Server (MSSQLServer, SQLServerAgent, MSSearch).

10.u Le professionnel du support doit savoir si SQL Server est configuré pour l'authentification

mixte ou pour l'authentification Windows uniquement.

11.u oyez si vous pouvez connecter votre ordinateur qui exécute SQL Server à partir du même

client en utilisant l'authentification SQL Server.

12.u oyez si vous pouvez vous connecter en utilisant le protocole Canaux nommés.

Retour au début

2


 
 
  






   

 
 

!



c


 
   

L'interface SSPI est l'interface de sécurité de Microsoft Windows ºT qui est utilisée pour l'authentification

Kerberos et prend en charge le schéma d'authentification du fournisseur de support de sécurité ºTLM.

L'authentification survient au niveau du système d'exploitation lorsque vous ouvrez une session sur un

domaine Windows. L'authentification Kerberos est uniquement disponible sur les ordinateurs

Windows 2000 sur lesquels Kerberos est activé et qui utilisent Active Directory.

SSPI est uniquement utilisée pour les connexions TCP/IP qui sont établies en utilisant l'authentification

Windows. L'authentification Windows est également appelée Connexions approuvées ou Sécurité

intégrée.) 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 vos clients pour 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  2 )  et passe à "négocier" pour le paramètre szrackage. 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 ºTLM 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 nom principal de service associé, correctement configuré. Sinon, Windows utilise la

délégation ºTLM.

G
 é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.

Retour au début

Références

Pour plus d'informations sur le fonctionnement de la sécurité Kerberos et SSPI, 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 L'authentification mutuelle SSPI est indiquée côté client mais pas côté serveur

232179 Administration Kerberos dans Windows 2000

230476 Description d'erreurs courantes liées à Kerberos dans Windows 2000

262177 COMMEºT FAIRE : Activer l'enregistrement d'événements Kerberos

277658 PROBLÈME : Échec de Setspn si le nom de domaine diffère du nom ºetBIOS où le nom principal

de service SQL Server est enregistré


c


 
   

244474 Obligation pour Kerberos d'utiliser TCP au lieu de UDP dans Windows 2000

326985 COMMEºT 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, reportez-vous

au site Web de Microsoft à l'adresse suivante :

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsql2k/html/sql_security2000.asp

Retour au début