Comment trouver le contrôleur de domaine (serveur d’ouverture de session) auquel vous êtes authentifié ?

Il est parfois très utile de savoir à quel contrôleur de domaine votre machine Windows communique, notamment en cas de problèmes de stratégie de groupe ou de connexion. Si une machine est mal configurée ou rencontre des problèmes réseau, elle peut se connecter à un contrôleur de domaine incorrect ou plus lent, ce qui ralentit la connexion ou empêche l’application immédiate des stratégies. Cela peut paraître technique, mais il existe des méthodes rapides pour le déterminer sans avoir à éplucher les journaux ni à se creuser la tête. La plupart de ces méthodes consistent simplement à utiliser des commandes ou à vérifier des variables d’environnement, mais elles peuvent révéler si votre ordinateur est connecté au bon contrôleur de domaine ou si des problèmes surviennent en arrière-plan.

Comment identifier le contrôleur de domaine auquel un ordinateur est authentifié ?

Connaître le serveur d’ouverture de session peut aider à résoudre les problèmes de lenteur de connexion, les dysfonctionnements des GPO ou simplement à vérifier que votre machine est bien connectée au contrôleur de domaine approprié. En général, quelques commandes dans l’invite de commandes, PowerShell ou la vérification des variables d’environnement suffisent. Sur une machine, le contrôleur de domaine correct peut s’afficher, tandis que sur une autre, ce n’est pas toujours le cas, surtout en cas de problème de configuration DNS ou réseau. L’important est que si vous voyez un nom de contrôleur de domaine inhabituel, il est conseillé de revoir la configuration réseau ou DNS.

Méthode 1 : Utilisation de l’invite de commandes ou de PowerShell

  • Ouvrez l’invite de commandes ou PowerShell (en tant qu’administrateur si possible).Tapez : echo %logonserver% Cette commande affichera le contrôleur de domaine auquel votre session est associée. Par exemple, il peut s’agir de \\MUN-DC02 ou d’un nom similaire. Si ce nom semble incorrect ou obsolète, il est peut-être temps de vérifier votre configuration DNS ou réseau.
  • Vous pouvez également consulter ces informations avec la commande suivante : systeminfo | find /i "logon server" qui affichera une ligne portant un nom similaire. Il arrive parfois, sur certaines configurations, que cette commande ne fonctionne pas correctement ou qu’elle soit lente, notamment si la machine est peu performante ou rencontre des problèmes de réseau.

Méthode 2 : Variables d’environnement dans PowerShell

  • Ouvrez PowerShell et saisissez : $env:LOGONSERVER Cela devrait afficher les mêmes informations, mais de manière plus claire. Si le résultat ressemble à \\WOSHUB-DC, c’est parfait. Si le résultat est vide ou ne correspond pas à vos attentes, votre machine est peut-être connectée à un contrôleur de domaine différent ou obsolète, ou la résolution DNS ne fonctionne pas correctement.

Méthode 3 : Utilisation de gpresult

  • Exécutez la commande : gpresult /r recherchez la ligne « La stratégie de groupe a été appliquée à partir de : ».Elle indique généralement le contrôleur de domaine exact qui a appliqué les stratégies. Si ce contrôleur de domaine est différent de celui attendu, cela peut entraîner des ralentissements ou des problèmes de stratégie, ou simplement révéler une erreur de configuration réseau.

Méthode 4 : Utilisation de nltest

  • Cet outil pratique indique auprès du contrôleur de domaine votre machine s’authentifie et vérifie également la relation d’approbation. Exécutez-le nltest /DSGETDC:yourdomain.com en remplaçant ` yourdomain.com<domain>` par votre domaine. Il affichera le nom du contrôleur de domaine, les informations du site et l’état. Si la réponse indique un contrôleur de domaine incorrect ou une erreur, cela peut être la cause de la lenteur des connexions ou des échecs de stratégie de groupe.
  • Une autre commande pour réinitialiser ou basculer manuellement vers un autre contrôleur de domaine : nltest /SC_RESET:DOMAIN\DCName Par exemple : nltest /SC_RESET:WOSHUB\MUN-DC02.woshub.com Gardez à l’esprit que si le contrôleur de domaine spécifié n’est pas accessible, vous obtiendrez une erreur du type ERROR_NO_LOGON_SERVERS.

Comment Windows trouve le contrôleur de domaine le plus proche

C’est un peu étrange, mais Windows utilise le service NetLogon pour trouver le contrôleur de domaine le plus approprié lors de votre connexion. Ce service s’exécute au démarrage : il interroge le DNS pour trouver un contrôleur de domaine, vérifie votre adresse IP par rapport aux informations du site et met en cache les informations du contrôleur de domaine le plus proche afin de ne pas avoir à effectuer toutes ces opérations à chaque fois. Si NetLogon ne fonctionne pas ou est mal configuré, vous risquez de vous retrouver avec un contrôleur de domaine moins performant (par exemple, un contrôleur éloigné ou avec une mauvaise connectivité), ce qui ralentit la connexion et le traitement des stratégies de groupe.

Vérifiez si NetLogon est en cours d’exécution :

get-service netlogon

Si le programme s’arrête, c’est un problème. Redémarrez-le avec :

Start-Service netlogon

En résumé, voici les étapes suivies par Windows pour trouver le contrôleur de domaine :

  1. NetLogon envoie une requête DNS pour trouver tous les contrôleurs de domaine (voir _ldap._tcp.dc._msdcs.yourdomain.com);
  2. Le DNS renvoie une liste de contrôleurs de domaine ;
  3. Windows vérifie l’adresse IP et interroge les contrôleurs de domaine au sujet de leur site (via des requêtes LDAP) ;
  4. Les informations du site le plus proche sont stockées dans le registre ( HKLM\System\CurrentControlSet\Services\Netlogon\Parameters) pour des recherches ultérieures plus rapides ;
  5. Windows contacte tous les contrôleurs de domaine locaux de ce site, et le premier à répondre devient votre serveur d’ouverture de session.

Si vous devez forcer manuellement Windows à utiliser un contrôleur de domaine spécifique en raison de problèmes, vous pouvez exécuter :

nltest /SC_RESET:yourdomain.com\DCName

Voyez si cela résout le problème. N’oubliez pas : si le contrôleur de domaine est inaccessible, vous obtiendrez des erreurs telles que « NERR_Success » ne s’affiche pas et vous finirez par être bloqué avec le message « Aucun serveur d’ouverture de session disponible ».

Et si la situation dégénère vraiment, le module AD de PowerShell dispose d’une commande du type :

Get-ADDomainController -Discover -NextClosestSite

Cette commande peut vous indiquer le contrôleur de domaine le plus approprié auquel votre machine devrait se connecter en fonction de la hiérarchie du site. Bien entendu, le module PowerShell Active Directory doit être installé, mais cette information s’avère très utile pour résoudre les problèmes de connexion aux contrôleurs de domaine.

Alors oui, c’est parfois un peu le bazar, mais ces commandes et vérifications permettent de déterminer rapidement si votre machine est connectée au bon contrôleur de domaine ou si un problème réseau sous-jacent provoque des dysfonctionnements. Je ne sais pas pourquoi ça fonctionne parfois et pas d’autres fois, mais bon, savoir, c’est déjà la moitié du chemin parcouru.

Résumé

  • Utilisez-le echo %logonserver%pour visualiser le courant continu.
  • Vérifiez auprès de systeminfo | find /i "logon server".
  • PowerShell $env:LOGONSERVERest bien pratique lui aussi.
  • Exécutez cette commande gpresult /rpour vérifier la source des politiques appliquées.
  • Utilisez nltest pour tester et réinitialiser les connexions.
  • Utilisez des commandes PowerShell comme celle-ci Get-ADDomainControllerpour trouver dynamiquement le meilleur contrôleur de domaine.

Conclure

Déterminer à quel contrôleur de domaine votre machine se connecte n’est pas si compliqué une fois qu’on a compris ces commandes. Parfois, des problèmes de DNS ou de réseau peuvent tout bloquer, mais la plupart du temps, il suffit d’une vérification rapide et éventuellement d’un vidage du cache DNS ou d’un redémarrage du service NetLogon. Ces informations permettent de diagnostiquer toutes sortes de problèmes de connexion étranges ou de lenteurs dans les applications GPO. Et oui, c’est utile de les connaître si vous devez dépanner un réseau lent ou des problèmes de stratégie de groupe. En espérant que cela permette à quelqu’un de gagner du temps !