Partager via

Localisation des contrôleurs de domaine dans Windows et Windows Server

L'emplacement du contrôleur de domaine, également connu sous le nom de DC Locator, fait référence à l'algorithme utilisé par l'ordinateur client pour trouver un contrôleur de domaine approprié. La localisation des contrôleurs de domaine est une fonction essentielle dans tous les environnements d'entreprise pour permettre l'authentification des clients avec Active Directory.

Dans cet article, découvrez le processus de localisation des contrôleurs de domaine, y compris la découverte, la détection du site le plus proche et la configuration des mappages de noms de domaine NetBIOS.

Processus de localisation des contrôleurs de domaine

L'algorithme de localisation des contrôleurs de domaine (Locator) se compose de deux parties :

  • Le localisateur recherche les contrôleurs de domaine enregistrés.

  • Le Locator soumet une requête pour localiser un contrôleur de domaine dans le domaine spécifié.

Une recherche LDAP User Datagram Protocol (UDP) est alors envoyée à un ou plusieurs des contrôleurs de domaine listés dans la réponse pour s'assurer de leur disponibilité. Enfin, le service Netlogon met en cache le contrôleur de domaine découvert pour faciliter la résolution des requêtes futures.

Processus de découverte

Les domaines Active Directory ont toujours deux noms distincts : le nom de domaine complet (FQDN) DNS et le nom de domaine NetBIOS. Les noms de domaine NetBIOS ont une longueur héritée et d’autres contraintes. Par exemple, les domaines NetBIOS sont limités à 15 caractères.

Le nom de domaine NetBIOS d'un domaine Active Directory ne doit pas nécessairement être le même que le FQDN du domaine Active Directory. Par exemple, le nom de domaine complet d’un domaine Active Directory peut être contoso.com associé à un nom de domaine NetBIOS fabrikam.

La localisation du contrôleur de domaine dans Windows peut fonctionner selon deux modes de base :

  • La découverte basée sur le DNS est basée sur l'annonce du contrôleur de domaine à l'aide du DNS.

    Les contrôleurs de domaine enregistrent divers enregistrements SRV dans le DNS, tels que les enregistrements qui représentent des capacités clés comme le Centre de distribution de clés ou le Catalogue global, et les enregistrements qui décrivent la localité comme les enregistrements de site Active Directory. Les clients interrogent ensuite DNS pour obtenir les enregistrements SRV appropriés, puis effectuent un test ping sur ces serveurs à l’aide de pings LDAP basés sur UDP.

    Ce mode n'est pris en charge que lorsque vous utilisez des noms de domaine DNS et que vos contrôleurs de domaine fonctionnent sous Windows 2000 ou une version ultérieure. Les contrôleurs de domaine pris en charge fonctionnent de manière plus optimale dans ce mode, mais peuvent passer à l'autre mode dans certains scénarios.

  • La découverte basée sur NetBIOS implique que les contrôleurs de domaine enregistrent des enregistrements dans Windows Internet Name Service (WINS). Les clients interrogent WINS pour obtenir les enregistrements appropriés, puis effectuent un test ping sur les contrôleurs de domaine candidats cibles possibles. Une variante de ce mode utilise un mécanisme de diffusion pris en charge par les messages mailslot où le client diffuse des paquets sur son réseau local pour rechercher des DC.

Important

Quand une application interroge un contrôleur de domaine en spécifiant un nom de domaine de type NetBIOS court, la localisation du contrôleur de domaine tente toujours de mapper ce nom de domaine court à un nom de domaine DNS. Si l'emplacement du DC peut mapper les noms de domaine avec succès, il utilise la découverte basée sur le DNS avec le nom de domaine DNS mappé.

Les noms de domaine de style NetBIOS sont mappés aux noms de domaine DNS à partir de plusieurs sources dans l'ordre suivant :

  1. Informations mises en cache à partir d’une recherche précédente

  2. Tous les domaines de la forêt actuelle

  3. Noms de niveau supérieur (TLN) pour toutes les approbations de forêt de confiance et approbations externes

  4. Pour Windows Server 2025 et versions ultérieures :

    1. Mappages de noms de domaine configurés par l’administrateur

    2. Mappages de noms de domaine pour toutes les forêts et domaines enfants dans l’approbation des forêts de confiance

  5. Sessions de connexion sur l’ordinateur client

Lorsqu'aucune de ces sources ne peut trouver un nom de domaine DNS, l'emplacement DC peut procéder à la découverte basée sur NetBIOS en utilisant le nom de domaine court de style NetBIOS d'origine

À partir de Windows Server 2025, Netlogon télécharge et met en cache les informations de dénomination sur les domaines et les domaines enfants dans toutes les forêts de confiance. Ces informations sont utilisées quand vous mappez des noms de domaine de type NetBIOS à des noms de domaine DNS.

Nous vous recommandons d'utiliser la recherche basée sur le DNS au lieu de la recherche basée sur le NetBIOS. La découverte basée sur le DNS est plus fiable et plus sûre. DsGetDcName est l’API principale de localisation du contrôleur de domaine.

Important

À partir de Windows Server 2025, le localisateur DC ne permet pas l'utilisation d'une localisation de type NetBIOS. Pour savoir comment configurer ce comportement, reportez-vous à la section relative au paramétrage de la stratégie de découverte NetBIOS.

Pour en savoir plus sur le processus de découverte, sélectionnez l'onglet correspondant à la méthode que vous souhaitez étudier.

Le processus suivi par le localisateur peut être résumé comme suit :

  1. Sur le client (l'ordinateur qui localise le contrôleur de domaine), le Locator est lancé sous la forme d'un appel de procédure à distance (RPC) au service Netlogon local. Le service Netlogon met en œuvre l'API Locator (DsGetDcName).

  2. Le client collecte les informations nécessaires à la sélection d'un contrôleur de domaine et les transmet au service Netlogon en utilisant l'API DsGetDcName.

  3. Le service Netlogon du client utilise les informations collectées pour rechercher un contrôleur de domaine pour le domaine spécifié. Le processus de recherche utilise l'une des deux méthodes suivantes :

  4. Netlogon interroge le DNS en utilisant le localisateur compatible IP/DNS. 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.

    • Lorsqu'une station de travail se connecte à un domaine Windows, elle interroge le DNS pour obtenir des enregistrements SRV au format _<service>._<protocol>.<DnsDomainName>. Les clients qui interrogent le DNS pour trouver un serveur LDAP pour le domaine en utilisant le format suivant, où DnsDomainName est le nom de domaine.

      _ldap._tcp.DnsDomainName

  5. Le service Netlogon envoie un datagramme en tant que recherche LDAP UDP aux contrôleurs de domaine découverts qui enregistrent le nom.

  6. Chaque contrôleur de domaine disponible répond au datagramme pour indiquer qu'il est actuellement opérationnel et renvoie ensuite les informations à DsGetDcName

  7. Le service Netlogon renvoie les informations au client à partir du contrôleur de domaine qui répond en premier.

  8. Le service Netlogon met en cache les informations relatives aux contrôleurs de domaine de sorte qu'il n'est pas nécessaire de répéter le processus de découverte pour les requêtes suivantes. La mise en cache de ces informations favorise l'utilisation cohérente du même contrôleur de domaine et, par conséquent, une vue cohérente d'Active Directory.

Paramétrage de la stratégie de découverte NetBIOS

À partir de Windows Server 2025, le localisateur de DC ne permet pas l'utilisation de la découverte basée sur NetBIOS. BlockNetBIOSDiscovery est un nouveau paramètre de stratégie de groupe pour le service Netlogon qui permet aux administrateurs de contrôler ce comportement. Pour accéder à la stratégie dans l’Éditeur de gestion des stratégies de groupe, accédez à Configuration ordinateur>Modèles d’administration>Système>Net Logon>Enregistrements DNS du localisateur de contrôleurs de domaine>Bloquer la découverte basée sur NetBIOS pour la localisation du contrôleur de domaine.

Les paramètres suivants s’appliquent à BlockNetBIOSDiscovery :

  • TRUE (valeur par défaut) : le localisateur de contrôleurs de domaine n’autorise pas l’utilisation de la localisation de contrôleur de domaine de type NetBIOS.
  • FALSE : DC locator permet l'utilisation de WINS ou d'une découverte basée sur le mailslot si toutes les contraintes héritées l'autorisent également.

Vous utilisez le paramètre BlockNetBIOSDiscovery pour appliquer une position sécurisée par défaut pour la localisation du contrôleur de domaine. Nous vous recommandons de conserver la valeur TRUE. Désactivez ce paramètre uniquement pour des périodes temporaires, pendant lesquelles vous recherchez d’autres atténuations.

Le nouveau paramètre de stratégie ressemble à ceci :

Capture d'écran du paramètre de stratégie de groupe BlockNetBIOSDiscovery avec la valeur par défaut activée.

Conseil

Vous pouvez activer ou désactiver séparément la possibilité d'utiliser des lots de courrier à l'échelle de la machine en utilisant le paramètre de stratégie SMB EnableMailslots. Pour que le localisateur de DC puisse utiliser les lots de courrier pour la découverte des DC, vous devez activer les lots de courrier au niveau SMB et désactiver BlockNetBIOSDiscovery Vous pouvez interroger et définir le paramètre EnableMailslots en exécutant les cmdlets PowerShell Get-SmbClientConfiguration et Set-SmbClientConfiguration.

Site Active Directory le plus proche

Une fois que le client a localisé un contrôleur de domaine, il é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 de son sous-réseau IP.

Si le client communique avec un contrôleur de domaine qui ne se trouve pas dans le site le plus proche et 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, il utilise à la place un contrôleur de domaine dans un site moins optimal. Par exemple, le client envoie une requête DNS Lookup à DNS pour trouver 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.

Le client met en cache l'entrée du contrôleur de domaine. Si le contrôleur de domaine ne se trouve pas sur le site optimal, le client vide le cache au bout de 15 minutes et supprime 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 et d'authentification. Si nécessaire, le client peut également configurer une chaîne sécurisée pour les ordinateurs basés sur Windows. Le client est maintenant prêt à effectuer des requêtes normales et à rechercher des informations dans l'annuaire.

Le client établit une connexion LDAP avec un contrôleur de domaine pour se connecter. La procédure de connexion utilise le gestionnaire de comptes de sécurité. Le chemin de communication utilise l'interface LDAP et un contrôleur de domaine authentifie le client. Ensuite, le compte client est vérifié et passé par Security Accounts Manager à 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).

Configuration des mappages de noms de domaine NetBIOS

À partir de Windows Server 2025, les administrateurs forestiers peuvent configurer des mappages personnalisés entre le nom de domaine DNS et le nom de domaine NetBIOS. Les mappages configurés par l'administrateur au niveau de la forêt sont un mécanisme facultatif que vous ne devez utiliser que lorsque toutes les autres options sont insuffisantes. Par exemple, si une application ou un environnement nécessite d'autres mappages de noms de domaine que d'autres sources ne peuvent pas fournir automatiquement.

Les mappages de noms de domaine personnalisés sont stockés dans un objet serviceConnectionPoint situé dans le contexte d’appellation de la configuration Active Directory. Par exemple :

CN=DCLocatorDomainNameMappings,CN=Windows NT,CN=Services,CN=Configuration,DC=contoso,DC=com

L’attribut msDS-Setting de cet objet serviceConnectionPoint peut contenir une ou plusieurs valeurs. Chaque valeur contient le nom de domaine DNS et le nom de domaine NetBIOS, séparés par un point-virgule, comme dans dnsdomainname.com:NetBIOSdomainname.

Par exemple :

  • contoso.com:fabrikam
  • tatertots.contoso.com:tots
  • tailspintoys.com:tailspintoys

Vous pouvez configurer ces mappages dans les paramètres de gestion des domaines et des trusts Active Directory en procédant comme suit :

  1. Cliquez avec le bouton droit sur le domaine.
  2. Sélectionnez Propriétés.
  3. Sélectionnez l’onglet Mappages du localisateur de contrôleurs de domaine.

Ensuite, le service Netlogon sur les clients télécharge et met en cache les mappages personnalisés dans l'objet DCLocatorDomainNameMappings toutes les 12 heures. Le service utilise automatiquement ces informations lorsque vous mappez des noms de domaine de type NetBIOS à des noms de domaine DNS.

La nouvelle page de gestion des domaines et approbations Active Directory ressemble à ceci :

Capture d'écran de la page des mappages de noms de domaine de localisateur de DC dans le snap-in Domaines et trusts Active Directory.

Important

Configurez des mappages de noms de domaine au niveau de la forêt configurés par l’administrateur uniquement si vous êtes certain que toutes les autres sources de mappage de noms sont insuffisantes. En règle générale, ces mappages arbitraires ne sont nécessaires qu’en l’absence de relation d’approbation entre les clients et les domaines cibles, quand les applications clientes ne peuvent pas être migrées pour spécifier des noms de domaine de type DNS.

Contenu connexe