Все что вы хотели знать о мастерах операций, но боялись спросить

Большинство системных администраторов в своей корпоративной среде для обеспечения системы идентификации и доступа своих пользователей к ресурсам предприятия используют доменные службы Active Directory, которые смело можно назвать сердцем всей инфраструктуры предприятия. Как многие из вас знают, структура доменных служб в организациях может включать в себя как один, так и несколько лесов (набор доменов, включающих описание сетевой конфигурации и единственный экземпляр каталога), в зависимости от таких факторов как ограничение области доверительных отношений, полное разделение сетевых данных, получение административной изоляции. В свою очередь, каждый большой лес для упрощения администрирования и репликации данных должен разделяться на домены. В каждом домене для управления доменными службами и выполнения таких задач как проверка подлинности, запуск службы «Центр распределения ключей Kerberos» и управления доступом используются контроллеры домена. А для управления сетевым трафиком между офисами разрабатываются сайты.
Вся информация о лесах, доменах и сайтах, естественно, должна быть согласована ещё при проектировании доменных служб Active Directory, согласно таким корпоративным требованиям как: бизнес-требованиям, функциональным требованиям, юридическим, требованиям по безопасности, а также проектным ограничениям к документации. Зачастую все эти моменты перед развёртыванием доменных служб тщательно планируются ИТ-подразделением самой компании или проектной группой, занимающейся инфраструктурой предприятия и записываются в специальное соглашение об уровне услуг, определяющее ожидаемый уровень быстродействия и качество предоставляемой услуги.
Полученная информация после проектирования или, чаще всего, уже после развёртывания доменных служб Active Directory должна быть тщательно задокументирована. В такую документацию должна входить информация о самой логической и физической структуре доменных служб, об административных моделях, инфраструктуре разрешения имён, обо всех планируемых изменениях в среде организации, а также о таких дополнительных компонентах инфраструктуры, как внедрение почтовых серверов Microsoft Exchange, серверов System Center и многое другое. В большинстве случаев, ИТ-персонал организации игнорирует процесс документирования и при смене ИТ-персонала у новых администраторов может уйти какое-то время на то, чтобы полностью сориентироваться с текущей инфраструктурой организации.
Также нужно понимать, что в службе каталогов практически все контроллеры доменов являются равноправными (в данном контексте мы не берём во внимание контроллеры домена только для чтения, RODC), то есть все контроллеры домена обладают правом записи в базу данных и могут реплицировать эти данные на другие контроллеры. Такая топология отлично справляется с большинством тривиальных операций Active Directory и называется репликацией с множеством равноправных участников (Multimaster). Но, все-таки, существуют некоторые операции, которые обязательно должны выполняться на отведённом непосредственно для таких операций уполномоченном сервере. Другими словами, контроллеры домена, выполняющие в своём домене определённые операции или роли, называются мастерами (или хозяевами) операций. Знать и понимать назначение всех ролей мастеров операций необходимо, так как в случае аварийного восстановления, обновления или миграции именно контроллеры домена, выполняющие роли мастеров операций, могут сыграть одну из важнейших ролей. Соответственно, именно о мастерах операций и пойдёт речь в данной статье.
Из этой статьи вы узнаете:

• О том, что было бы, если бы не существовало мастеров операций;
• О ролях мастеров операций уровня леса;
• О ролях мастеров операций уровня домена;
• О том, как можно определить, какой контроллер обладает ролью FSMO;
• О захватах и передаче ролей мастеров операций;
• О правильном размещении мастеров операций на контроллерах домена.

Что не будет рассматриваться в рамках текущей статьи:

• Планирование и документирование контроллеров доменов, обладающих ролями мастеров операций. Это отдельная тема, которая включает в себя понимание нюансов планирования доменных служб Active Directory и выходит за рамки этой статьи;
• Серверы глобального каталога. Многие системные администраторы приравнивают серверы глобального каталога к ролям мастеров операций. На самом деле, это ложное суждение. Глобальным каталогом называется репозиторий распределённых данных, который хранит информацию о каждом объекте, а также позволяет пользователям и приложениям находить объекты в любом домене текущего леса посредством поиска атрибутов, включённых в глобальный каталог, которые идентифицируются в схеме в качестве частного набора атрибутов. Сам глобальный каталог располагается на контроллерах доменов, назначенных в качестве серверов глобального каталога и, в свою очередь, реплицируется посредством репликации Multimaster. Несмотря на то, что глобальный каталог содержит полный список всех объектов леса, и серверы глобального каталога могут отвечать на все запросы без необходимости ссылки на другие контроллеры доменов, глобальный каталог не является ролью мастеров операций. О серверах глобального каталога вы можете почитать следующую статью: «Серверы глобальных каталогов»;
• Взаимодействие мастеров операций с контроллерами домена только для чтения. Контроллеры домена только для чтения (Read Only Domain Controller) представляют собой особый, относительно новый тип контроллеров домена, которые целесообразно развёртывать в филиалах организации, не обеспеченных достаточным уровнем безопасности и квалифицированным ИТ-персоналом. Также как и в случае с планированием мастеров операций и серверами глобального каталога, контроллеры домена только для чтения представляют собой отдельную обширную тему, которую захватывать в данной статье нет никакого смысла. Но сразу стоит обратить внимание на то, что контроллеры домена только для чтения не могут выступать в качестве контроллера домена с ролью мастера операций;
• Решение проблем и ошибки, связанные с мастерами операций. Интересная и довольно объёмная тема, которая не будет рассмотрена, ввиду того, что в текущей статье рассматриваются общие понятия ролей мастеров операций.

Что было бы, если бы не существовало мастеров операций

Перед тем как представить себе ситуацию с контроллерами доменов Active Directory, на которых не было бы разграничений на контроллеры домена, выполняющие специфические операции и на остальные контроллеры домена, рассмотрим преимущества контроллеров домена, оснащённых ролями мастеров операции.
Прежде всего, как уже было указано во вводном разделе данной статьи, мастерами операций называются контроллеры домена, выполняющие в Active Directory особую роль, предназначенную для гарантии целостности и исключения конфликтов. Именно для этой цели на такие контроллеры доменов назначается специальная роль, и ввиду того, что у таких ролей нет жёсткой привязки к одному контроллеру домена, такие роли называются мастерами операций (Flexible Single Master Operation, FSMO, что произносится как fizz-mo). По сути, эти роли могут выполнять и другие контроллеры домена, но назначаться каждая роль должна лишь одному контроллеру домена, причём, в одном домене одновременно не могут выполняться действия, которые должны выполняться на контроллерах доменов мастеров операций.
Думаю, будет полезно узнать, какие протоколы используют мастера операций. Мастера операций используют три протокола:

• Облегчённый протокол доступа к каталогам (Lightweight Directory Access Protocol, LDAP);
• RPC;
• SMTP.

Теперь на минуту представим себе, что было бы, если бы в доменных службах Active Directory не существовало мастеров операций, то есть, если бы все контроллеры домена могли одновременно выполнять одинаковые действия.
Предположим, есть организация с одним лесом и пятью доменами. В каждом из доменов системные администраторы решили одновременно установить почтовый сервер Microsoft Exchange, причём, в одном домене администратор устанавливает 2007 версию данного почтового сервера, во втором – 2000, а в третьем Microsoft Exchange Server 2010 SP1. Все изменения в схеме домена и, соответственно, всего леса записываются на контроллер домена, к которому были подключены администраторы, а через какое-то время все изменения, внесённые в схему Active Directory, реплицируются на каждый контроллер домена в лесу организации.
Если кто-то захочет переименовать свой домен при помощи системной утилиты Rendom.exe так, как уже назван другой домен, а соответствующей роли FSMO не будет на предприятии, при обращении к которой администратор увидел бы предупреждающее сообщение, мол, «Что же ты делаешь-то? Такой домен ведь уже есть, хочешь сломать все на свете?» и домен будет переименован, после репликации просто невозможно было бы избежать фатальных проблем.
Возьмём ещё один пример… Опять же, в природе не существует мастеров операций. На клиентских машинах может сбиваться время, пользователи могут сами как бы невзначай изменять своё время, но все клиенты в домене по умолчанию должны синхронизировать время с ближайшими контроллерами домена. В этом случае, если нет определённого контроллера домена, так называемого ведущего источника времени, то время у каждого пользователя во всем домене может отличаться, что может быть критичным для некоторых бизнес-приложений.
Собственно, примеры корпоративного апокалипсиса в связи с отсутствием мастеров операций можно приводить бесконечно много. Суть одна, мастера операций просто обязаны быть, должны быть доступными и должны выполнять только те операции, которые им предназначены.
Всего доменные службы Active Directory включают в себя пять различных ролей мастеров операций, А именно, две роли используются на уровне леса: мастер именования доменов и мастер схемы, причём, в каждом лесу может быть не более одного контроллера домена, с назначениями каждой роли. В каждом домене предусмотрены только три роли мастеров операций: мастер относительного идентификатора RID, мастер инфраструктуры, а также эмулятор главного контроллера домена PDC. То есть, при установке самого первого контроллера домена в лесу, ему одновременно назначаются все пять ролей мастеров операций, а при создании нового домена Active Directory в существующем лесу, новому контроллеру домена присваиваются три роли уровня домена. FSMO в лесу и число потенциальных владельцев этих ролей можно рассчитать по формуле «(количество доменов * 3) + 2».
Например, если у вас есть лес Active Directory с четырьмя доменами, где есть дочерний и внучатый домен у одного из основных доменов, то такой лес будет содержать 14 ролей FSMO. То есть: одного мастера схемы, одного мастера именования доменов, четыре эмулятора PDC (для двух основных, дочернего и внучатого домена по одной роли), четыре хозяина RID для каждого домена, а также четыре мастера инфраструктуры для каждого домена.
На этом этапе, думаю, настало самое время рассмотреть каждую роль мастера операций уровня леса и уровня домена.

Роли мастеров операций уровня леса

Как я уже написал выше, для уровня леса Active Directory предусмотрены две роли мастеров операций, а именно:

• Мастер схемы;
• Мастер именования доменов

Роль мастера схемы

Перед тем как сказать несколько слов о роли мастера схемы, думаю, есть смысл, в двух словах рассказать, что же вообще такое «Схема Active Directory».
– Видишь суслика?
— Нет.
— И я не вижу. А он есть!
К.Ф. «ДМБ»

Для многих начинающих администраторов, схему Active Directory можно проассоциировать с написанным выше выражением из известного кинофильма. Вроде бы, как и есть такая вещь как схема, но вот для чего она нужна, что она собой представляет, да и вообще, что это такое, никто не знает и не спешит об этом узнать.
Согласно терминологии, схема содержит определения каждого атрибута и класса, которые создаются и хранятся в лесу Active Directory. Думаю, вряд ли для кого-то окажется новостью, что доменные службы Active Directory хранят и в нужное время извлекают необходимую информацию многих корпоративных приложений. Это сделано для того, чтобы в случае необходимости, приложения обращались не к различным компонентам инфраструктуры предприятия, а к доменным службам Active Directory, информация о которых будет отреплицирована на все контроллеры домена. Стоит обратить внимание на то, что в каждом лесу Active Directory существует лишь одна схема, которая может реплицироваться на каждый контроллер домена в лесу. Поэтому, если нужно в организации развернуть несколько приложений, которые могут создать конфликты в схеме Active Directory, целесообразно развёртывать и поддерживать два отдельных леса.
Сама схема состоит из объектов classSchema и attributeSchema, которые запрашиваются при определении требуемого объекта в доменных службах. Сами классы представляют собой некие определения, расположенные в схеме, которые, в свою очередь, определяют группы атрибутов. Нужно помнить, что каждый класс может использовать множество атрибутов. И, в конце концов, для каждого атрибута, расположенного в доменных службах Active Directory, в схеме указывается тип данных в качестве синтаксиса самого атрибута. И, разумеется, значение каждого атрибута, включённого в экземпляр класса, должно соответствовать требованиям синтаксиса текущего атрибута.
Так как подробное рассмотрение схемы Active Directory выходит за рамки этой статьи, думаю, описанного выше определения более чем достаточно. Подробнее о схеме Active Directory будет рассказано в одной из следующих статей. Сейчас же рассмотрим, что собой представляет роль мастера схемы.
Контроллер домена, который является мастером схемы, отвечает за все изменения, которые вносятся в схему леса Active Directory. Нужно помнить, что контроллер домена, отвечающий за данную роль должен быть единственным во всем лесу, а все остальные контроллеры домена будут содержать лишь реплики схемы леса только для чтения. То есть, при внесении любых изменений в схему Active Directory вручную или при установке приложений, которые изменяют схему, администратору нужно выполнять изменения на контроллере домена, который управляет данной ролью. Для внесения изменений администратор должен подключиться к мастеру схемы и должен входить в группу безопасности «Администраторы схемы». После обновления схемы она реплицируется с мастера схемы на все остальные контроллеры домена. При попытке модификации схемы не на контроллере домена, выполняющем роль мастера схемы, действие обычно завершается отказом и вам нужно после внесения изменений в схеме переслать их на контроллер домена с ролью мастера схемы. Соответственно, данная роль является критически важной, так как при попытке модификации схемы Active Directory с выведенным из строя мастером схемы, вы будете все время нарываться на ошибки. В свою очередь, располагаться роль мастера схемы может на любом назначенном для этой цели контроллере домена в лесу.
По умолчанию, роль мастера схемы присваивается первому контроллеру домена, который устанавливается в лесу и эту роль рекомендуется размещать вместе с ролью мастера именования доменов о которой будет рассказано ниже, на одном контроллере домена. Несмотря на рекомендации, вы можете в любое время переместить эту роль на любой контроллер домена при помощи оснастки «Схема Active Directory» или посредством утилиты командной строки Ntdsutil. О переносе ролей на другие контроллеры домена вы также узнаете в этой статье. Идентифицируется мастер схемы значением атрибута fSMORoleOwner корневого объекта раздела схемы.

Роль мастера именования доменов

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

• Добавление и удаление доменов. Во время выполнения такой операции как добавление или удаление дочернего домена средствами мастера установки Active Directory или утилиты командной строки, мастер установки обращается именно к мастеру именования доменов и запрашивает право на добавление или, соответственно, удаление последнего. Также мастер именования доменов отвечает за обеспечение того, чтобы домены в лесу владели уникальными NETBIOS-именами в пределах всего леса. Естественно, по вполне понятным причинам, в том случае, если мастер именования доменов будет недоступен, вы не сможете добавлять или удалять домены в лесу;
• Добавление и удаление перекрёстных ссылок. Как вы уже знаете, во время создания первого контроллера домена в лесу, в нем создаются разделы каталога схемы, конфигурации и домена. В это время, для каждого раздела каталогов в контейнере Partitions раздела конфигурации (CN=partitions,CN=configuration,DC=forestRootDomain) создаётся объект перекрёстных ссылок (класс crossRef). Объект перекрёстной ссылки определяет имя и расположение серверов, которые хранят каждый раздел каталога в лесу. При создании каждого последующего домена или раздела каталога приложений, инициируется создание объекта перекрёстных ссылок в контейнере Partitions.
• Добавление и удаление разделов каталогов приложений. Разделы каталогов приложений представляют собой специальные разделы, которые вы можете создавать на контроллерах домена Windows Server 2003, Windows Server 2008 или Windows Server 2008 R2 для обеспечения хранилища динамических данных приложений LDAP. Если у вас лес работает на уровне Windows Server 2000, то в таком лесу все недоменные данные ограничиваются конфигурацией и данными схемы, которые реплицируются на все контроллеры домена в лесу. В лесу Windows Server 2003/2008 и 2008R2 разделы каталога приложений обеспечивают хранение специфических данных приложений на контроллере домена, которые могут быть воспроизведены на любом контроллере домена в лесу.
• Подтверждение инструкций переименования доменов. Последнее, выполняемое мастером именования доменов действие, является подтверждением инструкций переименования доменов. Обычно домены принято переименовывать при помощи специальной утилиты командной строки. Так вот, при использовании утилиты Rendom.exe, которая предназначена для переименования доменов, для того чтобы переименовать домен, утилита должна иметь доступ к мастеру именования доменов. Помимо вышеперечисленных возможностей, мастер именования доменов также отвечает за подтверждение инструкций переименования доменов. При запуске указанного средства, на контроллере домена с ролью мастера именования доменов, в атрибут msDS-UpdateScript объекта контейнера Partitions (CN=partitions,CN=configuration,DC=forestRootDomain) раздела каталогов Configuration записывается XML-сценарий, содержащий инструкции переименования доменов. Стоит помнить, что контейнер Partitions можно обновлять только на контроллере домена, который содержит роль мастера именования доменов. В дополнение к значению атрибута msDS-UpdateScript, утилита Rendom.exe записывает новое DNS-имя каждого переименованного домена в атрибут msDS-DnsRootAlias объекта перекрёстной ссылки (класс crossRef), соответствующего этому домену. Опять же, поскольку объект перекрёстной ссылки хранится в контейнере Partitrions, данный объект может обновляться только на контроллере домена с ролью мастера именования доменов. Изменённые данные атрибутов msDS-UpdateScript и msDS-DnsRootAlias реплицируются на все контроллеры домена в лесу.

По умолчанию, роль мастера именования доменов получает первый контроллер домена в новом лесу, но вы в любой момент можете переместить данную роль при помощи оснастки «Active Directory – домены и доверие» или утилиты командной строки Ntdsutil.exe. Не стоит забывать о том, что рекомендуется располагать на одном контроллере домена роли мастера схемы и мастера именования доменов. Контроллер домена, которому присвоена роль мастера именования доменов, должен одновременно являться сервером глобального каталога. В противном случае некоторые операции могут завершиться неудачно. Идентифицируется мастер схемы значением атрибута fSMORoleOwner в контейнере Partitions.
Так же как и в случае с предыдущим мастером операций, если вы попробуете выполнить любую из приведённых выше операций при недоступном мастере операций, ваши действия завершаться ошибкой. Но так как все эти действия выполняются за продолжительный промежуток времени практически однократно, о том, что мастер именования доменов в непригодном состоянии, вы можете узнать в критически важный момент, поэтому периодически проверяйте доступность мастеров операций леса.

Роли мастеров операций уровня домена

В отличие от уровня леса, в каждом домене Active Directory предусмотрено три следующие роли мастеров операций:

• Мастер относительных идентификаторов RID
• Эмулятор главного контроллера домена PDC
• Мастер инфраструктуры

Рассмотрим подробно каждый из этих мастеров операций.

Мастер RID

Первым мастером операций для уровня домена, описанным в этой статье, будет мастер относительных идентификаторов (RID). Мастер RID используется для управления пулом идентификаторов RID с целью генерирования идентификаторов безопасности (SID) для таких принципалов безопасности как пользователи, группы и компьютеры, а также за перемещение объектов из одного домена в другой. Идентификатор SID принципала безопасности должен быть уникальным для всего домена, поэтому каждому принципалу безопасности присваивается уникальный идентификатор безопасности SID, который содержит идентификатор домена и относительный идентификатор RID, который является уникальным для каждого принципала безопасности. Во всех идентификаторах SID присутствуют четыре различных элемента. Например, согласно документации Microsoft, элементы идентификатора S1-5-Y1-Y2-Y3-Y4 предоставлены в следующей таблице:
Таблица 1. Структура элемента идентификатора

Элемент идентификатора SID	Описание
S1	Указывает ревизию SID. В настоящее время для SID используется только одна ревизия
5	Указывает центр выдачи принципала безопасности. Значение 5 всегда указывается для доменов Windows NT, Windows 2000, Windows 2003, Windows 2008 и Windows 2008 R2
Y1-Y2-Y3	Часть идентификатора SID домена. Для принципалов безопасности, созданных в домене этот элемент идентификатора идентичен
Y4	Относительный идентификатор (RID) для домена, который представляет имя пользователя или группы. Этот элемент генерируется из пула RID на контроллере домена во время создания объекта

Так как принципалы безопасности может создавать любой контроллер домена, необходим механизм, гарантирующий уникальность SID-идентификаторов, генерируемых контроллером домена и поэтому мастер RID следит за тем, чтобы два контроллера домена не назначали одинаковые идентификаторы RID. Мастер RID присваивает блок относительных идентификаторов RID, которые называются пулом RID, каждому контроллеру в домене. Другими словами, мастер операций RID отвечает за поддержку пула относительных идентификаторов для использования контроллеров домена в домене и предоставления групп относительных идентификаторов для каждого контроллера домена. Когда к домену добавляется новый контроллер домена, мастер RID назначает этому контроллеру домена пул из 500 относительных запросов RID. Каждый раз, когда на контроллере домена создаётся новый принципал безопасности, для присвоения идентификатора новому объекту, контроллер домена назначает относительный идентификатор из своего пула. Когда число относительных идентификаторов RID в этом RID-пуле на любом контроллере домена опускается ниже 100, другими словами, приближается к нулевому рубежу, мастер RID выполняет запрос ещё одного блока RID. Выполнив запрос, мастер RID назначает контроллеру домена ещё один пул из 500 относительных идентификаторов RID.
Если говорить ещё точнее, то мастер RID не ведёт счёт номеров пула, а обслуживает высшее значение последнего выделенного диапазона. При получении нового запроса, увеличивается значение нового пула на единицу и 499 новых значений. После этого два значения отправляются запрашиваемому контроллеру домена для использования новых относительных идентификаторов RID. Если локальный пул RID контроллера домена пуст или мастер RID в течение некоторого времени недоступен, процесс создания учётных записей на некоторых контроллерах домена может прерваться и в журнале событий этого контроллера домена будет записано событие с кодом 16645. Этот код ошибки указывает на то, что присвоен максимальный идентификатор учётной записи из выделенных на контроллер домена и контроллер домена не смог получить новый пул идентификаторов от мастера RID. Таким же образом, при добавлении нового объекта в домен будет создано событие с кодом 16650, указывающее на то, что объект не может быть создан, так как служба каталогов не смогла выделить относительный идентификатор. Механизм запроса нового блока идентификаторов RID предназначен для предотвращения таких прерываний, поскольку запрос выполняется перед исчерпыванием всех доступных RID идентификаторов в пуле. Чтобы включить процесс создания учётных записей заново, нужно либо подключить к сети контроллер домена, который управляет ролью мастера RID, либо переместить эту роль ещё на один контроллер домена.
Также при процессе миграции объектов Active Directory между доменами, требуется наличие мастера RID, то есть, объект сможет мигрировать только в том случае, если в домене будет доступен мастер RID. Наличие активного текущего мастера операций предотвращает создание в разных доменах Active Directory двух объектов с идентичными идентификаторами. Во время осуществления миграции объектов из одного домена в другой, корпорация Microsoft рекомендует использовать утилиту Acrive Directory Migration Tool. По умолчанию, роль мастера RID получает первый контроллер домена, установленный в лесу. Вы можете в любое время переместить эту роль при помощи оснастки «Active Directory – пользователи и компьютеры» или средствами утилиты Ntdsutil.exe. Мастер RID идентифицируется значением атрибута fSMORoleOwner в объекте класса rIDManager в разделе Domain.

Эмулятор PDC

Контроллер домена с назначенным мастером операций эмулятор PDC (главный контроллер домена – Primary Domain Controller) выполняет функции основного контроллера домена для обеспечения обратной совместимости с операционными системами ниже Windows 2000. Во времена серверов-членов и клиентских компьютеров Windows NT 4.0, изменения в каталог могли вносить лишь главные контроллера домена PDC. Прежние инструменты, клиенты и утилиты, поддерживающие Windows NT 4.0, не рассчитаны на то, что все контроллеры домена Active Directory могут выполнять запись в каталог, и поэтому таким приложениям требуется подключение к PDC. Контроллер домена с ролью PDC-эмулятора регистрирует себя как главный контроллер домена PDC, специально для того, чтобы различные низкоуровневые приложения могли локализовать пишущий контроллер домена. Несмотря на то, что в наше время сервера и клиентские компьютеры с операционными системами ниже Windows 2000 встретить практически невозможно, эмулятор PDC все ещё остаётся важнейшей ролью мастеров операций. Помимо обратной совместимости с приложениями, работающими в среде Windows NT 4.0, эмулятор PDC выполняет следующие важные функции:

• Участие в репликации обновлений паролей домена. При изменении или сбросе пароля пользователя, контроллер домена, вносящий изменения, реплицирует это изменение на PDC-эмулятор посредством срочной репликации. Эта репликация гарантирует, что контроллеры домена быстро узнают изменённый пароль. В том случае, если пользователь пытается войти в систему сразу после изменения пароля, контроллер домена, отвечающий на этот запрос, может ещё не знать новый пароль. Перед тем как отклонить попытку входа, этот контроллер домена направляет запрос проверки подлинности на PDC-эмулятор, который проверяет корректность нового пароля и указывает контроллеру домена принять запрос входа. Это означает, что каждый раз при вводе пользователем неправильного пароля проверка подлинности направляется на PDC-эмулятор для получения окончательного заключения;
• Управление обновлениями групповой политики в домене. Как вы знаете, для управления большинства настройками в конфигурации компьютеров и пользователей вашей организации применяются групповые политики. В том случае, если объект групповой политики модифицируется на двух контроллерах домена приблизительно в одинаковое время, то впоследствии, могут возникать конфликты между двумя версиями, которые не разрешаются при репликации объектов групповых политик. Во избежание таких конфликтов, PDC-эмулятор действует следующим образом: при открытии объекта групповой политики, оснастка редактора управления групповой политики привязывается к контроллеру домена, выполняющего роль PDC и все изменения объектов GPO по умолчанию вносятся на PDC-эмулятор;
• Выполнение функции центрального браузера домена. Для обнаружения сетевых ресурсов клиенты используют Active Directory. При открытии окна «Сеть» в операционной системе отображается список рабочих групп и доменов. После того как пользователь откроет указанную рабочую группу или домен он сможет увидеть список компьютеров. Эти списки генерируются посредством службы браузера, и в каждом сетевом сегменте ведущий браузер создаёт список просмотра с рабочими группами, доменами и серверами данного сегмента. После чего центральный браузер объединяет списки всех ведущих браузеров для того, чтобы клиентские машины могли просмотреть весь список просмотра. Думаю, из всех функций эмулятора PDC у вас могут возникнуть вопросы, связанные непосредственно с центральным браузером домена, поэтому, данная тема будет подробно рассмотрена в отдельной статье;
• Обеспечение главного источника времени домена. Так как службы Active Directory, Kerberos, DFS-R и служба репликации файлов FRS используют штампы времени, во всех системах домена необходима синхронизация времени. PDC-эмулятор в корневом домене леса служит ведущим источником времени всего леса. Остальные контроллеры домена синхронизируют время с PDC-эмулятором, а клиентские компьютеры – со своими контроллерами доменов. Гарантию за соответствие времени несёт иерархическая служба синхронизации, которая реализована в службе Win32Time.

По умолчанию, роль мастера эмулятора PDC получает первый контроллер домена, установленный в лесу. Вы можете в любое время переместить эту роль при помощи оснастки «Active Directory – пользователи и компьютеры» или средствами утилиты Ntdsutil.exe. Мастер эмулятора PDC идентифицируется значением атрибута fSMORoleOwner в объекте класса rIDManager в корневом объекте раздела Domain.

Мастер инфраструктуры

В организациях, основанных на множестве доменов, объекты в одних доменах часто ссылаются на объекты в других. Мастер инфраструктуры подобен устройству, которое отслеживает членов группы из доменов. Мастер инфраструктуры отвечает за обновление ссылок «группа — пользователь» между доменами, тем самым обеспечивая отражение изменений имён объектов в информации о членствах в группах, локализованных в домене. Мастер инфраструктуры поддерживает обновляемый список таких ссылок, а затем реплицирует эту информацию на все контроллеры в домене. Следует знать, что во время добавления члена другого домена в группу целевого домена, к атрибуту member добавляется отличительное имя нового члена и если же контроллер домена члена такой группы недоступен, то в доменных службах создаётся объект-фантом, собственно, представляющий члена такой группы. Такой объект может содержать только SID члена, отличительное имя (DN), а также GUID объекта. В том случае, если мастер инфраструктуры недоступен, ссылки «группа — пользователь» между доменами не будут обновляться. Периодически мастер инфраструктуры сканирует учётные записи домена и проверяет членство в группах. Если учётная запись пользователя перемещается на новый домен, мастер инфраструктуры идентифицирует новый домен учётной записи пользователя и соответствующим образом обновляет группы.
Стоит обратить внимание на то, что роль мастера инфраструктуры не должна выполняться контроллером домена, который является сервером глобального каталога. В противном случае мастер инфраструктуры не будет обновлять сведения об объектах, так как он не содержит ссылок на объекты, которые не хранит. Это обусловливается тем, что сервер глобального каталога хранит частичные реплики всех объектов в лесу. В результате междоменные объектные ссылки в этом домене обновляться не будут, а в журнале событий данного контроллера домена появится соответствующее предупреждение. По умолчанию, роль мастера инфраструктуры получает первый контроллер домена, установленный в лесу. Вы можете в любое время переместить эту роль при помощи оснастки «Active Directory – пользователи и компьютеры» или средствами утилиты Ntdsutil.exe. Мастер инфраструктуры идентифицируется значением атрибута fSMORoleOwner в контейнере Infrastructure в разделе Domain.

Как можно определить, какой контроллер домена обладает ролью FSMO

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

Определение обладателей ролей мастеров операций средствами GUI

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

1. Выполните вход на контроллер домена под учётной записью, обладающей правами администратора;
2. Откройте диалоговое окно «Выполнить» и зарегистрируйте динамическую библиотеку оснастки «Схема Active Directory» при помощи команды regsvr32.exe schmmgmt;
3. Затем откройте окно консоли управления MMC и вызовите диалог добавления новой оснастки. В списке оснасток выберите «Схема Active Directory», как показано на следующей иллюстрации:
   
   
   Рис. 1. Добавление оснастки «Схема Active Directory»
4. В открытой оснастке «Схема Active Directory» нажмите правой кнопкой мыши на корневом узле оснастки и из контекстного меню выберите команду «Хозяин операций», как показано ниже:
   
   
   Рис. 2. Мастер операций схемы

Для идентификации остальных мастеров операций вам нужно выполнить существенно меньше действий. Чтобы найти, какой контроллер домена обладает правами мастера операций именования доменов, вам нужно:

1. Открыть окно оснастки «Active Directory – домены и доверие»;
2. Щёлкнуть правой кнопкой мыши на корневом узле оснастки и из контекстного меню выбрать команду «Хозяин операций», как изображено на следующей иллюстрации:
   
   
   Рис. 3. Мастер операций именования доменов

А для идентификации оставшихся трёх ролей уровня домена вам нужно выполнить меньше всего действий. Другими словами, все оставшиеся роли мастеров операций можно найти в одном диалоговом окне. Для этого откройте оснастку «Active Directory – пользователи и компьютеры», нажмите правой кнопкой мыши на своём домене и из контекстного меню выберите команду «Хозяева операций». В отобразившемся диалоговом окне на соответствующих вкладках можно просмотреть имена контроллеров домена, которым назначены текущие роли. Диалоговое окно «Хозяева операций» можно посмотреть на следующей иллюстрации:

Рис. 4. Хозяева операций для уровня домена

Определение обладателей ролей мастеров операций средствами командной строки

Как и для большинства возможностей предоставляемых операционными системами Windows, вы можете определить всех обладателей ролей мастеров операций при помощи специальной утилиты командной строки. В доменных службах Active Directory для контроля определённых изменений используется утилита командной строки Ntdsutil. Для того чтобы просмотреть все контроллеры домена, оснащённые ролями мастеров операций при помощи этой утилиты, выполните следующие действия:

1. Откройте окно командной строки;
2. Выполните команду Ntdsutil;
3. Перейдите к маркерам владельца управления ролью NTDS при помощи ввода команды roles;
4. На этом шаге вам нужно подключить определённый контроллер домена Active Dirctory. Для этого выполните команду connections;
5. В строке «server connections» введите connect to server, укажите в этой же строке имя сервера и нажмите на клавишу «Enter»;
6. Перейдите обратно к fsmo management, используя команду quit;
7. Выполните команду «Select operation target», предназначенную для выбора сайтов, серверов, доменов, ролей или контекстов именования;
8. Теперь вы можете просмотреть список ролей, известных подключённому серверу при помощи команды List roles for connected server, как показано на следующей иллюстрации:
   
   
   Рис. 5. Определение мастеров операций средствами командной строки

Также для просмотра FSMO-ролей вы можете воспользоваться утилитой Dcdiag с командой /test:Knowsofroleholders /v. Часть вывода данной команды вы можете увидеть ниже:


Рис. 6. Определение FSMO-ролей средствами утилиты Dcdiag

Захват и передача ролей мастеров операций

В Active Directory существуют такие понятия как передача и захват (также известный как отзыв) ролей мастеров операций. Прежде всего, следует узнать, что же это такое и какая у этих понятий разница.
Как уже было указано выше, изначально на первый контроллер домена в лесу устанавливаются все пять ролей мастеров операций. Обычно принято для повышения производительности и отказоустойчивости развёртывать в организации, в пределах одного домена несколько дополнительных контроллеров домена. И, соответственно, для того чтобы в будущем избежать конфликтов, рекомендуется сразу распределять роли мастеров операций на разные контроллеры доменов. Также, если вам нужно отключить контроллер домена, выполняющий роль мастера операций или вывести его из эксплуатации, вам следует перенести с него все FSMO-роли на другие контроллеры доменов.
В свою очередь, захват роли необходим в том случае, если контроллер домена, наделённый конкретными ролями мастеров операций, вышел из строя, и вы не успели вовремя перенести роли с этого DC. О рисках, которым вы можете подвергнуться в случае отказа контроллеров домена, обладающих ролями мастеров операций, рассказывалось немного ранее в данной статье. В этом случае у вас нет никакой возможности перенести FSMO-роль предпочтительным методом передачи ролей. Следовательно, приходится только захватывать маркёр операций посредством отзыва роли. Но стоит помнить, что захват роли является самым радикальным методом и выполнять его нужно только в том случае, когда обладатель ролей мастеров операций вышел из строя. Когда выполняется процесс захвата роли мастера операций, на существующем компьютере изменяется атрибут fsmoRoleOwner объекта, представляющий собой корневой каталог данных, без выполнения какой-либо синхронизации данных. Другие контроллеры домена, естественно, узнают о новом владельце роли FSMO по мере репликации произведённых изменений.
Рассмотрим процессы передачи и захвата ролей мастеров операций.
Для того чтобы передать FSMO-роль, выполните следующие действия:

1. Откройте оснастку, при помощи которой можно идентифицировать роли мастера операций, о которых шла речь в предыдущем разделе настоящей статьи. Например, для передачи роли эмулятора PDC, откройте оснастку «Active Directory – пользователи и компьютеры»;
2. При помощи текущей оснастки подключитесь к контроллеру домена, на который будет перенесена роли мастера операций. Это можно сделать при помощи диалогового окна «Смена контроллера домена», которое вызывается из контекстного меню корневого узла оснастки. Диалоговое окно смены контроллера домена можно увидеть ниже:
   
   
   Рис. 7. Смена контроллера домена для передачи роли мастера операций
3. Откройте диалоговое окно «Хозяева операций», перейдите на необходимую вкладку и нажмите на кнопку «Изменить». Роль мастера операций будет передана другому контроллеру домена.

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

1. Откройте командную строку и в ней перейдите к утилите ntdsutil;
2. Перейдите к управлению ролью NTDS, используя команду roles;
3. Нужно установить подключение к контроллеру домену, который в будущем будет выполнять роль владельца мастера операций. Для этого выполните команду connections;
4. В строке «server connections» введите connect to server и укажите требуемый контроллер домена;
5. Перейдите обратно к fsmo management, используя команду quit;
6. Теперь в строке fsmo management укажите команду seize и нажмите на Enter;
7. На этом, последнем, шаге вам нужно выбрать FSMO-роль, которая будет захвачена с неработающего контроллера домена.

Внимательный читатель может задаться следующим вопросом: а что же мне делать, если мёртвый контроллер домена удалось реанимировать и как мне вернуть на этот контроллер домена обратно владение захваченной ролью? Тут все относительно просто. Прежде всего, вам нужно знать, что если была отозвана роль эмулятора PDC или инфраструктуры, то вы сможете без особых проблем обратно передать роль мастера операций восстановленному контроллеру домена.
А вот в том случае, если захватывалась роль мастера схемы, именования доменов или относительных идентификаторов RID, то вам нужно будет выполнить следующие действия:

1. Физически отключить такой контроллер домена от сети;
2. Понизить роль контроллера домена до рядового сервера при помощи команды Dcpromo /forceremoval;
3. Очистить метаданные для текущего контроллера домена. Чистить метаданные вы можете при помощи утилиты Ntdsutil с командой Metadata Cleanup;
4. После удаления метаданных вам нужно подключить сервер к сети, присоединить к домену, а затем повысить сервер до контроллера домена;
5. На последнем шаге просто передайте роль этому контроллеру домена.

Размещение мастеров операций на контроллерах домена

В этом разделе я немного расскажу о рекомендациях по размещению всех ролей мастеров операций на контроллерах домена. Как таковых, таких рекомендаций не много, поэтому я постараюсь упростить данный раздел, как только можно.
Прежде всего, если у вас один лес, один домен и один контроллер домена, то все пять ролей мастеров операций будут размещены именно на этом контроллере домена, но в целях балансировки нагрузки рекомендуется передавать роли на другие контроллеры домена.
Основные рекомендации по размещению FSMO-ролей следующие:

• Размещайте роли мастера RID и PDC-эмулятора на одном контроллере домена. Совместное размещение этих ролей мастеров операций обусловлено соображениями балансировки нагрузки. Поскольку эти роли прямые партнёры по репликации, разместив эти роли на отдельных контроллерах домена, вам придётся для соответствующих двух систем устанавливать быстрое подключение и в Active Directory для них создавать явные объекты. Помимо этого, если у вас в организации присутствуют серверы, играющие роли резервных мастеров операций, на таких серверах эти роли также обязаны быть прямыми партнёрами;
• Размещайте роли мастеров схемы и именования доменов на одном контроллере домена. Как правило, роли мастера схемы и мастера именования доменов рекомендуется размещать на одном контроллере домена, который служит сервером глобального каталога. Роль мастера именования доменов, должна одновременно являться сервером глобального каталога, потому что при добавлении нового домена, мастер должен гарантировать, что в лесу нет объекта с тем же именем, что и у нового добавляемого домена. Если же контроллер домена с ролью мастера именования доменов не будет являться сервером глобального каталога, такие операции как создание внучатых доменов могут завершаться с ошибками. В связи с тем, что эти роли используются реже всего, вы должны проследить, чтобы контроллер домена, который ими управляет, был максимально защищён;
• Роль мастера инфраструктуры должна размещаться на контроллере домена, который не служит сервером глобального каталога. Обычно мастер инфраструктуры должен разворачиваться на контроллере домена, который не служит сервером глобального каталога, но имеет объект прямого подключения к одному из глобальных каталогов в лесу. Так как сервер глобального каталога хранит частичные реплики всех объектов в лесу, мастер инфраструктуры, размещённый на сервере глобального каталога, не будет выполнять обновления, потому что он не содержит ссылок на объекты, которые не хранит.

Руководствуясь этими тремя правилами, вы можете размещать мастера операций в своём лесу оптимальным образом.

Вместо заключения

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