Les appareils Windows Microsoft trouvent parfois difficilement un contrôleur de domaine

Question

Les appareils Windows Microsoft trouvent parfois difficilement un contrôleur de domaine

Pierer Rrobert 40

Bonjour,

Nous rencontrons un problème intermittent où plusieurs appareils Microsoft Windows ne parviennent pas toujours à localiser un contrôleur de domaine Active Directory. Dans certains cas, la connexion au domaine ou l’authentification échoue temporairement avant de fonctionner à nouveau sans intervention.

Comment puis-je vérifier les enregistrements DNS Active Directory, la connectivité réseau entre les clients Windows et les contrôleurs de domaine, la configuration des Sites et Services Active Directory, ainsi que le processus de découverte des contrôleurs de domaine afin d’identifier la cause du problème ?

Merci d’avance pour votre aide.

0 commentaires

1 réponse

Votre réponse

Answer 1

Bonjour,

Les échecs intermittents de découverte d’un contrôleur de domaine proviennent souvent d’enregistrements DNS AD DS manquants ou obsolètes, de clients utilisant un DNS non autorisé pour le domaine, d’une connectivité réseau instable ou d’une configuration incorrecte des sites Active Directory. Commencez par vérifier ces éléments sur un poste affecté au moment où le problème se produit.

Exécutez ipconfig /all et confirmez que le client utilise les serveurs DNS internes qui hébergent ou résolvent la zone Active Directory, et non directement des DNS publics. Vérifiez ensuite la découverte du contrôleur de domaine avec :

nltest /dsgetdc:contoso.com /force
nslookup -type=SRV _ldap._tcp.dc._msdcs.contoso.com
nslookup -type=SRV _kerberos._tcp.contoso.com

Remplacez contoso.com par le nom DNS réel du domaine. La commande nltest indique quel contrôleur de domaine est découvert, tandis que les requêtes SRV permettent de vérifier si DNS publie les services LDAP et Kerberos attendus.

Vérifiez ensuite la connectivité vers le contrôleur de domaine découvert avec Test-NetConnection dc01.contoso.com -Port 389, en remplaçant le nom par celui de votre contrôleur. Ce test valide la connexion TCP LDAP, mais pas l’ensemble des mécanismes de découverte AD, notamment la recherche LDAP via UDP 389. Si le problème est intermittent, contrôlez aussi les ports requis pour Kerberos, DNS, SMB et RPC selon les services utilisés et les règles de pare-feu de votre environnement. Microsoft recommande également d’examiner les journaux Netlogon sur les clients et les contrôleurs de domaine.

Pour vérifier les enregistrements DNS du contrôleur de domaine, exécutez sur un DC :

dcdiag /test:dns /DnsRecordRegistration

Dans Active Directory Sites and Services (dssite.msc), confirmez que le sous-réseau IP de chaque client est associé au bon site et que les contrôleurs de domaine sont correctement placés. Sur le client, exécutez nltest /dsgetsite pour vérifier le site détecté. Un sous-réseau absent ou mal associé peut entraîner la sélection d’un contrôleur de domaine distant.

Si les échecs persistent, examinez Event Viewer > Windows Logs > System pour les événements Netlogon et les journaux DNS côté serveur. Vous pouvez également générer un rapport détaillé avec dcdiag /v > C:\Temp\dcdiag.txt. Évitez de redémarrer les services Netlogon ou de modifier les enregistrements DNS avant d’avoir identifié l’anomalie, particulièrement dans un environnement de production.

Pour préciser le diagnostic, pourriez-vous partager le code d’erreur exact, le résultat de nltest /dsgetdc:<votre-domaine> /force et indiquer si les postes concernés se trouvent dans un même sous-réseau ou sur plusieurs sites ?

Domic Vo.