Как клиентская система в сети Active Directory находит, на каком сайте она находится?

Когда я составлял презентацию для начала администрирования Windows, меня поразил вопрос, который я изумляю, я не задавал раньше.

Я знаю это:

• AD логически настраивается на сайтах, чтобы помочь в репликации и уменьшении задержки необходимого для домена обмена данными между клиентскими компьютерами и доменными службами.
• Сайты определяются применяемыми к ним подсетями.
• поддомен _msdcs содержит иерархию записей SRV для общего поиска (_tcp) и для поиска по сайту (_sites)
• Компьютеры почему-то знают, на каком сайте они находятся, или контроллер домена прозрачно решает какую-то магию DNS ... или нет?

Этот пост в блоге намекает на то, что клиентские компьютеры в сети AD могут «знать», к какому сайту они принадлежат. Мой вопрос: если это так, как они это выясняют?

Если сам клиент не знает, как DC помогает машине в процессе выбора ближайших служб AD к этому клиентскому компьютеру?

Ответ заключается в том, что когда клиент впервые проходит аутентификацию в Active Directory, он не знает, на каком сайте он находится.

При первом присоединении к домену клиент выполняет общие запросы DNS и LDAP и получает список всех контроллеров домена в домене, а затем перемещается вниз по списку, пытаясь связать LDAP, и первым успешным DC, с которым он связывается - то есть первый DC, с которым он аутентифицируется.

После того, как клиент присоединился к домену, Active Directory сообщит клиенту, к какому сайту он принадлежит. Active Directory знает об этом, потому что администратор поместил IP-подсеть клиента в AD Sites & Services и связал ее с сайтом.

Active Directory сообщает клиенту, каков его сайт AD, и клиент сохраняет его в своем реестре в HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\DynamicSiteNameзначении реестра. Таким образом, в следующий раз, когда клиент загружается, он знает, какой специфичный для сайта DNS-запрос сделать, чтобы он получал только контроллеры домена, которые находятся на этом сайте.

Конечно, полное поведение описано в KB247811 , но если вы хотите убедиться в этом сами, вы можете запустить Wireshark или NetMon и выполнить трассировку пакетов, а затем присоединиться к домену во время трассировки. Вы увидите точную последовательность запросов DNS и привязок LDAP. Последующие DNS-запросы и привязки LDAP выполняются к подзонам, относящимся к конкретному сайту, потому что AD сказал клиенту, к какому сайту он принадлежит.

Служба Netlogon будет периодически обновлять информацию о своем сайте AD, поэтому, если вы перейдете в другую сеть, ваш клиент автоматически получит новый сайт. Это можно изменить в HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\SiteNameTimeoutзначении реестра. ( Ссылка )

Там на самом деле несколько взаимосвязанных функций / API. Несмотря на то, что они длинные, на самом деле это некоторые из наиболее интересных чтений Active Directory.

Независимо от объяснения, приведенного ниже, вам необходимо знать о двух вещах:

• Если DC на локальном сайте не отвечает по какой-либо причине, ожидается, что клиент свяжется с любым контроллером домена в домене. Это нормально, и это всегда было поведением по умолчанию. Иногда неясно, почему это происходит.

• Это может быть неоптимальным. Рассмотрим следующий сценарий: три сайта: Нью-Йорк (хаб / центр обработки данных - быстро), Лос-Анджелес (говорит с Нью-Йорком - быстро) и Казахстан (говорит с Нью-Йорком - определенно не быстро). Если ваш клиент на сайте LA по какой-либо причине не может связаться с местным DC, не исключено, что он будет аутентифицироваться в Казахстане.

Есть несколько решений. Вы можете сделать один или оба.

• Microsoft создала групповую политику / параметр реестра с именем TryNextClosestSite. Это означает, что клиент из Лос-Анджелеса должен попробовать Нью-Йорк, прежде чем бродить по планете в поисках DC. Brilliant! Прошло восемь лет, но мы наконец-то получили это с Vista / 2008. Помните, по умолчанию эта опция не включена, вам нужно создать объект групповой политики, чтобы включить это.

• Для подчиненных сайтов, где вы действительно не хотите, чтобы DC обслуживал клиентов на других сайтах, вы можете создать параметр групповой политики / реестра, который указывает, какие записи DNS не должны регистрироваться. Это называется DNS Mnemonics.

Поиск контроллера домена на ближайшем сайте (API DsGetSiteName)
http://technet.microsoft.com/en-us/library/cc978016.aspx

Сопоставление IP-адресов с именами сайтов

«Во время запуска Net Logon служба Net Logon на каждом контроллере домена перечисляет объекты сайта в контейнере конфигурации. Net Logon на каждом контроллере домена также уведомляется о любых изменениях, внесенных в объекты сайта. Net Logon использует информацию сайта для создания структура в памяти, которая используется для сопоставления IP-адресов с именами сайтов.

«Когда клиент, который ищет контроллер домена, получает список IP-адресов контроллера домена от DNS, клиент начинает по очереди запрашивать контроллеры домена, чтобы выяснить, какой контроллер домена доступен и подходит. Active Directory перехватывает запрос, который содержит IP-адрес клиента и передает его в Net Logon на контроллере домена. Net Logon ищет IP-адрес клиента в своей таблице сопоставления подсети и сайта, находя объект подсети, который наиболее точно соответствует IP-адресу клиента, а затем возвращает следующую информацию:

• Имя сайта, на котором находится клиент, или сайта, который наиболее точно соответствует IP-адресу клиента.

• Имя сайта, на котором находится текущий контроллер домена.

• Бит, который указывает, находится ли найденный контроллер домена (бит установлен) или нет (бит не установлен) на сайте, ближайшем к клиенту.

«Контроллер домена возвращает информацию клиенту. Ответ также содержит различные другие данные, которые описывают контроллер домена. Клиент проверяет информацию, чтобы определить, следует ли попытаться найти лучший контроллер домена. Решение принимается следующим образом:

«Если возвращенный контроллер домена находится в ближайшем узле (возвращенный бит установлен), клиент использует этот контроллер домена.

«Если клиент уже пытался найти контроллер домена на сайте, на котором контроллер домена утверждает, что клиент находится, клиент использует этот контроллер домена.

«Если контроллер домена не находится на ближайшем сайте, клиент обновляет информацию своего сайта и отправляет новый DNS-запрос, чтобы найти новый контроллер домена на сайте. Если второй запрос успешен, используется новый контроллер домена. Если Второй запрос не выполняется, используется оригинальный контроллер домена.

«Если домен, к которому запрашивается компьютер, совпадает с доменом, к которому присоединен компьютер, сайт, на котором находится компьютер (по сообщению контроллера домена), сохраняется в реестре компьютера. Клиент сохраняет это имя сайта в записи реестра DynamicSiteName в HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Netlogon \ Parameters. Следовательно, API-интерфейс DsGetSiteName возвращает сайт, на котором находится компьютер. "

Функция DsGetDcName
http://msdn.microsoft.com/en-us/library/ms675983%28VS.85%29.aspx

Типы локаторов
http://technet.microsoft.com/en-us/library/cc978019.aspx

Функции службы каталогов
http://technet.microsoft.com/en-us/subscription/ms675900%28v=vs.85%29.aspx

Как работает поддержка DNS для Active Directory
http://technet.microsoft.com/en-us/library/cc759550%28v=ws.10%29.aspx

Как оптимизировать расположение контроллера домена, который находится за пределами сайта клиента
http://support.microsoft.com/kb/306602