MSSQLSERVER_18456
S'applique à : 
SQL Server
Détails
| Attribut | Valeur |
|---|---|
| Nom du produit | SQL Server |
| ID de l’événement | 18456 |
| Source de l’événement | MSSQLSERVER |
| Composant | SQLEngine |
| Nom symbolique | LOGON_FAILED |
| Texte du message | Échec de la connexion pour l’utilisateur '%.*ls'.%.*ls |
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> »
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 :
| Cause potentielle. | Résolution suggérée |
|---|---|
| Vous essayez d’utiliser l’authentification SQL Server, mais l’instance SQL Server est configurée pour le mode d’authentification Windows. | Vérifiez que SQL Server est configuré pour utiliser le mode d’authentification SQL Server et Windows. Vous pouvez passer en revue et modifier le mode d’authentification de votre instance SQL Server dans la page Sécurité sous Propriétés de l’instance correspondante dans SQL Server Management Studio (SSMS). Pour plus d'informations, consultez Modifier le mode d'authentification du serveur. Vous pouvez également modifier votre application pour utiliser le mode d’authentification Windows pour vous connecter à SQL Server. Remarque : Vous pouvez voir un message semblable à celui suivant dans le journal des erreurs SQL Server pour ce scénario : Login failed for user '<UserName>'. Reason: An attempt to login using SQL authentication failed. Server is configured for Windows authentication only. |
| Vous essayez d’accéder à SQL Server via un groupe et vous voyez un message d’erreur. | Si vous n’avez pas les autorisations nécessaires pour accéder au serveur, le fournisseur affiche le message d’erreur « Échec de connexion pour l’utilisateur « contoso/user1 ». Utilisez la fonctionnalité « Accès via un groupe » qui vous permet d’accéder à un serveur en fonction de l’appartenance à votre groupe. Lorsque vous exécutez la xp_logininfo 'contoso/user1' procédure stockée, les éléments suivants peuvent se produire :- Si vous voyez une erreur, SQL Server ne peut pas résoudre le nom d’utilisateur du tout. Il est probable qu’un nom ne soit pas présent dans Active Directory (AD) ou qu’il peut y avoir des problèmes de connexion au contrôleur de domaine (DC). Essayez avec un autre nom pour vérifier si le problème est spécifique à un compte spécifique. - Si vous vous connectez à un serveur inter-domaines, le groupe doit se trouver dans le domaine SQL Server, et non dans le domaine utilisateur, afin que son appartenance puisse être résolue. - Lorsqu’une requête de base de données ne retourne aucune ligne, cela signifie qu’il n’existe aucun groupe qui fournit l’accès au serveur. Lorsqu’une requête retourne une ou plusieurs lignes, cela signifie que l’utilisateur appartient à un groupe qui fournit l’accès. L’administrateur de base de données peut double-vérifier les autorisations en vérifiant le dossier Security\Logins dans SQL Server Management Studio (SSMS). Security \Logins affiche la liste des connexions créées. S’il s’agit d’une base de données autonome, l’administrateur de base de données peut vérifier la sécurité\Connexions sous le nom de la base de données pour vérifier et gérer les connexions. Pour plus d’informations, consultez Configurer le contrôle d’accès utilisateur et les autorisations. |
| Les connexions SQL ne sont pas activées | Le système de gestion de base de données (SGBD) peut présenter une variante du Login failed for user '<username>' message. Pour résoudre cette erreur, procédez comme suit :1. Vérifiez si le journal des erreurs SQL Server contient le message d’erreur « Échec de la connexion pour l’utilisateur «< nom d’utilisateur> ». Raison : échec d’une tentative de connexion à l’aide de l’authentification SQL. Le serveur est configuré pour Authentification Windows uniquement. » 2. Utilisez l’une des méthodes suivantes pour résoudre l’erreur : - Utiliser une connexion intégrée. Par exemple, pour les fournisseurs OLE DB, ajoutez INTEGRATED SECURITY=SSPI au chaîne de connexion et pour les pilotes ODBC.TRUSTED_CONNECTION=YES Le fournisseur .NET accepte l’une ou l’autre syntaxe.Remarque : cela peut entraîner d’autres problèmes s’ils ne sont pas configurés correctement pour autoriser l’authentification intégrée et avoir besoin d’examiner en tant que problème distinct. - Activez les connexions SQL sur le serveur : a. Dans SQL Server Management Studio, cliquez avec le bouton droit sur le nom de SQL Server dans l’Explorateur d’objets, puis sélectionnez Propriétés. b. Dans le volet Sécurité , sélectionnez le mode d’authentification SQL Server et Windows. c. Cliquez sur OK. d. Redémarrez SQL Server pour que la modification se produise. Remarque : cela peut entraîner d’autres problèmes, tels que la définition d’une connexion SQL. - Essayez de spécifier un compte Windows local ou un compte de domaine pour le nom d’utilisateur. Seules les connexions SQL sont autorisées. L’application doit utiliser la sécurité intégrée. |
| La connexion n’existe pas sur l’instance SQL Server à laquelle vous essayez de vous connecter. | Vérifiez que la connexion SQL Server existe et que vous l’avez saisie correctement. Si l’identifiant de connexion n’existe pas, créez-le. S’il est présent mais mal saisi, corrigez cela dans l’application chaîne de connexion. Le journal des erreurs SQL Server aura l’un des messages suivants : - Login failed for user 'username'. Reason: Could not find a login matching the name provided.- Login failed for user 'Domain\username'. Reason: Could not find a login matching the name provided.Cela peut s’avérer un problème courant si vous déployez une application qui utilise un serveur DEV ou QA en production et que vous ne parvenez pas à mettre à jour le chaîne de connexion. Pour résoudre ce problème, confirmez que vous vous connectez au serveur approprié. Sinon, corrigez la chaîne de connexion. Si c’est le cas, accordez l’accès de connexion à votre SQL Server. Ou s’il s’agit d’une connexion Windows, accordez l’accès directement ou ajoutez-le à un groupe local ou groupe de domaine autorisé à se connecter au serveur de base de données. Pour plus d’informations, consultez Créer un compte de connexion. |
| Vous utilisez l’authentification SQL Server, mais le mot de passe que vous avez spécifié pour la connexion SQL Server est incorrect. | Vérifiez le journal des erreurs SQL pour les messages tels que « Motif : Mot de passe ne correspond pas à celui de la connexion fournie » pour confirmer la cause. Pour résoudre le problème, utilisez le mot de passe correct dans votre application ou utilisez un autre compte si vous ne vous souvenez pas du mot de passe. Vous pouvez également utiliser votre administrateur SQL Server pour réinitialiser le mot de passe du compte. Si l’application est SQL Server Integration Services (SSIS), il peut y avoir plusieurs niveaux de fichier de configuration pour le travail, ce qui peut remplacer les paramètres de Gestionnaire des connexions du package. Si l’application a été écrite par votre entreprise et que le chaîne de connexion est généré par programme, engagez l’équipe de développement pour résoudre le problème. En guise de solution de contournement temporaire, codez en dur la chaîne de connexion et testez. Utilisez un fichier UDL ou un script pour prouver qu’une connexion est possible avec un chaîne de connexion codé en dur. |
| Le chaîne de connexion a une syntaxe incorrecte, un nom de serveur ou des informations d’identification utilisateur. | Pour résoudre ce problème, procédez comme suit :
|
| Aucune connexion | Vérifiez si SQL Server affiche les messages suivants :Logon Error: 18456, Severity: 14, State: 11.Logon Login failed for user 'CONTOSO\JohnDoe'. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors. [CLIENT: ]Certaines erreurs appartiennent au compte d’ouverture de session anonyme. Cela est lié au problème Kerberos. Il y avait une entrée manuelle incorrecte dans le fichier HOSTS, autrement dit, le nom de serveur incorrect a été donné. Les problèmes restants peuvent se trouver dans les catégories suivantes :
|
| Vous essayez de vous connecter à l’aide de Authentification Windows, mais vous êtes connecté à un domaine incorrect. | Vérifiez que vous êtes correctement connecté au domaine approprié. Le message d’erreur affiche généralement le nom de domaine. |
| Vérifier les autorisations de base de données | La base de données n’apparaît pas hors connexion dans SQL Server Management Studio. D’autres utilisateurs, par exemple, l’administrateur de base de données peut se connecter à celui-ci. Le compte d’utilisateur en question doit disposer d’un accès explicite à la base de données ou être ajouté à un rôle SQL Server ou à un groupe de domaine Windows local qui a accès à la base de données. Pour plus d’informations, consultez CREATE USER, ALTER ROLE et ALTER SERVER ROLE |
| Vous n’exécutez pas votre application (par exemple, SSMS) en tant qu’administrateur. | Si vous essayez de vous connecter à l’aide de vos informations d’identification d’administrateur, démarrez votre application à l’aide de l’option Exécuter en tant qu’administrateur . Une fois connecté, ajoutez votre utilisateur Windows en tant que connexion individuelle. |
| La connexion est supprimée après une migration vers un utilisateur de base de données autonome. | Si le Moteur de base de données prend en charge les bases de données autonomes, vérifiez que la connexion n’a pas été supprimée après la migration vers un utilisateur de base de données autonome. Pour plus d’informations, consultez l’authentification de base de données autonome : Introduction. |
| La base de données par défaut de la connexion est hors connexion ou n’est pas disponible. | Contactez votre administrateur SQL Server et résolvez les problèmes liés à la disponibilité de la base de données. Si la connexion dispose d’autorisations sur d’autres bases de données sur le serveur et que vous n’avez pas besoin d’accéder à la base de données par défaut actuellement configurée dans votre application, utilisez l’une des options suivantes : - Demandez à l’administrateur de modifier la base de données par défaut pour la connexion à l’aide de l’instruction ALTER LOGIN ou de SSMS. - Spécifiez explicitement une autre base de données dans votre application chaîne de connexion. Ou si vous utilisez SSMS, basculez vers l’onglet Propriétés de connexion pour spécifier une base de données actuellement disponible.Les applications telles que SSMS peuvent afficher un message d’erreur comme celui suivant : Cannot open user default database. Login failed.Login failed for user <user name>. (Microsoft SQL Server, Error: 4064)Le journal des erreurs SQL Server aura un message d’erreur semblable à celui-ci : Login failed for user '<user name>'. Reason: Failed to open the database '<dbname>' specified in the login properties [CLIENT: <ip address>]Pour plus d’informations, consultez MSSQLSERVER_4064. |
| La base de données explicitement spécifiée dans le chaîne de connexion ou dans SSMS n’est pas correctement orthographié, hors connexion ou non disponible. | - Corrigez le nom de la base de données dans la chaîne de connexion. Attention à la sensibilité de la casse si vous utilisez un classement sensible à la casse sur le serveur. - Si le nom de la base de données est correct, contactez votre administrateur SQL Server et résolvez les problèmes liés à la disponibilité de la base de données. Vérifiez si la base de données est hors connexion, non récupérée, et ainsi de suite. - Si la connexion a été mappée aux utilisateurs disposant d’autorisations sur d’autres bases de données sur le serveur et que vous n’avez pas besoin d’accéder à la base de données actuellement configurée dans votre application, spécifiez une autre base de données dans votre chaîne de connexion. Ou si vous vous connectez avec SSMS, utilisez l’onglet Propriétés de connexion pour spécifier une base de données actuellement disponible. Le journal des erreurs SQL Server aura un message d’erreur semblable à celui-ci : Login failed for user <UserName>. Reason: Failed to open the explicitly specified database 'dbname'. [CLIENT: <ip address>]Remarque : Si la base de données par défaut de la connexion est disponible, SQL Server permet à la connexion de réussir. Pour plus d’informations, consultez MSSQLSERVER_4064. |
| L’utilisateur n’a pas d’autorisations pour la base de données demandée. | - Essayez de vous connecter en tant qu’autre utilisateur disposant de droits sysadmin pour voir si la connectivité peut être établie. - Accorder l’accès de connexion à la base de données en créant l’utilisateur correspondant (par exemple, CREATE USER [<UserName>] FOR LOGIN [UserName]) |
Vérifiez également la liste complète des codes d’erreur lors de la résolution des problèmes 18456.
Pour plus d’informations sur la résolution des problèmes, consultez Résolution des problèmes de connectivité SQL Client/Serveur.
É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.
| Causes possibles | Résolutions suggérées |
|---|---|
| Vous essayez de transmettre les informations d’identification NT LAN Manager (NTLM) d’un service à un autre service sur le même ordinateur (par exemple , d’IIS vers SQL Server), mais une défaillance se produit dans le processus. | Ajoutez les entrées de Registre DisableLoopbackCheck ou BackConnectionHostNames . |
| Il existe des scénarios de double tronçon (délégation de contrainte) sur plusieurs ordinateurs. L’erreur peut se produire si la connexion Kerberos échoue en raison de problèmes de noms de principal de service (SPN). | Exécutez SQLCheck sur chaque serveur SQL Server et le serveur web. Utilisez les guides de résolution des problèmes : problème de délégation d’informations d’identification 0600 et 0650 problèmes de délégation de serveur lié SQL Server. |
| Si aucune délégation de double tronçon (délégation de contrainte) n’est impliquée, il existe probablement des SPN dupliqués et le client s’exécute en tant que localSystem ou un autre compte d’ordinateur qui obtient des informations d’identification NTLM au lieu des informations d’identification Kerberos. | Utilisez SQLCheck ou Setspn.exe pour diagnostiquer et résoudre les problèmes liés au SPN. Consultez également la vue d’ensemble du Gestionnaire de configuration Kerberos pour SQL Server. |
| 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 demandes d’authentification à distance. | Accédez à La sécurité réseau des stratégies>locales de stratégie de sécurité>locale>: autoriser le système local à utiliser l’identité de l’ordinateur pour NTLM, sélectionnez l’option Activé si le paramètre est désactivé, puis sélectionnez OK. Remarque : Comme indiqué dans l’onglet Explication , cette stratégie est activée dans Windows 7 et versions ultérieures par défaut. |
| L’occurrence intermittente de ce problème lors de l’utilisation d’une délégation contrainte peut indiquer la présence d’un ticket expiré qui ne peut pas être renouvelé par niveau intermédiaire. Il s’agit d’un comportement attendu avec un scénario de serveur lié ou toute application qui contient une session d’ouverture de session pendant plus de 10 heures. | Modifiez les paramètres de délégation sur votre serveur de niveau intermédiaire de l’approbation de cet ordinateur pour la délégation aux services spécifiés uniquement - Utilisez Kerberos uniquement pour approuver cet ordinateur pour la délégation aux services spécifiés uniquement - Utilisez n’importe quel protocole. Pour plus d’informations, consultez ouverture de session ANONYME intermittente du serveur lié SQL Server double tronçon. |
| Connexion d’homologue NTLM | Cette erreur est liée au protocole d’authentification NTLM utilisé par le système d’exploitation Microsoft Windows. Lorsque vous communiquez entre les ordinateurs qui se trouvent dans des stations de travail ou dans des domaines qui ne font pas confiance les uns les autres, vous pouvez configurer des comptes identiques sur les deux ordinateurs et utiliser la connexion d’homologue NTLM NTLM Peer Login. Les connexions fonctionnent uniquement si le compte d’utilisateur et le mot de passe correspondent sur les deux ordinateurs. |
| Protection de bouclage | La protection de bouclage est conçue pour empêcher les applications d’appeler d’autres services sur le même ordinateur. Vous pouvez définir les DisableLoopbackCheck clés de Registre ou BackConnectionHostNames (par défaut) pour autoriser cela. Pour plus d’informations, consultez message d’erreur lorsque vous essayez d’accéder à un serveur localement à l’aide de son nom de domaine complet ou de son alias CNAME après avoir installé Windows Server 2003 Service Pack 1 : Accès refusé ou Aucun fournisseur réseau n’a accepté le chemin d’accès réseau donné. |
| Protection de bouclage de l’écouteur Always On | Lors de la connexion à l’écouteur Always-On à partir du nœud principal, la connexion est NTLM. Cela implique la vérification de bouclage et entraîne une erreur « Échec de connexion » indiquant que l’utilisateur provient d’un domaine non approuvé. Pour résoudre cette erreur, tapez le nom NETBIOS de l’écouteur et le nom complet dans la clé de BackConnectionHostNames Registre sur tous les ordinateurs du groupe de disponibilité. Pour plus d’informations, consultez message d’erreur lorsque vous essayez d’accéder à un serveur localement à l’aide de son nom de domaine complet ou de son alias CNAME après avoir installé Windows Server 2003 Service Pack 1 : Accès refusé ou Aucun fournisseur réseau n’a accepté le chemin d’accès réseau donné. |
| Niveau de compatibilité LANMAN | Cela se produit généralement entre les ordinateurs plus anciens (pré Windows 2008) et les ordinateurs plus récents. Définissez le niveau de compatibilité LANMAN sur 5 sur tous les ordinateurs. Cela interdit également NTLM v1. Vous pouvez également basculer vers Kerberos pour éviter ce problème. |
| Compte sensible | Certains comptes peuvent être marqués comme sensibles dans Active Directory. Ces comptes ne peuvent pas être délégués à un autre service dans un scénario à double tronçon. |
| Pas une cible contrainte | Si la délégation contrainte est activée pour un compte de service particulier, Kerberos échoue si le SPN du serveur cible ne figure pas dans la liste des cibles de délégation contrainte. |
| PAR SERVICE-SID | Cette fonctionnalité limite les connexions locales pour utiliser NTLM et non Kerberos comme méthode d’authentification. Le service peut effectuer un tronçon unique vers un autre serveur à l’aide d’informations d’identification NTLM, mais il ne peut pas être délégué plus loin sans utiliser la délégation contrainte. |
| Délégation NTLM et contrainte | Si la cible est un partage de fichiers, le type de délégation du compte de service de niveau intermédiaire doit être Contrainte-Any et non Contrainte-Kerberos. |
Remarque
Un double tronçon implique généralement la délégation d’informations d’identification utilisateur sur plusieurs ordinateurs distants. Par exemple, supposons que vous disposez d’une instance SQL Server nommée SQL1 où vous avez créé un serveur lié pour un serveur SQL Server distant nommé SQL2. Dans la configuration de sécurité du serveur lié, vous avez sélectionné l’option Be made using the login’s current security context. Lorsque vous utilisez cette configuration, si vous exécutez une requête de serveur lié sur SQL1 à partir d’un ordinateur client distant nommé Client1, les informations d’identification Windows devront d’abord passer de Client1 à SQL1, puis de SQL1 à SQL2 (par conséquent, il s’agit d’un double tronçon). Pour plus d’informations, consultez Présentation du double tronçon Kerberos et de la délégation Kerberos contrainte
É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 :
Utilisez SQLCheck ou Setspn.exe pour diagnostiquer et résoudre les problèmes liés au SPN.
Utilisez SQLCheck pour vérifier 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.
Remarque
Les SETSPN -X commandes utiles -Q sont utiles pour rechercher des noms de spN dupliqués ou mal placés.
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-4pour IPv4 et-6IPv6 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.
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.
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.
| State | Description |
|---|---|
| 1 | Les informations d’erreur ne sont pas disponibles. Cet état signifie généralement que vous n’êtes pas autorisé à recevoir les détails de l’erreur. Pour plus d’informations, contactez votre administrateur SQL Server. |
| 2 | L’ID utilisateur n’est pas valide. |
| 5 | L’ID utilisateur n’est pas valide. |
| 6 | Tentative d'utilisation d'un nom de connexion Windows avec l'authentification SQL Server. |
| 7 | La connexion est désactivée et le mot de passe est incorrect. |
| 8 | Le mot de passe est incorrect. |
| 9 | Le mot de passe n’est pas valide. |
| 11 | La connexion est valide mais l'accès au serveur a échoué. L’une des causes possibles de cette erreur est lorsque l’utilisateur Windows a accès à SQL Server en tant que membre du groupe des administrateurs locaux, mais Que Windows ne fournit pas d’informations d’identification d’administrateur. Pour vous connecter, démarrez le programme de connexion à l’aide de l’option Exécuter en tant qu’administrateur , puis ajoutez l’utilisateur Windows à SQL Server comme connexion spécifique. |
| 12 | La connexion est valide mais l'accès au serveur a échoué. |
| 18 | Le mot de passe doit être modifié. |
| 38, 46 | Impossible de trouver la base de données demandée par l’utilisateur. |
| 58 | SQL Server est défini pour utiliser l’authentification Windows uniquement et un client tente de se connecter à l’aide de l’authentification SQL. Une autre cause est quand les SID ne correspondent pas. |
| 102 - 111 | Échec d’Azure AD. |
| 122 - 124 | Échec lié à un mot de passe ou nom d’utilisateur vide. |
| 126 | La base de données demandée par l’utilisateur n’existe pas. |
| 132 - 133 | Échec d’Azure AD. |
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.
| Date | Source | Message |
|---|---|---|
| 2007-12-05 20:12:56.34 | Ouverture de session | Erreur : 18456, Gravité : 14, État : 8. |
| 2007-12-05 20:12:56.34 | Ouverture de session | Échec de la connexion pour l’utilisateur «< user_name> ». [CLIENT : <adresse> IP] |
Remarque
Lorsque SQL Server est installé à l’aide du mode d’authentification Windows et que le mode d’authentification SQL Server est modifié ultérieurement, la connexion sa est initialement désactivée. Cela provoque l’erreur d’état 7 : « Échec de la connexion pour l’utilisateur « sa ». Pour activer la connexion sa, consultez Modifier le mode d’authentification du serveur.