Résolution des erreurs de connectivité SQL Server

Cet article vous aide à résoudre différents problèmes de connectivité SQL serveur.

Notes

Pour une visite guidée de cet article, voir Résolution des erreurs de connectivité SQL Server.

Version du produit d’origine :   Microsoft SQL Server
Numéro de la ko d’origine :   4009936

Conditions préalables

Pour utiliser efficacement cet dépannage, vous pouvez collecter les informations suivantes.

  1. Texte complet du message d’erreur avec les codes d’erreur et si l’erreur est intermittente (se produit uniquement parfois) ou cohérente (se produit tout le temps).

  2. Leslogs d’SQL Server à partir des lesquels vous pouvez noter les remarques suivantes :

    1. Nom de domaine complet (FQDN) de l’ordinateur SQL Server ou en cas d’installations en cluster, nom virtuel du nom de domaine complet. Si vous utilisez une instance nommée, notez le nom de l’instance.

      Notes

      Vous pouvez rechercher la chaîne « Nom du serveur » pour obtenir ces informations dans lelog des erreurs.

    2. Bibliothèques réseau et ports sur SQL instance est à l’écoute. Exemples de messages :

      Canaux nommés : le fournisseur de connexion local du serveur est prêt à accepter la connexion sur [ \ \ .\pipe\sql\query ]. TCP/IP et numéro de port : le serveur est à l’écoute sur [ ::1 1433].

  3. Journaux d’événements système et d’application SQL Server et des systèmes clients.

  4. Si les connexions échouent à partir d’une application, la chaîne de connexion de l’application. Ceux-ci se trouvent généralement dansWeb.config fichiers pour ASP.NET applications.

Liste de vérification

  • Assurez SQL le serveur est démarré et que le message suivant s’SQL Server ErrorLog :

    SQL Server est maintenant prêt pour les connexions client. Il s’agit d’un message d’information ; aucune action de l’utilisateur n’est requise.

  • Vérifiez la connectivité de base sur l’adresse IP et vérifiez les problèmes : ping -a <SQL Server machine>, ping -a <SQL Server IP address> Si vous remarquez des problèmes, travaillez avec votre administrateur réseau pour résoudre le même problème.

  • Vérifiez si SQL est à l’écoute sur les protocoles appropriés en vérifiant ErrorLog.

  • Vérifiez si vous êtes en mesure de vous connecter à SQL serveur à l’aide d’un fichier UDL. Si elle fonctionne, il se peut qu’il y a un problème avec la chaîne de connexion. Pour obtenir des instructions sur la procédure sur le test UDL, déplacez-vous vers Connect to SQL server à l’aide d’une section de fichier UDL.

  • Vérifiez si vous êtes en mesure de vous connecter à SQL Server à partir d’autres systèmes clients et de connexions utilisateur différentes. Si vous le pouvez, le problème peut être spécifique au client ou à la connexion qui rencontre le problème. Consultez les journaux des événements Windows sur le client problématique pour obtenir des pointeurs supplémentaires. Vérifiez également si les pilotes réseau sont à jour.

  • Si vous rencontrez des échecs de connexion, assurez-vous que l’utilisateur dispose d’une connexion au niveau du serveur et des autorisations appropriées pour se connecter à la base de données à qui l’utilisateur tente de se connecter.

Pour plus d’informations sur l’erreur pertinente, consultez la section Vérifier les erreurs de connexion suivante.

Vérifier les erreurs de connexion

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

  • Une erreur liée au réseau ou à l’instance s’est produite lors de l’établissement d’une connexion SQL Server. Le serveur n’a pas été trouvé ou n’est pas accessible. Vérifiez que le nom de l’instance est correct et SQL Server est configuré pour autoriser les connexions distantes.

    provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified

  • SQL Server de liaison de données natives client

    [Microsoft SQL Server Native Client 10.0]: Login timeout expired
    [Microsoft SQL Server Native Client 10.0]: A network-related or instance-specific error has occurred while establishing a connection to SQL Server. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online.
    [Microsoft SQL Server Native Client 10.0]: SQL Server Network Interfaces: Error Locating Server/Instance Specified [xFFFFFFFF].

  • Une erreur liée au réseau ou à l’instance s’est produite lors de l’établissement d’une connexion SQL Server. Le serveur n’a pas été trouvé ou n’est pas accessible. Vérifiez que le nom de l’instance est correct et SQL Server est configuré pour autoriser les connexions distantes.

    fournisseur : Fournisseur TCP, erreur : 0
    Une tentative de connexion a échoué car la partie connectée n’a pas répondu correctement après un certain temps, ou la connexion établie a échoué car l’hôte connecté n’a pas réussi à répondre.
    Microsoft SQL Server, Erreur : 10060

  • Une erreur liée au réseau ou à l’instance s’est produite lors de l’établissement d’une connexion SQL Server. Le serveur n’a pas été trouvé ou n’est pas accessible. Vérifiez que le nom de l’instance est correct et SQL Server est configuré pour autoriser les connexions distantes.

    provider: Named Pipes Provider, error:40 - Could not open a connection to SQL Server
    Microsoft SQL Server, Error:53
    Le chemin d’accès réseau est in trouvé

  • [Microsoft] [SQL Server Native Client 11.0] Fournisseur TCP : aucune connexion n’a pu être réalisée car l’ordinateur cible l’a activement refusée.
    [Microsoft] [SQL Server Native Client 11.0] Expiration du délai d’expiration de la connexion
    [Microsoft] [SQL Server Native Client 11.0] Une erreur liée au réseau ou à l’instance s’est produite lors de l’établissement d’une connexion SQL Server. Le serveur n’est pas trouvé ou n’est pas accessible. Vérifiez si le nom de l’instance est correct SQL Server est configuré pour autoriser les connexions à distance. Pour plus d’informations, voir SQL Server Books Online.

Vous pouvez commencer à résoudre les problèmes à partir de cette section : Causes courantes de divers problèmes de connexion.

Causes courantes de divers problèmes de connexion

Recherchez chacune des causes applicables à votre instance ci-dessous et, pour chacune des causes applicables, essayez les résolutions correspondantes.

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

Pour confirmer :

  • Assurez-vous que le nom du serveur que vous spécifiez correspond à ce que vous avez dans le journal des erreurs.

  • Accédez au fichier Editing ASP.NET Configuration Files pour votre application et assurez-vous que la section Chaînes de connexion pointe vers le nom de serveur approprié et utilise les chaînes de connexion SQL Server correctes pour les applications Web ASP.NET.

    Notes

    Pour obtenir par programme les chaînes de connexion à partir de votre application, reportez-vous à l’exemple dans la procédure : Lire les chaînes de connexion à partir du Web.config .

Cause 2 : Alias incorrect sur l’ordinateur client

Les alias sont généralement utilisés dans les environnements lorsque vous devez vous connecter à SQL Server avec un autre nom ou lorsqu’il existe des problèmes de résolution de noms dans le réseau. Un alias incorrect sur l’ordinateur client peut entraîner l’échec des connexions à partir de vos applications vers le serveur incorrect.

Points à essayer :

  • Ouvrez SQL Server’utilitaire réseau client en tapantcliconfg.exe dans votre commande Exécuter.

  • Vérifiez si des alias sont définis pour le serveur à qui vous essayez de vous connecter.

  • Si ce n’est pas le cas, faites les choses suivantes :

    1. Cliquez sur Modifier et renommez l’alias de serveur. (par exemple, si votre nom de serveur est MySQL, renommez-le MySQL_test) et réessayez la connexion. Si la connexion fonctionne, cela indique que vous avez un alias incorrect, probablement à partir d’une ancienne configuration qui n’est plus nécessaire. Si vous continuez à faire l’expérience de l’erreur, renommez l’alias à son nom d’origine et procédez à l’étape suivante.

    2. Vérifiez les paramètres connection de l’alias et assurez-vous qu’ils sont corrects. Voici quelques-uns des scénarios courants qui peuvent entraîner des problèmes de connectivité :

      • Adresse IP incorrecte pour le paramètre Nom du serveur. Assurez-vous que cette adresse IP correspond à l’entrée du SQL ErrorLog.

      • Nom de serveur incorrect dans le paramètre Nom du serveur. Par exemple, si votre alias de serveur pointe sur le nom de serveur correct, si le paramètre Nom du serveur a une valeur incorrecte, les connexions échouent.

      • Si vous utilisez un alias de canaux nommé, assurez-vous que le nom du canal a le format correct.

        • Pour la connexion à l’instance par défaut nommée Mydefaultinstance, le nom du canal doit être \\Mydefaultinstance\pipe\sql\query
        • Pour la connexion à une instance nommée MySQL\Named, le nom du canal doit être \\MySQL\pipe\MSSQL$Named\sql\query

Cause 3 (instance par défaut) : pare-feu entre le client et le serveur bloquant le port SQL Server instance est à l’écoute sur

Instance par défaut: une instance par défaut s’exécute généralement sur le port 1433. Certaines installations utilisent également un port non standard (autre que 1433) pour l’exécution SQL instances. Le pare-feu peut bloquer l’un d’eux.

Points à essayer :

  • Déterminez le numéro de port SQL instance est en cours d’exécution. Si l’instance par défaut de votre serveur SQL utilise un port non standard, consultez l’SQL Server Exécution de l’instance « Par défaut » sur un port TCP non par défaut (ou non standard): : conseils pour que la connectivité des applications fonctionne.

  • Essayez d’SQL Server le numéro de port au nom du serveur en utilisant le format <servername> , numéro de port et voir si cela fonctionne. Par exemple, si le nom de votre instance SQL est MySQLDefaultinstance et qu’elle s’exécute sur le port 2000, spécifiez le nom du serveur en tant que MySQLServer, 2000 et voyez si cela fonctionne. Si elle fonctionne, cela indique que le pare-feu bloque le port.

  • S’il est confirmé, ajoutez le port à la liste d’exclusions du pare-feu. Pour obtenir des instructions, déplacez-vous vers la section Configuration des pare-feu.

Cause 4(instance nommée) : le SQL navigateur n’est pas démarré

Les applications clientes qui se connectent à une instance nommée de SQL Server utilisent le service de navigateur SQL sur le système sur lequel SQL est en cours d’exécution pour éumérer le port sur lequel SQL est à l’écoute. Si le service de navigateur n’est pas démarré, les connexions échouent.

Points à essayer :

Sur le système qui exécute votre instance SQL Server, utilisez le gestionnaire de configuration SQL Server ou l’applet Services dans le Panneau de configuration et démarrez le service SQL Browser s’il n’est pas déjà démarré. Pour plus d’informations, voir How to: Start and Stop the SQL Server Browser Service

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

Si votre instance SQL est une instance nommée, elle peut avoir été configurée pour utiliser des ports dynamiques ou un port statique. Dans les deux cas, les bibliothèques réseau sous-jacentes interrogent le service de navigateur SQL qui s’exécute sur votre ordinateur SQL Server via le port UDP 1434 pour obtenir 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 cliente ne peut pas déterminer le port (une exigence de connexion) et la connexion échoue.

Pour confirmer :

  • Méthode 1 :

    1. Notez le port sur SQL instance est à l’écoute à partir du SQL Server Errorlog.
    2. Essayez de vous connecter à l’instance nommée en utilisant le numéro de port qui est appendé au nom du serveur en utilisant le format <nom_serveur\nom_instance>, numéro_port et voir si cela fonctionne. Si elle fonctionne, cela indique que le pare-feu bloque le port UDP 1434. Par exemple, si le nom de votre instance SQL est MySQL\Namedinstance et qu’elle s’exécute sur le port 3000, spécifiez le nom du serveur en tant que MySQL\Namedinstance, 3000 et voyez si cela fonctionne. Si elle fonctionne, cela peut signifier que le port UDP 1434 est bloqué ou que le port statique est bloqué ou les deux. Pour vérifier s’il s’agit du port UDP ou du port statique à l’aide de Portqry à partir de la méthode 2 ci-dessous.
  • Méthode 2 :

    1. Utilisez l’outil PortqryUI avec votre instance nommée et observez la sortie qui en résulte. Si le message vous indique que le port UDP 1434 est filtré, cela indique que le port est bloqué sur le réseau. Pour obtenir des instructions sur l’utilisation de l’outil, utilisez l’outil PortqryUI SQL Server section.

Points à essayer :

Déterminez d’abord si SQL Server instance est à l’écoute sur un port dynamique ou statique et utilisez la procédure qui est pertinente pour votre scénario. Pour savoir si SQL est à l’écoute sur les ports dynamiques et statiques, déplacez-vous vers Indiquer si SQL est à l’écoute dans la section Ports dynamiques ou statiques.

  • Cas 1 : ports dynamiques. Dans ce cas, vous devez vous assurer que le service de navigateur SQL est bien démarré et que le port UDP 1434 n’est pas bloqué sur le pare-feu entre le client et le serveur. Si vous ne pouvez pas faire l’une ou l’autre d’entre elles, vous devez basculer votre instance SQL Server pour utiliser un port statique et utiliser la procédure documentée dans Configurer un serveur pour écouter sur un port TCP spécifique.

  • Cas 2 : configuration de port statique et SQL navigateur ne sont pas en cours d’exécution ou UDP 1434 ne peut pas être ouvert sur le pare-feu. Dans ce cas, vous devez vous assurer que le port statique est spécifié dans votre chaîne de connexion et que ce port n’est pas bloqué par le pare-feu. Pour obtenir des instructions, déplacez-vous vers la section Configuration des pare-feu.

Si cela ne résout pas votre problème, déplacez-vous vers la section Toujours avoir des problèmes.

Configuration des pare-feu

Vous trouverez ci-dessous quelques captures d’écran rapides montrant la configuration requise d’un pare-feu Windows pour les connexions réussies à une instance par défaut et à une instance nommée.

  • Instance par défaut de SQL Server à l’écoute sur le port par défaut 1433 sur le serveur Windows 2012 R2. Dans ce scénario, 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 hébergeant SQL instance par défaut du serveur et cliquez sur Nouvelle règle sous Règles de trafic entrant.

      Règles d’inound

    2. Sélectionnez l’option Port, puis cliquez sur Suivant.

      InboundRulePort

    3. Dans l’écran suivant :

      • Sélectionnez TCP comme protocole.

      • Sélectionnez des ports locaux spécifiques et spécifiez la valeur 1433, puis 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 le nom à votre règle et fournissez une description claire pour référence ultérieure, puis cliquez sur Terminer.

      NewInboundRuleName

    7. Une fois l’option effectuée, vous devez voir que la règle est créée et activée par défaut.

      EnableInboundRule

  • Ajout d’une exception au port UDP 1434 pour activer les connexions à une instance nommée de SQL serveur :

    1. Ouvrez le pare-feu Windows sur le système hébergeant SQL instance par défaut du serveur et cliquez sur Nouvelle règle sous Règles de trafic entrant.

      Règles d’inound

    2. Sélectionnez l’option Port, puis cliquez sur Suivant.

      InboundRulePort

    3. Dans l’écran suivant :

      • Sélectionnez UDP comme protocole.

      • Sélectionnez des ports locaux spécifiques et spécifiez la valeur 1434, puis 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 le nom à votre règle et fournissez une description claire pour référence ultérieure, puis cliquez sur Terminer.

      NewInboundName2

    7. Une fois l’option effectuée, vous devez voir que la règle est créée et activée par défaut.

      EnableInboundRule2

Si cela ne résout pas votre problème, déplacez-vous vers la section Toujours avoir des problèmes.

Utilisation de l’outil PortqryUI avec SQL Server

Emplacement de téléchargement : PortqryUI

  1. Lancez l’outil PortqryUI sur votre ordinateur client. (l’ordinateur sur lequel vous avez des problèmes de connexion, pour les applications web, il peut s’y avoir le serveur IIS)
  2. Spécifiez le nom de serveur de SQL Server instance ou le nom SQL serveur de destination dans l’adresse IP ou le nom de domaine complet de destination à interroger.
  3. Sélectionnez Service de requête prédéféré et sélectionnez SQL service dans la liste liste.
  4. Cliquez sur Requête, examinez la sortie et utilisez le tableau suivant pour obtenir des pointeurs supplémentaires.
Type d’instance Sortie de Portqry Causes potentielles des problèmes de connexion Que faire ?
Instance par défaut Port TCP 1433 (service ms-sql-s) : NON À L’ÉCOUTE Indique l’une des informations suivantes :
  • SQL n’est pas démarré.
  • Le protocole TCP/IP n’est pas activé SQL liste de protocoles du serveur.
  • SQL est à l’écoute sur un port autre que le port par défaut. (vérifier lelog des erreurs)
  • Le pare-feu entre le client et le serveur bloque le port.
  • Assurez-vous SQL est démarré.
  • Vérifiez SQL journal d’erreurs pour le numéro de port et utilisez-le dans vos chaînes de connexion au format <servername> , numéro de port.
  • Travaillez avec 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 SQL Server système.
Remarque Si vous souhaitez résoudre un problème de pare-feu, déplacez-vous vers la section Configuration des pare-feu.
Instance par défaut Port TCP 1433 (service ms-sql-s) : LISTENING
  • La bibliothèque cliente peut se connecter à l’ordinateur SQL serveur, mais un autre problème dans 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, elle est correctement spécifiée dans la chaîne de connexion.
  • Tous les anciens alias définis dans la zone.
Instance nommée Port UDP 1434 (service ms-sql-m) : FILTRÉ Indique l’une des informations suivantes :
  • SQL instance nommée n’est pas démarrée.
  • SQL navigateur n’a pas démarré sur le système hébergeant SQL instance.
  • Le port UDP 1434 est bloqué par un pare-feu sur le serveur SQL ou sur le réseau entre le client et le serveur.
  • Le service est démarré.
  • SQL service de navigateur est démarré.
  • Travaillez avec 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 SQL Server système.
Remarque Si vous souhaitez résoudre un problème de pare-feu, déplacez-vous vers la section Configuration des pare-feu.
Instance nommée Le port UDP 1434 est À L’ÉCOUTE
  • La bibliothèque cliente peut se connecter à l’ordinateur SQL serveur, mais un autre problème dans 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 incorrectement spécifié dans la chaîne de connexion.
  • Tous les anciens alias définis dans la zone.

Exemples de sorties :

  • Instance par défaut sur le port par défaut : scénario de travail

    DeaultInstanceDefaultPort_Working

  • Instance par défaut sur le port par défaut : scénario de non-travail

    DeaultInstanceDefaultPort_NonWorking

  • Instance nommée : scénario de travail : (nom de l’instance SQL 2014, nom d’hôte : SQLCONNVM)

    WorkingNameInstance

  • Instance nommée : Non - Scénario de travail : (nom de l’instance : SQL 2014, nom d’hôte : SQLCONNVM)

    NonWorkingNameInstance

Pour plus d’informations, voir la section Configuration des pare-feu.

Si cela ne résout pas votre problème, déplacez-vous vers la section Toujours avoir des problèmes.

Savoir si SQL est à l’écoute sur les ports dynamiques et statiques

  1. Dans SQL Server Configuration Manager, dans le volet console, développez SQL Server Configuration réseau, développez Protocoles pour, puis double-cliquez sur TCP/IP.

  2. Dans la boîte de dialogue Propriétés TCP/IP, sous l’onglet Adresses IP, plusieurs adresses IP apparaissent au format IP1, IP2, jusqu’à IPAll. L’une d’elles est pour l’adresse IP de l’adaptateur de boucle, 127.0.0.1. Des adresses IP supplémentaires apparaissent pour chaque adresse IP sur l’ordinateur. (Vous verrez probablement les adresses IP version 4 et IP version 6.) Cliquez avec le bouton droit sur chaque adresse, puis cliquez sur Propriétés pour identifier l’adresse IP à configurer.

  3. Si la boîte de dialogue Ports dynamiques TCP contient 0, cela indique que le moteur de base de données est à l’écoute sur les ports dynamiques. S’il contient un nombre spécifique, cela signifie que l’instance de base de données est à l’écoute sur un port statique.

    TCPDynamicPorts

Pour plus d’informations, voir Configurer un serveur pour écouter sur un port TCP spécifique.

Si cela ne résout pas votre problème, déplacez-vous vers la section Toujours avoir des problèmes.

Aucune connexion n’a pu être réalisée car l’ordinateur cible l’a activement refusée

Pour plus d’informations sur l’erreur d’absence de connexion, déplacez-vous vers la section Message d’erreur complet.

Message d’erreur complet

Vous pouvez obtenir une erreur semblable à celle-ci :

[Microsoft] [SQL Server Native Client 11.0] Fournisseur TCP : aucune connexion n’a pu être réalisée car l’ordinateur cible l’a activement refusée.
[Microsoft] [SQL Server Native Client 11.0] Expiration du délai d’expiration de la connexion.
[Microsoft] [SQL Server Native Client 11.0] Une erreur liée au réseau ou à l’instance s’est produite lors de l’établissement d’une connexion SQL Server. Le serveur n’est pas trouvé ou n’est pas accessible. Vérifiez si le nom de l’instance est correct SQL Server est configuré pour autoriser les connexions à distance. Pour plus d’informations, voir SQL Server Books Online.

Vous pouvez commencer à résoudre les problèmes à partir de cette section : Causes courantes de divers problèmes de connexion.

SQL Server’existe pas ou l’accès est refusé

Vous pouvez commencer à résoudre les problèmes à partir de cette section : Causes courantes de divers problèmes de connexion.

Échec de l’opération de tableau croisé dynamique : nous ne pouvons pas localiser un serveur pour charger le modèle de données du workbook

Vous pouvez commencer à résoudre les problèmes à partir de cette section : Causes courantes de divers problèmes de connexion.

Impossible de générer un message d’erreur de contexte SSPI

L’interface SSPI (Security Support Provider Interface) 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, le SSPI permet à un ordinateur exécutant un système d’exploitation Windows de déléguer en toute sécurité un jeton de sécurité utilisateur d’un ordinateur à un autre sur n’importe quelle couche de transport qui peut transmettre des octets bruts de données.
L’erreur de contexte SSPI impossible à générer est générée lorsque le SSPI utilise l’authentification Kerberos pour déléguer sur TCP/IP et que l’authentification Kerberos ne peut pas effectuer les opérations nécessaires pour déléguer correctement le jeton de sécurité utilisateur à l’ordinateur de destination qui exécute SQL Server.

Pour plus d’informations sur les raisons pour lesquelles les opérations Kerberos ne peuvent pas être effectuées, passer à la section Résolution des problèmes d’authentification en raison de problèmes Kerberos pour passer en revue et implémenter les étapes.

Résolution des problèmes d’authentification en raison de problèmes Kerberos

Des échecs d’authentification Kerberos peuvent se produire pour diverses raisons. Les causes principales et les résolutions correspondantes sont mises en évidence ci-dessous :

Type de problème Résolutions suggérées
Problèmes SPN :
  • SPN manquants : le SPN n’est pas enregistré dans Active Directory.
  • Entrées SPN incorrectes : le SPN existe, mais le numéro de port est incorrect ou il existe sur un autre compte que le compte SQL Service.
  • SPN en double : le même SPN existe sur plusieurs comptes dans active directory.
Consultez la section Utilisation du Gestionnaire de configuration Kerberos pour diagnostiquer et résoudre les problèmes de SPN et de délégation afin de diagnostiquer et de résoudre les problèmes de SPN.

Remarque Pour une compréhension approfondie des SNS, Kerberos et d’autres concepts connexes, examinez les informations de l’article de la base de connaissances suivant :
Comment résoudre le message d’erreur « Impossible de générer le contexte SSPI »
SQL de service non fiables 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 délégation du Gestionnaire de configurationKerberos pour confirmer et travailler avec votre administrateur Active Directory afin d’activer la délégation pour le compte. Consultez l’utilisation du Gestionnaire de configuration Kerberos pour diagnostiquer et résoudre les problèmes de SPN et de délégation pour plus d’informations dans le paragraphe suivant.
Résolution de nom incorrecte : le nom de votre serveur peut se résoudre en une adresse IP différente de celle inscrite par le serveur DNS de votre réseau. ping -a <your_target_machine> (utiliser -4 et -6 pour IPv4 et IPv6 spécifiquement)
ping -a <Your_remote_IPAddress> nslookup (tapez votre nom d’ordinateur local et distant et votre adresse IP plusieurs fois)

Recherchez les incohérences et les incohérences sur les résultats renvoyés. L’correctité de la configuration DNS sur le réseau est essentielle pour SQL connexion. Une entrée DNS erronée peut être à l’origine de toutes sortes de problèmes de connectivité ultérieurement.
Pare-feu ou autres périphériques réseau empêchant les connexions entre le client et le contrôleur de domaine : les SSN sont stockés dans Active Directory et si les clients ne parviennent pas à communiquer avec aD, la connexion ne peut pas poursuivre. Pour plus d’informations, consultez les liens suivants :

Notes

  1. Lorsqu’une instance du moteur de base de données SQL Server démarre, SQL Server tente d’inscrire le SPN pour le service SQL Server service. Lorsque l’instance est arrêtée, SQL Server tente d’désinsser le SPN. Pour ce faire, le compte SQL service a besoin des droits ReadServicePrincipalName et WriteServicePrincipalName dans l’annuaire actif. Toutefois, si le compte de service ne comprend pas ces droits, l’inscription automatique au SPN ne se produit pas et vous devez travailler avec votre administrateur Active Directory pour les inscrire pour les instances SQL afin d’activer l’authentification Kerberos. Dans ce scénario, si vous utilisez une instance nommée, il sera plus pratique d’utiliser un port statique pour cette instance. Si vous utilisez des ports dynamiques, le numéro de port peut changer chaque fois que le service est redémarré et que le SPN enregistré manuellement pour l’instance n’est plus valide. Pour plus d’informations, voir Register a Service Principal Name for Kerberos Connections.

  2. Dans les environnements où SQL est regroupée, l’inscription automatique des SPN n’est pas recommandée, car l’inscription du SPN dans Active Directory peut prendre plus de temps que le temps nécessaire à la mise en ligne de SQL. Si l’inscription du SPN ne se produit pas dans le temps, il se peut que l’SQL ne soit pas disponible en ligne, car l’administrateur de cluster ne peut pas se connecter SQL serveur.

Utilisation du Gestionnaire de configuration Kerberos pour diagnostiquer et résoudre les problèmes de SPN et de délégation

  1. Téléchargez Microsoft® Kerberos Configuration Manager pour SQL Server® et installez-le sur un ordinateur client.

  2. Lancez l’outil à l’aide d’un compte de domaine de préférence avec un compte qui dispose de privilèges suffisants pour créer des noms de service dans votre annuaire Active Directory. Consultez l’image ci-dessous :

    KerberosConfigManager

  3. Connectez-vous SQL Server vous souhaitez collecter les informations relatives aux erreurs Kerberos :

    ConnectKerberosConfigManager

  4. Une fois connecté, vous pouvez voir différents onglets comme indiqué ci-dessous :

    • Système: dispose des informations système de base.

      KerConfigManager_System

    • SPN : Fournit au SPN des informations sur les instances de chacune des instances de SQL trouvées sur le serveur cible et fournit différentes options, comme indiqué ci-dessous. Utilisez cet onglet pour rechercher les SNS 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 de génération de SPN. Cliquez sur le bouton Générer pour lancer la boîte de dialogue suivante :

        KerConfigManager_GenerateSPN

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

        Le contenu des generateSPNs sera similaire à ce 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>.com **SetSPN -s MSSQLSvc/<HostName>.<DomainName>.com UserName**
        

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

      • L’option de correction ajoute le SPN tant que vous avez le droit d’ajouter le SPN et affiche l’info-conseil suivante :  KerbConfigManager_Fix

        Notes

        L’outil fournit uniquement les options Fix et Generate pour les instances par défaut et les instances nommées avec des ports statiques. Pour les instances nommées utilisant le port dynamique, il est recommandé de passer de ports dynamiques à statiques ou de donner au compte de service les autorisations nécessaires pour enregistrer et désinsser le SPN chaque fois que le service est démarré. Sinon, vous devez désinsser manuellement l’inscription et réenregistrer les SNS correspondants à chaque fois que SQL service est démarré.

      • Onglet Délégation: l’onglet identifie les problèmes avec la configuration du compte de service pour la délégation. Cela est particulièrement utile pour résoudre les problèmes liés au serveur. Par exemple, si les SNS s’exécutent correctement mais que vous avez encore des problèmes avec des requêtes de serveur liées, cela peut indiquer que le compte de service n’est pas configuré pour déléguer les informations d’identification. Pour plus d’informations, ez la rubrique en ligne Livres sur la configuration des serveurs liés pour la délégation.

        KerbConfigManger_Delegation

  5. Une fois que vous avez corrigé les SPN, réexécutez l’outil Gestionnaire de configuration Kerberos et assurez-vous que les onglets SPN et Délégation ne signalent plus les messages d’erreur et retentent la connexion à partir de votre application.

Pour plus d’informations, examinez les liens suivants :

Si cela ne résout pas votre problème, déplacez-vous vers la section Toujours avoir des problèmes.

Échec de connexion pour l’utilisateur

Il peut y avoir une erreur plus spécifique. Sélectionnez l’erreur exacte que vous recevez :

Échec de connexion de l’utilisateur « AUTORITÉ NT\OUVERTURE DE SESSION ANONYME »

Il existe au moins trois scénarios pour ce problème. Utilisez le tableau suivant pour passer en compte chaque scénario applicable et suivre les étapes de résolution appropriées.

Cause potentielle Résolutions suggérées
Scénarios de double saut sur le même ordinateur : vous essayez d’utiliser un double saut, mais les informations d’identification NTLM sont utilisées à la place de Kerberos. Pour les scénarios de double saut sur le même ordinateur, ajoutez des entrées de Registre DisableLoopbackCheck ou BackConnectionHostNames comme suit :
Scénarios de double saut sur plusieurs ordinateurs : l’erreur peut se produire en cas d’échec des connexions Kerberos en raison de problèmes de SPN. Passer à la section : Résolution des problèmes d’authentification en raison de problèmes Kerberos en bas pour voir les détails.
Aucun double saut n’est impliqué. Si aucun double saut n’est impliqué, cela peut également signifier qu’il existe des SNS dupliqués et que le client s’exécute en tant que LocalSystem ou un autre compte d’ordinateur qui obtient les informations d’identification NTLM au lieu des informations d’identification Kerberos.

Passer à la section : Résolution des problèmes d’authentification en raison de problèmes Kerberos pour diagnostiquer et résoudre les problèmes de SPN.
La stratégie de sécurité locale Windows a peut-être été configurée pour empêcher l’utilisation du compte d’ordinateur pour les comptes locaux. Sur Windows 2008 R2/Windows 7 et les ultérieures, la sécurité réseau des options de sécurité des stratégies de sécurité locales peut être configurée pour ne pas utiliser le compte d’ordinateur pour les comptes locaux qui ne sont pas configurés ; il utiliserait plutôt les informations d’identification | | anonymes.

Si cela ne résout pas votre problème, déplacez-vous vers la section Toujours avoir des problèmes.

Échec de connexion pour le message de l’utilisateur « (null) »

Cela signifie que LSASS n’a pas pu déchiffrer le jeton de sécurité à l’aide des informations d SQL Server de compte de service. La raison principale est que le SPN est associé à un compte erroné.

Pour diagnostiquer et résoudre ces problèmes de SPN, déplacez-vous vers la section Résolution des problèmes d’authentification en raison des problèmes Kerberos.

Échec de connexion pour l’utilisateur est vide

Par exemple, vous pouvez voir une erreur semblable à ce qui suit :

Source: NETLOGON
Date: 8/12/2012 8:22:16 PM
Event ID: 5719
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: <computer name>
Description:This computer was not able to set up a secure session with a domain controller in domain due to the following: The remote procedure call was cancelled. This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator.
Empty string means that SQL tried to hand-off the credentials to LSASS but there was some problem. Either LSASS was not available or the domain controller could not be contacted.
Check the event logs on the client and the server machines to see if there are any network or Active Directory related messages around the time of failure and if you do, work with your domain administrator to fix the issues.

Si cela ne résout pas votre problème, déplacez-vous vers la section Toujours avoir des problèmes.

La connexion a échoué pour <username> l’utilisateur ' ou la connexion a échoué pour l’utilisateur <domain> \ <username> ' '

Si le nom de domaine n’est pas spécifié, il s’agit d’un SQL connexion. S’il est spécifié, il s’agit d’une connexion Windows-Integrated défaut. Examinez le tableau suivant pour déterminer les causes et les résolutions potentielles.

Cause Étapes de résolution
La base de données demandée est hors ligne ou n’est pas disponible. Vérifiez les autorisations et la disponibilité des bases de données dans SQL Server Management Studio.
L’utilisateur n’a pas d’autorisations sur la base de données demandée. Essayez de vous connecter en tant qu’autre utilisateur dispose de droits sysadmin.

Pour obtenir des conseils supplémentaires, examinez la résolution des problèmes : Échec de connexion pour l’utilisateur « x».

Si cela ne résout pas votre problème, déplacez-vous vers la section Toujours avoir des problèmes.

Échec de la connexion de l’utilisateur <domaine\nom_ordinateur$>'

Vous pouvez également le voir avec les applications IIS qui utilisent la connexion anonyme ou la connexion de formulaire où le compte d’utilisateur n’est pas usurpé. Le compte iis anonyme (IUSR) ou le compte du pool d’applications est à la place emprunt d’identité. Le compte IUSR est un compte local et le compte du pool d’applications peut également être un compte local.

Cette erreur se produit généralement si l’utilisateur est connecté avec un compte local plutôt qu’un compte de domaine. Si la connexion aux services est hors zone, les informations d’identification de l’ordinateur peuvent être transmises. Dans certains cas, vous pouvez ajouter ce compte en tant que connexion sur le serveur principal. Dans d’autres cas, vous pouvez vous connecter avec un compte de domaine et lui fournir les autorisations appropriées pour accéder au service distant.

Si cela ne résout pas votre problème, déplacez-vous vers la section Toujours avoir des problèmes.

Vérifier les erreurs d’expiration du délai d’expiration

L’erreur Expiration du délai d’expiration représente un ou plusieurs des messages d’erreur suivants :

Expiration du délai d’expiration. 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) : expiration du délai de connexion.
Le délai d’attente s’est écoulé lors de la tentative d’utiliser l’accusé de réception d’une connexion préalable.
Cela peut être dû à l’échec de la connexion préalable ou à l’échec de la réponse du serveur dans le temps.
La durée passée lors de la tentative de connexion à ce serveur était l’initialisation de [pré-connexion] = 23 ; handshake=14979; ---> System.ComponentModel.Win32Exception (0x80004005) : l’opération d’attente a été hors délai.

System.Data.SqlClient.SqlException (0x80131904) : expiration du délai d’expiration.
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) : l’opération d’attente a été hors délai.

Expiration du délai de connexion.
Le délai d’attente s’est écoulé lors de la tentative d’utiliser l’accusé de réception d’une connexion préalable.
Cela peut être dû à l’échec de la connexion préalable ou à l’échec de la réponse du serveur dans le temps.
La durée passée lors de la tentative de connexion à ce serveur était l’initialisation de [pré-connexion] =21036 ; handshake=0; (Microsoft SQL Server, Erreur : -2).

Notes

Les deuxième et troisième messages d’erreur se produisent lorsque .Net Framework 4.5 ou supérieur est installé.

Vous pouvez commencer à résoudre les problèmes à partir de la section suivante : Résolution des messages expirés de délai d’expiration.

Résolution des problèmes de messages expirés

Un délai d’délai est le moment où un quelque chose prend plus de temps qu’il n’est autorisé. Nous abandonnons essentiellement ce que nous essayions de faire pour ne pas attendre indéfiniment et éventuellement bloquer d’autres éléments et bloquer une application. Du point de vue de la connectivité, dans sa forme de base, nous pouvons voir cela de deux manières. L’un est un délai de connectivité, l’autre un délai d’accès à la requête. Vous devez donc d’abord examiner la pile d’appels complète du message d’erreur pour déterminer s’il s’agit d’un délai d’accès ou d’un délai d’accès à une commande.

Notes

Les valeurs par défaut de ces paramètres qui peuvent être définies par le biais du code, de la chaîne de connexion et d’autres méthodes sont les suivantes :

  • Délai de connexion : 15 secondes
  • Délai d’out de requête ou de commande : 30 secondes
  • Une pile d’appels de délai d’délai de connexion ressemble à ceci :

    System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
    at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
    at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
    at System.Data.SqlClient.TdsParserStateObject.ReadSniError(TdsParserStateObject stateObj, UInt32 error)
    at System.Data.SqlClient.TdsParserStateObject.ReadSni(DbAsyncResult asyncResult, TdsParserStateObject stateObj)
    at System.Data.SqlClient.TdsParserStateObject.ReadNetworkPacket()
    at System.Data.SqlClient.TdsParser.ConsumePreLoginHandshake(Boolean encrypt,Boolean trustServerCert, Boolean& marsCapable)
    at System.Data.SqlClient.TdsParser.Connect(ServerInfo serverInfo, SqlInternalConnectionTds connHandler, Boolean ignoreSniOpenTimeout, Int64 timerExpire, Boolean encrypt, Boolean trustServerCert, Boolean integratedSecurity, SqlConnectionowningObject)
    at System.Data.SqlClient.SqlInternalConnectionTds.AttemptOneLogin(ServerInfoserverInfo, String newPassword, Boolean ignoreSniOpenTimeout, Int64 timerExpire, SqlConnection owningObject)
    at System.Data.SqlClient.SqlInternalConnectionTds.LoginNoFailover(String host, String newPassword, Boolean redirectedUserInstance, SqlConnection owningObject, SqlConnectionString connectionOptions, Int64 timerStart)
    at System.Data.SqlClient.SqlInternalConnectionTds.OpenLoginEnlist(SqlConnection owningObject, SqlConnectionString connectionOptions, String newPassword, Boolean redirectedUserInstance)
    at System.Data.SqlClient.SqlInternalConnectionTds..ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, Object providerInfo, String newPassword, SqlConnection owningObject, Boolean redirectedUserInstance)
    at System.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection)
    at System.Data.ProviderBase.DbConnectionFactory.CreatePooledConnection(DbConnection owningConnection, DbConnectionPool pool, DbConnectionOptions options)  
    at System.Data.ProviderBase.DbConnectionPool.CreateObject(DbConnection owningObject) at System.Data.ProviderBase.DbConnectionPool.UserCreateRequest(DbConnection owningObject)
    at System.Data.ProviderBase.DbConnectionPool.GetConnection(DbConnection owningObject)
    at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)
    at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
    at System.Data.SqlClient.SqlConnection.Open() <-- SqlConnection along with Open tells us that we are trying to open a connection. So, this is not related to a query.  
    
  • Un délai d’accès à la commande dans .NET 2.0 Framework ressemble à ceci :

    System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
    at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
    at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
    at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
    at System.Data.SqlClient.SqlDataReader.ConsumeMetaData()
    at System.Data.SqlClient.SqlDataReader.get_MetaData()
    at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString) at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)
    at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result)
    at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
    at System.Data.SqlClient.SqlCommand.ExecuteScalar() <-- SqlCommand is used to work with a query, not a connection. ExecuteScalar is used to actually execute a query. You could also see other items like an ExecuteReader or ExecuteNonQuery for example.
    

Étapes de résolution : ces deux problèmes peuvent être liés à l’environnement ou SQL Server problèmes. Par exemple, il peut s’agit d’un réseau lent ou d’un problème de performances de requête. Il n’existe pas de règles strictes et rapides, car ce qui pourrait être fait ici et d’autres enquêtes peuvent être nécessaires quant à ce qui pourrait être à l’origine du problème. Il est beaucoup plus courant d’augmenter le délai d’out de requête que d’augmenter le délai de connexion. En effet, lorsque vous essayez de vous connecter à une source de données, la connexion se produit généralement rapidement (généralement en quelques millisecondes).

Type Choses à faire
Délai de connexion
1. Augmentez ConnectionTimout dans votre application.
2. Vérifiez si le port utilisé par SQL est bloqué sur le réseau à l’aide d’un outil tel que Portqry. Pour obtenir des instructions sur son utilisation, SQL Server à l’aide de l’outil PortqryUI.
Délai d’out de la commande
Augmentez la valeur CommandTimeout dans votre application et a affiner les requêtes exécutées sur le back-end.

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

Si cela ne résout pas votre problème, déplacez-vous vers la section Toujours avoir des problèmes.

Délai d’attente écoulé avant l’obtention d’une connexion à partir du pool

Elle est généralement causée si les connexions ne sont pas correctement fermées et que l’erreur complète peut ressembler à ce qui suit :

System.InvalidOperationException : expiration du délai d’expiration. Le délai d’attente s’est écoulé avant l’obtention d’une connexion à partir du pool.

Cela peut être dû au fait que toutes les connexions en pool étaient en cours d’utilisation et que la taille maximale du pool a été atteinte. Cela peut généralement être évité par expiration du délai d’expiration. Le délai d’attente s’est écoulé avant l’obtention d’une connexion à partir du pool.

Si cela ne résout pas votre problème, déplacez-vous vers la section Toujours avoir des problèmes.

Se connecter à SQL serveur à l’aide d’un fichier UDL

Pour plus d’informations sur le test des connexions à SQL Server à l’aide d’un fichier de liaison de données universelle, voir les connexions de test suivantes à SQL Server à l’aide d’une section de fichier de liaison de données universelle.

Les fichiers UDL offrent un moyen simple et efficace de tester les connexions à votre serveur SQL à partir de vos clients ou d’autres systèmes.

  1. Activez l’option pour afficher les extensions de fichier dans votre explorateur Windows. Pour ce faire :

    1. Sur les systèmes Windows 8 et ultérieurs : allez à Options de l’Explorateur de fichiers dans le Panneau de contrôle ou tapez simplement Masquer dans la recherche Windows et, dans l’onglet Affichage, décochez Masquer les extensions pour les types de fichiers connus.

    2. Windows 7 et versions antérieures :

      Win7ViewExtFile

  2. Accédez au dossier dans lequel vous souhaitez créer le fichier de liaison de données universelle (.udl) (par exemple c:\temp)

  3. Créez un fichier texte (sqlconn.txt) et renommez l’extension .txt en .udl. (cliquez sur Oui pour le message d’avertissement concernant la modification de l’extension de nom de fichier)

  4. Double-cliquez sur le fichier .udl de l’étape 3 et faites ce qui suit :

    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 SQL Server et le reste des paramètres pertinents pour votre application
  5. Cliquez ensuite sur Tester la connexion.

Pour plus d’informations et de captures d’écran, consultez le billet de blog suivant sur MSDN :
Informations de base : « Test UDL »

Si cela ne résout pas votre problème, déplacez-vous vers la section Toujours avoir des problèmes.

Encore des problèmes

Nous sommes désolés que ce guide ne vous ait pas permis de résoudre votre problème. Nous vous recommandons d’aller à la Communauté SQL Microsoft pour obtenir de l’aide. Voici quelques ressources supplémentaires que vous pourriez trouver utiles :