Установка контроллера домена

Таблица контрольных проверок помогает избежать проблем при установке AD

Установка Active Directory (AD) напоминает игру в шахматы. Необходимо продумывать свои действия на несколько ходов вперед, но при этом помнить о стратегии игры — о том, что нельзя терять короля, без которого пешки уже не нужны. Администратор должен настраивать домены, организационные единицы (OU), группы, учетные записи пользователей, но при этом не забывать о фундаментальных принципах ИТ: при внесении изменений важно убедиться, что система продолжает нормально работать. После перевода сервера Windows 2000 на роль контроллера домена (DC) целесообразно заполнить таблицу контрольных проверок, которые покажут, что перевод прошел успешно, выполнить несколько простых, но важных изменений в настройках и убедиться, что DC работает именно так как нужно. А теперь посмотрим на задачи в таблице контрольных проверок, которые предстоит выполнить после того, как домен AD будет сконфигурирован.

Проверка всех журналов событий

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

Проверка записей SRV в DNS

AD не может работать без DNS. Необходимо установить службу DNS и активизировать операции динамического обновления еще до того, как речь пойдет об установке AD. В AD записи SRV используются очень часто. Эти записи — относительно новый тип записей DNS, они идентифицируют серверы в сети, на которых запущены специфические службы. Microsoft использует SRV-записи для локализации служб, имеющих отношение к AD, таких, как серверы Lightweight Directory Access Protocol (LDAP).

Когда выполняется установка самого первого контроллера домена AD, служба Netlogon создает несколько записей SRV и специальные доменные узлы, которые содержат эти записи, — но только в том случае, если DNS-сервер квалифицируется как динамический DNS (DDNS). Windows 2000 DNS поддерживает DDNS, тогда как Windows NT 4.0 DNS не поддерживает. Однако нужно иметь в виду, что по умолчанию в Windows 2000 DNS функциональность DDNS не активизирована. Без DDNS администратор домена вынужден создавать все узлы AD и записи самостоятельно, а это не самая простая работа.

Убедиться, что служба Netlogon сгенерировала узлы и записи SRV, можно с помощью административной консоли DNS после того, как сервер впервые загрузится как DC. Под именем домена AD должны быть видны четыре новых дочерних узла: _msdcs, _sites, _tcp, и _udp, как показано на Экране 1. Если сервер к тому же является сервером глобального каталога (Global Catalog, GC), будет виден и узел _gc. Важно обратить внимание на записи SRV внутри этих узлов. Если, к примеру, выбрать узел _tcp, будут видны по крайней мере три записи SRV для каждого сервера: две для Kerberos (_kerberos и _kpasswd) и одна для LDAP (_ldap).

Экран 1. Дочерние объекты для вновь созданного домена.

Если видны четыре узла (или пять) и в них присутствуют записи SRV, можно продолжать анализ созданных узлов. Если нет — следует подождать несколько минут (службе Netlogon может потребоваться некоторое время для регистрации узлов), затем обновить экран DNS. Если записи SRV по-прежнему не видны, необходимо убедиться, что функциональность DDNS активизирована. Для этого нужно выбрать первичную зону DNS в домене AD. Требуется открыть контекстное меню этой зоны, выбрать Properties, перейти на вкладку General и убедиться, что флаг Allow dynamic updates установлен в Yes (см. Экран 2). Если это не так, следует установить значение Yes и перезапустить службу Netlogon на контроллере домена для принудительной регистрации записей SRV.

Экран 2. Проверка наличия динамического обновления DDNS.

Проверка каталогов Ntds и Sysvol

В процессе установки AD внутри корневого каталога системы (обычно — C:winnt) создаются два подкаталога, Ntds и Sysvol. Когда процесс установки AD закончится, нужно открыть Windows Explorer и убедиться, что каталоги созданы.

В подкаталоге Ntds расположена база данных AD, Ntds.dit, а также вспомогательные файлы, например журналы транзакций. Подкаталог Sysvol — это системный том общего доступа, и в нем содержатся объекты, совместно используемые всеми контроллерами домена, например файлы сценариев для групповых политик. Новая служба File Replication Service (FRS) — усовершенствованная NT 4.0 Directory Replication — автоматически реплицирует содержимое данного каталога на все остальные контроллеры в том же домене.

Проверка учетной записи компьютера

Как и при работе с NT 4.0, для всех станций Windows 2000, включая и контроллеры домена, нужны учетные записи компьютеров, чтобы функционировать в составе домена. Если открыть оснастку Active Directory Users and Computers и выбрать Domain Controllers OU, можно увидеть объект Computer Account для DC, который был только что установлен. Процедура установки AD создает эту учетную запись для самого первого DC домена. Если запустить в существующем домене процедуру Promote для рядового сервера домена, Dcpromo переместит учетную запись компьютера в названный OU.

Если учетная запись компьютера отсутствует, значит, что-то во время установки AD выполняется не так как надо. То же относится и к ситуации, когда подкаталоги Ntds и Sysvol не видны. Такие проблемы возникают довольно редко, но, если все же это случилось, необходимо удалить AD с DC, после чего запустить процедуру установки AD заново.

Защита учетной записи Administrator

Всякий раз при создании нового домена желательно переименовать учетную запись администратора домена и назначить для нее сложный пароль. Этому основополагающему шагу в обеспечении безопасности часто почему-то не придают должного значения.

Как известно, все домены Windows 2000 и NT 4.0 по умолчанию имеют учетную запись Administrator. Не стоит облегчать жизнь потенциальным хакерам — эту запись следует переименовать. Только не надо присваивать ей имя своего любимого музыканта, лучше использовать что-нибудь нейтральное, например Sue Johnson, чтобы проще было спрятать административную запись среди других пользовательских имен.

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

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

Принадлежность к сайту

Необходимо установить принадлежность DC определенному сайту и убедиться, что реплицирование данных и трафик регистрации не перегружают медленные каналы. Хотя рядовые серверы Windows 2000 и станции Windows 2000 Professional, входящие в состав домена, автоматически попадают в нужный сайт в соответствии с заданными IP-адресами, принадлежность DC — процесс статический и обычно нуждается в административных настройках. Но если сайты и связанные с ними подсети уже организованы и если можно установить IP-адрес DC до момента запуска утилиты dcpromo.exe, контроллер домена войдет в состав сайта автоматически.

Если планируется установить новый сайт или изменить настройки существующего сайта после установки контроллеров домена, принадлежность тому или иному сайту придется настраивать вручную. Для этого используется оснастка Active Directory Sites and Services консоли MMC. Настройка вручную потребуется и в том случае, когда DC настраивается на адрес IP, который не попадает в установленную подсеть — например, если настраивается сервер, предназначенный для филиала компании. И, наконец, необходимо изменить установленную принадлежность сайту для самого первого DC корневого леса, поскольку на момент установки AD никаких сайтов еще нет. Важное замечание: перед тем как изменить принадлежность DC, нужно убедиться, что IP-адрес DC относится к одной из подсетей конструируемого сайта.

Создание дополнительных серверов GC

Если в лесу имеется более одного домена AD, стоит назначить некоторые контроллеры доменов на роль серверов глобального каталога — GC-серверов. Сервер GC содержит некоторое подмножество данных со всех доменов леса, тогда как обычный DC включает данные только своего домена. Вот почему в однодоменной среде дополнительный GC-сервер не нужен, так как каждый DC имеет полную информацию обо всех объектах леса.

Во время процедуры регистрации пользователя сервер GC имеет информацию о членстве пользователя в универсальной группе. Кроме того, контроллеры домена запрашивают GC при поиске основных имен пользователей — User Principal Name (UPN) — в других доменах. Предположим, например, что пользователь, чье имя UPN — beth.jones@acme.com, регистрируется на станции, входящей в состав дочернего домена northeast.acme.com. Контроллер домена northeast.acme.com обращается к GC для выяснения, в каком домене находится учетная запись Beth.

По умолчанию существует только один сервер GC — это самый первый созданный DC в корневом домене, но при необходимости всегда можно организовать дополнительные GC. В идеале для каждого сайта Windows 2000 нужно иметь один GC для разгрузки каналов глобальной сети. При установке сервера Microsoft Exchange 2000 Server желательно организовать сервер GC в каждой подсети, где присутствует сервер Exchange, поскольку последний использует глобальный каталог еще более интенсивно, чем DC.

Чтобы сделать из обычного контроллера домена сервер глобального каталога, следует воспользоваться оснасткой Active Directory Sites and Services. Необходимо раскрыть контейнер Sites, затем выбрать сайт, в котором предстоит организовать сервер GC. Нужно открыть контейнер Servers и выбрать тот сервер, который планируется выдвинуть на роль GC-сервера. Снизу от сервера виден объект Ntds Settings. Открыв контекстное меню этого объекта, следует выбрать Properties и установить флажок Global Catalog (см. Экран 3). Важно иметь в виду, что это изменение породит дополнительный репликационный трафик от каждого сервера сайта к созданному GC-серверу. Возможно, потребуется пересмотреть настройку сайта и план репликации и учесть рост сетевого трафика в реальных условиях работы.

Экран 3. Указание контроллера в качестве GC.

Настройка мастеров ролей

В AD используется модель организации доменов с несколькими главными доменами. Из этого следует, что вносить изменения в каталог можно с любого контроллера домена, в то время как в сети NT 4.0 изменения можно было внести только на PDC. Вместе с тем, некоторые изменения, например создание нового дочернего домена, необходимо выполнять только на одном сервере — во избежание конфликтов. По этой причине самый первый созданный в домене DC выполняет сразу три специфические роли, именуемые ролями Flexible Single-Master Operation (FSMO): PDC Emulator, Relative ID Master и Infrastructure Master. Первый DC в корневом домене леса выполняет дополнительно еще две FSMO-роли: Schema Master и Domain Naming Master. Во врезке «Мастера домена» рассматриваются соответствующие функции ролей FSMO.

Когда в домене число контроллеров становится больше одного, при назначении сервера на роль PDC Emulator следует исходить из требований балансировки нагрузки и отказоустойчивости. Роли FSMO в случае выхода из строя операционных мастеров автоматически не переназначаются. Для изменения ролей приходится использовать различные программные инструменты. Active Directory Users and Computers применяется для переназначения другим контроллерам трех специфичных для домена ролей — PDC Emulator, Relative ID Master и Infrastructure Master. Для этого нужно открыть контекстное меню домена, выбрать Operations Masters, в открывшемся окне выбрать вкладку RID (см. Экран 4) и передать соответствующую роль другому DC домена.

Экран 4. Передача роли другому контроллеру домена.

В каждом лесу имеется только один Domain Naming Master. Для переназначения этой роли используется Active Directory Domains and Trusts. Следует открыть контекстное меню Active Directory Domains and Trusts и выбрать Operations Master.

В каждом лесу имеется только один сервер в роли Schema Master. Для переназначения этой роли сначала необходимо сделать доступной оснастку Active Directory Schema в MMC, для чего требуется зарегистрировать соответствующую DLL. Нужно открыть окно командной строки и набрать:

regsrvr32 schmmgmt.dll

Затем следует добавить Active Directory Schema в консоль MMC, открыть контекстное меню Active Directory Schema и выбрать Operations Master для переназначения роли Schema Master на другой DC.

Если один из операционных мастеров выходит из строя, с помощью ntdsutil.exe можно перехватить роль отказавшего сервера. Но если после этого включить оригинальную программу-мастер, могут возникнуть проблемы. За исключением, возможно, PDC emulator, выход из строя операционного мастера пользователями замечен не будет, и администраторы должны использовать ролевые функции, только когда это действительно необходимо. Если можно обойтись без операционного мастера, пока его восстанавливают, — например, если можно отказаться от создания новых доменов, пока вышедший из строя Domain Naming Master не будет восстановлен, — рекомендую так и поступить.

Настройка службы времени

Требуется выполнить настройку контроллеров домена таким образом, чтобы время на них было взаимно синхронизировано. Программа установки AD данной проблемой не занимается, но это первоочередная задача после установки AD. Очень удобно, что настройка временной синхронизации выполняется один раз сразу для всего леса AD. Если Time Service не настроить, то, вероятнее всего, в течение недели ни один из пользователей сети зарегистрироваться не сможет.

Вопрос времени очень важен, если вспомнить о протоколе Kerberos, который используется в AD для аутентификации. Kerberos не выдает мандат (credential), если время на сервере Key Distribution Center (KDC, центр распространения ключей) и на клиенте, пославшем запрос, различается больше чем на 5 мин (все контроллеры домена AD являются KDC). Более того, если время на двух DC идет по-разному, реплицирование данных между этими серверами будет выполняться с ошибками. Поскольку внутренние часы на большинстве компьютеров могут быть выставлены по-разному, расхождение во времени — обычное дело. Если компания разбросана по странам и континентам, беспокоиться не нужно, Kerberos «знает» о временных зонах и учитывает этот фактор.

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

Чтобы установить внешний источник времени, необходимо открыть окно командной строки на контроллере, исполняющем роль PDC Emulator, и набрать

net time /setsntp:

Internet-провайдер должен предоставить имя или IP-адрес соответствующего сервера NTP (Network Time Protocol) либо сервера SNTP (Simple Network Time Protocol).

В крайнем случае можно воспользоваться синхронизирующими серверами военно-морского флота США — tick.usno.navy.mil или tock.

usno.navy.mil, но лучше, конечно, задействовать самый близкий в географическом отношении сервер.

После того как внешний источник времени определен, все остальные контроллеры домена будут автоматически синхронизовать свои часы с часами на PDC Emulator, и одно и то же время будет каскадом распространяться по всему лесу. Серверы — члены домена и станции Windows 2000 Professional — синхронизируют время с DC своего домена, PDC Emulator в дочерних доменах — с PDC Emulator родительского домена, рядовые контроллеры домена — с часами доменного PDC Emulator, и так по всей иерархии доменов, пока во всем лесу время на станциях Windows 2000 не станет синхронизованным.

Как мы видим, AD — большой и сложный проект. Администраторам предстоит приложить немало усилий для того, чтобы учетные записи пользователей не перестали работать. Последнее, о чем я хотел бы предупредить читателей и к чему надо быть готовым, — вновь образованный DC может очень сильно замедлить или даже остановить развертывание AD. Выполняя несложные контрольные проверки, нужно каждый раз убеждаться, что контроллеры домена сконфигурированы должным образом начиная с самого первого дня. Тем самым число конфликтов в работе AD значительно снизится — как на начальном этапе формирования AD, так и в процессе эксплуатации.

Мастера домена

Роли FSMO предназначены для предотвращения конфликтов в AD.

Мастера леса

• Schema Master - все изменения, затрагивающие схему AD, проводятся только на сервере, выполняющем роль мастера схемы Schema Master. Схема описывает план базы данных AD, объекты (пользователей, группы и т. д.) и их атрибуты (номера телефонов, членство в группах и т. д.). Поскольку одна схема распространяется на весь лес, мастер Schema Master гарантирует, что два администратора своими несогласованными действиями не спровоцируют конфликт внутри AD.
• Domain Naming Master - требуется создать или удалить домен? Тогда все действия проводятся только с сервера - мастера именования домена, во избежание конфликтов имен.

Мастера домена

• Infrastructure Master - задача контроллера домена, мастера инфраструктуры, в этой роли заключается поддержание непротиворечивой инфраструктуры AD, в частности непротиворечивости групп и членства пользователей в этих группах. Например, если некая учетная запись пользователя переименована, Infrastructure Master гарантирует, что в любой группе, содержащей учетную запись этого пользователя, внесенные изменения будут отражены. Сервер в роли Infrastructure Master не должен быть сервером GC, но, по умолчанию, для корневого домена это именно так. Необходимо изменить ситуацию сразу же, как только в корневом домене леса будет установлен второй DC, перенеся роль Infrastructure Master на другой сервер.
• Relative ID Master - в каждом домене сервер в роли мастера относительных идентификаторов Relative ID Master генерирует уникальные числовые идентификаторы; эти числовые значения раздаются контроллерам домена для присвоения их объектам домена. Относительный идентификатор в комбинации с идентификатором домена, Domain SID, составляет глобальный уникальный идентификатор объекта, Globally Unique Identifier (GUID). GUID представляет собой AD-версию использовавшегося ранее в Windows NT 4.0 идентификатора SID. Применение только одного сервера в каждом домене для генерации RID гарантирует, что эти идентификаторы действительно будут уникальными.
• PDC Emulator - если в сети присутствуют домены NT 4.0, сервер в роли PDC Emulator эмулирует работу основного контроллера домена NT 4.0 PDC, и, таким образом, резервные контроллеры NT 4.0 BDC могут выполнять обновление своих баз данных SAM. Но даже в том случае, если совершается переход в Native Mode, сервер PDC Emulator продолжает выполнять некоторые важные функции: в частности, решает проблемы при несоответствии паролей (например, когда пользователь изменил пароль на одном DC, но аутентификация для этого пользователя выполняется другим DC, который еще не успел получить соответствующие изменения). Во избежание конфликтов изменение групповых политик также происходит на PDC Emulator. Этот же сервер выполняет функцию главного сервера времени внутри своего домена. По существу, любые "чуждые" AD работы сбрасываются на PDC Emulator. Если контроллер домена в роли PDC Emulator выйдет из строя, его отсутствие почувствуется очень скоро.