Active Directory — трудности перевода. Часть 2

Из первой части, мы четко уяснили, что для нормальной работы вашей доменной сети контроллер домена должен быть доступен, при этом иметь созданные учетные записи для ваших пользователей и компьютеров. А клиенты с свою очередь обязаны при входе в сеть обратиться к этому контроллеру. Теперь необходимо понять как клиент узнает IP-адрес контроллера что бы передать ему данные, введенные пользователем. Ведь ни имя, ни тем более IP-адрес контроллера не задается на клиентах.

Ответ скрывается в базовом правиле Active Directory, говорящем о том что Active Directory не функционирует без системы разрешения имен DNS. Когда вы только настраиваете первый контроллер, служба DNS в вашей сети уже должна быть поднята. Если вдруг мастер установки Active Directory не обнаружит работающей службы DNS, она будет установлена на этот  же сервер вместе со службой AD и должным образом сконфигурирована. В  DNS будет автоматически создана зона (точнее две но пока это не важно) с именем вашего домена и в этой зоне появятся записи специального типа SRV, которые будут указывать на ваш контроллер. Следовательно клиент который работает в этом домене должен быть настроен на использование этого dns-сервера в качестве предпочитаемого. И  перед обращением к контроллеру домена, клиент осуществит запрос к DNS-серверу с просьбой сообщить ему SRV-запись для домена в котором он работает. Таким образом он в результате получит IP-адрес нужного контроллера и сможет переслать данные.

Важно: На практике все контроллеры домена по совместительству несут на себе службу DNS. И причин разделять на разных серверах  DNS и контроллеры домена внутри вашей сети нет. (единственный случай где имеет смысл разделение это вынос DNS сервера за пределы вашей сети в демилитаризованную зону)

Рис.1 Схема порядка входа клиента в сеть. Вначале обращение к DNS. В дальнейшем получив от DNS  IP-адрес контроллера, обращение к контроллеру. В жизни это как правило один сервер. (DC+DNS)

Получается, что в вашей сети будет установлен Контроллер домена (со службой DNS на борту) и работа всей сети зависит от него. Как быть в ситуации, если по причине “метеоритного дождя” сервер вышел из строя? Как перестраховаться и обеспечить отказоустойчивость?

Все просто. Необходимо установить еще один контроллер в рамках уже созданного домена Active Directory. Поднимая второй контроллер, вы создаете брата близнеца, который также как и первый будет хранить заветный файл ntds.dit  и также как и первый контроллер отвечать на запросы клиентов. Вашим клиентам будет абсолютно все равно какой из контроллеров их обслужил. Второй контроллер как и первый должен  иметь службу DNS иначе толку от него в случае падения первого будет очень мало. (я думаю понятно почему – AD не работает без DNS, а если мы имеем два контроллера и только на одном служба DNS, то что будет делать второй если первого не станет).

Когда вы создаете пользователя в Active Directory, он создается в базе (ntds.dit) того контроллера, к которому в данный момент подключена оснастка.  А если контроллеров несколько  возникает ситуация в которой один контроллер знает об изменениях, а второй еще нет. Естественно такое безобразие долго длиться не должно и данные изменения обязаны быть доставлены на остающийся “незнающим” контроллер. Процесс синхронизации баз контроллеров в домене называется репликацией, которая происходит в фоном режиме без оповещения системного администратора.

С выходом Windows Server 2008 появилась новая технология “Read Only Domain Controller” или контроллер домена только для чтения.  Особенность данного контроллера в том, что он работает только на чтение, т.е может обсуживать ваших клиентов, но записать в его базу AD вам ничего не удастся. Репликация в таком случае идет в одну сторону с полноценного контроллера на контроллер домена только для чтения. Используется он в ситуациях когда необходимо установить сервер в месте не обеспечивающего физическую безопасность.

И так два контроллера будут прекрасно сосуществовать в рамках вашей сети и все будет здорово до одного момента. Когда к вам придет шэф и скажет: “Понимаешь %SysadminName%, мы слегка подросли и покупаем/арендуем новый офис в другом конце города. Часть компьютеров и самое главное Марью Ивановну из бухгалтерии мы перевозим в новое здание.” Ничего сложного отвечаете вы, достаете из тумбочки запылившиеся Cisco, в течении следующей недели неспешно настраиваете VPN-туннель между офисами  и перевозите на новый участок часть компьютеров, Марью Ивановну и конечно же один из контроллеров домена. В результате получаете следующую схему сети.

Рис.2 Схема сети нашей фирмы.  

А получаете вы сеть разделенную на два сегмента, каждый сегмент находится в своей подсети, трафик между подсетями маршрутизируется и передается в зашифрованном виде по VPN-туннелю. И все замечательно домен Active Directory продолжает работать, но вы начинаете замечать, что вход пользователя на компьютер стал занимать несколько  больше времени, а судя по детализации провайдера у вас появился лишний расход трафика. Ничего таинственного в этом нет. Те кто внимательно читали первую часть не могли пропустить строчку “Клиенту неважно какой контроллер домена его обслуживает”. Получается что ваши клиенты аутентифицируются на том контроллере, чью запись SRV вернул первой DNS сервер и далеко не всегда будет тот контроллер домена, который находится ближе. Таким образом трафик между клиентом и контроллером будет проходить VPN-туннель основанный на медленном WAN канале вызывая задержки при входе в сеть и лишний трафик.

Для того, чтобы все было по-взрослому необходимо сконфигурировать сайты  Active Directory. Сайт AD не имеет ничего общего с www.ya.ru и.т.д. Это логическое объединение  клиентов и контроллеров связанных высокоскоростным соединением.  Ваша сеть состоит из двух участков в каждой скорость не меньше ста мегабит, а вот эти участки связанны каналом в два мегабита или того меньше. Получается что у вас будет два сайта (каждый филиал это сайт). И сконфигурировав сайты Active Directory вы добьетесь того, что клиенты всегда в первую очередь буду обращаться к тому контроллеру который находится с ними в одном сайте и если уж он не доступен, то запрос будет послан на другой контроллер. Когда вы устанавливали первый контроллер домена сайт с именем “default first site name” был создан автоматически и если вы ручками не меняли настройки, Active Directory считает, что все дополнительные контроллеры и все клиенты работают в одном сайте.

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

Предвидя вопросы  “Как клиент понимает, что он принадлежит к тому или иному сайту” отвечу, что конфигурируя сайт, вы явно задаете подсети которые входят в него. Т.е если вы создали сайт “Rostov-on-Don” и закрепили за ним подсеть “192.168.5.0/24”, все клиенты имеющие IP-адрес в данной подсети будут считать себя члена данного сайта.

И в окончании второй части раскрою “секретную команду”, позволяющую посмотреть, какой контроллер аутентифицировал вашего клиента. Эта команда SET.

Рис. 3 Результат вывода команды SET.

Введя SET в командной строке, вы получите множество информации, но интересовать вас должен параметр “LOGONSERVER”. При входе в домен “LOGONSERVER” будет указывать на аутентифицировавший вас контроллер домена, а при локальном входе  вместо имени контроллера домена  естественно будет стоять имя вашего клиентского компьютера.

Автор статьи:Илья Рудь