Procédure de localisation 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.

Version du produit d’origine :   Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Numéro de la base de connaissances initiale :   247811

Cet article s’applique à Windows 2000. La prise en charge de Windows 2000 se termine le 13 juillet 2010. Le centre de solutions de fin de prise en charge Windows 2000 est un point de départ pour la planification de votre stratégie de migration à partir de Windows 2000. Pour plus d’informations, consultez la politique de support Microsoft.

Résumé

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

Plus d’informations

Cette séquence décrit la façon dont le localisateur trouve un contrôleur de domaine :

  • Sur le client (l’ordinateur qui recherche le contrôleur de domaine), le localisateur est initié comme un appel de procédure distante (RPC) au service Netlogon local. L’appel de l’interface de programmation d’application (API) DsGetDcName du localisateur est implémenté par le service Netlogon.
  • Le client recueille les informations nécessaires pour sélectionner un contrôleur de domaine et 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 façons suivantes :
    • Pour un nom DNS, Netlogon interroge DNS à l’aide du localisateur compatible IP/DNS, c’est-à-dire que DsGetDcName appelle l’appel DnsQuery pour lire les enregistrements de ressources de service (SRV) et « A » à partir 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 le DNS pour les enregistrements SRV sous la forme générale :

_service. _protocol. Les serveurs Active Directory nom_domaine_dns offrent le service LDAP (Lightweight Directory Access Protocol) sur le protocole TCP. Par conséquent, les clients recherchent un serveur LDAP en interrogeant le DNS pour un enregistrement au format : _ldap. _tcp. DnsDomainName

  • Pour un nom NetBIOS, Netlogon effectue une découverte de contrôleur de domaine à l’aide du localisateur compatible avec la version 4,0 de Microsoft Windows NT (autrement dit, à l’aide du mécanisme spécifique au transport (par exemple, WINS).

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

  • Le service Netlogon envoie un datagramme aux ordinateurs qui ont enregistré le nom. Pour les noms de domaine NetBIOS, le datagramme est implémenté en tant que message mailslot. 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 protocole 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, 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 du 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 favorise une 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 trouver un contrôleur de domaine. Le client envoie une requête de recherche DNS au DNS pour trouver des contrôleurs de domaine, de préférence dans le sous-réseau du client. Par conséquent, les clients recherchent un contrôleur de domaine en interrogeant le DNS pour un enregistrement de la forme :

_LDAP. _TCP. DC. _msdcs. DomainName une fois que le client a localisé un contrôleur de domaine, il établit la communication à l’aide de 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 se basant sur le sous-réseau IP de ce client. 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 de recherche DNS au 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. Dans le cas contraire, le client effectue 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 de 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 ignore l’entrée de cache. Il essaie 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, configurer un canal sécurisé. Le client est ensuite prêt à effectuer des requêtes normales et à rechercher des informations dans 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é. Étant donné que 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 passé via le gestionnaire de comptes de sécurité à l’agent de service d’annuaire, puis à la couche de base de données et enfin à la base de données dans le moteur ESE (Extensible Storage Engine).

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

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

  1. Consultez l’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 l’observateur d’événements, cliquez sur Démarrer, pointez sur programmes, sur outils d’administration, puis cliquez sur Observateur d’événements. Vérifiez le journal 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 à l’aide de la commande ipconfig/all dans une invite de commandes.
  3. Utilisez l’utilitaire Ping pour vérifier la connectivité réseau et la résolution de noms. Exécutez la commande ping sur l’adresse IP et le nom du serveur. Vous pouvez également utiliser la commande ping pour 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 vers un fichier texte, utilisez la commande suivante :

Netdiag/v >test.txt consulter le fichier journal, rechercher les problèmes et examiner les composants liés. Ce fichier contient également d’autres détails relatifs à la configuration du réseau. 5. Pour résoudre les problèmes mineurs, utilisez l’outil NetDiag avec la syntaxe suivante : Netdiag/fix. 6. Utilisez la commande nltest/dsgetdc : DomainName 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 enregistrées dans le système DNS. Vérifiez que les enregistrements de l’hôte du serveur et le GUID des enregistrements SRV peuvent être résolus.

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

Guid nslookup. _msdcs. rootdomain. com

  1. Si l’une de ces commandes échoue, utilisez l’une des méthodes suivantes pour réenregistrer les enregistrements avec DNS :

    • Pour forcer l’inscription de l’enregistrement de l’hôte, tapez ipconfig/registerdns.
    • Pour forcer l’inscription du service contrôleur de domaine, arrêtez et démarrez le service Netlogon.
  2. 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 un certain nombre de tests pour vérifier qu’un contrôleur de domaine s’exécute correctement. Utilisez cette commande pour envoyer les résultats dans un fichier texte : Dcdiag/v >dcdiag.txt

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

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

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

Références

Pour plus d’informations, reportez-vous au chapitre 10 du kit de ressources Windows, « diagnostic Active Directory, résolution des problèmes et récupération ».