Comment un système client dans un réseau Active Directory trouve-t-il sur quel site il réside?

Alors que je préparais une présentation pour commencer l'administration de Windows, j'ai été frappé par une question que je suis étonnée de ne pas avoir posée plus tôt.

Je le sais:

• AD est logiquement configuré dans les sites pour faciliter la réplication et réduire la latence des communications nécessaires au domaine entre les ordinateurs clients et les services de domaine.
• Les sites sont définis par les sous-réseaux qui leur sont appliqués
• le sous-domaine _msdcs contient une hiérarchie d'enregistrements SRV pour la recherche générale (_tcp) et pour la recherche spécifique au site (_sites)
• Les ordinateurs savent en quelque sorte sur quel site ils se trouvent, ou le contrôleur de domaine décide de manière transparente dans une certaine magie du DNS ... ou le fait-il?

Ce billet de blog indique que les ordinateurs clients d'un réseau AD peuvent «savoir» à quel site ils appartiennent. Ma question est, si tel est le cas, comment le découvrent-ils?

Si le client lui-même ne le sait pas, comment le contrôleur de domaine aide-t-il la machine dans le processus de sélection des services AD les plus proches de cet ordinateur client?

La réponse est que la première fois qu'un client s'authentifie auprès d'Active Directory, il ne sait pas sur quel site il se trouve.

Lorsqu'il rejoint le domaine pour la première fois, le client effectue des requêtes DNS et LDAP générales et obtient une liste de tous les contrôleurs de domaine du domaine. le premier DC avec lequel il s'authentifie.

Une fois que le client a rejoint le domaine, Active Directory indiquera au client à quel site il appartient. Active Directory le sait car l'administrateur a placé le sous-réseau IP du client dans AD Sites & Services et l'a associé à un site.

Active Directory indique au client quel est son site AD et le client le stocke dans son propre registre dans la HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\DynamicSiteNamevaleur de registre. De cette façon, la prochaine fois que le client démarrera, il saura quelle requête DNS spécifique au site effectuer pour n'obtenir que les contrôleurs de domaine qui se trouvent sur ce site.

Bien sûr, le comportement complet est documenté dans KB247811 , mais si vous voulez le voir par vous-même, vous pouvez exécuter Wireshark ou NetMon et faire une trace de paquet, puis rejoindre un domaine pendant que la trace est en cours d'exécution. Vous verrez la séquence exacte des requêtes DNS et des liaisons LDAP. Les requêtes DNS et les liaisons LDAP suivantes sont effectuées dans les sous-zones spécifiques au site car le client a été informé par AD du site auquel il appartient.

Le service Netlogon actualisera périodiquement les informations de son site AD, donc si vous passez à un autre réseau, votre client obtiendra son nouveau site automatiquement. Cela peut être ajusté dans la HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\SiteNameTimeoutvaleur de registre. ( Lien )

Il existe en fait plusieurs fonctions / API interdépendantes. Même s'ils sont longs, il s'agit en fait d'une des lectures Active Directory les plus intéressantes.

Quelle que soit l'explication ci-dessous, il y a deux choses dont vous devez être conscient:

• Si un contrôleur de domaine sur le site local ne répond pas pour une raison quelconque, il est prévu que le client contacte n'importe quel contrôleur de domaine du domaine. C'est normal, et c'est toujours le comportement par défaut. Parfois, il n'est pas évident pourquoi cela se produit.

• Cela peut être sous-optimal. Considérez le scénario suivant: Trois sites: New York City (hub / datacener - rapide), Los Angeles (a parlé à NYC - rapide) et le Kazakhstan (a parlé à NYC - certainement pas rapide). Si votre client sur le site de LA ne peut pas contacter son DC local pour une raison quelconque, il n'est pas inconcevable qu'il s'authentifie auprès du Kazakhstan.

Il y a quelques solutions. Vous pouvez faire l'un ou l'autre ou les deux.

• Microsoft a créé le paramètre de stratégie de groupe / registre nommé à juste titre TryNextClosestSite. Cela signifie que le client LA devrait essayer NYC avant de parcourir la planète à la recherche de DC. Brillant! Cela a pris huit ans, mais nous l'avons finalement obtenu avec Vista / 2008. N'oubliez pas, non activé par défaut, vous devez créer un objet de stratégie de groupe pour l'activer.

• Pour les sites à rayons où vous ne voulez vraiment pas que le contrôleur de domaine serve des clients dans d'autres sites, vous pouvez créer une stratégie de groupe / paramètre de registre qui spécifie quels enregistrements DNS ne doivent pas être enregistrés. Ceci est appelé DNS Mnemonics.

Recherche d'un contrôleur de domaine dans le site le plus proche (API DsGetSiteName)
http://technet.microsoft.com/en-us/library/cc978016.aspx

Mappage des adresses IP aux noms de site

"Au démarrage de Net Logon, le service Net Logon sur chaque contrôleur de domaine énumère les objets de site dans le conteneur de configuration. Net Logon sur chaque contrôleur de domaine est également informé de toute modification apportée aux objets de site. Net Logon utilise les informations de site pour créer un structure en mémoire utilisée pour mapper les adresses IP aux noms de site.

«Lorsqu'un client qui recherche un contrôleur de domaine reçoit la liste des adresses IP de contrôleur de domaine de DNS, le client commence à interroger les contrôleurs de domaine à son tour pour savoir quel contrôleur de domaine est disponible et approprié. Active Directory intercepte la requête, qui contient l'adresse IP du client et la transmet à Net Logon sur le contrôleur de domaine. Net Logon recherche l'adresse IP du client dans sa table de mappage de sous-réseau au site en recherchant l'objet de sous-réseau qui correspond le mieux à l'adresse IP du client, puis renvoie les informations suivantes:

• Nom du site dans lequel se trouve le client ou du site qui correspond le mieux à l'adresse IP du client.

• Nom du site dans lequel se trouve le contrôleur de domaine actuel.

• Un bit qui indique si le contrôleur de domaine trouvé est localisé (le bit est défini) ou non (le bit n'est pas défini) dans le site le plus proche du client.

"Le contrôleur de domaine renvoie les informations au client. La réponse contient également divers autres éléments qui décrivent le contrôleur de domaine. Le client inspecte les informations pour déterminer s'il doit essayer de trouver un meilleur contrôleur de domaine. La décision est prise comme suit:

"Si le contrôleur de domaine renvoyé se trouve dans le site le plus proche (le bit renvoyé est défini), le client utilise ce contrôleur de domaine.

"Si le client a déjà essayé de trouver un contrôleur de domaine sur le site dans lequel le contrôleur de domaine prétend que le client est situé, le client utilise ce contrôleur de domaine.

"Si le contrôleur de domaine n'est pas dans le site le plus proche, le client met à jour ses informations de site et envoie une nouvelle requête DNS pour trouver un nouveau contrôleur de domaine sur le site. Si la deuxième requête réussit, le nouveau contrôleur de domaine est utilisé. Si le la deuxième requête échoue, le contrôleur de domaine d'origine est utilisé.

"Si le domaine interrogé par un ordinateur est le même que le domaine auquel l'ordinateur est joint, le site sur lequel réside l'ordinateur (tel que signalé par un contrôleur de domaine) est stocké dans le registre informatique. Le client le stocke nom de site dans l'entrée de Registre DynamicSiteName dans HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Netlogon \ Parameters. Par conséquent, l'API DsGetSiteName renvoie le site dans lequel se trouve l'ordinateur. "

Fonction DsGetDcName
http://msdn.microsoft.com/en-us/library/ms675983%28VS.85%29.aspx

Types de localisateurs
http://technet.microsoft.com/en-us/library/cc978019.aspx

Fonctions de service d'annuaire
http://technet.microsoft.com/en-us/subscriptions/ms675900%28v=vs.85%29.aspx

Fonctionnement de la prise en charge DNS pour Active Directory
http://technet.microsoft.com/en-us/library/cc759550%28v=ws.10%29.aspx

Comment optimiser l'emplacement d'un contrôleur de domaine qui réside en dehors du site d'un client
http://support.microsoft.com/kb/306602