Что такое pdc и relative id master. Управление ролями FSMO при помощи Ntdsutil

Доменные службы AD поддерживают пять ролей мастеров операций:

1 Владелец доменных имён (Domain Naming Master);

2 Владелец схемы (Schema Master);

3 Владелец относительных идентификаторов (Relative ID Master);

4 Владелец инфраструктуры домена (Infrastructure Master);

5 Эмулятор основного контроллера домена (Primary Domain Controller Emulator (PDC Emulator)).

Владелец доменных имён (Domain Naming Master).

Роль предназначена для добавления и удаления доменов в лесу. Если контроллер с этой ролью недоступен во время добавления или удаления доменов в лесу возникнет ошибка операции.

В лесу используется только один контроллер домена с ролью - владелец доменных имён (Domain Naming Master).

Для того, что бы посмотреть какой из контроллеров домена у вас выполняет роль Владельца доменных имен, необходимо запустить оснастку Active Directory - Домены и доверие щелкнуть правой кнопкой на корневой узел и выбрать "Хозяин операции "

В строке Хозяин именования доменов вы увидите какой контроллер домена выполняет эту роль.

Владелец схемы (Schema Master).

Контроллер с ролью владелец схемы отвечает за внесение всех изменений в схему леса. Все остальные домены содержат реплики схемы только для чтения.

Роль Владелец схемы уникальна во всем лесу и может быть определена только на одном контроллере домена.

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

regsvr32 schmmgmt.dll

После этого нажимаем "Пуск " выбераем команду "Выполнить " и вводим "mmc " и нажмите кнопку "ОК ". Далее в меню нажимаем "Файл " выбаем команду "Добавить или удалить оснастку ". В группе Доступные оснастки выбираем "Схема Active Directory ", нажимаем кнопку "Добавить ", а затем кнопку "ОК ".

Щелкните правой кнопкой мыши корневой узел оснастки и выберите "Хозяин операции ".

В строке Текущий хозяин схемы (в сети) увидите имя контроллера домена выполняющую эту роль.

Владелец относительных идентификаторов (Relative ID Master).

Эта роль обеспечивает всех пользователей, компьютеров и групп уникальными SID (Security Identifier- структура данных переменной длины, которая идентифицирует учетную запись пользователя, группы, домена или компьютера)

Роль мастера RID уникальна в домене.

Что бы увидеть какой контролер в домене выполняет роль владельца идентификатора, необходимо запустить оснастку "Хозяин операции ".

Во вкладке RID увидите имя сервера выполняющую роль RID

Владелец инфраструктуры домена (Infrastructure Master).

Эта роль актуальна при использовании нескольких доменов в лесу. Основная ее задача заключается в управлении фантомными объектами. Фантомный объект - объект который создается в другом домене для предоставления каких либо ресурсов.

Роль инфраструктуры домена уникальна в домене.

Что бы увидеть какой контролер в домене выполняет роль владельца инфраструктуры домена, необходимо запустить оснастку "Active Directory- пользователи и компьютеры ", кликнуть на домене правой кнопкой мыши и выберать "Хозяин операции ".

Во вкладке "Инфраструктура " увидите контроллер выполняющий эту роль в домене.

Эмулятор основного контроллера домена (Primary Domain Controller Emulator (PDC Emulator)).

Роль PDC- эмулятора несколько важных функций (здесь указаны не все- только основные):

Участвует в репликации обновления паролей. Каждый раз когда пользователь меняет пароль эта информация сохраняется на контроллере домена с ролью PDC. При вводе пользователя неправильного пароля проверка подлинности направляется на PDC- эмулятор для получения возможно изменившегося пароля учетной записи (поэтому при вводе не правильного пароля вход проверка пароля происходит дольше в сравнении с вводом правильного пароля).

Участвует в обновлении групповой политики в домене. В частности когда изменяется групповая политика на разных контроллерах домена в одно время PDC- эмулятор действует как точка фокуса всех изменений групповой политики. При открытии редактора управлениями групповыми политиками она привязывается к контроллеру домена, выполняющую роль PDC- эмулятора. Поэтому все изменения групповых политик по умолчанию вносятся в PDC- эмулятор.

PDC- эмулятор является главным источником времени для домена. PDC- эмуляторы в каждом домене синхронизирует свое время с PDC эмулятором корневого домена леса. Другие контролеры синхронизируют свое время с PDC- эмулятором домена, компьютеры и сервера синхронизируют время с контролера домена.

Что бы увидеть какой контролер в домене выполняет роль PDC- эмулятора, необходимо запустить оснастку "Active Directory- пользователи и компьютеры ", кликните на домене правой кнопкой мыши и выберите "Хозяин операции ".

Во вкладке PDC увидите контроллер выполняющий эту роль.

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

Прежде чем приступать к практической части, вспомним что такое и рассмотрим что именно произойдет с ActiveDirectory при их отказе. Всего ролей FSMO пять, две для леса и три для домена.

Роли уровня леса существуют в единственном экземпляре и, несмотря на свою важность, наименее критичны для функционирования AD. Что произойдет при недоступности каждой из них:

  • Хозяин схемы - невозможно изменить схему. Однако данная процедура проводится раз в несколько лет при введении в сеть контроллеров на более новой ОС или установке некоторых иных серверных продуктов, таких как Exchange. На практике отсутсвие хозяина схемы можно не замечать годами.
  • Хозяин именования домена - невозможно добавить или удалить домен. Аналогично с хозяином схемы его отсутвие может быть незамеченным довольно длительное время.

Роли уровня домена существуют по одной в каждом домене и являются более критичными для функционирования AD.

  • Хозяин инфраструктуры - при наличии нескольких доменов на контроллерах которые не являются глобальными каталогами может быть нарушено членство в локальных группах домена. Если все контроллеры домена - глобальные каталоги (сегодня именно такая конфигурация является рекомендуемой Microsoft), то про существование хозяина инфраструктуры можно смело забыть, точно также как и при единственном домене в лесу.
  • Хозяин RID - через некоторое время будет невозможно создать новый объект в AD, время зависит от оставшегося количества свободных SID, которые выдаются пачками по 500 заготовок. Если в вашей AD небольшое количество объектов и вы не каждый день заводите новые, то отсутствие хозяина RID останется незамеченным на протяжении длительного времени.
  • Эмулятор PDC - самая критичная роль. При его недоступности сразу станет невозможным вход в домен клиентов до Windows 2000 (если они где-то еще остались), прекратится синхронизация времени и не будут действовать некоторые политики при вводе неправильного пароля. На практике отсутствие эмулятора PDC будет замечено при первой рассинхронизации времени более чем на 5 минут, а это может произойти раньше, чем вы можете предполагать.

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

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

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

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

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

Узнать какие именно контроллеры обладают ролями FSMO можно командой:

Netdom query fsmo

Для управления ролями FSMO запустите утилиту ntdsutil на любом контроллере домена:

Ntdsutil

Затем перейдем к управлению ролями:

Следующим шагом следует соединиться с контроллером домена, которому мы собираемся передать роли, для этого перейдем в подменю соединения с серверами:

Connections

и соединимся с нужным сервером:

Connect to server SERVERNAME

где SERVERNAME - имя необходимого нам контроллера домена. Затем выйдем из подменю:

При этом следует помнить, что мы можем запустить утилиту на любом из контроллеров домена и присоединиться к любому другому КД для передачи или захвата ролей. В нашем примере мы физически находясь на сервере SRV-DC01 соединились с сервером WIN2K8R2-SP1 и попробуем передать ему какую нибудь роль.

Для передачи ролей служит команда transfer в качестве агрумента которой выступает имя передаваемой роли, для каждой из ролей используются следующие имена:

  • naming master - хозяин именования домена
  • infrastructure master - хозяин инфраструктуры
  • PDC - эмулятор PDC
  • RID master - хозяин RID
  • schema master - хозяин схемы

Внимание! В системах до Windows Server 2008 R2 для хозяина именования домена использовалось имя domain naming master .

Например для передачи роли хозяина именования домена выполним команду:

Transfer naming master

Появится диалоговое окно, которое попросит нас подтвердить действие, советуем всегда внимательно изучать его содержимое.

Получив утвердительный ответ утилита передаст выбранную роль другому серверу.

Теперь представим, что сервер WIN2K8R2-SP1 безвозвратно выбыл из строя и нам требуется захватить роль хозяина именования назад. Для захвата ролей служит команда seize , которая имеет аналогичный синтаксис.

Для захвата роли снова запустим ntdsutil и, подключившись к контроллеру для которого будем производить захват, выполним команду:

Seize naming master

После того как мы подтвердим захват ntdsutil попытается осуществить операцию передачи роли и только в случае ее невозможности произведет захват.

Это сделано для того, чтобы избежать ситуации, когда роль будет захвачена у исправного контроллера и в сети возникнет два обладателя одной и той же роли.

Помните , что после захвата включать в сеть контроллер с которого была захвачена роль нельзя!

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

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 .