Comment les contrôleurs de domaine sont situés dans Windows

• 09/08/2020
• 6 minutes de lecture
• • D
  • . v
  • s

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

Version originale du produit : Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Numéro KB original : 247811

Summary

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 rétrocompatibilité. Dans tous les autres cas, les noms de style DNS doivent être utilisés par principe. Cet article aborde également le dépannage du processus de localisation du contrôleur de domaine.

Plus d’informations

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

• Sur le client (l’ordinateur qui localise le contrôleur de domaine), le Locator est initié comme un appel de procédure à distance (RPC) au service Netlogon local. L’appel de l’interface de programmation d’application (API) DsGetDcName du Locator est mis en œuvre par le service Netlogon.

• Le client collecte les informations nécessaires pour sélectionner un contrôleur de domaine et transmet ces informations au service Netlogon en utilisant 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 le DNS en utilisant le Locator compatible IP/DNS– c’est-à-dire que DsGetDcName appelle l’appel DnsQuery pour lire les enregistrements de ressources de service (SRV) et les enregistrements « A » du 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 basé sur Windows interroge le DNS pour les enregistrements SRV sous la forme générale :

    _service._protocol.DnsDomainName

    Les serveurs Active Directory offrent le service Lightweight Directory Access Protocol (LDAP) sur le protocole TCP. Par conséquent, les clients trouvent un serveur LDAP en interrogeant le DNS pour un enregistrement de la forme:

    _ldap._tcp.DnsDomainName

Pour un nom NetBIOS, Netlogon effectue la découverte du contrôleur de domaine en utilisant le Microsoft Windows NT version 4.0-compatible Locator (c’est-à-dire en utilisant le mécanisme spécifique au transport (par exemple, WINS).

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

• Le service Netlogon envoie un datagramme aux ordinateurs qui ont enregistré le nom. Pour les noms de domaine NetBIOS, le datagramme est implémenté comme un message mailslot. Pour les noms de domaine DNS, le datagramme est implémenté comme une recherche LDAP User Datagram Protocol (UDP). (UDP est le protocole de transport de datagrammes 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 renvoie 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, ce 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 renvoie les informations à DsGetDcName.
• Le service Netlogon met en cache les informations relatives au contrôleur de domaine afin que les demandes ultérieures n’aient pas à 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 se connecte ou rejoint le réseau, il doit pouvoir localiser un contrôleur de domaine. Le client envoie une requête DNS Lookup au DNS pour trouver des contrôleurs de domaine, de préférence dans le propre sous-réseau du client. Par conséquent, les clients trouvent un contrôleur de domaine en interrogeant le DNS pour un enregistrement de la forme:

_LDAP._TCP.dc._msdcs.domainname

Après avoir localisé un contrôleur de domaine, le client établit la communication en utilisant LDAP pour accéder à Active Directory. Dans le cadre de cette négociation, le contrôleur de domaine identifie le site sur lequel se trouve le client en fonction du sous-réseau IP de ce dernier. Si le client communique avec un contrôleur de domaine qui ne se trouve pas dans le site le plus proche (le plus optimal), le contrôleur de domaine renvoie le nom du site du client. Si le client a déjà essayé de trouver des contrôleurs de domaine dans ce site (par exemple, lorsque le client envoie une requête DNS Lookup à DNS pour trouver des contrôleurs de domaine dans le sous-réseau du client), le client utilise le contrôleur de domaine qui n’est pas optimal. 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 des informations du service d’annuaire pour identifier les sites et les sous-réseaux.

Après que le client ait 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 quinze minutes et jette l’entrée du cache. Il tente ensuite de trouver un contrôleur de domaine optimal dans le même site que le client.

Après avoir établi un chemin de communication vers le contrôleur de domaine, le client peut établir les informations d’identification et d’authentification et, si nécessaire pour les ordinateurs basés sur Windows, configurer un canal sécurisé. Le client est alors prêt à effectuer des requêtes normales et à rechercher des informations par rapport à l’annuaire.

Le client établit une connexion LDAP à un contrôleur de domaine pour se connecter. Le processus d’ouverture de session utilise le gestionnaire de comptes de sécurité. Comme le chemin de communication utilise l’interface LDAP et que le client est authentifié par un contrôleur de domaine, le compte client est vérifié et transmis par Security Accounts Manager à l’agent de 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).

Dépannage du processus de localisation de domaine

Pour dépanner le processus de localisation de domaine :

1. Vérifier l’observateur d’événements sur le client et le serveur. Les journaux d’événements peuvent contenir des messages d’erreur indiquant qu’il y a un problème. Pour afficher l’observateur d’événements, cliquez sur Démarrer, pointez sur Programmes, pointez sur Outils d’administration, puis cliquez sur Observateur d’événements. Vérifiez le journal du système sur le client et le serveur. Vérifiez également les journaux du service d’annuaire sur le serveur et les journaux DNS sur le serveur DNS.

2. Vérifiez la configuration IP en utilisant la commande ipconfig /all à une invite de commande.

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

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

   netdiag /v >test.txt
   Examinez le fichier journal, à la recherche de problèmes, et examinez les composants impliqués. Ce fichier contient également d’autres détails de configuration du réseau.

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

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

8. Utiliser l’outil NSLookup pour vérifier que les entrées DNS sont correctement enregistrées dans le DNS. Vérifiez que les enregistrements d’hôte de serveur et les enregistrements SRV de GUID peuvent être résolus.

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

9. Si l’une de ces commandes ne réussit pas, utilisez l’une des méthodes suivantes pour réenregistrer les enregistrements avec le DNS :
   • Pour forcer l’enregistrement des enregistrements d’hôte, tapez ipconfig /registerdns.
   • Pour forcer l’enregistrement du service du contrôleur de domaine, arrêtez et démarrez le service Netlogon.

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

11. Utiliser l’outil Ldp.exe pour se connecter et se lier au contrôleur de domaine afin de vérifier la connectivité LDAP appropriée.

12. Si vous pensez qu’un contrôleur de domaine particulier a 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 consignées dans le dossier Debug du fichier Netlogon.log.

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

.