FSMO-роль эмулятор первичного контроллера домена (PDC emulator) является второй ролью (из трех) уровня домена. То есть в одном домене должен быть один PDC emulator, но во всем лесу AD их может быть несколько, в зависимости от количества доменов.

Основная статья по Active Directory — . Читайте также другие статьи по ролям хозяев операций — .

Если вам интересна тематика Windows Server, рекомендую обратиться к рубрике на моем блоге.

Чтобы лучше понимать функционал данной роли FSMO, необходимо сначала обратиться к истории его появления.

Немного истории

Роль эмулятора PDC необходима прежде всего для обеспечения совместимости с версиями Windows ниже 2000. В смешанной среде с клиентами Windows NT, 95, 98 PDC emulator выполняет следующие задачи:

1. Участвует в процессе смены паролей учетных записей пользователей и компьютеров;
2. Реплицирует обновления на резервные контроллеры домена (backup domain controllers);
3. Выполняет задачи хозяина обозревателя сети домена (Domain Master Browser).

Для доменов Windows NT 3.51, 4 эмулятор первичного контроллера домена выполнял очень важную функцию и при его отказе весь домен фактически переходил в режим «только чтение»:

• Пользователи не смогли бы изменить пароли (выдавалась бы ошибка «Unable to change password on this account. Please contact your system administrator» );
• При создании учетной записи вы получили бы ошибку («could not find domain controller for this domain» );
• На резервных контроллерах домена были бы ошибки репликации (связано с тем, что резервные контроллеры домена реплицировали изменения только с PDC. Чтобы можно было вносить изменения в базу BDC, его необходимо сделать первичным контроллером домена).

С развитием технологии упор делался на взаимозаменяемость и равноправность всех контроллеров домена и таким образом домен Windows 2003 уже представлял из себя совершенно другую структуру, основу которой составляла репликация с несколькими хозяевами. Хоть и «вторичные» (некоторое подобие BDC) контроллеры домена остались, первичные контроллеры как таковые перестали существовать.

Современное назначение

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

1) Репликация паролей идет на PDC emulator в приоритетном режиме . То есть, если пользователь изменил пароль (а сделать это он может на любом DC), то контроллер домена первым делом обращается к эмулятору PDC, чтобы сообщить о факте смены пароля. В свою очередь другие DC, если авторизация с измененным паролем идет через них, не отказывают пользователю, а обращаются к эмулятору первичного контроллера домена, чтобы просмотреть возможные изменения и получив их, авторизуют пользователя с новым паролем.

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

То же касается и блокировок учетных записей — первым делом они реплицируются на эмулятор PDC.

2) Для предупреждения конфликтов изменения групповых политик, все изменения GPO в реальности происходят именно на эмуляторе PDC и не важно где конкретно вы работаете с оснасткой;

3) В Windows Server 2003 включены некоторые дополнительные объекты безопасности по умолчанию. При обновлении инфраструктуры с версии Windows Server 2000 сам процесс обновления вы должны начать непосредственно с эмулятора PDC , чтобы эти группы и учетные записи первым делом появились на нем и уже потом реплицировались на другие контроллеры. Сами объекты хранятся в контейнере CN=WellKnown Security Principals,CN=Configuration,DC=;

4) Механизм SDProp (Security Descriptor propagator) запускается именно на PDC эмуляторе . Этот механизм «приводит в порядок» списки контроля доступа (ACL’s) у объектов Active Directory. У критически важных объектов безопасности домена (эти объекты имеют выставленное в 1 значение атрибута adminCount ) образцовые ACL хранятся в специальном контейнере, который называется AdminSDHolder.

Кстати, вот полный список наиболее важных объектов безопасности для только что созданного домена:

Разумеется учетная запись bissquit создана мной вручную, у вас она будет отличаться;

5) Во время установки первого контроллера домена служба NetLogon создает SRV-запись DNS _ldap._tcp.pdc._msdcs.DnsDomainName . Эта запись позволяет клиентам обнаруживать эмулятор PDC. Только владелец этой роли может изменять эту запись;

6) На эмуляторе первичного контроллера домена выполняются изменения пространства имен DFS (Distributed File System). Если PDC emulator не будет найден, то DFS будет работать некорректно;

7) Процесс повышения функционального уровня домена или леса выполняется на эмуляторе PDC .

8) Пожалуй одной из самых важных функций является распространение времени по всему домену . Подробнее про настройку времени в домене вы можете прочитать в моей статье .

Лучшие практики

Многие лучшие практики администрирования эмулятора первичного домена соответствуют другим ролям хозяев операций:

Администрирование

Специальная оснастка для управления работой эмулятора PDC отсутствует.

Изменить владельца роли вы можете с помощью оснастки . Для этого:

1. Открываем оснастку на DC01, правой кнопкой нажимаем на Active Directory — Пользователи и компьютеры и выбираем Сменить контроллер домена Active Directory ;
2. Далее выбираем контроллер домена, на который мы хотим перенести роль (у меня это DC02, по умолчанию всегда выбирается сервер-владелец роли). Подтверждаем предупреждение;
3. Снова правой кнопкой на Active Directory — Пользователи и компьютеры , но уже выбираем Хозяин операций… ;
4. Нажимаем кнопку Изменить… .

После этого необходимо подтвердить выбор и получить уведомление об успешном переносе роли.

На этом обзор fsmo-роли PDC эмулятор завершен.

Служба Active Directory содержит в себе роли FSMO (Flexible Single Master Operations — гибкие операции с одним хозяином), которые применяются для выполнения различных задач внутри леса и домена. Существуют две роли на уровне леса и три роли на уровне домена.

1. Schema Master (Хозяин схемы) / Лес / Содержит в себе схему леса
2. Domain Namiпg Master (Хозяин именования доменов) / Лес / Управляет именами доменов
3. lnfrastructure Master Домен (Хозяин инфраструктуры) / Домен / Обеспечивает меж-доменные ссылки на объекты
4. PDC Emulator (Эмулятор основного контроллера домена) / Домен / Отвечает за время в лесе
Обрабатывает изменения паролей, Является точкой подключения для управления объектами GPO, Блокирует учетные записи.
5. RID Master (Хозяин относительных идентификаторов (RID)) / Домен / Управляет и пополняет пулы RID (relative identifier — относительный идентификатор)

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

Чтобы передать роли FSMO домена, выполните описанные далее шаги:
1 . Откройте окно командной строки (cmd.eхе) . введите NTDSUtil и нажмите .
2. Введите roles и нажмите .
3 . Введите connections и нажмите .
connect to server [Имя_сервера ] и нажмите .
5. Введите quit и нажмите .
6. Первой будет передаваться роль PDС Emulator. Введите transfer pdc и нажмите . Вы должны подтвердить запрос, нажав на кнопке Yes (Да).
transfer rid master и нажать для перемещения роли RID Master. Вы должны подтвердить запрос, щелкнув на кнопке Yes (Да).
8. При необходимости можно ввести transfer infrastructure master и нажать для перемещения роли lnfrastructure Master. Вы должны подтвердить запрос, щелкнув на кнопке Yes (Да).
9. Теперь, когда передача всех ролей FSMO домена завершена, введите quit и нажмите затем снова введите quit и нажмите . чтобы закрыть окно командной строки.

Разумеется, приведенные шаги должны быть выполнены в каждом домене.
Если вы решите передать роли FSMO уровня леса, выполните следующие шаги:
Откройте окно командной строки (cmd.eхе ), введите NTDSUtil и нажмите .
2. Введите roles и нажмите .
3. Введите connections и нажмите < Enter>.
4. Теперь необходимо подключиться к серверу, который в будущем будет содержать эти роли FSMO. Введите connect to server [ Имя:_сервера ] и нажмите .
5. Введите quit и нажмите .
6. Первой будет передаваться роль Schema Master. Введите transfer schema master и нажмите . Вы должны подтвердить запрос, щелкнув на кнопке Yes (Да).
7. При необходимости можно ввести transfer naming master и нажать для перемещения роли Domain Naming Master. Вы должны подтвердить запрос, щелкнув на кнопке Yes (Да) .
8. Теперь, когда передача всех ролей FSMO леса завершена, введите quit и нажмите , затем снова введите quit и нажмите , чтобы закрыть окно командной строки.

Передача и захват ролей FSMO

Определившись с назначением ролей FSMO рассмотрим варианты передачи ролей другому контроллеру домена, а также принудительное назначение, или «захват» роли в случае недоступности контроллера домена, который ее выполняет.

При создании домена, по умолчанию все роли назначаются первому контроллеру домена в лесу. Переназначение ролей требуется крайне редко. Microsoft рекомендует использовать передачу ролей FSMO в следующих случаях:

Плановое понижение роли контроллера домена, являющегося обладателем ролей FSMO , например с целью вывода сервера из эксплуатации;
Временное отключение контроллера домена, например для выполнения профилактических работ. В этом случае его роли должны быть назначены другому, работающему контроллеру домена. Это особенно необходимо при отключении эмулятора PDC . Временное отключение остальных хозяев операций в меньшей степени сказывается на работе AD .

Захват ролей FSMO производится в следующих случаях:

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

Примечание. Начиная с Windows Server 2003 SP1 при выполнении команды dcpromo /forceremoval осуществляется проверка, имеет ли контроллер домена роль хозяина операций, является DNS-сервером или сервером глобального каталога. Для каждой из этих ролей будет получено уведомление с указаниями по выполнению соответствующих действий.

В том случае, если в домене два или более контроллеров, первым делом нам необходимо выяснить, кто является обладателем каждой из ролей FSMO . Это достаточно просто сделать с помощью команды netdom query fsmo

Ну а теперь приступим к передаче ролей. Есть несколько вариантов действий, рассмотрим их все по порядку. Вариант первый, самый простой и доступный.

Добровольная передача ролей FSMO с помощью оснасток управления Active Directory

RID Master , PDC Emulator и Infrastructure Master ) используем оснастку Active Directory Пользователи и компьютеры (Users and Computers ). Для этого заходим на контроллер домена, которому хотим передать роли, запускаем оснастку и щелкнув правой клавишей мыши на нужном домене, выбираем пункт «Хозяева операций».

В открывшемся окне выбираем нужную нам роль (в нашем примере RID Master ) и нажимаем кнопку «Изменить».

И смотрим на результат. Дело сделано, роль передана другому серверу.

Перенос роли Domain Naming Master осуществляется из оснастки Active Directory Домены и доверие (Domains and Trust ). Запускаем оснастку, при необходимости подключаемся к нужному контроллеру домена, щелкаем правой клавишей мыши в корне оснастки и выбираем пункт меню «Хозяин операций».

Открывается знакомое окно, в котором надо нажать кнопку «Изменить», а затем подтвердить изменения так же, как и в предыдущем примере.

С ролью Schema Master дела обстоят несколько сложнее. Для передачи этой роли необходимо предварительно зарегистрировать в системе библиотеку управления схемой Active Directory . Делается это с помощью команды regsvr32 schmmgmt.dll , введенной в окне Выполнить (Run ).

Затем открываем консоль MMC и добавляем в нее оснастку Схема Active Directory .

Если по каким то причинам не удается передать роли с помощью графических оснасток, а также для любителей командной строки есть второй вариант:

Добровольная передача ролей fsmo при помощи Ntdsutil

ntdsutil.exe – утилита командной строки, предназначенная для обслуживания каталога Active Directory . Она представляет из себя мощный инструмент управления, и в число ее возможностей входит передача и захват ролей FSMO .

Для передачи ролей заходим на любой контролер домена, расположенный в том лесу, в котором следует выполнить передачу ролей FSMO . Рекомендуется войти в систему на контроллере домена, которому назначаются роли FSMO . Запускаем командную строку и вводим команды в такой последовательности:

• ntdsutil
• roles
• connections
• connect to server <имя сервера>

После успешного подключения к серверу мы получаем приглашение к управлению ролями (fsmo maintenance ), и можем начать передавать роли:

• transfer domain naming master — передача роли хозяина доменных имен.
• transfer infrastructure master — передача роли хозяина инфраструктуры;
• transfer rid master — передача роли хозяина RID ;
• transfer schema master — передача роли хозяина схемы;
• transfer pdc — передача роли эмулятора PDC .

Для завершения работы Ntdsutil вводим команду q и нажимаем Ввод.

Примечание. Начиная с Windows Server 2008R2 команда для передачи роли хозяина доменных имен transfer naming master.

В качестве примера передадим роль Infrastructure Master серверу SRV2 и проверим результат.

Ну и третий, самый печальный вариант развития событий:

Принудительное назначение ролей fsmo при помощи Ntdsutil

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

• ntdsutil
• roles
• connections
• connect to server <имя сервера>

Для захвата ролей FSMO используется команда seize

И еще несколько важных моментов, которые нужно учесть при передаче\захвате ролей FSMO :

Для передачи ролей уровня домена (RID Master , PDC Emulator и Infrastructure Master ) ваша учетная запись должна быть членом группы Администраторы домена (Domain admins ), а для передачи ролей уровня леса (Domain Naming Master и Schema Master ) — Администраторы предприятия (Enterprise Admins ).
По возможности не назначайте роль Infrastructure Master контроллеру домена, являющемуся сервером глобального каталога, поскольку в этом случае он не будет обновлять сведения об объектах. Причина такого поведения заключается в том, что сервер глобального каталога хранит частичные реплики всех объектов в лесу.
В случае захвата ролей FSMO контроллер домена, ранее исполнявший эти роли, ни в коем случае нельзя возвращать обратно, т.к. при его появлении в сети возникнет конфликт, что может вызвать проблемы в работе домена. Кроме того, его необходимо удалить из Active Directory. В Windows Server 2008 и 2008 R2 это можно сделать, просто удалив объект сервера в оснастке Active Directory Пользователи и компьютеры , а в Windows Server 2003 с помощью программы Ntdsutil , используя команду ntdsutil — metadata cleanup . Подробнее об этом можно почитать в техподдержке Microsoft

Есть несколько ситуаций, когда приходится вспоминать о ролях FSMO — это аварийное восстановление после сбоя, миграция, а также поиск работы (обычно на собеседованиях очень любят задавать вопросы типа «Какие существуют роли в AD для контроллера домена, зачем они нужны?»). И хотя все эти ситуации происходят крайне редко, для общего понимания работы AD весьма полезно понимать назначение ролей FSMO .

FSMO , или Flexible single-master operations (операции с одним исполнителем) — это операции, выполняемые контроллерами домена Active Directory (AD) , которые требуют обязательной уникальности сервера для каждой операции. В зависимости от типа операции уникальность FSMO подразумевается в пределах одного домена или леса доменов. Различные типы FSMO могут выполняться как на одном, так и на нескольких контроллерах домена. Выполнение FSMO сервером называют ролью сервера, а сами сервера — хозяевами операций.

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

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

Всего в лесу есть пять ролей FSMO. Для начала приведу их краткое описание:

• Хозяин схемы (Schema Master ) — отвечает за внесение изменений в схему Active Directory . Может быть только один на весь лес доменов.
• Хозяин именования доменов (Domain Naming Master ) — отвечает за уникальность имен для создаваемых доменов и разделов приложений в лесу. Может быть только один на весь лес доменов.
• Хозяин инфраструктуры (Infrastructure Master ) — хранит данные о пользователях из других доменов, входящих в локальные группы своего домена. Может быть один на каждый домен в лесу.
• Хозяин RID (RID Master ) — отвечает за выделение уникальных относительных идентификаторов (RID ), необходимых при создании доменных учетных записей. Может быть один на каждый домен в лесу.
• Эмулятор PDC (PDC Emulator ) — отвечает за совместимость с доменом NT4 и клиентами до Windows 2000 . Может быть один на каждый домен в лесу.

А теперь пройдемся подробнее по каждой роли и выясним, насколько они важны для функционирования Active Directory .

Schema Master

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

Domain Naming Master

Domain Naming Master отвечает за операции, связанные с именами доменов AD, однако список его обязанностей несколько больше:

• Добавление и удаление доменов в пределах леса. Добавлять и удалять домены позволяется только контролеру с ролью Domain Naming Master . Он отслеживает, чтобы добавляемый домен имел уникальное в пределах леса NETBIOS -имя. Если Naming Master недоступен, добавить или удалить домен в лесу невозможно.
• Создание и удаление разделов. Начиная с Windows 2003 появилась возможность создавать обособленные разделы — Application Directory Partitions , которые используются для хранения в AD произвольных данных. Как пример — хранение данных для DNS -серверов в разделах ForestDnsZones и DomainDnsZones . Управление разделами при недоступном Domain Naming Master невозможно.
• Создание и удаление перекрестных ссылок. Перекрестные ссылки используются для поиска по каталогу в том случае, если сервер, к которому подключен клиент, не содержит нужной копии каталога, причем ссылаться можно и на домены вне леса, при условии их доступности. Хранятся перекрестные ссылки (crossRef ) в контейнере Partitions раздела Configuration , и только Domain Naming Master имеет право на изменение содержимого этого контейнера. При недоступности Domain Naming Master не получится создать новую перекрестную ссылку, или удалить ненужную.
• Одобрение переименования домена. Для переименования домена используется утилита rendom.exe. Она составляет скрипт с инструкциями, которые должны будут выполниться в процессе переименования. Скрипт этот помещается в контейнер Partitions раздела Configuration . Поскольку право менять содержимое этого контейнера есть только у контроллера с ролью Domain Naming Master , то за проверку инструкций и запись атрибутов отвечает именно он.

Находиться данная роль может на любом контроллере домена в пределах леса.

Infrastructure Master

Если сервер не является глобальным каталогом (GC ), то в его базе нет данных о пользователях из других доменов. Тем не менее, в локальные группы домена мы можем добавлять пользователей из других доменов. А группа в базе AD должна физически иметь ссылки на всех пользователей. Эту проблему решили созданием фиктивного объекта — фантома (phantom ). Фиктивные объекты представляют собой особый тип объектов внутренней базы данных и не могут просматриваться через ADSI или LDAP . Именно работой с фантомами занимается мастер инфраструктуры.

Еще одна особенность данной роли — для правильной работы в многодоменной среде контролер домена, выполняющий роль хозяина инфраструктуры не должен быть сервером глобального каталога. Если обладатель роли Infrastructure Master также является сервером GC , фиктивные объекты не создаются или не обновляются на этом контроллере домена. Это происходит потому, что глобальный каталог уже содержит частичные реплики всех объектов в Active Directory, и ему нет необходимости в фантомах.

RID Master

У каждой учетной записи в домене (пользователя, компьютера, группы) должен быть уникальный идентификатор безопасности (SID ), который однозначно идентифицирует эту учетную запись и служит для разграничения прав доступа. Выглядит SID следующим образом:

S-1-5-Y1-Y2-Y3-Y4 , где

• S-1 — SID ревизии 1. В настоящее время используется только эта ревизия.
• 5 — Обозначает, кем был выдан SID. 5 означает NT Authority . Однако так называемые «хорошо известные идентификаторы» SID (well-known SID ) могут в данной части иметь 0, 1, и некоторые другие значения.
• Y1-Y2-Y3 — Идентификатор домена, к которому относится учетная запись. Одинаковый для всех объектов security principal в пределах одного домена.
• Y4 — Относительный идентификатор (Relative ID, RID ), относящийся к конкретной учетной записи. Подставляется из пула отностительных идентификаторов домена в момент создания учетной записи.

Контроллер домена с ролью RID Master отвечает за выделение последовательности уникальных RID каждому контроллеру домена в своем домене, а также за корректность перемещения объектов из одного домена в другой. У контроллеров домена есть общий пул относительных идентификаторов (RID Pool ), RID из которого каждому контроллеру выделяются порциями по 500 штук. Когда их число подходит к концу (становится меньше 100), контроллер запрашивает новую порцию. При необходимости число выдаваемых RID и порог запроса можно изменить.

Еще одна зона ответственности RID Master — перемещение объектов между доменами. Именно RID Master следит за тем, чтобы нельзя было одновременно переместить один объект в два разных домена. Иначе возможна ситуация, когда в двух доменах будет два объекта с одинаковым GUID , что чревато самыми неожиданными последствиями.

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

PDC Emulator

Изначально основной задачей Primary Domain Controller (PDC) Emulator было обеспечение совместимости с предыдущими версиями Windows . В смешанной среде, в которой встречаются клиенты Windows NT4.0/ 95/98 и контроллеры домена NT4 , PDC Emulator выполняет (только для них) следующие функции:

• Обработка операции “смена пароля” для пользователей и компьютеров;
• Репликация обновлений на BDC (Backup Domain Controller );
• Обозреватель сети (поиск сетевых ресурсов).

Начиная с уровня домена Windows 2000 и старше работы ему прибавилось. Контроллер домена с ролью PDC Emulator выполняет следующие функции:

• Отвечает за изменение паролей и отслеживает блокировки пользователей при ошибках паролей. Пароль, измененный любым другим контроллером домена, первым делом реплицируется на PDC Emulator . Если аутентификация на любом другом контроллере домена не была успешной, запрос повторяется на PDC Emulator . При успешной аутентификации учетной записи сразу после неудачной попытки, PDC Emulator о ней уведомляется и сбрасывает счетчик неудачных попыток в ноль. Важно заметить, что в случае недоступности PDC Emulator информация об изменении пароля всё равно распространится по домену, просто произойдет это несколько медленнее.
• Редактор групповых политик по умолчанию соединяется с сервером PDC Emulator , и изменения политик происходят на нем же. Если PDC Emulator недоступен, придется указать редактору, к какому контроллеру домена подключиться.
• По умолчанию именно PDC Emulator является для клиентов сервером точного времени в домене. PDC Emulator корневого домена в лесу является по умолчанию сервером точного времени для PDC Emulator в дочерних доменах.
• Изменения, вносимые в пространство имен Distributed File System (DFS ), вносятся на контроллере домена с ролью PDC Emulator . Корневые серверы DFS периодически запрашивают с него обновленные метаданные, сохраняя их у себя в памяти. Недоступность PDC Emulator может повлечь за собой неверную работу DFS .
• В Active Directory есть так называемые «Встроенные участники системы безопасности» (Well Known Security Principals ). Примерами могут служить учетные записи Everyone, Authenticated Users, System, Self и Creator Owner . Управление ими всеми осуществляет контроллер домена с ролью PDC Emulator . Точнее говоря, при изменениях в AD PDC Emulator проверяет и обновляет содержимое контейнера “CN=WellKnown Security Principals, CN=Configuration, DC=>”.
• В каждом домене леса Active Directory есть владелец административных дескрипторов безопасности — AdminSDHolder . Он хранит информацию о настройках безопасности для так называемых защищённых групп (protected groups ). С определённой периодичностью данный механизм запрашивает перечень всех участников этих групп и выставляет им права в соответствии со своим списком управления доступом. Таким образом AdminSDHolder защищает административные группы от изменений. Выполняется AdminSDHolder на контроллере домена с ролью PDC Emulator .

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

hb860 25 ноября 2011 в 14:02

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

• Системное администрирование

Большинство системных администраторов в своей корпоративной среде для обеспечения системы идентификации и доступа своих пользователей к ресурсам предприятия используют доменные службы 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);
• 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-идентификаторов, генерируемых контроллером домена и поэтому мастер 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 получает первый контроллер домена, установленный в лесу. Вы можете в любое время переместить эту роль при помощи оснастки или средствами утилиты 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 используются различные административные оснастки. Тяжелее всего идентифицировать мастера схемы. С него и начнём. Чтобы узнать, какой контроллер домена обладает ролью мастера схемы, выполните следующие действия:


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


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

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

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

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


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

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

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

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


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