Active Directory - от теории к практике. Часть 1 - общие вопросы.

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

Онлайн-курс по устройству компьютерных сетей
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

Перед тем как создавать ваш первый контроллер домена необходимо определиться с режимом его работы. Режим работы определяет доступные возможности и зависит от версии применяемой операционной системы. Мы не будем рассматривать все возможные режимы, кроме тех которые имеют актуальность на текущий момент. Таких режимов три: Windows Server 2003, 2008 и 2008 R2.

Режим Windows Server 2003 следует выбирать только тогда, когда в вашей инфраструктуре уже развернуты сервера на данной ОС и планируется использовать один или несколько таких серверов в качестве контроллеров домена. В остальных случаях нужно выбирать режим Windows Server 2008 или 2008 R2 в зависимости от купленных лицензий. Следует помнить, что режим работы домена можно всегда повысить, а вот понизить уже не удастся (разве что восстановив из резервной копии), поэтому подходите к данному вопросу осмотрительно, с учетом возможных расширений, лицензий в филиалах и т.д. и т.п.

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

Поэтому сразу же после создания первого контроллера домена нужно развернуть второй, вне зависимости от размеров сети и бюджета. Второй контроллер должен быть предусмотрен еще на стадии планирования и без него за развертывание AD даже не стоит браться. Также не стоит совмещать роль контроллера домена с любыми иными серверными ролями, в целях обеспечения надежности операций с базой AD на диске отключается кэширование записи, что приводит к резкому падению производительности дисковой подсистемы (это объясняет и долгую загрузку контроллеров домена).

В итоге наша сеть должна принять следующий вид:

Вопреки распространенному мнению, все контроллеры в домене равнозначны, т.е. каждый контроллер содержит полную информацию о всех объектах домена и может обслужить клиентский запрос. Но это не значит, что контроллеры взаимозаменяемы, непонимание этого момента зачастую приводит к отказам AD и простою сети предприятия. Почему так происходит? Самое время вспомнить про роли FSMO.

Когда мы создаем первый контроллер, то он содержит все доступные роли, а также является глобальным каталогом, с появлением второго контроллера ему передаются роли хозяина инфраструктуры, хозяина RID и эмулятора PDC. Что будет если администратор решил временно вывести из строя сервер DC1, например чтобы почистить от пыли? На первый взгляд ничего страшного, ну перейдет домен в режим "только чтение", но работать то будет. Но мы забыли про глобальный каталог и если в вашей сети развернуты приложения требующие его наличия, например Exchange, то вы узнаете об этом раньше, чем снимете крышку с сервера. Узнаете от недовольных пользователей, да и руководство вряд ли придет в восторг.

Из чего следует вывод: в лесу должно быть не менее двух глобальных каталогов, а лучше всего по одному в каждом домене. Так как у нас домен в лесу один, то оба сервера должны быть глобальными каталогами, это позволит вам без особых проблем вывести любой из серверов на профилактику, временное отсутствие каких либо ролей FSMO не приводит к отказу AD, а лишь делает невозможным создание новых объектов.

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

Проходит время, ваша организация растет и у нее появляется филиал в другом конце города и возникает необходимость включить их сеть в общую инфраструктуру предприятия. На первый взгляд ничего сложного, вы настраиваете канал связи между офисами и размещаете в нем дополнительный контроллер. Все бы хорошо, но есть одно но. Данный сервер вы контролировать не можете, а следовательно не исключен несанкционированный доступ к нему, да и местный админ вызывает у вас сомнения в его квалификации. Как быть в такой ситуации? Для этих целей специально существует особый тип контроллера: контроллер домена доступный только на чтение (RODC), данная функция доступна в режимах работы домена начиная с Windows Server 2008 и выше.

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

Настраиваем в филиале RODC, все работает, вы спокойны, но пользователи начинают жаловаться на долгий вход в систему и счета за трафик в конце месяца показывают превышение. Что происходит? Самое время еще раз вспомнить про равнозначность контроллеров в домене, клиент может направить свой запрос к любому контроллеру домена, даже находящемуся в другом филиале. Примите во внимание медленный и, с большой вероятностью, загруженный канал связи - вот и причина задержек входа.

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

Здесь мы вплотную подошли к понятию сайтов AD, которые не следует путать с интернет сайтами. Сайты Active Directory представляют способ физического деления структуры службы каталогов на области отделенные от других областей медленными и/или нестабильными каналами связи. Сайты создаются на основе подсетей и все клиентские запросы отправляются в первую очередь контроллерам своего сайта, также крайне желательно иметь в каждом сайте свой глобальный каталог. В нашем случае потребуется создать два сайта: AD Site 1 для центрального офиса и AD Site 2 для филиала, точнее один, так как по умолчанию структура AD уже содержит сайт, куда входят все ранее созданные объекты. Теперь рассмотрим как происходит репликация в сети с несколькими сайтами.

Будем считать, что наша организация немного подросла и главный офис содержит целых четыре контроллера домена, репликация между контроллерами одного сайта называется внутрисайтовой и происходит моментально. Топология репликации строится по схеме кольца с условием, чтобы между любыми контроллерами домена было не более трех шагов репликации. Схема кольца сохраняется до 7 контроллеров включительно, каждый контроллер устанавливает связь с двумя ближайшими соседями, при большем числе контроллеров появляются дополнительные связи и общее кольцо как бы превращается в группу наложенных друг на друга колец.

Межсайтовая репликация происходит иначе, в каждом домене автоматически выбирается один из серверов (сервер-плацдарм) который устанавливает связь с аналогичным сервером другого сайта. Репликация по умолчанию происходит раз в 3 часа (180 минут), однако мы можем установить собственное расписание репликации и для экономии трафика все данные передаются в сжатом виде. При наличии в сайте только RODC репликация происходит однонаправленно.

Безусловно, затронутые нами темы весьма глубоки и в данном материале мы только слегка их коснулись, однако это тот необходимый минимум знаний, который нужно иметь перед практическим внедрением Active Directiry в инфраструктуру предприятия. Это позволит избежать глупых ошибок при развертывании и авральных ситуаций при обслуживании и расширении структуры, а каждая из поднятых тем еще будет обсуждаться более подробно.