Les utilisateurs rencontrent souvent un problème où le message suivant apparaît et les empêche de se connecter.
« La méthode de connexion que vous essayez d’utiliser n’est pas autorisée. »
Le message « la méthode de connexion que vous tentez d'utiliser n'est pas autorisée » apparaît généralement lorsque certaines stratégies de sécurité ou paramètres de connexion ont été modifiés.
Cette erreur peut concerner un compte local, un compte de domaine Active Directory, une connexion à distance ou une machine virtuelle. Les causes possibles incluent notamment des informations d’identification incorrectes, des stratégies locales restrictives, des problèmes de communication avec Active Directory, une résolution DNS défaillante, une stratégie d’accès conditionnel ou un problème d’authentification multifacteur.
Vérifier les informations d’identification
Si vous ne pouvez pas vous connecter et continuez à recevoir un message d’erreur indiquant que vos informations d’identification sont incorrectes, commencez par vérifier que vous utilisez les bonnes informations d’identification.
Votre compte est configuré pour vous empêcher d’utiliser cet appareil.
Lorsque vous utilisez un compte de domaine, un changement dans le format de connexion peut également être une solution rapide, en particulier pour les nouveaux utilisateurs ou lorsqu’il existe des problèmes avec la configuration du DNS.
Lorsque vous êtes confronté à des problèmes de AD ou de DNS, un tel changement dans le format de connexion peut être une solution rapide, en particulier pour les nouveaux utilisateurs ou lorsqu’il existe des problèmes avec la configuration du DNS.
Bien qu’il soit important de s’attaquer à la cause profonde du problème, cette approche peut servir de mesure intérimaire efficace jusqu’à ce que le problème soit entièrement résolu.
Activer l’authentification par mot de passe
Nous vous recommandons de vérifier dans Paramètres → Comptes → Options de connexion que l’authentification par mot de passe est bien activée.
Il peut également être utile de contrôler les stratégies locales via secpol.msc ou gpedit.msc afin de s’assurer que l’utilisation des comptes locaux n’a pas été restreinte.
Autoriser le compte local à ouvrir une session
Pour résoudre ce problème, vous pouvez essayer de vous connecter à l’aide d’un compte d’administrateur système lorsque vous êtes sur la page de connexion.
- Connectez-vous à votre compte administrateur.
- Appuyez sur Win + R pour ouvrir la boîte de dialogue Exécuter la commande.
- tapez gpedit.msc et cliquez sur OK pour ouvrir l’éditeur de stratégie de groupe locale (LGPE).
- accédez à Configuration ordinateur > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Attribution des droits utilisateur.
- Double-cliquez sur la stratégie « Autoriser la connexion localement ».
- Accédez à l’onglet Paramètres de sécurité locaux.
- Cliquez sur l’option « Ajouter un utilisateur ou un groupe » pour ajouter votre compte local à la liste.
- Cliquez sur le bouton « Avancé » pour accéder à la page de sélection du compte.
- Cliquez sur le bouton « Rechercher maintenant » pour obtenir une liste complète des comptes locaux.
- Recherchez et cliquez sur le compte local avec lequel vous rencontrez des problèmes.
- Cliquez sur OK et suivez les étapes à l’écran pour terminer le processus.
Ces étapes devraient vous aider à activer l’option « Autoriser l’ouverture de session localement » et à résoudre le problème de connexion.
Utiliser l’Environnement de récupération Windows
Merci pour votre retour concernant l’impossibilité d’accéder aux comptes locaux sur votre poste Windows 11.
Comme vous ne pouvez pas ouvrir de session ni accéder à secpol.msc ou gpedit.msc, même en mode sans échec, nous vous recommandons d’utiliser l’Environnement de récupération Windows (WinRE).
Cela vous permettra de vous connecter avec ce nouveau compte et de reprendre la main sur les paramètres système.
Vérifier la communication avec Active Directory
Tout d’abord, il est important de vérifier si votre appareil communique correctement avec Active Directory (AD).
Spécifiquement, les utilisateurs qui se sont déjà connectés sur cet appareil peuvent se reconnecter car leurs informations d’identification sont mises en cache.
Si une erreur se produit sur un appareil client qui communique avec Active Directory (AD), il peut y avoir un problème de DNS.
Normalement, même si le nom d’hôte de l’appareil client est changé, Active Directory devrait le reconnaître sans aucun problème.
Cependant, il existe de rares cas où la synchronisation entre Active Directory et le client ne se déroule pas correctement, entraînant l’erreur « domaine non disponible ».
Contrôler l’adresse IP et la connectivité réseau
Lorsque vos utilisateurs vous signalent l’apparition d’un message « Un contrôleur de domaine active directory pour le domaine n’a pas pu être contacté », ce problème peut avoir plusieurs causes.
Le plus souvent, les utilisateurs qui ne peuvent contacter le contrôleur de domaine ont des problèmes de réseau ou de matériel.
La commande Windows permettant d’afficher l’adresse IP actuelle et d’autres informations utiles est « ipconfig -all ».
Il faut d’abord vérifier l’adresse IP : vous semble-t-elle correcte ?
Si ce n’est pas le cas, redémarrez le client pour obtenir une nouvelle adresse et rafraîchir la pile réseau.
Une fois que vous avez résolu les problèmes d’adresse IP, vérifiez que le client peut faire un ping sur le contrôleur de domaine.
Si le contrôleur de domaine est inaccessible à partir du client mais que les autres clients n’ont pas le même problème, ce dernier peut être dû à un câble ou un matériel défectueux sur le client ou sur un équipement situé entre les deux.
Vérifier les paramètres DNS
Dans cette situation, vérifiez d’abord si le serveur DNS peut résoudre le nom de domaine.
Si la résolution du nom de domaine n’est pas possible, l’appareil ne pourra pas récupérer les informations d’identification nécessaires, entraînant un échec de la connexion.
Dans de tels cas, même si AD fonctionne correctement, vous pourriez être confronté à la situation déroutante de ne pas pouvoir vous connecter.
Les paramètres du serveur DNS sont une partie essentielle de la qualité et de la stabilité de la connexion réseau.
En entrant les bonnes adresses de serveur DNS, vous pouvez résoudre les noms de domaine Internet en adresses IP, permettant l’accès aux ressources réseau.
Par conséquent, surtout dans les systèmes dépendants d’Active Directory, il est crucial d’avoir les bonnes adresses de serveur DNS.
Le serveur DNS principal doit généralement être le serveur DNS le plus fiable sur le réseau, et le serveur DNS alternatif devrait être le deuxième plus fiable.
Par conséquent, lors de problèmes de connexion sur le réseau, il est recommandé de vérifier d’abord cet écran de paramètres pour s’assurer que le bon serveur DNS est spécifié.
Les utilisateurs finaux peuvent être en mesure de résoudre rapidement les problèmes de connexion en examinant ces paramètres.
Contrôler les enregistrements SRV du DNS
Dans le DNS, on trouve ce que l’on appelle un enregistrement SRV qui définit des services spécifiques.
L’enregistrement SRV dont nous avons besoin est le pointeur vers le contrôleur de domaine, qui se trouve dans Zones de recherche directes -> domaine -> dossier _tcp.
L’entrée se nomme _ldap.
Si le nom que vous obtenez ne correspond pas à un contrôleur de domaine correct, cela explique pourquoi vous obtenez l’erreur « contrôleur de domaine inaccessible ».
Le système recherche le contrôleur de domaine sur le mauvais ordinateur.
Vider le cache DNS
En tant qu’approche alternative pour résoudre le problème, vous pouvez vous connecter au système en utilisant un compte utilisateur local et effacer le cache DNS avec des privilèges administratifs.
Cette commande supprime le cache des résultats de résolution DNS stockés sur le système.
Elle aborde les problèmes temporaires et les dysfonctionnements liés aux informations DNS, incitant le système à effectuer une résolution de nom basée sur des données DNS fraîches et précises.
Vérifier l’authentification multifacteur et les stratégies d’accès
Si vous n’avez répondu à aucune de ces questions, vous devez reconfigurer votre authentification multifacteur.
Les connexions aux machines virtuelles ne prennent pas en charge l’authentification multifacteur Microsoft Entra activée ou appliquée par utilisateur.
Vous disposez de stratégies d’accès conditionnel limitant l’accès.
Si vous avez intégré les journaux Microsoft Entra aux journaux Azure Monitor pour accéder à vos journaux de connexion Microsoft Entra via Log Analytics, vous pouvez voir si vous avez activé l’authentification multifacteur et quelle stratégie d’accès conditionnel déclenche l’événement.
Vous devez autoriser les applications suivantes pour les identités externes à se connecter correctement.
Messages associés aux échecs de connexion
- La méthode de connexion que vous essayez d’utiliser n’est pas autorisée.
- Vous disposez de stratégies d’accès conditionnel limitant l’accès.
- Une session ouverte spécifiée n’existe pas.
- Une erreur d’authentification s’est produite.
- Échec de la connexion.
- Oops, nous n’avons pas pu nous connecter à NAME.
- Nous n’avons pas pu nous connecter au PC distant en raison d’une erreur de sécurité.
- Nous n’avons pas pu nous connecter au PC distant, car vos informations d’identification ne fonctionnaient pas.
Vérifier les mises à jour Windows Server
Les mises à jour de sécurité d’avril 2025 pour Windows Server sont à l'origine de problèmes d’authentification sur les contrôleurs de domaine Active Directory.
Quelles sont les versions affectées ? Dans quels cas de figure ?
Le mardi 8 avril 2025, Microsoft a publié de nouvelles mises à jour cumulatives obligatoires pour ses OS, dont Windows Server.
Il y a notamment la mise à jour KB5055523 à destination de Windows Server 2025 et à l'origine de ces problèmes de connexion.
L'entreprise américaine a reconnu l'existence de ce problème et la bonne nouvelle, c'est que tout le monde n'est pas concerné.
L’authentification par clé publique de l’appareil, connue sous le nom Machine PKINIT, est concernée.
Le coupable de ce dysfonctionnement a été identifié par Microsoft : il s'agit du correctif de sécurité pour la faille associée à la référence CVE-2025-26647.
Celle-ci est située dans Kerberos et permettrait à un attaquant authentifié d'élever ses privilèges.
« Un attaquant authentifié peut exploiter cette vulnérabilité en obtenant un certificat contenant la valeur SKI (Subject Key Identifier) cible auprès d'une autorité de certification (CA). »
En attendant une solution pérenne, Microsoft évoque une solution de contournement.
Celle-ci consiste à modifier la valeur du registre AllowNtAuthPolicyBypass située dans HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc en la passant de « 2 » à « 1 ».
Apprenez le Kerberoasting Active Directory
Rejoindre le domaine ou corriger la configuration du client
Vérifier la communication avec Active Directory, tester la fonctionnalité DNS, vérifier les paramètres DNS appropriés sur les appareils clients, vérifier les changements de nom d’hôte, et rejoindre le domaine ou utiliser un format de connexion spécifique sont présentés comme des clés pour résoudre le problème.
En suivant ces étapes, de nombreux utilisateurs ont pu surmonter leurs problèmes de connexion.
Espérons que l’une de ces solutions vous aidera à résoudre le problème de « contrôleur de domaine inaccessible » et que vous ne serez pas obligé de remplacer une partie de votre matériel.