Domain naming master – Хозяин именования доменов

Fsmo-роль хозяин именования доменов (Domain naming master) является второй ролью уровня леса (наравне с хозяином схемы), то есть в каждом конкретном лесе Active Directory должен существовать лишь один контроллер домена – владелец роли.

---

Основная статья по Active Directory – Active Directory Domain Services. Читайте также другие статьи по ролям хозяев операций – FSMO — Fexible Single Master Operations.

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

---

Domain naming master – Хозяин именования доменов

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

Теория

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

1) Добавление или удаление доменов. Domain naming master отвечает за уникальность имен каждого домена в лесу и не позволяет добавить домены с дублирующими именами. Все операции, связанные с изменениями именования доменов, должны получить подтверждение у владельца этой роли fsmo. Разумеется если хозяин роли по каким-либо причинам недоступен, вы не сможете добавить/удалить/изменить имя домена.

2) Добавление или удаление разделов каталогов приложений. Для начала стоит немного рассказать о разделах каталогов приложений – это специальные разделы, которые могут быть созданы на контроллерах домена (версии 2003 и выше, в 2000 – только данные конфигурации и схемы) для хранения динамических данных в ldap-хранилище. Данные в этих разделах также реплицируются на все контроллеры домена, обеспечивая таким образом повышенный уровень сохранности и доступности. Разделы приложений например использует служба DNS (именно поэтому она называется Active Directory-Integrated DNS) – при установке она создает два раздела на уровне ниже корневого домена леса в иерархии доменов. Один раздел для леса (ForestDnsZones) и один для домена (DomainDnsZones). Вы можете увидеть эти зоны в оснастке DNS:

Использование раздела каталога приложений службами DNS дает массу преимуществ как в плане скорости и надежности репликации, так и безопасности. К тому же добавляется и некоторый новый функционал. Подробнее о интегрированных в AD службах DNS читайте в официальной документации ^{2 3}. Напоминаю, что использовать преимущества AD-Integrated DNS вы сможете только если все DC обновлены до версии 2003 ⁴:

Windows Server 2003 DNS Active Directory stores zone data in application directory partitions. The domain partition was the only Active Directory storage option in Windows 2000 Server, and it is available in Windows Server 2003 DNS for backward compatibility. The following DNS-specific application directory partitions are created during Active Directory installation:
– A forest-wide application directory partition, called ForestDnsZones.
– Domain-wide application directory partitions for each domain in the forest, named DomainDnsZones.

Просмотреть текущие разделы каталогов можно с помощью утилиты ntdsutil ⁵:

Подробнее о принципе работы разделов каталогов приложений и их администрировании читайте на Technet ⁶. Как было сказано выше, функционал разделов каталогов приложений в версии Windows Server 2000 отсутствует.

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

3) Добавление или удаление перекрестных ссылок объектов к или от внешних каталогов. Перекрестные ссылки необходимы для того, чтобы каждый контроллер домена имел представление о всех разделах директорий в лесу, а не только о тех, которые он поддерживает. Перекрестные ссылки имеют формат записи crossRef и хранятся в разделе Configuration, который распространяется на все DC в домене.

Перекрестные ссылки бывают двух типов – внутренние и внешние. Внутренние ссылки создаются автоматически системой. Например во время создания нового леса, мастер создает три раздела каталогов – первичный раздел каталога домена, раздел каталога конфигурации, раздел каталога схемы. Для каждого раздела каталога автоматически создаются перекрестные ссылки и располагаются они в контейнере CN=Partitions,CN=Configuration,DC=corp,DC=bissquit,DC=com на примере моего домена – corp.bissquit.com (или контейнера CN=partitions,CN=configuration,DC=ForestRootDomain для общего случая, где CN – общее имя, OU – раздел, DC – класс объекта домена). Похожие разделы каталогов создаются и при добавлении нового домена к существующему лесу.

Внешние перекрестные ссылки создаются вручную администраторами при необходимости явным образом объявить расположения объектов, которые находятся вне леса AD. Создать перекрестные ссылки можно с помощью оснастки adsiedit.msc, подробнее читайте в документации ⁷.

4) Контроль и подтверждение инструкций на переименование доменов. Поскольку присутствует возможность переименования существующих доменов AD, этот процесс также должен жестко контролироваться и функцию контроля как раз выполняет хозяин именования доменов.  Сам процесс переименования условно делится на два этапа – подготовка к переименованию и сам по себе факт смены имени (все задачи выполняются с помощью утилиты rendom.exe). На первом этапе происходит генерация XML-скрипта, содержание которого записывается в атрибут msDS-UpdateScript контейнера CN=Partitions,CN=Configuration,DC=corp,DC=bissquit,DC=com на примере моего домена (или контейнера CN=partitions,CN=configuration,DC=ForestRootDomain для общего случая). Этот контейнер может быть обновлен только хозяином именования доменов.

После этого новые имена каждого переименованного домена записываются в атрибут msDS-DnsRootAlias перекрестных ссылок объектов, относящихся к этим доменам. Если бы я хотел переименовать свой домен corp.bissquit.com, то этот атрибут находился бы в CN=CORP,CN=Partitions,CN=Configuration,DC=corp,DC=bissquit,DC=com:

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

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

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

1) Перед любыми изменениями имен доменов, перекрестных ссылок, разделов каталогов приложений всегда делайте резервное копирование. Перед началом выполнения этих задач вы можете отключать все контроллеры домена, которые за эту роль не отвечают. После этого делаете резервную копию оставшегося контроллера домена, выполняете все необходимы изменения и если все прошло удачно, то просто включаете заглушенные ранее DC. Если же что-то пошло не так, просто поднимаете единственный работающий на это время контроллер из резервной копии, включаете остальные и далее исследуете проблему;

2) Рекомендуется держать роли хозяина именования доменов и хозяина схемы на одном и том же контроллере домена ^{9 10}:

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

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

3) Если вы по каким-либо причинам лишились сервера-хозяина именования доменов, то на любом другом контроллере домена вы можете принудительно захватить эту роль, но помните, что после этого изначальный хозяин роли не должен появиться в сети.

4) В действительности в нормально работающем окружении не существует задач (или мне они не известны), при которых потребовалось бы вручную вносить изменения в перекрестные ссылки или в разделы каталогов приложений. В любом случае не делайте этого. Если все же хотите рискнуть, см. пункт 1;

5) Процесс переименования существующих доменов хоть и полностью поддерживается, но является достаточно нетривиально задачей, требующей немало времени на подготовку ¹¹ и тестирование. Выполните эти задачи на изолированной среде и обязательно проверьте работоспособность доменнозависимых сервисов (например Exchange). В любом случае залогом отсутствия проблем с подобными задачами является изначально правильный подход к планированию именования доменов AD, подробнее об этом читайте в моей общей статье Active Directory Domain Services и непосредственно в Пара слов про именование доменов Active Directory.

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

Как и было сказано выше, все операции по управлению именами доменов выполняются в утилите командной строки rendom.exe. Пример работы программы ниже:

Некоторые задачи администрирования выполняются через оснастку Active Directory – домены и доверие. Например переносить роль с одного контроллера домена на другой нужно именно через эту оснастку. Допустим у вас два контроллера домена и вы хотите перенести роль хозяина схемы с DC01 на DC02:

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

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

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