Рука руку гріє active directory і dns

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

Active Directory використовує DNS як механізм пошуку контролерів домену та інших об'єктів. Виділяють три наступних компонента, від яких залежить робота AD в DNS:

  • Domain controller locator
  • Доменні імена Active Directory в DNS
  • Об'єкти Active Directory в DNS

А тепер давайте розглянемо більш докладно:

Domain controller locator

Представлений службою NET LOGON, що дозволяє клієнтам знайти контролери домену.

Доменні імена Active Directory в DNS

Кожен домен має DNS ім'я (наприклад: inadmin.ru), так само кожен комп'ютер з цього домену має своє DNS ім'я (наприклад: Server01.inadmin.ru). Архітектурно, кожен компонент зберігається як об'єкт в Active Directory і як вузол в DNS. Тут є принципова відмінність, хоча імена однакові, але виконують вони різні ролі.
  • DNS дозволяє імена доменів і комп'ютерів з ресурсних записів. Для цього надсилається запит на DNS сервер, який зберігає DNS базу даних
  • Active Directory дозволяє доменні об'єкти. Виходила шляхом запиту до контролерів домену, такими як LDAP запити.

Об'єкти Active Directory в DNS

Коли DNS зберігається в Active Directory, то для кожної DNS зони створюється контейнер (клас dnsZone). Усередині даного об'єкта зберігаються об'єкти DNS (клас dnsNode) для кожного унікального імені. Ці унікальні імена включають зміни, пов'язані з хостовой машиною. У кожного об'єкта dnsNode є атрибут з декількома значеннями dnsRecord, який містить значення для кожної ресурсної записи, пов'язаної з ім'ям об'єкта.

імена комп'ютерів

Browser Service Elections

DNS ім'я називають повним ім'ям або FQDN (fully qualified domain name). FQDN ім'я виходить шляхом додавання імені комп'ютера (перші 15 байт SAMAccountName, без символу "$") і первинного DNS суфікса (DNS ім'я домену, в якому знаходиться комп'ютер). Для ОС Windows можна подивитися по шляху WIN + Break. За замовчуванням, первинний DNS суфікс для FQDN імені повинен бути таким же, як і ім'я Active Directory домену, в якому ви перебуваєте. При необхідності можна додати інші доменні суфікси, які створюються як msDS-AllowedDNSSuffixes атрибути.

Отже ми маємо, що для Server01.inadmin.ru

  • Префікс - це перша частина імені. У моєму прикладі: Server01
  • Суфікс - це друга частина імені, що містить домен, в якому знаходиться компьютер.В моєму прикладі: inadmin.ru

Так само є SPN (service principal name), це трохи інше. Зазвичай SPN ім'я виходить з DNS імені хоста. SPN використовується в процесі взаємної аутентифікації між клієнтом і сервером, котрі володіють конкретними службами. Клієнт знаходить облікову обліковий запис комп'ютера використовує SPN сервіс. І намагається з нею з'єднатися.

Active Directory в DNS

Під час інсталяції контролера домену SRV і A записи динамічно реєструються в DNS. Обидва типи записів необхідні для механізму пошуку контролерів домену (Domain controller locator). Після установки Active Directory необхідні записи можна знайти на контролері домену в.
% Systemroot% \ System32 \ Config \ Netlogon .dns.

  • _msdcs- це піддомен, певний Microsoft. Його завдання визначати розташування DC, які виконую определнного ролі в лісі і в домені. Дана зона зберігається в forest-wide application directory partition. Служба Net Logon реєструє SRV записи для ідентифікації Well-Known ресурсів, таких як DC (Domain Controller), GC (Global catalog), PDC (Primary Domain Controller), Domains (Globally Unique Identifier, GUID), як префікси в піддомені _msdcs. Певні таким чином піддомени визначають контролери домену, що знаходяться в домені або лісі і виконують певні ролі. Що б визначати розташування DC за типом або за GUID, сервера Windows реєструють SRV за наступним шаблоном:

_Service._Protocol.DcType._msdcs.DnsDomainName

  • SRV Записи. Коли контролер домену завантажується, служба Net Logon за допомогою динамічних оновлень реєструє SRV і А записи на DNS сервері. SRV записи використовуються для закріплення імені служби (наприклад LDAP) за DNS ім'ям комп'ютера, на якому запущена дана служба. Коли робоча станція підключається до домену, то вона запитує DNS на наявність SRV записів за такою формою:

Так як Active Directory використовує TCP протокол, клієнти знаходять LDAP сервер в такому вигляді:

SRV записи, реєстровані службою Net Logon

В наступній таблиці, ми побачимо якісь SRV записи реєструються службою Net Logon. А так же область застосування записи і хто її реєструє.

  • DnsDomainName DNS ім'я домену, в якому знаходиться сервер
  • DnsForestName DNS ім'я лісу, тобто DNS ім'я кореневого домену лісу.

Хто читав першу статтю, для них наступні кілька таблиць уже відомі.

Дозволяє клієнту знайти сервер з запущеним LDAP сервісом в домені DnsDomainName. Наприклад: _ldap._tcp.inadmin.ru

_ldap._tcp. SiteName. _sites. DnsDomainName.

Дозволяє клієнту знайти сервер з запущеним LDAP сервісом в домені DnsDomainName в сайті SiteName. SiteName відносне ім'я, яке зберігається в контейнері Configuration в Active Directory. Наприклад: _ldap._tcp.Moscow._Sites.inadmin.ru

Дозволяє клієнту знайти контролер домену в домені DnsDomainName. Все DС реєструють цю SRV запис.

_ldap._tcp. SiteName. _sites.dc._msdcs. DnsDomainName.

Дозволяє клієнту знайти контролер домену в домені DnsDomainName в сайті SiteName. Все DС реєструють цю SRV запис.

Дозволяє клієнту знайти PDC в домені DnsDomainName.Только PDC сервер реєструє дану SRV запис.

Дозволяє клієнту знайти PDC в лісі DnsForestName.Только GC сервера реєструють цю SRV запис.

_ldap._tcp. SiteName. _sites.gc._msdcs. DnsForestName.

Дозволяє клієнту знайти GC в лісі DnsForestName.Только GC сервера належать даному лісі реєструють цю SRV запис. Наприклад: _ldap._tcp.Moscow._Sites._gc._msdcs.inadmin.ru

Дозволяє клієнту знайти GC в даному домені. Тільки GC сервера належать даному лісі DnsForestName реєструють цю SRV запис. Наприклад: _gc._tcp.inadmin.ru

Дозволяє клієнту знайти GC в даному лісі DnsForestName в сайті SiteName. Тільки GC сервера належать даному лісі DnsForestName реєструють цю SRV запис. Наприклад: _gc._tcp._Moscow._Sites.inadmin.ru

_ldap._tcp. DomainGuid. domains._msdcs. DnsForestName.

Дозволяє клієнтам знайти DC по GUID. GUID це 128-бітний унікальний покажчик. Розраховано на той момент, коли DnsDomainName і DnsForestName змінилися. Наприклад: _ldap._tcp.4f904480-7c78-11cf-b057-00aa006b4f8f.domains. _msdcs.inadmin.ru

Дозволяє клієнтам знайти Kerberos KDC в даному домені DnsDomainName. Все DC реєструють цю SRV запис.

Теж саме, що і _kerberos._tcp. DnsDomainName тільки через UDP

_kerberos._tcp. SiteName. _sites. DnsDomainName.

Дозволяє клієнтам знайти Kerberos KDC в даному домені DnsDomainName в сайті SiteName. Все DC реєструють цю SRV запис.

Дозволяє клієнтам знайти DC на якому запущена роль Kerberos KDC в даному домені DnsDomainName. Все DC з роллю KDC реєструють цю SRV запис.

_kerberos.tcp. SiteName. _sites.dc._msdcs. DnsDomainName.

Дозволяє клієнтам знайти DC на якому запущена роль Kerberos KDC в даному домені DnsDomainName в сайті SiteName. Все DC з роллю KDC реєструють цю SRV запис.

Дозволяє знайти Kerberos Password Change для поточного домену. Все DC c роллю kerberos KDC реєструю дану SRV запис

Теж саме, що і _kpassword._tcp. DnsDomainName тільки через UDP

Так само служба Net logon реєструє CNAME ресурсну запис для реплікації Active Directory.

DC Locator не використовує даний запис. Фактично цей запис допомагає при перейменуванні контролера домену.

Так само у SRV записів є додаткові поля:

Пріоритет сервера. Клієнти намагаються підключитися до серверів з меншим пріоритетом.

Використовується в ролі Load-balanced для серверів з однаковим пріоритетом. Клієнти рандомно вибирають сервер з ймовірністю, пропорційної вазі.

Служба Net Logon так само реєструє ресурсні записи A-типу для LDAP клієнтів, які не підтримують SRV записи. DC Locator не використовує дані записи.

Приклад реєстрації імен

Служба Net Logon. як ми вже говорили реєструє необхідні для виявлення записи. Простий приклад які записи оновлюються або створюються.

Хочеться доповнити, що реєструються не тільки DNS імена, але і NetBIOS.

  • DNS ім'я сервера, реєструється на DNS сервері (DC001.inadmin.ru)
  • NetBIOS ім'я, реєструється на WINS сервері (якщо він є) (DC001)

Коли клієнт, призначений для користувача комп'ютер, намагається зайти в домен, то він повинен виконати одну з двох дій

  • Якщо ім'я домену, в який входить клієнт, DNS ім'я, то комп'ютер повинен запросити DNS для пошуку контролера домену
  • Якщо ім'я домену, в який входить клієнт, NetBIOS ім'я, то комп'ютер повинен запросити WINS (можливе використання broadcast повідомлення для пошуку NetBIOS імені) для пошуку контролера домену

Після цього клієнт кешируєт даний запис. І зберігає її у себе, що б більше не генерувати зайвий трафік і навантаження на сервера.

Active Directory інтегровані зони

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

делегування

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

У звичайній ситуації делегують дочірні простір DNS імен, що збігається з ім'ям дочірнього домену Active Directory. Варто пам'ятати, що при делегування дозвіл імен повинно відбуватися не тільки в сторону з кореневого домена "вниз", а й навпаки. Тобто, DNS сервера розташовані в кореневому домені повинні з легкістю вирішити імена будь-якого дочірнього домену Active Directory.

Правильною роботою DNS буде вважатися коли користувачі з дочірнього домену Sokolniki.moscow.inadmin.ru зможу дозволяти імена в кореневому домені Inadmin.ru і його будь-яких дочірніх доменах. наприклад SPB.inadmin.ru

Процес Domain Controller Locator

Перш за все алгоритм складається з основних дій:

  • Знаходження контролерів домену зареєстрованих в DNS
  • Відправка DNS запиту на знаходження контролерів домену в певному домені
  • Відправка LDAP запиту для підтвердження працездатності контролера домену
  • кешування запиту

А тепер давайте розглянемо більш докладно.

  1. На клієнті, комп'ютері, який хоче знайти контролер домену Locator ініціює RPC для Net Logon (DsGetDcName)
  2. Клієнт збирає необхідну інформацію для вибору контролера домену та передає інформацію службі Net Logon, використовуючи DsGetDcName API
  3. Служба Net Logon використовує отриману інформацію для вибору контролера домену в домені.
    • Для DNS імені Net Logon використовує DNS запити (DNS-compatible Locator) DnsQuery для отримання SRV і A записів.
    • Для короткого імені пошук контролера домену випольняется за допомогою NT 4.0-compatible Locator, який спирається, наприклад на WINS.

Пошук контролера домену в найближчому сайті

Коли DC Locator намагається знайти контролер домену, то він намагається знайти найближчий контролер домену. Для цього він використовує інформацію, збережену в Active Directory.

Коли контролер домену реєструє записи DNS, то він виробляє це в декількох місцях. Одним з таких місць є піддомен _sites, в якому зберігається інформація про сайти і серверах, що знаходяться в цих сайтах. Коли відбувається пошук контролера домену, то перш за все йде пошук в своєму сайті, і тільки потім в інших сайтах (наприклад, якщо контролери домену не доступні в своєму сайті, або їх там взагалі немає).

Ви напевно знаєте, що кожному сайту можна прив'язати свою підмережа? Ось саме для цієї мети це і необхідно робити.

Примітка: Коли у комп'ютер не знає свій останній сайт (з реєстру), то він буде звертатися до будь-якого контролера домену. Є варіант налаштувати Netmask ordering і тоді DNS буде намагатися видати IP найближчого контролера домену тільки з точки зору IP маршрутизації.

Сайти Active Directory і Subnet

Раджу прочітатьданную статтю. Дуже добре Ілля описав сайти і їх взаємодія. Описано просто, тому переписувати ще раз - немає сенсу

Сайт це набір підмереж, з'єднаних швидким каналом обміну даних. Служать для управління трафіком реплікації.

  • У Active Directory сайти визначені як об'єкти в cn = Sites, cn = Configuration, dc = ForestRootDomain контейнері.
    • Контролери домену визначені в cn = servers, cn = site_name, cn = Sites, cn = Configuration, dc = ForestRootDomain
  • Subnet це частина сегмента сайту і представлена ​​cn = Subnets, cn = Configuration, dc = ForestRootDomain контейнері. У кожного об'єкта Subnet є siteObject атрибут, який пов'язує його з об'єктом сайту; значення siteObject - distinguished name сайту.
  • Об'єкти транспорту представлені в CN = Inter-Site Transports, cn = Sites, cn = Configuration, dc = ForestRootDomain

Важливо: Сайти можуть в собі містити одну або кілька IP мереж. Задаються в форматі network / mask_bits. Адміністратор повинен вручну визначити сайти, контролери домену і підмережі.

Примітка: Так як об'єкти сайтів зберігаються в розділі Configuration, то вони реплікуються по всьому лісу Active Directory. Саме це дає можливість кожному контролеру домену знати про розташування всіх контролерів домену в лісі і будувати топологію. Служба Net Logon реєструє так само зміни відбулися в сайті.

в ключі DynamicSiteName

Примітка: можна перезаписати параметр DynamicSiteName на заданий вручну, для цього потрібно використовувати параметр SiteName (необхідно створити), при цьому DynamicSiteName не використовуватиметься

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

Site Coverage

Є така можливість, що в не в кожному сайті буде буде контролер домену. За замовчуванням, кожен контролер домену перевіряє всі сайти в лісі і будує матрицю реплікації. Всі контролери домену реєструю себе в сайтах, в яких немає контролерів домену або визначені lowest-cost з'єднання. Це забезпечує, що кожен сайт буде мати контролери домену за замовчуванням для кожного домена в лісі, навіть якщо в сайті немає контролерів домену.

Алгоритм Site Coverage

В даному алгоритмі ми розглянемо, як контролера домену необхідно визначати чи варто реєструвати необхідні записи в сайтах, які не мають контролерів домену.

  • Побудувати список всіх цільових сайтів - в яких немає контролерів домену для поточного домену.
  • Побудувати список для всіх сайтів - в яких є контролери домену для поточного домена
  • Для кожного сайту, в якому немає контролера домену виконуються:
    1. Побудувати список сайтів, в яких є контролери домену
    2. З них, побудувати список сайтів які мають мінімальну вартість для сайтів зі списку п.1
    3. Якщо більше одного, то скоротити до одного кандидата, вибравши сайт з великим кол-вом контролерів домену.
    4. Якщо більше одного, то залишити одного кандидата, сортую в алфавітному порядку.
    5. Зареєструвати SRV записи для контролера домену в сайті.

Кеші і timeout

Кеші служать для того, що б рідше звертатися до пошуку контролерів домену. Скільки зберігати дані про поточний контролері домену. Здається в реєстрі поле CloseSiteTimeout. За замовчуванням час встановлено у 15 хвилин. (Мінімально 1 хвилина, максимум 49 днів).

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

висновок

Прочитавши дві стати повинно скластися загальне поняття про те як працює DNS, де і що зберігається. Для яких цілей. По хорошому, можна розкривати тему і далі, але тут я розповів основи. Більш глибше можна знайти на TechNet Microsoft.