Введение
В жизни каждого системного администратора наступает момент, когда ему приходится лихорадочно вспоминать, какая роль на каком контроллере домена развернута, а главное, какая за что отвечает. Как правило, это сценарии обновления, миграции или аварийного восстановления.
По долгу службы регулярно приходится сталкиваться с большим разнообразием фантазий и суеверий на тему равноправности контроллеров домена (“начиная с Windows 2000”), интересных предположений о работе, например, роли Infrastructure Master, поэтому прояснить ситуацию раз и навсегда крайне желательно.
Итак. Все мы знаем, что ролей FSMO (Flexible Single Master Operation) в Active Directory встречается аж пять штук. Это:
- Schema Master
- Domain Naming Master
- Infrastructure Master
- RID Master
- PDC Emulator
Каждая из них сейчас будет рассмотрена подробнее. Поехали!
Schema Master
В каждом лесу Active Directory есть не более одного хозяина схемы (Schema Master). Именно он отвечает за внесение изменений в раздел Schema, где находятся описания всех классов и атрибутов Active Directory.
Располагаться данная роль может на любом контроллере домена в пределах леса. Если вдруг ей случится оказаться на сервере с ОС Windows 2000, считайте, что вам повезло – вы сможете запретить ее изменение галочкой в настройках. В Windows 2003 эту галочку декомиссовали, т.к. польза от нее неизмерима.
Хорошая роль, простая и нужная.
Domain Naming Master
Следующая роль лесного уровня – хозяин именования доменов. Как понятно из определения “лесной”, этого товарища в лесу также не более одного.
Domain Naming Master отвечает за операции, связанные с именами доменов Active Directory. Но не только. Зон ответственности у него четыре:
- Добавление и удаление доменов в пределах леса
- Создание и удаление разделов (application directory partitions)
- Создание и удаление перекрестных ссылок (crossRef)
- Одобрение переименования домена
Пройдемся по каждой чуть подробнее.
Добавление и удаление доменов
Добавлять и удалять домены позволяется только контроллеру с ролью Domain Naming Master. Этот контроллер бдительно следит, чтобы добавляемый домен имел уникальное в пределах леса NETBIOS-имя. Если Naming Master недоступен, на попытках изменить число доменов в лесу можно ставить крест.
Нужно отметить, что проверять уникальность FQDN-имени нового домена на специально отведенном контроллере смысла нет, проще запросить информацию из DNS.
Создание и удаление разделов
В Windows 2003 появилась возможность создавать обособленные разделы, или, как их еще называют, партиции. Партиции используются для хранения в AD произвольных данных. Самый яркий пример использования партиций – хранение данных для DNS-серверов в партициях ForestDnsZones и DomainDnsZones.
Стоит ли говорить, что управление партициями при недоступном DNM невозможно? Хотя… Да, возможен вариант, когда доступный Domain Naming Master хостится на сервере с ОС Windows 2000, тогда о партициях речи тоже не будет.
Создание и удаление перекрестных ссылок
Перекрестные ссылки используются для поиска по каталогу в том случае, если сервер, к которому подключен клиент, не содержит нужной копии каталога; причем ссылаться можно даже на домены вне леса, при условии их доступности. Хранятся перекрестные ссылки (объекты класса crossRef) в контейнере Partitions раздела Configuration, и только Domain Naming Master имеет право в этом контейнере хозяйничать. Понятно, что читать содержимое контейнера может любой контроллер, благо раздел Configuration один для всего леса, но вот изменять его содержимое может лишь один.
Очевидно, что недоступность контроллера с ролью Domain Naming Master опечалит администратора, желающего создать новую перекрестную ссылку, или удалить ненужную.
Одобрение переименования домена
В процессе переименования домена основная утилита этого действа (rendom.exe) составляет скрипт с инструкциями, которые должны будут выполниться в процессе переименования. Все инструкции проверяются, после чего скрипт помещается в атрибут msDS-UpdateScript контейнера Partitions раздела Configuration. Помимо этого, значения атрибута msDS-DnsRootAlias для каждого объекта класса crossRef устанавливаются в соответствии с новой моделью именования доменов. Поскольку право менять содержимое crossRefContainer есть только у контроллера с ролью Domain Naming Master, то очевидно, что проверку инструкций и запись атрибутов выполняет именно он.
Если при проверке скрипта обнаружатся ошибки, или новый лес окажется некошерным, или выявятся пересечения имен между доменами старого и нового лесов, весь процесс переименования будет остановлен.
Пожалуй, Domain Naming Master – единственная роль, без которой можно безболезненно жить годами. Но, разумеется, лучше, когда всё работает.
Infrastructure Master
В случаях, когда наш домен содержит ссылки на объекты из других доменов или лесов, возможны разные интересные ситуации. Например, переименование объекта, или перенос объекта в другой OU в пределах домена, или перенос объекта в другой домен. В первых двух случаях меняется DN, в третьем – DN и SID. В результате таких изменений найти объект по нашей ссылке станет невозможно. Последствия навскидку – устаревание информации в адресной книге, отказ внешнему пользователю в доступе к ресурсам нашего домена, и так далее. Infrastructure Master как раз и предназначен для разгребания таких интересных ситуаций.
Дело в том, что в Active Directory есть три основных атрибута уникальности объекта – GUID, SID (у Security Principal’ов), и distinguished name (DN). Сервер с ролью IM отвечает за обновление так называемых “фантомных записей” (Phantom Records), содержащих GUID, SID и DN не-местных объектов. Он старательно проверяет, не изменилось ли чего важного, и при необходимости обновляет информацию в своем домене. Проверка заключается в поиске объектов неродного домена по GUID – как по единственному категорически неизменному атрибуту.
Причем, совершенно неважно, идет речь о разных доменах одного леса, или о разных лесах. Возможна ситуация, когда домен в лесу один, но он имеет доверительные отношения с другим доменом. Здесь тоже найдется работа для хозяина инфраструктуры.
Роль IM отслеживает изменения в текущем лесу. Доверие между доменами других лесов и сопутствующие объекты – не его зона ответственности.
RID Master
В жизни каждого домена возникает момент, когда создается первая учетная запись. У кого-то такая потребность возникает сразу, кто-то приходит к ней со временем. Но рано или поздно учетные записи возникают абсолютно в любом домене. И у каждой учетной записи (пользователя, компьютера, группы, TDO) должен быть уникальный идентификатор безопасности (SID) – он будет служить великой задаче разграничения доступа. Поэтому было бы неплохо понять, как формируется данный идентификатор, и при чем тут RID Master.
Воспользуемся тайным знанием Майкрософт. Любой доменный идентификатор безопасности состоит из нескольких частей.
SID: S-1-5-Y1-Y2-Y3-Y4. Здесь:
| элемент SID | Описание |
|---|---|
| S-1 | SID ревизии 1. В настоящее время используется только эта ревизия. |
| 5 | Обозначает, кем был выдан SID. 5 означает NT Authority. Однако, так называемые well-known SIDs могут в данной части иметь 0, 1, и некоторые другие значения для обозначения своей “well-known’ости”. |
| Y1-Y2-Y3 | Идентификатор домена, к которому относится учетная запись. Одинаковый для всех объектов security principal в пределах данного домена. |
| Y4 | Относительный идентификатор (Relative ID, RID), относящийся к конкретной учетной записи. Подставляется из пула отностительных идентификаторов (RID Pool) домена в момент создания учетной записи. |
Так вот. Контроллер домена с ролью RID Master отвечает за выделение последовательности уникальных RID’ов каждому контроллеру домена в своем домене, а также за корректность перемещения объектов из одного домена в другой. У контроллеров домена есть общий пул относительных идентификаторов, из которого каждому контроллеру выделяется пачка “примерно” по 500 штук. Когда число выделенных контроллеру RID’ов подходит к концу (становится меньше 100), он запрашивает новую пачку. Разумеется, число выдаваемых RID и порог запроса можно при желании менять.
В действительности же всё не совсем так, как на самом деле 🙂 Выдаются не сами идентификаторы, а ссылки на них. Для каждого контроллера домена – своя ссылка, которая, к тому же, хранится в его собственном контейнере. Поэтому, если мы вдруг удаляем контроллер домена из Active Directory вручную, может возникнуть нехорошая ситуация, когда при создании учетных записей (пользователя, компьютера, группы, TDO) будут использоваться уже выданные RID, что, в свою очередь, приведет к увлекательнейшему траблшутингу.
Не будем забывать и про перемещение объектов между доменами. Именно RID Master следит за тем, чтобы в каждый момент времени каждый объект перемещался только в один домен. Иначе возможна крайне нездоровая ситуация, когда в двух доменах будет два объекта с одинаковым GUID. Траблшутинг подобной ситуации грозит быть не менее увлекательным, чем ловля дублирующихся SID.
Если RID Master не будет доступен, то после истощения запаса свободных RID создать новую учетную запись (пользователя, компьютера, группы, TDO*) станет невозможно. А заодно не удастся провести миграцию объектов из текущего домена в другой.
—
* TDO – Trusted Domain Object. Создаётся при настройке доверительных отношений.
