Résolution des erreurs de connectivité à SQL Server

S’applique à : Microsoft SQL Server

À quoi sert ce guide ?
La majorité des problèmes de connectivité à SQL Server peuvent être résolus en suivant une simple liste de vérification et en suivant quelques étapes. Ce guide détaillé vous propose la même chose pour différentes erreurs de connexion rencontrées lors de la connexion à SQL Server.

À qui s’adresse-t-il ?
Toute personne qui travaille avec SQL Server et qui rencontre des problèmes de connexion.

Comment cela fonctionne-t-il ?
Avant de vous lancer dans la résolution des erreurs de connectivité, bien que cela ne soit pas obligatoire, nous vous conseillons de collecter les informations requises et de suivre une petite liste de vérification. Bien que cela puisse prendre quelques minutes, ces étapes permettent d’arriver plus rapidement à une résolution du problème.

Durée estimée
Variable selon les cas, mais entre 15 minutes et 2 heures.

Configuration requise

Pour utiliser cet utilitaire de résolution des problèmes de façon efficace, rassemblez les informations suivantes.
  1. Le texte complet du message d’erreur, ainsi que les codes d’erreur et si l’erreur est intermittente (se produit parfois) ou constante (se produit systématiquement).
  2. Journaux d'erreurs du server SQL à partir desquels vous pouvez noter ce qui suit :
    1. Le nom de domaine complet (FQDN) de la machine SQL Server ou, dans le cas des installations en cluster, le nom de domaine complet virtuel. Si vous utilisez une instance nommée, notez le nom de l’instance. (Remarque : Vous pouvez rechercher : la chaîne « Server name is » pour retrouver cette information dans le journal des erreurs).
    2. Bibliothèques réseau et ports sur lesquels l’instance SQL est en écoute
      Messages d'exemple :
      Canaux nommés : Le fournisseur de connexion locale du serveur est prêt à accepter la connexion sur [ \\.\pipe\sql\query ].
      TCP/IP et numéro de port : Le serveur est en écoute sur [ ::1 1433].
  3. Les journaux des événements du système et de l’application SQL Server et du système client.
  4. Si les connexions échouent à partir d’une application, la chaîne de connexion de cette application. Elle se trouve en général dans les fichiers Web.config des applications ASP.net.

Liste de vérification

  • Assurez-vous que le serveur SQL est démarré et que le message suivant s'affiche dans le journal des erreurs du serveur SQL :
    Le serveur SQL est désormais prêt pour les connexions client. Ceci est un message d’information, aucune action n’est requise de la part de l’utilisateur.
  • Vérifiez la connectivité sur l’adresse IP et contrôlez toutes les anomalies :
    ping –a <machine SQL Server>, ping –a <Adresse IP SQL Server>. Si vous remarquez des problèmes, contactez votre administrateur réseau pour les résoudre. 
  • Vérifiez si SQL écoute les protocoles appropriés en examinant le journal des erreurs.
  • Vérifiez si vous pouvez vous connecter à SQL Server avec un fichier UDL. Si cette opération fonctionne, le problème vient peut-être de la chaîne de connexion. Pour obtenir des instructions sur la procédure de test UDL, sélectionnez l’option Connexion à SQL Server avec un fichier UDL plus bas.
  • Vérifiez si vous pouvez vous connecter à SQL Server à partir d’autres systèmes clients et avec différentes informations de connexion utilisateur. Si cette procédure fonctionne, le problème est peut-être lié au client ou aux informations de connexion. Recherchez d’autres indices dans les journaux d’événements Windows sur le client qui pose problème. Vérifiez également si les pilotes réseau sont à jour.
  • Si vous rencontrez des problèmes à la connexion, assurez-vous que l’utilisateur dispose d’une connexion au niveau du serveur et dispose aussi des autorisations appropriées pour se connecter à la base de données à laquelle il tente de se connecter.

Maintenant, vous pouvez choisir les problèmes que vous avez rencontrés pour continuer. 

Configuration requise

Pour utiliser cet utilitaire de résolution des problèmes de façon efficace, rassemblez les informations suivantes.
  1. Le texte complet du message d’erreur, ainsi que les codes d’erreur et si l’erreur est intermittente (se produit parfois) ou constante (se produit systématiquement).
  2. Journaux d'erreurs du server SQL à partir desquels vous pouvez noter ce qui suit :
    1. Le nom de domaine complet (FQDN) de la machine SQL Server ou, dans le cas des installations en cluster, le nom de domaine complet virtuel. Si vous utilisez une instance nommée, notez le nom de l’instance. (Remarque : Vous pouvez rechercher : la chaîne « Server name is » pour retrouver cette information dans le journal des erreurs).
    2. Bibliothèques réseau et ports sur lesquels l’instance SQL est en écoute
      Messages d'exemple :
      Canaux nommés : Le fournisseur de connexion locale du serveur est prêt à accepter la connexion sur [ \\.\pipe\sql\query ].
      TCP/IP et numéro de port : Le serveur est en écoute sur [ ::1 1433].
  3. Les journaux des événements du système et de l’application SQL Server et du système client.
  4. Si les connexions échouent à partir d’une application, la chaîne de connexion de cette application. Elle se trouve en général dans les fichiers Web.config des applications ASP.net.

Liste de vérification

  • Assurez-vous que le serveur SQL est démarré et que le message suivant s'affiche dans le journal des erreurs du serveur SQL :
    Le serveur SQL est désormais prêt pour les connexions client. Ceci est un message d’information, aucune action n’est requise de la part de l’utilisateur.
  • Vérifiez la connectivité sur l’adresse IP et contrôlez toutes les anomalies :
    ping –a <machine SQL Server>, ping –a <Adresse IP SQL Server>. Si vous remarquez des problèmes, contactez votre administrateur réseau pour les résoudre. 
  • Vérifiez si SQL écoute les protocoles appropriés en examinant le journal des erreurs.
  • Vérifiez si vous pouvez vous connecter à SQL Server avec un fichier UDL. Si cette opération fonctionne, le problème vient peut-être de la chaîne de connexion. Pour obtenir des instructions sur la procédure de test UDL, sélectionnez l’option Connexion à SQL Server avec un fichier UDL plus bas.
  • Vérifiez si vous pouvez vous connecter à SQL Server à partir d’autres systèmes clients et avec différentes informations de connexion utilisateur. Si cette procédure fonctionne, le problème est peut-être lié au client ou aux informations de connexion. Recherchez d’autres indices dans les journaux d’événements Windows sur le client qui pose problème. Vérifiez également si les pilotes réseau sont à jour.
  • Si vous rencontrez des problèmes à la connexion, assurez-vous que l’utilisateur dispose d’une connexion au niveau du serveur et dispose aussi des autorisations appropriées pour se connecter à la base de données à laquelle il tente de se connecter.

Maintenant, vous pouvez choisir les problèmes que vous avez rencontrés pour continuer. 

L’erreur « Une erreur liée au réseau ou spécifique à l’instance s’est produite lors de l’établissement d’une connexion à SQL Server » représente un ou plusieurs des messages d’erreur suivants :

  • Une erreur liée au réseau ou spécifique à l’instance s’est produite lors de l’établissement d’une connexion à SQL Server. Le serveur est introuvable ou n'est pas accessible. Vérifiez que le nom d'instance est correct et que SQL Server est configuré de manière à autoriser les connexions à distance. (fournisseur : Interfaces réseau SQL, erreur : 26 - Erreur lors de la localisation du serveur/de l’instance spécifiés
  • Erreur de liaison de données du client natif du serveur SQL
    ---------------------------
    [Microsoft SQL Server Native Client 10.0] : Délai de connexion expiré
    [Microsoft SQL Server Native Client 10.0] : Une erreur liée au réseau ou spécifique à l’instance s’est produite lors de l’établissement d’une connexion à SQL Server. Le serveur est introuvable ou n’est pas accessible. Vérifiez que le nom d’instance est correct et que SQL Server est configuré de manière à autoriser les connexions à distance. Pour plus d’informations, reportez-vous à la documentation en ligne de SQL Server.
    [Microsoft SQL Server Native Client 10.0] : Interfaces réseau SQL Server : Erreur lors de la localisation du serveur/de l’instance spécifiés [xFFFFFFFF].
  • Une erreur liée au réseau ou spécifique à l’instance s’est produite lors de l’établissement d’une connexion à SQL Server. Le serveur est introuvable ou n'est pas accessible. Vérifiez que le nom d'instance est correct et que SQL Server est configuré de manière à autoriser les connexions à distance. (fournisseur : fournisseur TCP, erreur : 0 - Une tentative de connexion a échoué, car le participant connecté n’a pas répondu convenablement au-delà d’une certaine durée ou bien la connexion établie a échoué, car l’hôte connecté n’a pas répondu.) (Microsoft SQL Server, Erreur : 10060)
  • Une erreur liée au réseau ou spécifique à l’instance s’est produite lors de l’établissement d’une connexion à SQL Server. Le serveur est introuvable ou n'est pas accessible. Vérifiez que le nom d'instance est correct et que SQL Server est configuré de manière à autoriser les connexions à distance. (fournisseur : Fournisseur de canaux nommés, erreur : 40 - Impossible d’ouvrir une connexion au serveur SQL) (serveur SQL Microsoft, Erreur : 53)
    Le chemin réseau n’a pas été trouvé.
  • [Microsoft][SQL Server Native Client 11.0]Fournisseur TCP : Aucune connexion n’a pu être établie, car l’ordinateur cible la refuse expressément.
    [Microsoft][SQL Server Native Client 11.0]Expiration du délai de connexion
    [Microsoft][SQL Server Native Client 11.0]Une erreur liée au réseau ou spécifique à l’instance s’est produite lors de l’établissement d’une connexion à SQL Server. Le serveur est introuvable ou n’est pas accessible. Vérifiez que le nom d’instance est correct et que SQL Server est configuré de manière à autoriser les connexions à distance. 
    Pour plus d’informations, reportez-vous à la documentation en ligne de SQL Server.  

L’erreur peut être plus spécifique. Sélectionnez l’erreur que vous voyez.

L’erreur « Délai expiré » représente un ou plusieurs des messages d’erreur suivants :

  • Expiration du délai d’attente. Le délai d'expiration s'est produit avant la fin de l'opération ou le serveur ne répond pas.
  • System.Data.SqlClient.SqlException (0x80131904) : Le délai d’attente de la connexion a expiré. Le délai d'attente s'est écoulé lors de la tentative de consommation de l'accusé réception de la poignée de main de préconnexion. Cela peut être dû à un échec de la poignée de main de préconnexion ou au fait que le serveur n'a pas pu répondre dans les temps. Le temps écoulé lors de la tentative de connexion à ce serveur était de - [Préconnexion] initialisation = 23 ; poignée de main = 14979 ; ---> System.ComponentModel.Win32Exception (0x80004005) : Dépassement du délai d’attente
  • System.Data.SqlClient.SqlException (0x80131904) : Expiration du délai d’attente. Le délai d'expiration s'est produit avant la fin de l'opération ou le serveur ne répond pas. ---> System.ComponentModel.Win32Exception (0x80004005) : Dépassement du délai d’attente
  • Le délai d’attente de la connexion a expiré. Le délai d'attente s'est écoulé lors de la tentative de consommation de l'accusé réception de la poignée de main de préconnexion. Cela peut être dû à un échec de la poignée de main de préconnexion ou au fait que le serveur n'a pas pu répondre dans les temps. Le temps écoulé lors de la tentative de connexion à ce serveur était de - [Préconnexion] initialisation = 21036 ; poignée de main = 0 ; (Microsoft SQL Server, Erreur : -2)

Vous risquez de voir une erreur comme celle-ci :[Microsoft][SQL Server Native Client 11.0]Fournisseur TCP : Aucune connexion n’a pu être établie, car l’ordinateur cible la refuse expressément. 

[Microsoft][SQL Server Native Client 11.0]Expiration du délai de connexion. 
[Microsoft][SQL Server Native Client 11.0]Une erreur liée au réseau ou spécifique à l’instance s’est produite lors de l’établissement d’une connexion à SQL Server. Le serveur est introuvable ou n’est pas accessible. Vérifiez que le nom d’instance est correct et que SQL Server est configuré de manière à autoriser les connexions à distance. Pour plus d’informations, reportez-vous à la documentation en ligne de SQL Server.

Examinez chacune des causes suivantes applicables à votre instance, et essayez la résolution correspondante.

Cause 1 : Le nom de serveur spécifié dans la chaîne de connexion ou la boîte de dialogue du nom de serveur est incorrect.

Si ceci ne résout pas le problème, continuez avec les autres causes dans cette section.
 

Cause 2 : Alias incorrect sur la machine cliente

Les alias sont en général utilisés dans les environnements dans lesquels vous devez vous connecter à SQL Server avec un autre nom ou lorsque des problèmes de résolution de noms se produisent sur le réseau. Un alias incorrect sur la machine cliente peut rediriger les connexions de vos applications vers le mauvais serveur et donc provoquer un échec de la connexion.
 
Si ceci ne résout pas le problème, continuez avec les autres causes dans cette section lorsqu’elles s’appliquent à votre type d’instance (instance par défaut ou instance nommée)

Cause 3 (Instance par défaut) : un ou plusieurs pare-feu entre le client et le serveur bloquent le port sur lequel l’instance SQL Server écoute

Instance par défaut : Les instances par défaut utilisent en général le port 1433. Certaines installations utilisent également un port non standard (autre que 1433) pour l’exécution des instances SQL. Le pare-feu bloque peut-être un de ces ports.

Cause 4 (Instance nommée) : SQL Browser n’est pas démarré

Les applications clientes qui se connectent à une instance nommée de SQL Server utilisent le service SQL Browser sur le système sur lequel SQL est exécuté pour énumérer le port sur lequel SQL écoute. Si le service SQL Browser n’est pas démarré, les connexions échouent. 
Si SQL Browser est déjà lancé, vérifiez si le port UDP 1434 est bloqué par le pare-feu, en suivant les instructions du paragraphe ci-dessous.

Cause 5 (Instance nommée) : Le port UDP 1434 utilisé par SQL Browser est bloqué sur le réseau

Si votre instance SQL est une instance nommée, elle a peut-être été configurée pour utiliser des ports dynamiques ou un port statique. Dans un cas comme dans l’autre, les bibliothèques réseau sous-jacentes interrogent le service SQL Browser qui s’exécute sur votre machine SQL Server via le port UDP 1434 pour énumérer le numéro de port de l’instance nommée. Si un pare-feu entre le client et le serveur bloque ce port UDP, la bibliothèque de client ne peut pas déterminer le port (nécessaire pour la connexion) et la connexion échoue. 
Votre problème est-il résolu ?
 
 
 
Vous trouverez ci-dessous quelques captures d’écran présentant la configuration requise du pare-feu Windows pour que les connexions de l’instance par défaut et de l’instance nommée réussissent.
  • Une instance par défaut de SQL Server écoute sur le port par défaut 1433 sur un serveur Windows 2012 R2 : Dans ce cas, vous devez vous assurer qu’une exception est ajoutée au port TCP 1433 dans le pare-feu Windows.
    1. Ouvrez le pare-feu Windows sur le système qui héberge l’instance par défaut du serveur SQL, puis cliquez sur Nouvelle règle dans la section Règles de trafic entrant.
      Inound rules
       
    2. Sélectionnez l’option Port, puis cliquez sur Suivant.
      InboundRulePort
       
    3. Dans l’écran suivant :
      • Sélectionnez le protocole TCP.
      • Sélectionnez Ports locaux spécifiques, puis indiquez la valeur 1433 et cliquez sur Suivant.
        TCP1433
         
    4. Dans l’écran suivant, sélectionnez Autoriser la connexion, puis cliquez sur Suivant.
      
      AllowConnection
       
    5. Dans l’écran suivant, sélectionnez l’option qui convient le mieux à votre environnement, puis cliquez sur Suivant.
      NewInboundRule
       
    6. Dans l’écran suivant, donnez un nom à votre règle et ajoutez une description claire pour référence, puis cliquez sur Terminer.
       
      NewInboundRuleName
       

    7. Une fois l’opération effectuée, la règle doit avoir été créée et activée par défaut.
      EnableInboundRule
       
  • Ajout d’une exception pour le port UDP 1434 pour activer les connexions à une instance nommée de SQL Server
    1. Ouvrez le pare-feu Windows sur le système qui héberge l’instance par défaut de SQL Server, puis cliquez sur Nouvelle règle dans la section Règles de trafic entrant.
      Inound rules
       
    2. Sélectionnez l’option Port, puis cliquez sur Suivant.
      InboundRulePort
       
    3.  Dans l’écran suivant :
      • Sélectionnez le protocole UDP.
      • Sélectionnez Ports locaux spécifiques, puis indiquez la valeur 1434 et cliquez sur Suivant.
        NewInboundUDP
         
    4. Dans l’écran suivant, sélectionnez Autoriser la connexion, puis cliquez sur Suivant.
      AllowConnection
       
    5. Dans l’écran suivant, sélectionnez l’option qui convient le mieux à votre environnement, puis cliquez sur Suivant.
      NewInboundRule
       
    6. Dans l’écran suivant, donnez un nom à la règle et ajoutez une description claire pour référence ultérieure, puis cliquez sur Terminer.
      NewInboundName2
       
    7. Une fois l’opération effectuée, la règle doit avoir été créée et activée par défaut.
      EnableInboundRule2
       
Votre problème est-il résolu ?

  1. Dans le Gestionnaire de configuration SQL Server, dans le volet de la console, développez Configuration du réseau SQL Server, développez Protocoles pour <nom_instance>, puis double-cliquez sur TCP/IP.
  2. Dans la boîte de dialogue Propriétés TCP/IP, dans l’onglet Adresses IP, plusieurs adresses IP apparaissent sous la forme IP1, IP2, jusqu’à IPAll. Une de ces adresses correspond à l’adresse IP de la carte de bouclage, 127.0.0.1. D’autres adresses IP apparaissent pour chaque adresse IP sur l’ordinateur. (Vous verrez probablement des adresses IP version 4 et des adresses IP version 6.) Cliquez avec le bouton droit sur chaque adresse, puis cliquez sur Propriétés pour identifier l’adresse IP que vous souhaitez configurer.
  3. Si la boîte de dialogue Ports TCP dynamiques contient 0, c’est que le moteur de base de données écoute sur les ports dynamiques. Si cette boîte de dialogue contient un autre chiffre, cela signifie que l’instance de la base de données est en cours d'écoute sur un port statique.
    TCPDynamicPorts
     
Pour plus d’informations, reportez-vous à :

Votre problème est-il résolu ?
Emplacement du téléchargement : PortqryUI
  1. Lancez l’outil PortqryUI sur votre machine cliente (la machine sur laquelle vous rencontrez des problèmes de connexion ; pour les applications web, cela peut être le serveur IIS.)
  2. Spécifiez le nom de serveur de l’instance SQL Server ou le nom du serveur SQL virtuel dans Destination IP or FQDN to query.
  3. Sélectionnez Query predefined service, puis sélectionnez SQL Service dans la liste déroulante.
  4. Cliquez sur Query, puis examinez le résultat et utilisez le tableau qui suit pour rechercher des indices supplémentaires. 
 Type d’instance Résultat de Portqry Causes possibles des problèmes de connexion Méthodes à essayer
 Instance par défaut Port TCP 1433 (service ms-sql-s) : PAS D’ÉCOUTE  Indique une de ces possibilités :
  • SQL n’est pas démarré
  • TCP/IP n’est pas activé sur la liste des protocoles de SQL Server.
  • SQL écoute sur un port autre que le port par défaut (consultez le journal des erreurs)
  • Un pare-feu entre le client et le serveur bloque le port 
  •  Assurez-vous que SQL est bien démarré
  • Recherchez le numéro de port dans le journal des erreurs SQL et utilisez cette information dans vos chaînes de connexion en suivant le format <nom_serveur>, numéro_port
  • Contactez votre administrateur réseau Windows pour vous assurer que le port TCP 1433 n’est pas bloqué par un pare-feu sur le réseau ou par le pare-feu Windows sur le système SQL Server. 
    Remarque : Si vous voulez résoudre un problème lié au pare-feu, sélectionnez l’option Résolution des problèmes de pare-feu en bas. 
 Instance par défaut Port TCP 1433 (service ms-sql-s) : ÉCOUTE
  •  La bibliothèque de client peut se connecter à la machine SQL Server, mais un autre élément de la couche d’application peut être à l’origine du problème.
 Vérifiez si
  • Le nom du serveur est correctement spécifié dans la chaîne de connexion
  • Si la chaîne de connexion utilise le numéro de port, il est correctement spécifié dans la chaîne de connexion
  • Tous les alias obsolètes dans la boîte de dialogue. 
 Instance nommée Port UDP 1434 (service ms-sql-m) : FILTRÉ Indique une de ces possibilités :
  • L’instance nommée SQL n’est pas démarrée.
  • SQL Browser n’est pas démarré sur le système qui héberge votre instance SQL.
  • Le port UDP 1434 est bloqué par le pare-feu sur SQL Server ou sur le réseau entre le client et le serveur. 
  •  Le service est démarré.
  • Le service SQL Browser est démarré
  • Contactez votre administrateur réseau Windows pour vous assurer que le port UDP 1434 n’est pas bloqué par un pare-feu sur le réseau ou par le pare-feu Windows sur le système SQL Server. 
    Remarque : Si vous voulez résoudre un problème lié au pare-feu, sélectionnez l’option Résolution des problèmes de pare-feu en bas.
 Instance nommée Le port UDP 1434 est ÉCOUTE
  •  La bibliothèque de client peut se connecter à la machine SQL Server, mais un autre élément de la couche d’application peut être à l’origine du problème.
  •  Le nom du serveur est correctement spécifié dans la chaîne de connexion
  • Le numéro de port est correctement spécifié dans la chaîne de connexion
  • Tous les alias obsolètes dans la boîte de dialogue. 

Exemples de sorties :
 

Votre problème est-il résolu ?


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.
Pour plus d’informations sur la raison pour laquelle les opérations Kerberos ne peuvent pas être effectuées, sélectionnez l’option Résolution des problèmes d’authentification dus à des problèmes Kerberos en bas de la page pour consulter les étapes et les appliquer.


Au moins trois scénarios peuvent être à l’origine de ce problème. Utilisez le tableau suivant pour consulter chacun de ces scénarios et appliquer la résolution adaptée.

 Cause possible  Suggestions de résolution
 Scénarios à deux tronçons sur la même machine : vous essayez de suivre deux tronçons, mais les informations d’identification NTLM sont utilisées plutôt que celles de Kerberos  Pour les scénarios à double tronçon sur la même machine, ajoutez les entrées de Registre DisableLoopbackCheck ou BackConnectionHostNames comme suit :
 Scénarios à double tronçon sur plusieurs machines : l’erreur peut se produire lorsque les connexions Kerberos échouent en raison d’erreurs SPN. Sélectionnez l’option Résolution des problèmes d’authentification dus à des problèmes Kerberos plus bas pour voir plus de détails.
 Pas de double tronçons  S’il n'y a pas de double tronçon, cela peut aussi signifier qu’il existe des SPN en double et que le client s’exécute en tant que LocalSystem ou autre compte d’ordinateur qui obtient des identifiants NTLM plutôt que des identifiants Kerberos.

Sélectionnez l’option « Résolution des problèmes d’authentification liés au protocole Kerberos» pour diagnostiquer et résoudre les problèmes de nom de serveur (SPN).
 La stratégie de sécurité locale de Windows est peut-être configurée pour empêcher toute utilisation du compte d’ordinateur pour les comptes locaux sortants Sur Windows 2008 R2/Windows 7 et versions ultérieures, la stratégie de sécurité locale, les options de sécurité et la sécurité réseau peuvent être configurées pour ne pas utiliser le compte d’ordinateur pour les comptes locaux sortants et utiliser plutôt des informations d’identification anonymes.

 

Votre problème est-il résolu ?

Cette erreur indique que LSASS n’a pas pu déchiffrer le jeton de sécurité à l’aide des informations d’identification du compte de service SQL Server. La principale raison de ce problème est que le SPN est associé au mauvais compte.

Pour diagnostiquer et résoudre ces problèmes de SPN, sélectionnez l’option Résolution des problèmes d’authentification dus à des problèmes Kerberos et poursuivez.

Vous pouvez par exemple voir une erreur qui ressemble à ce qui suit :

Source : NETLOGON
Date : 12/08/2012 20:22:16
ID d’événement : 5719
Catégorie de tâche : Aucune
Niveau : erreur
Mots clés : Classique
Utilisateur : N/A
Ordinateur : <nom_ordinateur>
Description : cet ordinateur n’a pas pu configurer une session sécurisée avec un contrôleur de domaine dans le domaine pour la raison suivante : L’appel de procédure distante a été annulé. Ceci peut entraîner des problèmes d’authentification. Assurez-vous que cet ordinateur est connecté au réseau. Si le problème persiste, contactez votre administrateur de domaine. 
Si la chaîne est vide, c’est que SQL a essayé de passer les informations d’identification à LSASS, mais qu’un problème est survenu. Soit LSASS n’était pas disponible, soit le contrôleur de domaine n’a pas pu être contacté. 
Consultez le journal des événements sur les machines client et serveur pour voir s’ils contiennent des messages réseau ou des messages concernant Active Directory au moment où le problème se produit. Si c’est le cas, contactez votre administrateur de domaine pour résoudre les problèmes.

 

Votre problème est-il résolu ?

 

Si le nom de domaine n’est pas spécifié, la raison est l’échec de la connexion SQL. S’il est spécifié, la raison est l’échec de la connexion intégrée à Windows. Consultez le tableau suivant pour rechercher les causes et les résolutions possibles.


 Cause  Étapes de résolution
La base de données demandée est hors connexion ou n’est pas disponible Vérifiez les autorisations et la disponibilité de la base de données dans SQL Server Management Studio.
L’utilisateur ne dispose pas des autorisations pour accéder à la base de données demandée. Essayez de vous connecter sous un autre nom d’utilisateur qui dispose des droits d’administrateur système

Pour retrouver d’autres conseils, consultez Résolution des problèmes : Échec de la connexion pour l’utilisateur 'x'.

Votre problème est-il résolu ?

Vous pouvez également constater ce problème avec les applications IIS qui utilisent une connexion anonyme ou une authentification par formulaire dans lequel l’identité de l’utilisateur n’est pas empruntée. Le compte anonyme IIS (IUSR) ou le compte de pool d’applications empruntent eux une identité. Le compte IUSR est un compte local et le compte de pool d’applications peut aussi être un compte local.

Cette erreur se produit en général si l’utilisateur est connecté avec un compte local plutôt qu’un compte de domaine. En cas de connexion à des services sortants, les informations d’identification de la machine peuvent être transmises. Dans certains cas, vous pouvez ajouter ce compte comme connexion au serveur principal. Dans d’autres cas, vous pouvez essayer de vous connecter avec un compte de domaine et approvisionner les autorisations appropriées pour ce compte afin d’accéder au service distant.

Votre problème est-il résolu ?

Les problèmes d’authentification Kerberos peuvent être dus à de nombreuses raisons. Les principales causes et les résolutions correspondantes sont présentées ci-dessous :

 Type de problème  Suggestions de résolution
 Problèmes SPN :
  • SPN manquants : SPN non inscrit dans Active Directory
  • Entrées SPN incorrectes : Le SPN existe, mais le numéro de port est incorrect ou il existe sur un compte autre que le compte de service SQL.
  • SPN en double : Le même SPN existe sur plusieurs comptes dans Active Directory 
Consultez « Utilisation du gestionnaire de configuration Kerberos pour diagnostiquer et résoudre les problèmes de SPN et de délégation » dans le paragraphe suivant pour diagnostiquer et résoudre les problèmes de SPN.

Remarque : Pour une compréhension approfondie des SPN, Kerberos et d’autres concepts connexes, consultez les informations contenues dans l’article suivant de la KB :
Comment faire pour résoudre le message d’erreur « Impossible de générer le contexte SSPI »
 Comptes de services SQL non approuvés pour la délégation. Si vous utilisez un compte système local, le serveur intermédiaire doit être approuvé pour la délégation dans Active Directory Utilisez l’onglet Delegation de Kerberos configuration manager pour confirmer que c’est bien le cas et contactez votre administrateur Active Directory pour activer la délégation pour ce compte. Consultez Utilisation de Kerberos Configuration manager pour diagnostiquer et corriger les problèmes de SPN et de délégation dans le paragraphe suivant pour plus de détails. 
Résolution de noms incorrecte : Votre serveur de noms effectue peut-être la résolution à une adresse IP autre que celle inscrite par le serveur DNS de votre réseau. localisez -a <your_target_machine> (utilisez -4 et -6 pour IPv4 et IPv6 spécifiquement)
localisez -a <Your_remote_IPAddress> nslookup (tapez plusieurs fois le nom et l'adresse IP de votre ordinateur local et à distance)

Recherchez les éventuelles divergences et les incompatibilités dans les résultats retournés. La configuration correcte de la configuration DNS sur le réseau est un élément vital pour la connexion SQL. Une entrée DNS erronée peut entraîner de nombreux problèmes de connectivité. Consultez par exemple ce lien : Message d’erreur Impossible de générer le contexte SSPI, DNS incorrect.
Des pare-feu ou d’autres périphériques réseau empêchent le client de se connecter au contrôleur de domaine : Les SPN sont stockés dans Active Directory, et si les clients ne peuvent pas communiquer avec Active Directory, la connexion ne peut pas se poursuivre.  Consultez les liens suivants pour plus d’informations

Utilisation de Kerberos Configuration manager pour diagnostiquer et corriger les problèmes de SPN et de délégation

  1. Téléchargez le gestionnaire de configuration Microsoft® Kerberos pour server SQL® et installez-le sur une machine cliente.
  2. Lancez cet outil à l’aide d’un compte de domaine, de préférence avec un compte disposant des privilèges nécessaires pour créer des SPN dans votre Active Directory. Voir l’illustration ci-dessous :

    KerberosConfigManager

  3. Connectez-vous au serveur SQL pour recueillir les informations relatives aux erreurs Kerberos :

    ConnectKerberosConfigManager

  4. Une fois connecté, vous voyez différents onglets, comme illustré ci-dessous :

    Système : Dispose des informations système de base.

    KerConfigManager_System

    SPN : Fournit les informations SPN sur les instances de chacune des instances SQL trouvées sur le serveur cible et propose différentes options, comme présenté ci-dessous. Utilisez cet onglet pour trouver les SPN manquants ou mal configurés et les boutons Générer ou Corriger pour résoudre ces problèmes.

    KerConfigManager_SPN

    • L’option Générer vous permet de créer le script SPN Generation. En cliquant sur le bouton Générer, la boîte de dialogue suivante s'affiche :

      KerConfigManager_GenerateSPN

      Cette option crée un fichier de commandes qui peut être exécuté à partir de l’invite de commandes pour générer le nom SPN.

      Le chemin dʼaccès aux fichiers du carnet dʼadresses en mode hors connexion sera identique à celui qui suit :

      :: This script is generated by the Microsoft(c) SQL Server(c) Kerberos Configuration Manager tool.:: The script may update the system information, SPN settings and Delegation configurations of a given server.:: SPN and Delegation configuration updates require Windows Domain Administrator permission to execute.:: A Domain Admin should review the configurations recommended by this tool and take appropriate actions to enable Kerberos authentication.:: Please contact Microsoft Support if Kerberos connection problem persists.:: The file is intended to be run in domain "<DomainName>.com":: Corrections for MSSQLSvc/<HostName>.<DomainName>.comSetSPN -s MSSQLSvc/<HostName>.<DomainName>.com UserName

      Il utilise simplement l’option SelfSSL pour créer un SPN sous le compte de service pour le serveur SQL.

    • L’option Fix ajoute le SPN si vous disposez de l’autorisation d’ajout de SPN et présente l’astuce suivante :

      KerbConfigManager_Fix
       
    • Onglet Delegation : cet onglet identifie les problèmes de la configuration de délégation du compte de service. Il est particulièrement utile pour la résolution des problèmes de serveur lié. Par exemple si les SPN sont corrects, mais que vous rencontrez encore des problèmes de requêtes sur le serveur lié, c’est peut-être que le compte de service n’est pas configuré pour déléguer les informations d’identification. Pour obtenir des informations supplémentaires, consultez la rubrique Configuration des serveurs liés pour la délégation dans la documentation en ligne.

      KerbConfigManger_Delegation
       

  5. Une fois que vous avez corrigé les SPN, relancez l’outil Kerberos Configuration Manager et assurez-vous que les onglets SPN et Delegation ne contiennent plus de messages d’erreur, puis testez à nouveau la connexion à partir de votre application.

Pour plus d’informations, consultez les liens suivants :

Votre problème est-il résolu ?

Un délai d’expiration se produit lorsqu’une opération prend plus de temps qu’elle ne devrait. Cette opération est donc simplement annulée afin de ne pas avoir à attendre indéfiniment et éventuellement bloquer d’autres éléments et bloquer complètement l’application. Du point de vue le plus simple de la connectivité, cette situation peut être envisagée de deux façons. L’une est un délai d’expiration de la connectivité, l’autre est un délai d’expiration de la requête. Donc, vous devez d’abord examiner l’ensemble de la pile des appels du message d’erreur afin de savoir s’il s’agit d’une expiration de commande ou un délai d’attente de la connexion.

Étapes de résolution : 
ces deux problèmes peuvent être liés à votre environnement ou à SQL Server. Par exemple, il est possible que votre réseau soit lent ou que vous rencontriez des problèmes de performances de vos requêtes. Il n’existe pas de règles pour ce qui est à faire ou à ne pas faire, et une investigation plus poussée peut être nécessaire pour déterminer la cause du problème. L’augmentation du délai d’expiration de la requête est bien plus courante que l’augmentation du délai d’attente de la connexion. Ceci est dû au fait que lors de la tentative de connexion à une source de données, la connexion se produit en général très rapidement (normalement en quelques millisecondes).



 Type  Solutions à essayer
Délai d’attente de la connexion
  1. Augmentez le délai d’attente de la connexion dans votre application.
  2. Vérifiez si le port utilisé par SQL est bloqué sur le réseau, avec un outil comme Portqry.  Sélectionnez l’option Utilisation de l’outil PortqryUI avec SQL Server en bas de la page pour obtenir des instructions sur son utilisation. 
Expiration de commande
  1.  Augmentez la valeur CommandTimeout dans votre application et ajustez les requêtes exécutées sur le serveur principal.

Pour plus de conseils et de suggestions, consultez : Résolution des problèmes : Expiration du délai d’attente.

Votre problème est-il résolu ?

Cette situation se produit généralement si les connexions ne sont pas correctement fermées. L’erreur complète peut ressembler à ce qui suit :

System.InvalidOperationException : Expiration du délai d’attente. Le délai d’attente s’est écoulé avant obtention d’une connexion du pool.

 

Ceci est probablement dû au fait que toutes les connexions regroupées sont en cours d’utilisation et que la taille maximale du pool a été atteinte.

Il est en général possible d’éviter cette situation en appliquant les meilleures pratiques présentées dans le billet de blog suivant sur MSDN : Expiration du délai d’attente. Le délai d’attente s’est écoulé avant l’obtention d’une connexion à partir du pool.

Votre problème est-il résolu ?

Les fichiers UDL sont un moyen simple et efficace pour tester les connexions au serveur SQL Server depuis vos clients ou autres systèmes.

  1. Activez l’option permettant d’afficher les extensions de fichiers dans votre Explorateur Windows. Pour cela, procédez comme suit :
    1. Sur Windows 8 et systèmes ultérieurs : Allez soit dans Explorateur de fichiers Options dans le Panneau de configuration ou tapez simplement « Masquer » dans la recherche Windows. Puis, dans l’onglet Affichage, désactivez la case à cocher Masquer les extensions pour les types de fichiers connus.
    2. Windows 7 et versions antérieures : Consultez ce KB.
      Win7ViewExtFile
       
  2. Accédez au dossier dans lequel vous souhaitez créer le fichier .udl (par exemple c:\temp)
  3. Créez un fichier texte (sqlconn.txt) et remplacez l’extension .txt par .udl (cliquez sur Yes dans le message d’avertissement concernant la modification des extensions de noms de fichier).
  4. Double-cliquez sur le fichier .udl de l’étape 3 et effectuez les opérations suivantes :
    1. Dans l’onglet Fournisseur, sélectionnez le fournisseur que vous utilisez dans votre application (par exemple SQL Server Native Client).
    2. Dans l’onglet Connexion, sélectionnez ou entrez votre serveur SQL Server et le reste des paramètres de votre application.
  5. Cliquez ensuite sur Tester la connexion.

Pour plus d’informations et pour voir des captures d’écran, reportez-vous au billet de blog suivant sur MSDN :

Premiers pas : test UDL

Votre problème est-il résolu ?

Félicitations ! Nous sommes heureux que ce guide ait résolu votre problème.

Nous sommes désolés que ce guide ne vous ait pas permis de résoudre votre problème. Nous vous conseillons de consulter la communauté Microsoft SQL pour obtenir de l’aide.

Voici quelques ressources supplémentaires que vous pourriez trouver utiles :