Emplacement des contrôleurs de domaine dans Windows

Cet article décrit le mécanisme utilisé par Windows pour localiser un contrôleur de domaine dans un domaine Windows.

Produits concernés : Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Numéro de la base de connaissances d’origine : 247811

Résumé

Cet article détaille le processus de localisation d’un domaine par son nom de style DNS et son nom de style plat (NetBIOS). Le nom de style plat est utilisé pour la compatibilité descendante. Dans tous les autres cas, les noms de style DNS doivent être utilisés comme une question de stratégie. Cet article traite également de la résolution des problèmes liés au processus d’emplacement du contrôleur de domaine.

Comment le localisateur trouve un contrôleur de domaine

Cette séquence décrit comment le localisateur trouve un contrôleur de domaine :

• Sur le client (l’ordinateur qui localise le contrôleur de domaine), le localisateur est démarré en tant qu’appel de procédure distante (RPC) au service Netlogon local. L’appel d’interface de programmation d’application (API) Locator DsGetDcName est implémenté par le service Netlogon.

• Le client collecte les informations nécessaires pour sélectionner un contrôleur de domaine. Ensuite, il transmet les informations au service Netlogon à l’aide de l’appel DsGetDcName.

• Le service Netlogon sur le client utilise les informations collectées pour rechercher un contrôleur de domaine pour le domaine spécifié de l’une des deux manières suivantes :

  • Pour un nom DNS, Netlogon interroge DNS à l’aide du localisateur compatible IP/DNS. Autrement dit, DsGetDcName appelle l’appel DnsQuery pour lire les enregistrements de ressource de service (SRV) et les enregistrements « A » de DNS après avoir ajouté le nom de domaine à la chaîne appropriée qui spécifie les enregistrements SRV.

  • Une station de travail qui se connecte à un domaine Windows interroge DNS pour les enregistrements SRV sous la forme générale :

    _service._protocol.DnsDomainName
    

    Les serveurs Active Directory offrent le service LDAP (Lightweight Directory Access Protocol) sur le protocole TCP. Ainsi, les clients recherchent un serveur LDAP en interrogeant DNS pour obtenir un enregistrement au format :

    _ldap._tcp. DnsDomainName

• Pour un nom NetBIOS, Netlogon effectue la découverte du contrôleur de domaine à l’aide du localisateur compatible avec Microsoft Windows NT version 4.0. Autrement dit, en utilisant le mécanisme spécifique au transport, tel que WINS.

  Dans Windows NT 4.0 et versions antérieures, la « découverte » est un processus permettant de localiser un contrôleur de domaine pour l’authentification dans le domaine principal ou un domaine approuvé.

• Le service Netlogon envoie un datagramme aux ordinateurs qui ont inscrit le nom. Pour les noms de domaine NetBIOS, le datagramme est implémenté en tant que message maillot. Pour les noms de domaine DNS, le datagramme est implémenté en tant que recherche UDP (User Datagram Protocol) LDAP. (UDP est le protocole de transport de datagramme sans connexion qui fait partie de la suite de protocoles TCP/IP. TCP est un protocole de transport orienté connexion.)

• Chaque contrôleur de domaine disponible répond au datagramme pour indiquer qu’il est actuellement opérationnel et retourne les informations à DsGetDcName.

UDP permet à un programme sur un ordinateur d’envoyer un datagramme à un programme sur un autre ordinateur. UDP inclut un numéro de port de protocole, qui permet à l’expéditeur de faire la distinction entre plusieurs destinations (programmes) sur l’ordinateur distant.

• Chaque contrôleur de domaine disponible répond au datagramme pour indiquer qu’il est actuellement opérationnel et retourne les informations à DsGetDcName.
• Le service Netlogon met en cache les informations du contrôleur de domaine afin que les requêtes ultérieures n’ont pas besoin de répéter le processus de découverte. La mise en cache de ces informations encourage l’utilisation cohérente du même contrôleur de domaine et une vue cohérente d’Active Directory.

Lorsqu’un client ouvre une session ou rejoint le réseau, il doit être en mesure de localiser un contrôleur de domaine. Le client envoie une requête de recherche DNS au DNS pour rechercher des contrôleurs de domaine, de préférence dans le propre sous-réseau du client. Ainsi, les clients recherchent un contrôleur de domaine en interrogeant DNS pour obtenir un enregistrement au format :

_LDAP._TCP.dc._msdcs.domainname

Une fois que le client a localisé un contrôleur de domaine, il établit la communication à l’aide du protocole LDAP pour accéder à Active Directory. Dans le cadre de cette négociation, le contrôleur de domaine identifie le site dans lequel se trouve le client en fonction du sous-réseau IP de ce client.

Si le client communique avec un contrôleur de domaine qui n’est pas dans le site le plus proche (le plus optimal), le contrôleur de domaine retourne le nom du site du client. Si le client a déjà essayé de trouver des contrôleurs de domaine dans ce site, il utilise le contrôleur de domaine qui n’est pas optimal. Par exemple, le client envoie une requête de recherche DNS à DNS pour rechercher des contrôleurs de domaine dans le sous-réseau du client.

Sinon, le client effectue à nouveau une recherche DNS spécifique au site avec le nouveau nom de site optimal. Le contrôleur de domaine utilise certaines informations du service d’annuaire pour identifier les sites et les sous-réseaux.

Une fois que le client a localisé un contrôleur de domaine, l’entrée du contrôleur de domaine est mise en cache. Si le contrôleur de domaine ne se trouve pas dans le site optimal, le client vide le cache après 15 minutes et ignore l’entrée du cache. Il tente ensuite de trouver un contrôleur de domaine optimal dans le même site que le client.

Une fois que le client a établi un chemin de communication vers le contrôleur de domaine, il peut établir les informations d’identification d’ouverture de session et d’authentification. Et si nécessaire pour les ordinateurs Windows, il peut configurer un canal sécurisé. Le client est alors prêt à effectuer des requêtes normales et à rechercher des informations sur le répertoire.

Le client établit une connexion LDAP à un contrôleur de domaine pour se connecter. Le processus d’ouverture de session utilise le Gestionnaire des comptes de sécurité. Le chemin de communication utilise l’interface LDAP et le client est authentifié par un contrôleur de domaine. Ainsi, le compte client est vérifié et transmis via le Gestionnaire des comptes de sécurité à l’agent du service d’annuaire, puis à la couche de base de données et enfin à la base de données dans le moteur de stockage extensible (ESE).

Résolution des problèmes liés au processus de localisateur de domaine

Pour résoudre les problèmes liés au processus de localisateur de domaine :

1. Vérifiez observateur d'événements sur le client et le serveur. Les journaux des événements peuvent contenir des messages d’erreur indiquant qu’il y a un problème. Pour afficher observateur d'événements, sélectionnez Démarrer, pointez sur Programmes>Outils d’administration, puis sélectionnez observateur d'événements. Vérifiez le journal système sur le client et le serveur. En outre, case activée les journaux du service d’annuaire sur le serveur et les journaux DNS sur le serveur DNS.

2. Vérifiez la configuration IP à l’aide de la ipconfig /all commande à partir d’une invite de commandes.

3. Utilisez l’utilitaire Ping pour vérifier la connectivité réseau et la résolution de noms. Effectuez un test ping sur l’adresse IP et le nom du serveur. Vous pouvez également effectuer un test ping sur le nom de domaine.

4. Utilisez l’outil Netdiag pour déterminer si les composants réseau fonctionnent correctement. Pour envoyer une sortie détaillée à un fichier texte, utilisez la commande suivante :

   netdiag /v >test.txt
   Passez en revue le fichier journal, recherchez les problèmes et examinez les composants impliqués. Ce fichier contient également d’autres détails de configuration réseau.

5. Pour résoudre des problèmes mineurs, utilisez l’outil Netdiag avec la syntaxe suivante :

   netdiag /fix.

6. Utilisez la nltest /dsgetdc:domainname commande pour vérifier qu’un contrôleur de domaine peut être localisé pour un domaine spécifique.

7. Utilisez l’outil NSLookup pour vérifier que les entrées DNS sont correctement inscrites dans DNS. Vérifiez que les enregistrements de l’hôte du serveur et les enregistrements SRV GUID peuvent être résolus.

   Par exemple, pour vérifier l’inscription des enregistrements, utilisez les commandes suivantes :
   nslookup servername. childofrootdomain. rootdomain.com
nslookup guid._msdcs. rootdomain.com

8. Si l’une de ces commandes échoue, utilisez l’une des méthodes suivantes pour réinscrire des enregistrements auprès de DNS :

   • Pour forcer l’inscription des enregistrements d’hôte, tapez ipconfig /registerdns.
   • Pour forcer l’inscription du service de contrôleur de domaine, arrêtez et démarrez le service Netlogon.

9. Pour détecter les problèmes de contrôleur de domaine, exécutez l’utilitaire DCdiag à partir d’une invite de commandes. L’utilitaire exécute de nombreux tests pour vérifier qu’un contrôleur de domaine s’exécute correctement. Utilisez cette commande pour envoyer les résultats à un fichier texte : dcdiag /v >dcdiag.txt

10. Utilisez l’outil Ldp.exe pour vous connecter et établir une liaison au contrôleur de domaine afin de vérifier la connectivité LDAP appropriée.

11. Si vous pensez qu’un contrôleur de domaine particulier rencontre des problèmes, il peut être utile d’activer la journalisation de débogage Netlogon. Utilisez l’utilitaire NLTest en tapant cette commande : nltest /dbflag:0x2000ffff. Les informations sont ensuite enregistrées dans le dossier Debug dans le fichier Netlogon.log.

12. Si vous n’avez toujours pas isolé le problème, utilisez le Moniteur réseau pour surveiller le trafic réseau entre le client et le contrôleur de domaine.

References

Pour plus d’informations, consultez le Kit de ressources Windows, chapitre 10, « Diagnostic, résolution des problèmes et récupération Active Directory ».