Partager via

Problèmes d’authentification cohérente dans SQL Server

  • Article

S’applique à : SQL Server

Remarque

Les commandes fournies dans cet article s’appliquent uniquement aux systèmes Windows.

Les problèmes d’authentification cohérents qui se produisent dans Microsoft SQL Server sont généralement liés à l’authentification et à l’autorisation des utilisateurs ou des applications qui tentent d’accéder à la base de données SQL Server. Ces problèmes peuvent être des échecs d’authentification, des erreurs d’accès refusé ou d’autres problèmes liés à la sécurité.

La clé pour résoudre efficacement les problèmes d’authentification cohérente est de comprendre les différents types d’erreurs et ce que signifie chaque message d’erreur. Certaines erreurs peuvent apparaître dans plusieurs problèmes d’authentification. Vous pouvez utiliser les informations de résolution des problèmes mentionnées dans la section Types d’erreurs pour résoudre l’erreur.

Configuration requise

Avant de commencer la résolution des problèmes, consultez la liste de vérification des prérequis pour disposer des informations suivantes :

Types d’erreurs

Cette section décrit les types d’erreurs et les informations associées.

  • Erreurs des services d’annuaire : si le fichier journal des erreurs SQL Server contient l’un des messages suivants, ou les deux, cette erreur est liée aux services de domaine Active Directory (AD DS). Cette erreur peut également se produire si Windows sur l’ordinateur SQL Server ne peut pas contacter le contrôleur de domaine (DC) ou si le service de sous-système d’autorité de sécurité locale (LSASS) rencontre un problème.

    Error -2146893039 (0x80090311): No authority could be contacted for authentication.
Error -2146893052 (0x80090304): The Local Security Authority cannot be contacted.

  • Erreurs d’échec de connexion : lorsque vous résolvez l’erreur « Échec de connexion », le journal des erreurs SQL Server fournit des insights supplémentaires sur le code d’erreur 18456, y compris une valeur d’état spécifique qui offre plus de contexte sur l’erreur. Pour plus d’informations, consultez le fichier journal des erreurs SQL Server dans la valeur de l’état SQL. Vous pouvez essayer de résoudre le problème en fonction de la description de la valeur d’état.

    Le tableau suivant répertorie certains messages d’erreur « Échec de connexion » spécifiques, ainsi que leurs causes et solutions possibles.

    Message d’erreur Informations supplémentaires
    « Une erreur au niveau du transport s’est produite lors de l’envoi de la requête au serveur. » Vérifiez si le mappage de compte de serveur lié est correct. Pour plus d’informations, consultez sp_addlinkedsrvlogin.
    « Impossible de générer le contexte SSPI »
    « Impossible d’ouvrir le test> de base de données <demandé par la connexion. Échec de la connexion. » La base de données peut être hors connexion ou les autorisations peuvent ne pas être suffisantes. Pour plus d’informations, consultez Base de données hors connexion dans MSSQLSERVER_18456.
    Vérifiez également si le nom de la base de données dans la chaîne de connexion est correct.
    « Échec de la connexion pour le nom d’utilisateur> de l’utilisateur<. » Cette erreur peut se produire si le compte proxy n’est pas correctement authentifié.
    « Échec de la connexion pour l’utilisateur : 'NT AUTHORITY\ANONYMOUS LOGON' » Cette erreur peut se produire si le SPN est manquant, si le SPN est dupliqué ou si le SPN se trouve sur le mauvais compte.
    « Échec de la connexion pour le nom d’utilisateur> de l’utilisateur<. »
    « Échec de la connexion pour l’utilisateur '<database\username> »
    		 Vérifiez si une chaîne de connexion contient un nom de serveur incorrect. Vérifiez également si l’utilisateur appartient à un groupe local utilisé pour accorder l’accès au serveur. Pour plus d’informations, consultez NT AUTHORITY\ANONYMOUS LOGON.
    « Échec de la connexion pour l’utilisateur '<nom d’utilisateur>'. Motif : Le mot de passe ne correspondait pas à celui de la connexion fournie. » Cette erreur peut se produire si un mot de passe incorrect est utilisé. Pour plus d’informations, consultez Échec de la connexion pour l’utilisateur «< nom d’utilisateur> » ou Échec de connexion pour l’utilisateur « nom d’utilisateur> de domaine><».<
    « SQL Server n’existe pas ou l’accès est refusé. » Les connexions de canaux nommés échouent, car l’utilisateur n’est pas autorisé à se connecter à Windows.
    « La connexion provient d’un domaine non approuvé et ne peut pas être utilisée avec l’authentification Windows. » Cette erreur peut être liée aux problèmes du sous-système de sécurité local .
    « Le type de connexion réseau n’est pas autorisé pour le compte d’utilisateur. » Vous ne pourrez peut-être pas vous connecter au réseau.

Types de problèmes d’authentification cohérente

Cette section décrit les causes classiques des problèmes d’authentification cohérente avec leurs solutions respectives. Sélectionnez le type de problème pour voir les problèmes, les causes et les solutions pertinents.

Chaîne de connexion

Cette section répertorie les problèmes liés aux paramètres de configuration utilisés par les applications pour se connecter à une base de données.

Base

Cette section répertorie les problèmes spécifiques à différents aspects de SQL Server :

  • La base de données est hors connexion : fait référence à un scénario dans lequel une base de données SQL Server tente de se reconnecter à une instance SQL Server configurée pour le mode d’authentification Windows.

    Solution: Pour plus d’informations, consultez MSSQLSERVER_18456.

  • Autorisations de base de données : fait référence à l’activation ou à la restriction de l’accès à une base de données SQL Server.

    Solution: Pour plus d’informations, consultez MSSQLSERVER_18456.

  • Erreurs de connectivité des serveurs liés dans SQL Server : vous rencontrez un problème de processus d’authentification qui affecte les serveurs liés dans le contexte de SQL Server.

    Solution: Pour résoudre ce problème, consultez Erreurs de connectivité du serveur lié dans SQL Server.

  • Les métadonnées du serveur lié sont incohérentes : fait référence à un problème dans lequel les métadonnées du serveur lié sont incohérentes ou ne correspondent pas aux métadonnées attendues.

    Une vue ou une procédure stockée interroge les tables ou les vues dans le serveur lié, mais reçoit des échecs de connexion, même si une instruction distribuée SELECT copiée à partir de la procédure ne le fait pas.

    Ce problème peut se produire si la vue a été créée, puis si le serveur lié a été recréé, ou si une table distante a été modifiée sans regénérer l’affichage.

    Solution : Actualisez les métadonnées du serveur lié en exécutant la sp_refreshview procédure stockée.

  • Le compte proxy n’a pas d’autorisations : un travail SQL Server Integration Service (SSIS) exécuté par SQL Agent peut nécessiter des autorisations autres que celles que le compte de service SQL Agent peut fournir.

    Solution: Pour résoudre ce problème, consultez Le package SSIS ne s’exécute pas lorsqu’il est appelé à partir d’une étape de travail sql Server Agent.

  • Impossible de se connecter à la base de données SQL Server : l’impossibilité de se connecter peut entraîner des échecs d’authentification.

    Solution: Pour résoudre ce problème, consultez MSSQLSERVER_18456.

Services d’annuaire

Cette section répertorie les problèmes liés aux services d’annuaire et aux serveurs.

  • Un compte est désactivé : vous pouvez rencontrer ce scénario si le compte d’utilisateur a été désactivé par un administrateur ou par un utilisateur. Dans ce cas, vous ne pouvez pas vous connecter à l’aide de ce compte ou vous ne pouvez pas utiliser ce compte pour démarrer un service. Cela peut entraîner des problèmes d’authentification cohérente, car cela peut vous empêcher d’accéder aux ressources ou d’effectuer des actions qui nécessitent une authentification.

    Solution: Un administrateur de domaine peut résoudre ce problème en réactivant le compte. Lorsqu’un compte est désactivé, c’est généralement parce qu’un utilisateur a trop essayé de se connecter avec un mot de passe incorrect ou parce qu’une application ou un service tente d’utiliser un ancien mot de passe.

  • Un compte n’est pas dans le groupe : ce problème peut se produire si un utilisateur tente d’accéder à une ressource limitée à un groupe spécifique.

    Solution: Vérifiez les connexions SQL pour énumérer les groupes autorisés et vérifiez que l’utilisateur appartient à l’un des groupes.

  • Échec de la migration de compte : si les anciens comptes d’utilisateur ne peuvent pas se connecter au serveur, mais que les comptes nouvellement créés le peuvent, la migration de compte peut ne pas être correcte. Ce problème est lié à AD DS.

    Solution: Pour plus d’informations, consultez Transférer des connexions et des mots de passe entre des instances de SQL Server.

  • Contrôleur de domaine hors connexion : fait référence à un problème où le contrôleur de domaine n’est pas accessible.

    Solution: Utilisez la nltest commande pour forcer l’ordinateur à basculer vers un autre contrôleur de domaine. Pour plus d’informations, consultez Id d’événement de réplication Active Directory 2087 : échec de la recherche DNS à l’origine de l’échec de la réplication.

  • Le pare-feu bloque le contrôleur de domaine : vous pouvez rencontrer des problèmes lorsque vous gérez l’accès de l’utilisateur aux ressources.

    Solution: Assurez-vous que le contrôleur de domaine est accessible à partir du client ou du serveur. Pour ce faire, utilisez la nltest /SC_QUERY:CONTOSO commande .

  • La connexion provient d’un domaine non approuvé : ce problème est lié au niveau d’approbation entre les domaines. Le message d’erreur suivant peut s’afficher : « Échec de la connexion. La connexion provient d’un domaine non approuvé et ne peut pas être utilisée avec l’authentification Windows. (18452)."

    L’erreur 18452 indique que la connexion utilise l’authentification Windows, mais que la connexion est un principal Windows non reconnu. Un principal Windows non reconnu indique que la connexion ne peut pas être vérifiée par Windows. Cela peut se produire car la connexion Windows provient d’un domaine non approuvé. Le niveau d’approbation entre les domaines peut entraîner des échecs dans l’authentification du compte ou la visibilité des noms de fournisseur de services (SPN).

    Solution: Pour résoudre ce problème, consultez MSSQLSERVER_18452.

  • Aucune autorisation pour les groupes inter-domaines : les utilisateurs du domaine distant doivent appartenir à un groupe dans le domaine SQL Server. Il peut y avoir un problème si vous essayez d’utiliser un groupe local de domaine pour vous connecter à une instance SQL Server à partir d’un autre domaine.

    Solution: Si les domaines ne sont pas approuvés correctement, l’ajout d’utilisateurs dans un groupe dans le domaine distant peut empêcher le serveur d’énumérer l’appartenance au groupe.

  • L’authentification sélective est désactivée : fait référence à une fonctionnalité d’approbations de domaine qui permet à l’administrateur de domaine de limiter les utilisateurs qui ont accès aux ressources du domaine distant. Si l’authentification sélective n’est pas activée, tous les utilisateurs du domaine approuvé peuvent accéder au domaine distant.

    Solution: Pour résoudre ce problème, activez l’authentification sélective pour vous assurer que les utilisateurs ne sont pas autorisés à s’authentifier dans le domaine distant.

Authentification Kerberos

Cette section répertorie les problèmes liés à l’authentification Kerberos :

  • Un suffixe DNS incorrect est ajouté au nom NetBIOS : ce problème peut se produire si vous utilisez uniquement le nom NetBIOS (par exemple, SQLPROD01) au lieu du nom de domaine complet (FQDN) (par exemple, SQLPROD01.CONTOSO.COM). Lorsque cela se produit, le suffixe DNS incorrect peut être ajouté.

    Solution: Vérifiez les paramètres réseau des suffixes par défaut pour vous assurer qu’ils sont corrects, ou utilisez le nom de domaine complet pour éviter les problèmes.

  • L’asymétrie de l’horloge est trop élevée : ce problème peut se produire si plusieurs appareils d’un réseau ne sont pas synchronisés. Pour que l’authentification Kerberos fonctionne, les horloges entre les appareils ne peuvent pas être désactivées pendant plus de cinq minutes ou des échecs d’authentification cohérents peuvent se produire.

    Solution: Configurez les ordinateurs pour synchroniser régulièrement leurs horloges avec un service de temps central.

  • Délégation de comptes sensibles à d’autres services : certains comptes peuvent être marqués comme Sensitive dans AD DS. Ces comptes ne peuvent pas être délégués à un autre service dans un scénario à double tronçon. Les comptes sensibles sont essentiels pour assurer la sécurité, mais ils peuvent affecter l’authentification.

    Solution: Pour résoudre ce problème, consultez Échec de la connexion pour l’utilisateur NT AUTHORITY\ANONYMOUS LOGON.

  • Délégation à un partage de fichiers : fait référence à une situation dans laquelle un utilisateur ou une application délègue ses informations d’identification pour accéder à un partage de fichiers. Sans contraintes appropriées, la délégation d’informations d’identification à un partage de fichiers peut créer des risques pour la sécurité.

    Solution: Pour résoudre ce type de problème, veillez à utiliser la délégation contrainte.

  • Espace de noms DNS disjoint : fait référence à un problème d’authentification cohérent qui peut se produire si le suffixe DNS ne correspond pas entre le membre de domaine et LE DNS. Vous pouvez rencontrer des problèmes d’authentification si vous utilisez un espace de noms disjoint. Si la hiérarchie organisationnelle dans AD DS et dans DNS ne correspond pas, le spN incorrect peut être généré si vous utilisez le nom NETBIOS dans la chaîne de connexion de l’application de base de données. Dans ce cas, le SPN est introuvable et les informations d’identification NTLM (New Technology LAN Manager) sont utilisées à la place des informations d’identification Kerberos.

    Solution: Pour atténuer le problème, utilisez le nom de domaine complet du serveur ou spécifiez le nom du SPN dans la chaîne de connexion. Pour plus d’informations sur le nom de domaine complet, consultez Nom de domaine des ordinateurs.

  • SpN dupliqué : fait référence à une situation dans laquelle plusieurs SPN sont identiques au sein d’un domaine. Les SPN sont utilisés pour identifier de manière unique les services qui s’exécutent sur des serveurs dans un domaine Windows. Les noms de principal du service dupliqués peuvent entraîner des problèmes d’authentification.

    Solution: Pour résoudre ce problème, consultez Corriger l’erreur avec Kerberos Configuration Manager (recommandé).

  • Activer les ports HTTP sur les SPN : en règle générale, les spn HTTP n’utilisent pas de numéros de port (par exemple, http/web01.contoso.com).

    Solution: Pour résoudre ce problème, vous pouvez l’activer à l’aide de la stratégie sur les clients. Le SPN doit alors être au http/web01.contoso.com:88 format pour permettre à Kerberos de fonctionner correctement. Sinon, les informations d’identification NTLM sont utilisées.

    Les informations d’identification NTLM ne sont pas recommandées, car elles peuvent compliquer le diagnostic du problème. En outre, cette situation peut générer une surcharge administrative excessive.

  • Tickets expirés : fait référence aux tickets Kerberos. L’utilisation de tickets Kerberos expirés peut entraîner des problèmes d’authentification.

    Solution: Pour résoudre ce problème, consultez Tickets expirés.

  • Le fichier HOSTS est incorrect : le fichier HOSTS peut perturber les recherches DNS et peut générer un nom spN inattendu. Cette situation entraîne l’utilisation des informations d’identification NTLM. Si une adresse IP inattendue se trouve dans le fichier HOSTS, le SPN généré peut ne pas correspondre au serveur principal pointé.

    Solution: Passez en revue le fichier HOSTS et supprimez les entrées de votre serveur. Les entrées de fichier HOSTS sont affichées dans le rapport SQLCHECK.

  • Problème avec les autorisations d’identificateur de sécurité par service ( SID) : le SID par service est une fonctionnalité de sécurité de SQL Server qui limite les connexions locales à utiliser NTLM et non Kerberos comme méthode d’authentification. Le service peut effectuer un seul tronçon vers un autre serveur à l’aide des informations d’identification NTLM, mais il ne peut pas être délégué davantage sans utiliser la délégation contrainte. Pour plus d’informations, consultez Échec de la connexion pour l’utilisateur NT AUTHORITY\ANONYMOUS LOGON.

    Solution: Pour résoudre ce problème, l’administrateur de domaine doit configurer la délégation contrainte.

  • Authentification en mode noyau : le SPN sur le compte du pool d’applications est généralement requis pour les serveurs web. Toutefois, lorsque l’authentification en mode noyau est utilisée, le SPN HÔTE de l’ordinateur est utilisé pour l’authentification. Cette action a lieu dans le noyau. Ce paramètre peut être utilisé si le serveur héberge de nombreux sites web différents qui utilisent la même URL d’en-tête d’hôte, différents comptes de pool d’applications et l’authentification Windows.

    Solution: Supprimez les SPN HTTP si l’authentification en mode noyau est activée.

  • Limiter les droits de délégation à Access ou Excel : les fournisseurs JET (Joint Engine Technology) et Access Connectivity Engine (ACE) sont similaires à tous les systèmes de fichiers. Vous devez utiliser la délégation contrainte pour permettre à SQL Server de lire les fichiers situés sur un autre ordinateur. En règle générale, le fournisseur ACE ne doit pas être utilisé dans un serveur lié, car cela n’est explicitement pas pris en charge. Le fournisseur JET est déconseillé et est disponible uniquement sur les ordinateurs 32 bits.

    Remarque

    Lorsque SQL Server 2014, la dernière version à prendre en charge les installations 32 bits, ne sera plus prise en charge, le scénario JET ne sera plus pris en charge.

  • SpN manquant : ce problème peut se produire si un SPN lié à une instance SQL Sever est absent.

    Solution: Pour plus d’informations, consultez Corriger l’erreur avec Kerberos Configuration Manager (recommandé).

  • 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.

    Solution: Pour résoudre ce problème, un administrateur de domaine doit ajouter le SPN du serveur cible aux SPN cibles du compte de service de niveau intermédiaire.

  • NTLM et délégation 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 Constrained-Any et non Constrained-Kerberos. Si le type de délégation est défini sur Constrained-Kerberos, le compte de niveau intermédiaire peut allouer uniquement à des services spécifiques, mais Constrained-Any autorise le compte de service à déléguer à n’importe quel service.

    Solution: Pour résoudre ce problème, consultez Échec de la connexion pour l’utilisateur NT AUTHORITY\ANONYMOUS LOGON.

  • Le compte de service ne peut pas être approuvé pour la délégation dans AD : dans un scénario de double tronçon, le compte de service du service de niveau intermédiaire doit être approuvé pour la délégation dans AD DS. Si le compte de service n’est pas approuvé pour la délégation, l’authentification Kerberos peut échouer.

    Solution: Si vous êtes administrateur, activez l’option Approuvé pour la délégation .

  • Certains fournisseurs hérités ne prennent pas en charge Kerberos sur les canaux nommés : le fournisseur OLE DB hérité (SQLOLEDB) et le fournisseur ODBC (SQL Server) qui sont fournis avec Windows n’offrent pas la prise en charge de l’authentification Kerberos sur les canaux nommés. Au lieu de cela, ils prennent uniquement en charge l’authentification NTLM.

    Solution: Utilisez une connexion TCP pour autoriser l’authentification Kerberos. Vous pouvez également utiliser un pilote plus récent, par exemple MSOLEDBSQL ou ODBC Driver 17. Toutefois, TCP est toujours préféré aux canaux nommés, quelle que soit la version du pilote.

  • Le SPN est associé à un compte incorrect : ce problème peut se produire si un SPN est associé au mauvais compte dans AD DS. Pour plus d’informations, consultez Corriger l’erreur avec Kerberos Configuration Manager (recommandé).

    Vous pouvez recevoir un message d’erreur si votre SPN est configuré sur le mauvais compte dans AD DS.

    Solution: Pour résoudre l’erreur, procédez comme suit :

    1. Utilisez SETSPN -Q spnName pour localiser le SPN et son compte actuel.
    2. Utilisez SETSPN -D pour supprimer les spN existants.
    3. Utilisez pour SETSPN -S migrer le SPN vers le compte approprié.

  • L’alias SQL peut ne pas fonctionner correctement : un alias SQL Server peut entraîner la génération d’un SPN inattendu. Cela entraîne l’échec des informations d’identification NTLM si le SPN est introuvable, ou un échec SSPI s’il correspond par inadvertance au SPN d’un autre serveur.

    Solution: Les alias SQL sont affichés dans le rapport SQLCHECK. Pour résoudre le problème, identifiez et corrigez les alias SQL incorrects ou mal configurés afin qu’ils pointent vers le serveur SQL Server correct.

  • L’utilisateur appartient à de nombreux groupes : si un utilisateur appartient à plusieurs groupes, des problèmes d’authentification peuvent se produire dans Kerberos. Si vous utilisez Kerberos sur UDP, le jeton de sécurité entier doit tenir dans un seul paquet. Les utilisateurs qui appartiennent à de nombreux groupes ont un jeton de sécurité plus important que les utilisateurs qui appartiennent à moins de groupes.

    Solution: Si vous utilisez Kerberos sur TCP, vous pouvez augmenter le paramètre [MaxTokenSize]. Pour plus d’informations, consultez MaxTokenSize et Kerberos Token Bloat.

  • Utiliser l’en-tête d’hôte de site web : l’en-tête d’hôte HTTP joue un rôle très important dans le protocole HTTP pour accéder aux pages web.

    Solution: Si le site web a un nom d’en-tête d’hôte, le SPN HOSTS ne peut pas être utilisé. Un SPN HTTP explicite doit être utilisé. Si le site web n’a pas de nom d’en-tête d’hôte, NTLM est utilisé. NTLM ne peut pas être délégué à une instance sql server principale ou à un autre service.

Gestionnaire NT LAN (NTLM)

Cette section répertorie les problèmes spécifiques à NTLM (NT LAN Manager) :

  • L’accès est refusé pour les connexions d’homologues NTLM : fait référence à un problème lié aux connexions d’homologue NTLM.

    Solution: Lorsque vous communiquez entre des ordinateurs qui se trouvent dans des stations de travail ou des domaines qui ne se font pas confiance les uns les autres, vous pouvez configurer des comptes identiques sur les deux ordinateurs et utiliser l’authentification homologue NTLM.

    Les connexions fonctionnent uniquement si le compte d’utilisateur et le mot de passe correspondent sur les deux ordinateurs. L’authentification NTLM peut être désactivée ou non prise en charge côté client ou côté serveur. Cette situation peut entraîner des échecs d’authentification. Pour plus d’informations, consultez MSSQLSERVER_18456.

  • Scénarios de double tronçon sur plusieurs ordinateurs : un processus de double tronçon échoue si des informations d’identification NTLM sont utilisées. Les informations d’identification Kerberos sont requises.

    Solution: Pour résoudre ce problème, consultez Échec de la connexion pour l’utilisateur NT AUTHORITY\ANONYMOUS LOGON.

  • La protection contre le bouclage n’est pas définie correctement : la protection contre le bouclage est conçue pour empêcher les applications d’appeler d’autres services sur le même ordinateur. Si la protection de bouclage n’est pas configurée correctement ou s’il y a un dysfonctionnement, cette situation peut indirectement entraîner des problèmes d’authentification.

    Solution: Pour résoudre ce problème, consultez MSSQLSERVER_18456.

  • La protection contre le bouclage échoue lorsque vous vous connectez à l’écouteur Always On : ce problème est lié à la protection contre le bouclage. Lorsque vous vous connectez à l’écouteur Always-On à partir du nœud principal, la connexion utilise l’authentification NTLM.

    Solution: Pour plus d’informations, consultez MSSQLSERVER_18456.

  • Problème affectant le niveau de compatibilité LANMAN : le problème d’authentification LAN Manager (LANMAN) se produit généralement si une incompatibilité existe dans les protocoles d’authentification utilisés par des ordinateurs plus anciens (antérieurs à Windows Server 2008) et plus récents. Lorsque vous définissez le niveau de compatibilité sur 5, NTLMv2 n’est pas autorisé.

    Solution: Le passage à Kerberos évite ce problème, car Kerberos est plus sécurisé. Pour plus d’informations, consultez Échec de la connexion pour l’utilisateur NT AUTHORITY\ANONYMOUS LOGON.

Connexion SQL

Cette section répertorie les problèmes liés aux informations d’identification d’authentification :

  • Mot de passe incorrect : fait référence à un problème lié à la connexion.

    Solution: Pour résoudre ce problème, consultez MSSQLSERVER_18456.

  • Nom d’utilisateur non valide : fait référence à un problème lié à la connexion.

    Solution: Pour résoudre ce problème, consultez MSSQLSERVER_18456.

  • Les connexions SQL Server ne sont pas activées : fait référence à un scénario dans lequel vous essayez de vous connecter à une instance Microsoft SQL Server à l’aide de l’authentification SQL Server, mais la connexion associée au compte est désactivée.

    Solution: Pour résoudre ce problème, consultez MSSQLSERVER_18456.

  • Les connexions de canaux nommés échouent, car l’utilisateur n’a pas l’autorisation de se connecter à Windows : fait référence à un problème d’autorisation dans Windows.

    Solution: Pour résoudre ce problème, consultez Problème de connexions de canaux nommés dans SQL Server.

Autorisations Windows

Cette section répertorie les problèmes spécifiques aux autorisations windows ou aux paramètres de stratégie :

  • L’accès est accordé via des groupes locaux : si l’utilisateur n’appartient pas à un groupe local utilisé pour accorder l’accès au serveur, le fournisseur affiche le message d’erreur « Échec de la connexion pour l’utilisateur 'contoso/user1' ».

    Solution: L’administrateur de base de données peut vérifier cette situation en examinant le dossierConnexions de sécurité> dans SQL Server Management Studio (SSMS). Si la base de données est une base de données autonome, vérifiez sous databasename. Pour plus d’informations, consultez Échec de la connexion pour l’utilisateur «< nom d’utilisateur> » ou Échec de la connexion pour l’utilisateur «< domaine>\<nom_utilisateur> ».

  • Credential Guard est activé : ce scénario indique que la fonctionnalité Credential Guard est activée sur un système Windows et utilisée pour créer un environnement sécurisé pour stocker des informations sensibles. Toutefois, dans certaines situations, cette fonctionnalité peut entraîner des problèmes d’authentification.

    Solution: Pour résoudre ce problème, demandez à un administrateur de domaine de configurer la délégation contrainte. Pour plus d’informations, consultez Considérations et problèmes connus lors de l’utilisation de Credential Guard.

  • Erreurs de sous-système de sécurité local : lorsque vous rencontrez des erreurs de sous-système de sécurité locale, en particulier celles liées à LSASS qui ne répondent plus, cela peut indiquer des problèmes sous-jacents qui affectent l’authentification.

    Solution: Pour résoudre ces erreurs, consultez Erreurs du sous-système de sécurité local dans SQL Server.

  • Connexion réseau non autorisée : ce scénario se produit lorsque vous essayez de vous connecter à un réseau, mais que votre demande de connexion est refusée pour certaines raisons.

    Solution: Pour résoudre ce problème, consultez L’utilisateur ne dispose pas des autorisations nécessaires pour se connecter au réseau.

  • Seuls les administrateurs peuvent se connecter : ce problème se produit si le journal de sécurité sur un ordinateur est plein et n’a pas suffisamment d’espace pour remplir les événements. La fonctionnalité de sécurité CrashOnAuditFail est utilisée par les administrateurs système pour vérifier tous les événements de sécurité. Les valeurs valides pour CrashOnAuditFail sont 0, 1 et 2. Si la clé de CrashOnAuditFail est définie sur 2, cela signifie que le journal de sécurité est plein et que le message d’erreur « Seuls les administrateurs peuvent se connecter » s’affiche.

    Solution: Pour résoudre ce problème, procédez comme suit :

    1. Démarrez l’Éditeur du Registre.
    2. Recherchez et vérifiez la HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa!crashonauditfail sous-clé pour voir si la valeur est définie sur 2. Cette valeur indique que le journal de sécurité doit être nettoyé manuellement.
    3. Définissez la valeur sur 0, puis redémarrez le serveur. Vous pouvez également modifier le journal de sécurité pour permettre le basculement des événements. Pour plus d’informations sur la façon dont le paramètre affecte tous les services tels que SQL, IIS, le partage de fichiers et la connexion, consultez Les utilisateurs ne peuvent pas accéder aux sites Web lorsque le journal des événements de sécurité est plein.

    Remarque

    Ce problème affecte uniquement les connexions intégrées. Une connexion de canaux nommés est également affectée dans une connexion SQL Server, car les canaux nommés se connectent d’abord au canal d’administration Windows avant de se connecter à SQL Server.

  • Le compte de service n’est pas approuvé pour la délégation : ce type de problème se produit généralement si un compte de service n’est pas autorisé à attribuer des informations d’identification à d’autres serveurs. Ce problème peut affecter les services qui nécessitent une délégation.

    Solution: Si un scénario de délégation n’est pas activé, vérifiez le secpol.msc SQL Server pour déterminer si le compte de service SQL Server est répertorié sous les paramètres de stratégie de sécurité Stratégies > locales Attribution > des droits utilisateur Emprunter l’identité d’un client après l’authentification . Pour plus d’informations, consultez la section Activer l’ordinateur et les comptes utilisateur approuvés pour la délégation.

  • Impossible de charger le profil utilisateur Windows dans SQL Server : fait référence au problème de profil utilisateur Windows.

    Solution: Pour plus d’informations sur la résolution des problèmes liés aux profils utilisateur endommagés, consultez Le profil utilisateur Windows ne peut pas être chargé dans SQL Server.

Autres aspects

Cette section répertorie les problèmes liés à l’authentification et au contrôle d’accès au sein d’un environnement web :

  • L’authentification intégrée n’est pas activée : fait référence à un problème de configuration dans lequel l’authentification Windows intégrée (IWA) n’est pas configurée correctement.

    Solution: Pour résoudre ce problème, vérifiez que l’option Authentification Windows intégrée est activée dans les paramètres Options Internet .

  • L’authentification IIS n’est pas autorisée : ce problème se produit en raison de configurations incorrectes dans IIS. Les paramètres d’authentification définis dans le fichier Web.config de l’application web peuvent entrer en conflit avec les paramètres configurés dans IIS. Cette situation peut entraîner des problèmes d’authentification.

    Solution: Pour résoudre ce problème, configurez le site web pour activer l’authentification Windows et définissez la <identity impersonate="true"/> valeur dans le fichier Web.config .

  • Mauvaise zone Internet : ce problème peut se produire si vous essayez d’accéder à un site web qui ne se trouve pas dans la zone Internet appropriée dans Internet Explorer. Les informations d’identification ne fonctionnent pas si le site web se trouve dans la zone Intranet locale.

    Solution: Ajoutez le serveur web à la zone intranet locale d’Internet Explorer.

Exclusion de responsabilité de tiers

Les produits tiers mentionnés dans le présent article sont fabriqués par des sociétés indépendantes de Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces produits.

Informations supplémentaires

Collecter des données pour résoudre les problèmes de connectivité SQL Server