MSSQLSERVER_18456

S’applique à :SQL Server

Détails

Explication

Vous recevez ce message d’erreur lorsqu’une tentative de connexion est rejetée en raison d’un échec d’authentification. Les connexions utilisateur peuvent échouer pour de nombreuses raisons, telles que les informations d’identification non valides, l’expiration du mot de passe et l’activation du mode d’authentification incorrect. Dans de nombreux cas, les codes d’erreur incluent des descriptions.

Action utilisateur

Voici quelques-uns des échecs de connexion courants. Sélectionnez l’erreur exacte que vous rencontrez pour résoudre le problème :

• Échec de la connexion pour l’utilisateur «< nom d’utilisateur> » ou échec de la connexion pour l’utilisateur «< domain>\<username> »

• Échec de la connexion pour l’utilisateur « NT AUTHORITY\ANONYMOUS » LOGON

• Échec de la connexion pour l’utilisateur « vide »

• Échec de la connexion pour l’utilisateur '(null)'

Échec de la connexion pour l’utilisateur «< nom d’utilisateur> » ou échec de la connexion pour l’utilisateur «< domain>\<username> »

Si le nom de domaine n’est pas spécifié, le problème est une tentative de connexion SQL Server défaillante. Si le nom de domaine est spécifié, le problème est un échec de connexion au compte d’utilisateur Windows. Pour connaître les causes potentielles et les résolutions suggérées, consultez :

En outre, case activée la liste complète des codes d’erreur lors de la résolution des problèmes d’erreur 18456.

Pour plus d’informations sur la résolution des problèmes, consultez Résolution des problèmes de Connecter ivity sql Client /Server.

Échec de la connexion pour l’utilisateur NT AUTHORITY\ANONYMOUS LOGON

Il existe au moins quatre scénarios pour ce problème. Dans le tableau suivant, examinez chaque cause potentielle applicable et utilisez la résolution appropriée : consultez la note ci-dessous pour obtenir une explication du terme double tronçon.

Échec de la connexion pour l’utilisateur (vide)

Cette erreur se produit lorsqu’un utilisateur tente de se connecter sans succès. Cette erreur peut se produire si votre ordinateur n’est pas connecté au réseau. Par exemple, vous pouvez recevoir un message d’erreur semblable à celui-ci :

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.

Une chaîne vide signifie que SQL Server a essayé de transmettre les informations d’identification au service de sous-système de l’autorité de sécurité locale (LSASS), mais qu’il n’a pas pu en raison d’un problème. LSASS n’était pas disponible ou le contrôleur de domaine n’a pas pu être contacté.

Vous pouvez également voir les codes d’erreur SSPI correspondants suivants :

Échec de la négociation SSPI avec le code d’erreur 0x80090311 lors de l’établissement d’une connexion avec une sécurité intégrée ; la connexion a été fermée.

Échec de la négociation SSPI avec le code d’erreur 0x80090304 lors de l’établissement d’une connexion avec une sécurité intégrée ; la connexion a été fermée.

Ces codes d’erreur se traduisent comme suit :

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.

Pour résoudre ces erreurs, vous pouvez prendre le contrôleur de domaine incriminé hors connexion ou utiliser NLTEST.EXE pour changer de contrôleur de domaine. - Pour interroger le contrôleur de domaine, exécutez la NLTEST /SC_QUERY:CONTOSO commande. - Pour modifier le contrôleur de domaine, exécutez la NLTEST /SC_RESET:CONTOSO\DC03 commande.

Si vous avez besoin d’aide supplémentaire, contactez l’équipe Microsoft Active Directory.

Vérifiez les journaux des événements sur le client et le serveur pour tous les messages liés au réseau ou liés à Active Directory enregistrés au moment de l’échec. Si vous le trouvez, collaborez avec votre administrateur de domaine pour résoudre les problèmes.

Échec de la connexion pour l’utilisateur '(null)'

Une indication de « null » peut signifier que LSASS ne peut pas déchiffrer le jeton de sécurité à l’aide des informations d’identification du compte de service SQL Server. La raison principale de cette condition est que le SPN est associé au compte incorrect.

Pour résoudre ce problème, effectuez les étapes suivantes :

1. Utilisez SQLCheck ou Setspn.exe pour diagnostiquer et résoudre les problèmes liés au SPN.

2. Utilisez SQLCheck pour case activée si le compte de service SQL est approuvé pour la délégation. Si la sortie indique que le compte n’est pas approuvé pour la délégation, collaborez avec votre administrateur Active Directory pour activer la délégation pour le compte.

1. Diagnostiquer et résoudre les problèmes de résolution de noms DNS (Domain Name System). Par exemple :

   • Adresse IP ping à l’aide de scripts PowerShell :

     • ping -a <your_target_machine> (utilisation -4 pour IPv4 et -6 IPv6 spécifiquement)
     • ping -a <your_remote_IPAddress>

   • Utilisez NSLookup pour entrer plusieurs fois le nom et l’adresse IP de votre ordinateur local et distant.

2. Recherchez les différences et les incompatibilités dans les résultats retournés. La précision de la configuration DNS sur le réseau est importante pour une connexion SQL Server réussie. Une entrée DNS incorrecte peut entraîner de nombreux problèmes de connectivité ultérieurement.

3. Assurez-vous que les pare-feu ou d’autres appareils réseau ne bloquent pas un client de se connecter au contrôleur de domaine. Les spN sont stockés dans Active Directory. Si les clients ne peuvent pas communiquer avec le répertoire, la connexion ne peut pas réussir.

Informations supplémentaires sur les erreurs

Pour des raisons de sécurité, le message d'erreur retourné au client masque délibérément la nature de l'erreur d'authentification. Toutefois, dans le journal des erreurs SQL Server, une erreur correspondante contient un état d’erreur qui correspond à une condition d’échec d’authentification. Comparez l'état d'erreur à la liste suivante afin de déterminer la raison de l'échec de connexion.

Il existe d'autres états d'erreurs qui signifient une erreur de traitement interne inattendue.

Cause plus rare possible

La raison de l’erreur d’échec d’une tentative de connexion à l’aide de l’authentification SQL. Le serveur est configuré pour Authentification Windows uniquement. Peut être retourné dans les situations suivantes.

• Lorsque le serveur est configuré pour l’authentification en mode mixte, et qu’une connexion ODBC utilise le protocole TCP et que la connexion ne spécifie pas explicitement que la connexion doit utiliser une connexion approuvée.

• Quand SQL Server est configuré pour l’authentification en mode mixte et qu’une connexion ODBC utilise des canaux nommés, et les informations d’identification utilisées par le client pour ouvrir le canal nommé sont utilisées pour emprunter automatiquement l’identité de l’utilisateur, et l’chaîne de connexion ne spécifie pas explicitement l’utilisation d’une authentification approuvée.

Pour résoudre ce problème, incluez TRUSTED_CONNECTION = TRUE dans la chaîne de connexion.

Exemples

Dans cet exemple, l'état d'erreur d'authentification est 8. Cela indique que le mot de passe est incorrect.

Voir aussi

• 0420 Raisons de problèmes d’authentification cohérents