Partager via

Problèmes d’authentification intermittents ou périodiques dans SQL Server

  • Article

Note

Avant de commencer à résoudre un problème, nous vous recommandons de consulter les prérequis et de parcourir la liste de vérification. Pour plus d’informations, consultez les articles d’aide autonome.

Cet article décrit les causes courantes des problèmes d’authentification intermittente dans la connectivité SQL Server et fournit des solutions.

Symptômes

Des problèmes d’authentification intermittents ou périodiques dans la connectivité SQL Server se produisent lorsque des utilisateurs ou des applications rencontrent des difficultés sporadiques lors de l’authentification avec la base de données SQL Server. Cela provoque des interruptions dans l’accès aux données et les fonctionnalités d’application.

Messages d’erreur les plus courants

  • Impossible de générer un contexte SSPI

  • Échec de la connexion pour l’utilisateur

    • Échec de la connexion pour l’utilisateur « »
    • Échec de la connexion pour l'utilisateur 'NT AUTHORITY\ANONYMOUS LOGON'
    • Échec de la connexion pour l’utilisateur «< UserName> »
    • Échec de la connexion pour l’utilisateur «< Domain>\<UserName> »
    • Échec de la connexion. La connexion provient d’un domaine non approuvé et ne peut pas être utilisée avec Authentification Windows.

Cause

Les problèmes les plus courants sont causés par les performances de SQL Server ou la réponse lente du contrôleur de domaine. Si vous utilisez NT LAN Manager (NTLM), le service de sous-système de l’autorité de sécurité locale (LSASS) a un goulot d’étranglement et limite le nombre de nouvelles connexions à la fois. D’autres demandes sont sauvegardées et peuvent expirer. Certaines causes, telles que l’antivirus, peuvent être difficiles à prouver, mais sont toujours courantes et doivent être examinées même sans preuve dure si d’autres avenues d’enquête sont inefficaces.

Processus de résolution des problèmes

Étant donné que le problème est intermittent, il est probable que la configuration, telle que les noms de principal de service Kerberos (SPN), soit correcte. Pour résoudre ce problème, essayez les étapes de résolution des problèmes suivantes :

Différence de latence entre plusieurs domaines ou centres de données

Si plusieurs domaines ou centres de données sont impliqués, vérifiez si les utilisateurs du domaine local ou du centre de données ne rencontrent pas le problème alors que les utilisateurs d’autres domaines ou centres de données le font. Dans ce cas, il peut indiquer une latence de communication entre les centres de données ou les contrôleurs de domaine. Utilisez les commandes suivantes pour examiner le problème :

  • Pour vérifier la latence du réseau, utilisez ping. Par exemple :

    1. Exécuter la commande : ping <DatabaseServer>.

    2. Examinez la colonne de temps et comparez cette heure à celle-ci dans l’autre domaine ou centre de données :

      Pinging <DatabaseServer> [10.10.10.3] with 32 bytes of data:
Reply from 10.10.10.3: bytes=32 time=68ms TTL=116
Reply from 10.10.10.3: bytes=32 time=67ms TTL=116
Reply from 10.10.10.3: bytes=32 time=67ms TTL=116

  • Pour tester les problèmes de latence de validation des informations d’identification, utilisez Runas avec différents utilisateurs. Par exemple :

    1. Exécutez runas /user:<DomainName>\<UserAccountName> cmd.exe.
    2. Entrez le mot de passe de l’utilisateur après qu’une invite de commandes s’affiche.

Si le problème persiste même après le test avec ces commandes, le problème n’est pas avec SQL Server, mais avec les performances de l’infrastructure réseau ou du contrôleur de domaine.

Rechercher un problème de performances dans le journal des erreurs SQL Server

Le journal des erreurs SQL Server peut révéler des problèmes de performances sur SQL Server, tels que des entrées indiquant des E/S prenant plus de 15 secondes. L’équipe SQL Performance a PSSDIAG pour exécuter et analyser. Vous devrez peut-être effectuer cette opération si une trace réseau révèle des retards dans les réponses SQL Server.

Le journal des erreurs peut également inclure d’autres erreurs liées au domaine, telles que le journal des erreurs suivant qui indique certains problèmes de performances Active Directory :

SSPI handshake failed with error code 0x80090311 while establishing a connection with integrated security; the connection has been closed.
SSPI handshake failed with error code 0x80090304 while establishing a connection with integrated security; the connection has been closed.

Les codes d’erreur du système d’exploitation suivants indiquent la cause de l’échec :

  • Erreur -2146893039 (0x80090311) : aucune autorité n’a pu être contactée pour l’authentification.

  • Erreur -2146893052 (0x80090304) : l’autorité de sécurité locale ne peut pas être contactée.

Examiner les journaux des événements sur le système client pour les erreurs réseau

Le journal des événements système comporte différents événements, tels que Kerberos, l’autorité de sécurité locale (LSA) et les événements Netlogon. Ces événements indiquent que l’ordinateur ne peut pas se connecter au contrôleur de domaine pendant un certain temps. Pour faciliter leur recherche, filtrez uniquement les événements Erreur, Avertissement et Critique . L’heure de l’événement doit être autour du moment de la panne. S’il existe une correspondance, il peut s’agir d’un problème Active Directory.

Dans certains cas, ce problème peut se produire sur SQL Server. Vérifiez également les journaux d’activité sur cet ordinateur.

Source: NETLOGON
Date: <DateTime>
Event ID: 5719
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: SQLPROD01
Description:
This computer was not able to set up a secure session with a domain controller in domain CONTOSO 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.

Dans le journal des événements de sécurité, filtrez l’ID d’événement 4625. Cet événement affiche des informations détaillées sur l’échec de connexion.

Collecter et passer en revue la mémoire tampon d’anneau de connectivité SQL

La mémoire tampon en anneau est un journal historique des événements de connexion sur SQL Server, ce qui signifie qu’il peut être pris après une panne. De nombreux événements incluent des minuteurs de connexion qui vous indiquent où le temps est passé :

  • Le temps passé sur le réseau indique une latence possible du réseau ou du client.
  • Le temps passé sur les API SSL (Secure Sockets Layer) ou SSPI (Security Support Provider Interface) indique des problèmes potentiels avec le sous-système de sécurité Windows.
  • L’heure en file d’attente indique un problème de performances SQL Server.

Pour plus d’informations, consultez Collecter la mémoire tampon en anneau de connectivité.

Regroupement de connexions

Le manque de regroupement de connexions peut entraîner des échecs de connexion intermittents.

Note

L’absence de regroupement de connexions affiche un grand nombre de codes d’état TIME_WAIT dans la NETSTAT sortie par rapport aux connexions établies.

Si le regroupement de connexions n’est pas activé, le client peut manquer de ports sortants et également surcharger le serveur. Cette surcharge peut entraîner le rejet par le serveur des demandes de connexion entrantes ou l’inondation d’un contrôleur de domaine mal performant.

La meilleure chose à faire est que le développeur d’applications utilise le regroupement de connexions dans ses applications. Le regroupement de connexions est activé par défaut dans les applications .NET et Internet Information Services (IIS), mais il a peut-être été désactivé pour une raison quelconque.

Il est fortement déconseillé aux applications d’utiliser du code de regroupement personnalisé. Presque toutes les implémentations de regroupement personnalisées que nous avons rencontrées ont rencontré des problèmes. Il est préférable d’utiliser le mécanisme de regroupement de connexions intégré.

L’épuisement des ports éphémères est une cause relativement courante des délais d’attente de connexion intermittents.

Problème : mémoire du noyau faible sur l’ordinateur SQL Server.

Solution : ajustez la mémoire maximale du serveur (Mo) dans le volet Propriétés de SQL Server Management Studio. Il est préférable de définir la mémoire maximale du serveur (Mo) sur environ 4 Go à 8 Go de moins que la mémoire physique sur l’ordinateur. Cette valeur doit être inférieure si plusieurs instances, IIS ou d’autres serveurs d’applications s’exécutent sur l’ordinateur. Pour obtenir des recommandations sur le paramètre max server memory (Mo), consultez les options de configuration de la mémoire du serveur.

Note

La valeur par défaut est 2147483647 MB, ce qui signifie que le serveur peut entraîner l’exécution du système d’exploitation (OS) en mémoire insuffisante.