Як клієнтська система в мережі 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 на локальному сайті не відповідає з будь-якої причини, очікується, що клієнт зв’яжеться з будь-яким контролером домену в домені. Це нормально, і це завжди було поведінкою за замовчуванням. Іноді не видно, чому це відбувається.

• Це може бути неоптимальним. Розглянемо наступний сценарій: Три сайти: Нью-Йорк (концентратор / datacener - швидкий), Лос-Анджелес (розмовляв з NYC - швидкий) та Казахстан (розмовляв з NYC - точно не швидко). Якщо ваш клієнт на веб-сайті LA не може з будь-якої причини зв’язатися з місцевим постійним клієнтом, немислимо, що він автентифікується з Казахстаном.

Є пара рішень. Можна зробити і те, і те і інше.

• Microsoft влучно створила групову політику / налаштування реєстру на ім'я TryNextClosestSite. Це означає, що клієнт LA повинен спробувати NYC перед роумінгом по планеті, шукаючи DC. Блискуче! Минуло вісім років, але ми нарешті це отримали з Vista / 2008. Пам’ятайте, що не включено за замовчуванням, для створення цього потрібно створити групову групу.

• Для сайтів з розмовою, де ви дійсно не хочете, щоб DC обслуговував клієнтів на інших сайтах, ви можете створити групову політику / параметр реєстру, який визначає, які записи DNS не слід реєструвати. Це називається мнемонікою DNS.

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

Картографування IP-адрес до імен сайтів

"Під час запуску Net Logon послуга Net Logon на кожному контролері домену перераховує об'єкти сайту в контейнері Конфігурація. Net Logon на кожному контролері домену також повідомляється про будь-які зміни, внесені в об'єкти сайту. Net Logon використовує інформацію про сайт для створення структура пам'яті, яка використовується для відображення IP-адрес на імена сайтів.

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

• Назва веб-сайту, на якому знаходиться клієнт, або веб-сайт, який найбільше відповідає IP-адресі клієнта.

• Назва сайту, на якому знаходиться поточний контролер домену.

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

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

"Якщо контролер повернутого домену знаходиться на найближчому веб-сайті (повернений біт встановлений), клієнт використовує цей контролер домену.

"Якщо клієнт вже намагався знайти контролер домену на сайті, на якому контролер домену стверджує, що клієнт знаходиться, клієнт використовує цей контролер домену.

"Якщо контролер домену не знаходиться на найближчому сайті, клієнт оновлює інформацію про свій сайт і надсилає новий DNS-запит, щоб знайти на сайті новий контролер домену. Якщо другий запит успішний, використовується новий контролер домену. Якщо другий запит не вдається, використовується оригінальний контролер домену.

"Якщо домен, до якого запитується комп'ютер, такий самий, як домен, до якого приєднано комп'ютер, сайт, на якому знаходиться комп'ютер (як повідомляється контролером домену), зберігається в реєстрі комп'ютера. Клієнт зберігає це назва сайту в записі реєстру DynamicSiteName в HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Netlogon \ Параметри. Тому 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/subscriptions/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