FSMO-роль хозяин инфраструктуры (Infrastructure master) является третьей и последней ролью уровня домена, то есть в каждом домене AD должен быть один контроллер домена-владелец роли. В лесу же, напротив, может быть несколько хозяев инфраструктуры в зависимости от количества доменов.
Основная статья по Active Directory — Active Directory Domain Services. Читайте также другие статьи по ролям хозяев операций — FSMO — Fexible Single Master Operations.
Если вам интересна тематика Windows Server, рекомендую обратиться к рубрике Windows Server на моем блоге.
Infrastructure master — Теория
Каждый контроллер домена AD хранит полную информацию о всех объектах внутри своего домена. Тем не менее иерархия леса может не ограничиваться одним единственным доменом, а состоять из множества других. Все это никоим образом не сказывается на работе до того времени, пока объекты безопасности одного домена не начнут использоваться в других.
На практике мало примеров, когда домены одного леса существуют фактически изолированно друг от друга. Очень часты случаи, когда в локальных группах одного домена, содержатся пользователи из других доменов. За работоспособность таких схем внутри каждого домена отвечает владелец роли хозяин инфраструктуры.
Пример: в домене В есть группа, в которую необходимо включить пользователя из домена А 1. Как только пользователь включен в группу, происходит следующее:
- Хозяин инфраструктуры домена В обращается к серверу глобального каталога (GC — Global Catalog) для получения сведений о пользователе домена А. Поскольку глобальный каталог хранит информацию об объектах всех доменов леса, он возвращает данные хозяину инфраструктуры домена В;
- Хозяин инфраструктуры домена В создает фантомную запись пользователя домена А. Эта запись является особым типом объекта AD и не может быть просмотрена через какие-либо оснастки (adsiedit.msc, Пользователи и компьютеры и др.). Фантомные записи содержат минимум информации, включая в себя следующие параметры:
— Различающееся имя объекта (Distinguished name, пример имени — CN=bissquit,OU=01.1 Admins,OU=01 Users,DC=corp,DC=bissquit,DC=com);
— GUID объекта;
— SID объекта.
- Хозяин инфраструктуры периодически сравнивает (раз в 2 дня 2 по умолчанию) все фантомные объекты с данными глобального каталога. Если с пользователем А произошли какие-либо изменения:
— он был перенесен в другой домен и изменился SID (подробнее читайте в статье RID master — Хозяин относительных идентификаторов) и различающееся имя (Distinguished name);
— он был переименован или перемещен в другой контейнер и изменилось различающееся имя;
— он был удален.
об этих изменениях узнает хозяин инфраструктуры и вносит соответствующие изменения у себя. Если пользователь из домена А был удален, удаляется и фантом в домене В.
Помимо обозначенных выше процессов, хозяин инфраструктуры также ответственен за выполнение команды adprep /domainprep 3 4, которая должна запускаться именно на сервере-держателе этой роли fsmo.
Лучшие практики
Сервер глобального каталога хранит у себя полную реплику данных своего домена, а также частичную реплику каждого домена леса. Частичная реплика включает в себя данные об объектах, состоящие из GUID, SID, а также различающегося имени объекта. То есть хранит все те же данные, что и фантомные записи хозяина инфраструктуры. Таким образом, если Infrastructure Master располагается на сервере Глобального каталога, то новые фантомные объекты создаваться/изменяться/удаляться не будут, поскольку глобальный каталог и так хранит подобные записи у себя. Следствием этого будет неактуальная информация о междоменных объектах (cross-domain object) у других контроллеров этого домена, ведь они по-прежнему обращаются к хозяину инфраструктуры для получения информации об объектах других доменов. Из этого следует один вывод 5:
Не размещайте хозяина инфраструктуры на сервере глобального каталога, если не все DC в лесу являются серверами глобального каталога.
Однако давайте рассмотрим ситуацию, когда все контроллеры домена в лесу являются ещё и глобальными каталогами. В этом случае каждый контроллер домена содержит самую актуальную информацию о всех объектах леса. Ведь каждый сервер глобального каталога получает данные об изменении любого объекта в лесу через процесс репликации. Таким образом необходимость в хозяине инфраструктуры отпадает полностью и из этого следует рекомендация:
Сделайте все контроллеры домена в лесу серверами глобального каталога.
Это можно рассматривать положительно с точки зрения балансировки нагрузки, отказоустойчивости.
Пришло время прояснить один момент: необходимость создания фантомных записей существует только в многодоменном лесе AD. То есть если ваш лес состоит из одного домена, то фантомы создаваться не будут в принципе, а значит и необходимости в хозяине инфраструктуры нет вообще. Подытожим сказанное.
Хозяин инфраструктуры не нужен, когда:
- Лес AD состоит из одного домена;
- В многодоменном лесу каждый контроллер домена является сервером глобального каталога.
Но какие лучшие практики администрирования существуют для ситуации, когда у вас множество доменов в лесу, а глобальным каталогом является далеко не каждый контроллер домена? Мне известен только один совет 6:
Размещайте роль хозяина инфраструктуры на контроллере домена, который имеет стабильный канал связи с любым глобальным каталогом в лесу и желательно, чтобы они оба находились в одном сайте.
Пожалуй на этом все.
Администрирование
Специальная оснастка для управления работой хозяина инфраструктуры отсутствует.
Изменить владельца роли вы можете с помощью оснастки Active Directory — Пользователи и компьютеры. Для этого:
- Открываем оснастку на DC01, правой кнопкой нажимаем на Active Directory — Пользователи и компьютеры и выбираем Сменить контроллер домена Active Directory;
- Далее выбираем контроллер домена, на который мы хотим перенести роль (у меня это DC02, по умолчанию всегда выбирается сервер-владелец роли). Подтверждаем предупреждение;
- Снова правой кнопкой на Active Directory — Пользователи и компьютеры, но уже выбираем Хозяин операций…;
- Нажимаем кнопку Изменить….
После этого необходимо подтвердить выбор и получить уведомление об успешном переносе роли.
На этом обзор fsmo-роли Infrastructure master завершен.
Notes:
- How Operations Masters Work ↩
- Phantoms, tombstones and the infrastructure master ↩
- Running Adprep.exe ↩
- AD:Роли FSMO и самая важная роль контроллера домена ↩
- AD DS: The infrastructure master for this domain should be held by a domain controller that is not a global catalog server ↩
- Размещение и оптимизация FSMO на контроллерах домена Active Directory ↩
