Управление ролями FSMO при помощи Ntdsutil. Управление ролями FSMO при помощи Ntdsutil Seize domain naming master неправильный синтаксис

Иногда администратору домена Active Directory нужно быстро узнать на каких контроллерах в текущий момент находятся роли FSMO – Flexible Single-Master Operation , то есть кто из них является так называемым хозяином или владельцем определенной операции. Самый быстрый способ определения – это использование встроенной команды Netdom .

Просмотр ролей FSMO командой Netdom

Запустите cmd и выполните следующую команду:

netdom query fsmo

Она выводит роли владельцев операций для текущего домена. Если нужно посмотреть FSMO роли для другого домена, то нужно использовать ключ domain :

netdom query fsmo /domain:имя домена

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

• Schema master – роль хозяина схемы. Через GUI ее можно увидеть в оснастке Active Directory Schema.
• Domain naming master – роль хозяина доменных имен. Через GUI ее можно найти в оснастке Active Directory Domains and Trusts.

И три роли уникальны для каждого домена:

• RID pool manager – роль хозяина пула RID (относительных идентификаторов).
• PDC Emulator – роль эмулятора PDC (основного контроллера домена).
• Infrastructure master – роль владельца инфраструктуры.

Через графический интерфейс эти роли можно проверить в оснастке Active Directory Users and Computers.

Подробнее про Flexible Single-Master Operation можно узнать

Управление ролями 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 .