В продолжение предыдущей статьи, рассказывающей об основах DNS, хочу рассказать об более тесном взаимодействии службы 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, который содержит значение для каждой ресурсной записи, связанной с именем объекта.

Имена компьютеров

Домены Active Directory имеют два типа имен. DNS и NetBIOS. Оба этих имени видны для конечных пользователей. Имена доменов обычно определяются DNS именем, но для обратной совместимости ( с Windows 2000) каждый домен содержит NetBIOS имя. NetBIOS это “короткое” имя. Содержит до 15 ASCII символов. Последний ,т.е. 16-й, зарезервирован как NetBIOS суффикс. NetBIOS суффикс описывает тип данной записи:

00	Workstation Service
03	Messenger Service
20	File Service (also called Host Record)
1B	Domain Master Browser — Primary Domain Controller for a domain
1C	Domain Controllers for a domain (group record with up to 25 IP addresses)
01	Master Browser
1E	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

Физическая структура информации Active Directory в DNS представлена DNS зонами и ресурсными записями, которые хранятся в Active Directory, как Active Directory интегрированные DNS зоны (Active Directory поддерживает хранение DNS зон в файлах). Кроме того, протокол динамических обновлений DNS используется Active Directory для автоматизации обновления ресурсных записей DNS, что бы автоматически поддерживать актуальность данных. Для работы Active Directory необходима поддержка SRV записей и динамических обновлений зоны. Active Directory использует DNS как механизм поиска необходимой информации, предоставляя компьютерам возможность поиска IP адреса контроллеров домена и другой необходимой информации.

Во время инсталляции контроллера домена SRV и A записи динамически регистрируются в DNS. Оба типа записей необходимы для механизма поиска контроллеров домена ( Domain controller locator ). После установки Active Directory необходимые записи можно найти на контроллере домена в :
%systemroot%\System32\Config\Netlogon.dns.

При поиске контроллеров домена в домене или лесу Active Directory, клиент запрашивает SRV и A ресурсные записи. Эти ресурсные записи предоставляют клиент DNS имена и IP адреса контроллеров домена. Когда контроллер домена добавляется в домен или в лес Active Directory, в DNS зоне добавляются необходимые записи для нового контроллера домена. Именно по этой причине, DNS сервер должен поддерживать динамические обновления. В противном случае, необходимо вручную вносить необходимые изменения в 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 записей по такой форме:

_Service ._ Protocol . DnsDomainName

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

_ldap._tcp. DnsDomainName

SRV записи, регистрируемые службой Net Logon

В следующей таблице, мы увидим какие SRV записи регистрируются службой Net Logon. А так же область применения записи и кто ее регистрирует.

• DnsDomainName DNS имя домена, в котором находится сервер
• DnsForestName DNS имя леса, т.е. DNS имя корневого домена леса.

Кто читал первую статью, для них следующие несколько таблиц уже известны.

_ldap._tcp. DnsDomainName .	Позволяет клиенту найти сервер с запущенным LDAP сервисом в домене DnsDomainName. К примеру: _ldap._tcp.inadmin.ru
_ldap._tcp. SiteName . _sites. DnsDomainName .	Позволяет клиенту найти сервер с запущенным LDAP сервисом в домене DnsDomainName в сайте SiteName. SiteName относительное имя, которое хранится в контейнере Configuration в Active Directory. К примеру: _ldap._tcp.Moscow._Sites.inadmin.ru
_ldap._tcp.dc._msdcs. DnsDomainName .	Позволяет клиенту найти контроллер домена в домене DnsDomainName. Все DС регистрируют данную SRV запись.
_ldap._tcp. SiteName . _sites.dc._msdcs. DnsDomainName .	Позволяет клиенту найти контроллер домена в домене DnsDomainName в сайте SiteName. Все DС регистрируют данную SRV запись.
_ldap._tcp.pdc._msdcs. DnsDomainName .	Позволяет клиенту найти PDC в домене DnsDomainName.Только PDC сервер регистрирует данную SRV запись.
_ldap._tcp.gc._msdcs. DnsForestName .	Позволяет клиенту найти PDC в лесу DnsForestName.Только GC сервера регистрируют данную SRV запись.
_ldap._tcp. SiteName . _sites.gc._msdcs. DnsForestName .	Позволяет клиенту найти GC в лесу DnsForestName.Только GC сервера принадлежащие данному лесу регистрируют данную SRV запись. К примеру: _ldap._tcp.Moscow._Sites._gc._msdcs.inadmin.ru
_gc._tcp.DnsForestName.	Позволяет клиенту найти GC в данном домене. Только GC сервера принадлежащие данному лесу DnsForestName регистрируют данную SRV запись. К примеру: _gc._tcp.inadmin.ru
_gc._tcp.SiteName. _sites.DnsForestName.	Позволяет клиенту найти 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._tcp. DnsDomainName .	Позволяет клиентам найти Kerberos KDC в данном домене DnsDomainName. Все DC регистрируют данную SRV запись.
_kerberos._udp. DnsDomainName .	Тоже самое, что и _kerberos._tcp. DnsDomainName только через UDP
_kerberos._tcp. SiteName . _sites. DnsDomainName .	Позволяет клиентам найти Kerberos KDC в данном домене DnsDomainName в сайте SiteName. Все DC регистрируют данную SRV запись.
_kerberos._tcp.dc._msdcs. DnsDomainName .	Позволяет клиентам найти DC на котором запущена роль Kerberos KDC в данном домене DnsDomainName. Все DC с ролью KDC регистрируют данную SRV запись.
_kerberos.tcp. SiteName . _sites.dc._msdcs. DnsDomainName .	Позволяет клиентам найти DC на котором запущена роль Kerberos KDC в данном домене DnsDomainName в сайте SiteName. Все DC с ролью KDC регистрируют данную SRV запись.
_kpasswd._tcp.DnsDomainName.	Позволяет найти Kerberos Password Change для текущего домена. Все DC c ролью kerberos KDC регистрирую данную SRV запись
_kpasswd._udp.DnsDomainName.	Тоже самое, что и _kpassword._tcp. DnsDomainName только через UDP

Так же служба Net logon регистрирует CNAME ресурсную запись для репликации Active Directory.

DsaGuid._msdcs.DnsForestName.

DC Locator не использует данную запись. Фактически эта запись помогает при переименовании контроллера домена.

Так же регистрируется A запись, содержащая DNS имя контроллера домена и его IP адрес. Это необходимо для того, что бы SRV записи могли ссылаться на эту A запись для разрешения имени в IP адрес.

Так же у SRV записей есть дополнительные поля:

Priority	Приоритет сервера. Клиенты пытаются подключиться к серверам с меньшим приоритетом.
Weight	Используется в роли Load-balanced для серверов с одинаковым приоритетом. Клиенты рандомно выбирают сервер с вероятностью, пропорциональной весу.
Port Number	Порт, на котором сервер "слушает"
Target	FQDN сервера

Host записи для Non-SRV клиентов.

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

DnsDomainName.	Позволяет Non-SRV клиентам найти контроллер домена в домене, путем просмотра A-записи. Non-SRV клиенты смотрят данное имя; SRV поддерживающие клиенты ищут соответствующую SRV запись
gc._msdcs.DnsForestName.	Позволяет Non-SRV клиентам найти глобальный каталог в лесу, путем просмотра A-записи. Non-SRV клиенты смотрят данное имя; SRV поддерживающие клиенты ищут соответствующую SRV запись

Пример регистрации имен

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

DC001.inadmin.ru   A   192.168.0.3
_ldap._tcp.inadmin.ru    SRV  0 0 389 DC001.inadmin.ru
_kerberos._tcp.inadmin.ru   SRV  0 0 88 DC001.inadmin.ru
_ldap._tcp.dc._msdcs.inadmin.ru  SRV  0 0 389 DC001.inadmin.ru
_kerberos._tcp.dc._msdcs.inadmin.ru  SRV  0 0 88 DC001.inadmin.ru

Когда клиенты запрашивают к примеру _kerberos._tcp.dc._msdcs.inadmin.ru, то ему возвращается целая пачка имен и IP адресов,состоящая из контроллеров домена, которые предоставляют kerberos аутентификацию.

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

• DNS имя сервера, регистрируется на DNS сервере (DC001.inadmin.ru )
• NetBIOS имя, регистрируется на WINS сервере (если он есть) (DC001)

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

• Если имя домена, в который входит клиент, DNS имя, то компьютер должен запросить DNS для поиска контроллера домена
• Если имя домена, в который входит клиент, NetBIOS имя, то компьютер должен запросить WINS (возможно использование broadcast сообщения для поиска NetBIOS имени) для поиска контроллера домена

После этого клиент кэширует данную запись. И хранит ее у себя, что бы больше не генерировать лишний трафик и нагрузку на сервера.

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

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

1. Domain Partition. Часть раздела Active Directory, присутствующая на каждом DC в лесу. DNS зоны реплицируются на все DC в домене. Используется только для DC под управлением Windows 2000
2. Forest-wide DNS Application directory partition. Хранится в разделе приложений Active Directory. DNS зоны, хранящиеся в данном разделе, реплицируются на все DC в лесу. Этот раздел создается автоматически, когда устанавливается роль DNS сервера на первом DC в лесу под управлением Windows 2003 и выше.
3. Domain-wide DNS Application directory partition. Раздел DNS для каждого отдельного домена в лесу. Хранится в разделе приложений Active Directory и реплицируется на все DC в текущем домене. Автоматически создается при установки роли DNS сервера в домене под управлением Windows 2003 и выше. Для каждого нового домена в лесу создается новая зона и область доступности, ограниченная текущим доменом.
4. Custom DNS Application directory partition. Используется для репликации между зарание определенными DC. Хранится в разделе приложений Active Directory. Доступна во всем лесу Active Directory, на заранее определенных DC.

Примечание: Если лес Active Directory создавался в Windows 2000, то _msdcs.DnsDomainName был частью поддомена DnsDomainName. Если же лес Active Directory создавался в версиях начиная с Windows 2003, то _msdcs.DnsDomainName создавалась как новая DNS зона (рядом с DnsDomainName ) и помещалась в forest-wide DNS application directory partition.

Примечание: DNS зоны хранящиеся в application directory partitions не видны для контроллеров домена под управлением Windows 2000.

Делегирование

Более подробно я эту тему раскрывал в первой части статьи. Сейчас же хочу упомянуть лишь о том, что пространство имен во всем лесу должно быть уникальным. Разрешение имен должно проходить без проблем для всего леса. Делегирование помогает поддерживать актуальность ресурсных записей, а так же распределять административные задачи в каждом домене.

В обычной ситуации делегируют дочерние пространство 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, в котором хранится информация о сайтах и серверах, находящихся в этих сайтах. Когда происходит поиск контроллера домена, то прежде всего идет поиск в своем сайте, и только потом в других сайтах ( например, если контроллеры домена не доступны в своем сайте, или их там вообще нету).

Клиентские компьютеры хранят информацию о том в каком сайте они последний раз находились. Но компьютер не обязательно статичен. Если у нас ноутбук и мы часто с ним ездим, и включаемся в сеть в разных сайтах, то что же делать ? Для этого есть свой алгоритм действия. Допустим компьютер был перемещен в другой сайт. Он может соединиться с контроллером домена в его домашнем сайте. Но сейчас он находится не в этом сайте. В этом случае контроллер домена видит, что сейчас компьютер находится в другом сайте и извещает его о текущем местоположении. После этого клиент вносит изменения в свой реестр. Делается это на основе IP адреса компьютера.

Вы наверное знаете, что каждому сайту можно привязать свою подсеть? Вот именно для этой цели это и необходимо делать.

Контроллеры домена хранят в себе всю топологию леса в контейнере Configuration. На основе этого и IP адреса делается вывод где сейчас находится компьютер и какой ближайший сайт с контроллерами домена к клиенту.

Примечание: Когда у компьютер не знает свой последний сайт (из реестра), то он будет обращаться к любому контроллеру домена. Есть вариант настроить 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 регистрирует так же изменения произошедшие в сайте.

Алгоритм работы:

1. Служба Net Logon смотрит на IP адрес клиента, и т.к. хранит всю информацию о сайтах и их структурах, то определяет (на основе IP адреса) откуда клиент. Возвращает ему необходимую информацию.
   • Имя сайта в котором клиент расположен или имя ближайшего для него сайта
   • Имя сайта в котором расположен контроллер домена
   • "bit", который указывает,находится ли контроллер домена (бит установлен) или не находится (бит не установлен) в том же сайте, что и клиент.
2. Клиент смотрит возвращаемые данные для определения лучшего контроллера домена.
   • Если возвращаемый контроллер домена находится в том же сайте ("Bit" установлен), клиент использует этот контроллер домена
   • Если клиент пытался до этого найти контроллер домена в этом же сайте. клиент использует этот контроллер домена.
   • Если контроллер домена находится не в ближайшем для него сайте, то клиент обновляет информацию у себя. Отправляет DNS запрос для поиска нового контроллера домена в сайте. Если запрос удался , то используется новый контроллер домена, иначе используется старый.
   • Если домен, в котором происходит текущий запрос, такой же как и домен к которому подключен компьютер. Сайт, в котором находится компьютер, сохраняется в реестре.

     HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ Netlogon\Parameters

     в ключе 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.

Баканов Денис

MCSE+S; MCITP EA

Оригинал статьи

Popularity: 1% [?]