Доменные службы 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. Цель нашего мероприятия передать FSMO с одного контроллера домена на другой. На всякий случай я рассмотрю несколько способов переноса ролей, в том числе и случай, когда действующий хозяин FSMO недоступен.

Сначала немного теории:
FSMO (Flexible single-master operations - «операции с одним исполнителем»)- типы выполняемых контроллерами домена Active Directory операций, требующие обязательной уникальности сервера их выполняющего.

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

Всего корпорацией мелкомягких нам дано 5 ролей:

• Владелец схемы (Schema master) - один сервер с этой ролью на весь лес. Роль нужна для расширения схемы леса Active Directory, обычно эта операция выполняется командой adprep /forestprep
• Владелец доменных имён (Domain naming master) - один на весь лес. Сервер с данной ролью должен обеспечить уникальность имен для всех создаваемых доменов и разделов приложений в лесу AD.
• Владелец относительных идентификаторов (PDC emulator) - один сервер на каждый домен. Выполняет несколько функций: является основным обозревателем в сети Windows, отслеживает блокировки пользователей при неправильно введенном пароле, являетсяглавным NTP сервером в домене, предназначен для поддержки клиентов с ОС предшествующим Windows 2000.
• Эмулятор основного контроллера домена (Infrastructure Master) - один сервер на каждый домен. Сервер с такой ролью нужен для успешного выполнения команды adprep /domainprep. Отвечает за обновление идентификаторов защиты (GUID, SID)и различающихся имен объектов в междоменных объектных ссылках.
• Владелец инфраструктуры домена (RID Master) - один сервер на каждый домен. Сервер раздает другим контроллерам домена идентификаторы RID (по 500 штук) для создания уникальных SID.

Для управления ролью Schema master необходимо быть в группе «Schema admins».
Для управления ролью Domain naming master необходимо состоять в группе «Enterprise admins».
Для управления ролями PDC emulator, Infrastructure Master и RID Master необходимо иметь права администратора домена «Domain Admins»

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

При создании домена, по умолчанию все роли назначаются первому контроллеру домена в лесу. Переназначение ролей требуется крайне редко. Microsoft рекомендует использовать передачу ролей FSMO в следующих случаях:

• Плановое понижение роли контроллера домена, являющегося обладателем ролей FSMO, например с целью вывода сервера из эксплуатации (это как раз мой случай);
• Временное отключение контроллера домена, например для выполнения профилактических работ. Это особенно важно при отключении эмулятора PDC. Временное отключение остальных хозяев операций в меньшей степени сказывается на работе AD.

Захват ролей FSMO придется осуществлять в следующих случаях:

• Если в работе текущего обладателя роли FSMO возникли сбои, препятствующие успешному выполнению функций, присущих данной роли, и не дающие выполнить передачу роли;
• На контролере домена, являвшемся обладателем роли FSMO, переустановлена или не загружается операционная система;
• Роль контроллера домена, являвшегося обладателем роли FSMO, была принудительно понижена с помощью команды dcpromo /forceremoval.

Итак первое что нам понадобится это узнать какой сервер является хозяином FSMO. Проще всего это сделать с помощью утилиты netdom. Набрав в консоли:

> netdom query fsmo

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

Теперь можно приступить непосредственно к переносу FSMO:

Способ первый, самй простой и мне он наиболее симпатичен - передача ролей FSMO с помощью утилиты ntdsutil:

ntdsutil.exe – утилита командной строки, предназначенная для обслуживания каталога Active Directory. Она предоставляет много возможностей по управлению AD, в числе которых передача и захват ролей FSMO.
Для передачи ролей заходим на любой контролер домена (Это не обязательно должен быть текущий или будующий хозяин FSMO), расположенный в том лесу, в котором следует выполнить передачу ролей. Рекомендуется войти в систему на контроллере домена, которому назначаются роли FSMO. Запускаем консоль и вводим:
>ntdsutil
После чего утилита запускается в интерактивном режиме и может принимать команды. Первая наша команда указывает на то что мы хотим работать с FSMO
>roles
В ответ приглашение изменится на fsmo maintenance: Затем для вызова «меню» подключения вводим
>connections
И приглашение меняется на server connections: Теперь можно указать к какому серверу мы хотм подключиться (<Имя_сервера> - имя контроллера домена, на который вы хотите перенести роль FSMO.)
>connect to server <Имя_сервера>
для выхода из меню подключения введите
>q
и нажмите Enter. Теперь, получив опять приглашение fsmo maintenance: мы можем приступить к переносу ролей. Для этого предназначена команда transfer:
>transfer <имя_роли>
В качестве <имя_роли> нужно указать ту роль которую вы хотите перенести:

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

В версиях Windows предшествующих Windows Server 2008R2 хозяин доменных имен называется domain naming master. Как это принято в Windows системах регистр не имеет значения.

После ввода каждой команды transfer появляется диалоговое окно с запросом подтверждения (могли бы и в консоли подтверждение спрашивать а то «недоконсольно» как то получается), нажимаем каждый раз «OK», если конечно вы не набрали все предидущие команды случайно. :)
Для завершения работы Ntdsutil вводим команду q и нажимаем Enter.

Принудительное назначение ролей fsmo при помощи Ntdsutil

А что же нам делать, если хозяин роли недоступен, поврежден и нет надежды вернуть его в строй в ближайшее время? И тут нам снова поможет ntdsutil.exe:
Принудительное назначение (захват) ролей производятся только в случае полного выхода из строя сервера, с невозможностью его восстановления. Если возможно, лучше восстановить работоспособность вышедшего из строя хозяина FSMO. Сама процедура захвата похоже на описанную выше. Заходим на контроллер домена, которому хотим передать роли и проделываем то же что было писано в предидущем пункте введя:
>ntdsutil
>roles
>connections
>connect to server <имя_сервера>
>q
Единственно различие, вместо команды transfer для принудительного захвата роли используется команда seize
>seize <имя_роли>
Где <имя_роли> как и прежде

• naming master - хозяин доменных имен (до Windows Server 2008R2 - domain naming master);
• infrastructure master - хозяин инфраструктуры;
• rid master - хозяин RID;
• schema master - хозяин схемы;
• pdc - эмулятор PDC.

Не забудьте перед захватом роли попробовать передать роль с помощью команды transfer и только в случае неудачи применяйте seize.

По возможности не назначайте роль Infrastructure Master контроллеру домена, являющемуся сервером глобального каталога, поскольку в этом случае он не будет обновлять сведения об объектах. Причина такого поведения заключается в том, что сервер глобального каталога хранит частичные реплики всех объектов в лесу.

Ни в коем случае не возвращайте «в строй» контроллер домена ранее исполнявший роли FSMO в случае если исполняемые им роли были захвачены командой seize т.к. при его появлении в сети возникнет конфликт, что может вызвать привести к большим неприятностям. Его необходимо удалить из Active Directory. В Windows Server 2008 и старше это можно сделать, просто удалив объект сервера в оснастке Active Directory Пользователи и компьютеры, а в Windows Server 2003 с помощью программы Ntdsutil , используя команду ntdsutil - metadata cleanup.

Второй вариант - Добровольная передача ролей FSMO с помощью оснасток управления Active Directory, странный и неудобный, но это лишь моё субъективное мнение, сам способ прекрасно работает.

Передать роли уровня домена (RID Master, PDC Emulator и Infrastructure Master) можно с помощю оснастки Active Directory Пользователи и компьютеры (Users and Computers). Для этого заходим на контроллер домена, которому хотим передать роли, запускаем оснастку и щелкнув правой клавишей мыши на нужном домене, выбираем пункт «Хозяева операций».

В открывшемся окне выбираем нужную нам роль и нажимаем кнопку «Изменить», Далее подтверждаем перенос роли и смотрим на результат. Имя хозяина операий должно поменятся на имя текущего сервера.

Для переноса роли Domain Naming Master потребуется оснастка Active Directory Домены и доверие (Domains and Trust). Запускаем оснастку, при необходимости подключаемся к нужному контроллеру домена, щелкаем правой клавишей мыши в корне оснастки и выбираем пункт меню «Хозяин операций».

Открывается окно, в котором надо нажать кнопку «Изменить», а затем подтвердить изменения так же, как и в предыдущем случае.

Для передачи роли Schema Master придется проделать несколько более сложные манипуляции. Сначало необходимо зарегистрировать в системе библиотеку управления схемой Active Directory. Сделать это можно командой
> regsvr32 schmmgmt.dll

Затем открываем консоль MMC и добавляем в нее оснастку Схема Active Directory.

Теперь можно зайти в оснастку и сменить хозяина роли Schema Master как и в предидущих примерах кликнув правой клавишей мыши по схеме и выбрав пункт «Хозяин операций...».

Ура! Все роли переданы. И ещё раз: никогда не оставляйте ваш домен без назначенных хозяев ролей FSMO. Никогда! :)

• Назад

Комментарии

Новые статьи:

• Не включается сетевое обнаружение в Windows 7/8/2008/2012

  Суть проблемы - у пользователя в системе Windows 7 не включается сетевое обнаружение в настройках сети. Точнее включается, но если закрыть и...

• Ошибка: This application failed to start because it could not find or load the Qt platform plugin «windows».

  Итак, после установки путём прямого копирования приложения написанного на С++ с использованием библиотеки Qt Получаем следующую ошибку: This application failed to start...

hb860 25 ноября 2011 в 14:02

Все что вы хотели знать о мастерах операций, но боялись спросить

• Системное администрирование

Большинство системных администраторов в своей корпоративной среде для обеспечения системы идентификации и доступа своих пользователей к ресурсам предприятия используют доменные службы Active Directory, которые смело можно назвать сердцем всей инфраструктуры предприятия. Как многие из вас знают, структура доменных служб в организациях может включать в себя как один, так и несколько лесов (набор доменов, включающих описание сетевой конфигурации и единственный экземпляр каталога), в зависимости от таких факторов как ограничение области доверительных отношений, полное разделение сетевых данных, получение административной изоляции. В свою очередь, каждый большой лес для упрощения администрирования и репликации данных должен разделяться на домены. В каждом домене для управления доменными службами и выполнения таких задач как проверка подлинности, запуск службы «Центр распределения ключей Kerberos» и управления доступом используются контроллеры домена. А для управления сетевым трафиком между офисами разрабатываются сайты.
Вся информация о лесах, доменах и сайтах, естественно, должна быть согласована ещё при проектировании доменных служб Active Directory, согласно таким корпоративным требованиям как: бизнес-требованиям, функциональным требованиям, юридическим, требованиям по безопасности, а также проектным ограничениям к документации. Зачастую все эти моменты перед развёртыванием доменных служб тщательно планируются ИТ-подразделением самой компании или проектной группой, занимающейся инфраструктурой предприятия и записываются в специальное соглашение об уровне услуг, определяющее ожидаемый уровень быстродействия и качество предоставляемой услуги.
Полученная информация после проектирования или, чаще всего, уже после развёртывания доменных служб Active Directory должна быть тщательно задокументирована. В такую документацию должна входить информация о самой логической и физической структуре доменных служб, об административных моделях, инфраструктуре разрешения имён, обо всех планируемых изменениях в среде организации, а также о таких дополнительных компонентах инфраструктуры, как внедрение почтовых серверов Microsoft Exchange, серверов System Center и многое другое. В большинстве случаев, ИТ-персонал организации игнорирует процесс документирования и при смене ИТ-персонала у новых администраторов может уйти какое-то время на то, чтобы полностью сориентироваться с текущей инфраструктурой организации.
Также нужно понимать, что в службе каталогов практически все контроллеры доменов являются равноправными (в данном контексте мы не берём во внимание контроллеры домена только для чтения, RODC), то есть все контроллеры домена обладают правом записи в базу данных и могут реплицировать эти данные на другие контроллеры. Такая топология отлично справляется с большинством тривиальных операций Active Directory и называется репликацией с множеством равноправных участников (Multimaster). Но, все-таки, существуют некоторые операции, которые обязательно должны выполняться на отведённом непосредственно для таких операций уполномоченном сервере. Другими словами, контроллеры домена, выполняющие в своём домене определённые операции или роли, называются мастерами (или хозяевами) операций. Знать и понимать назначение всех ролей мастеров операций необходимо, так как в случае аварийного восстановления, обновления или миграции именно контроллеры домена, выполняющие роли мастеров операций, могут сыграть одну из важнейших ролей. Соответственно, именно о мастерах операций и пойдёт речь в данной статье.
Из этой статьи вы узнаете:

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

Что не будет рассматриваться в рамках текущей статьи:

• Планирование и документирование контроллеров доменов, обладающих ролями мастеров операций . Это отдельная тема, которая включает в себя понимание нюансов планирования доменных служб Active Directory и выходит за рамки этой статьи;
• Серверы глобального каталога . Многие системные администраторы приравнивают серверы глобального каталога к ролям мастеров операций. На самом деле, это ложное суждение. Глобальным каталогом называется репозиторий распределённых данных, который хранит информацию о каждом объекте, а также позволяет пользователям и приложениям находить объекты в любом домене текущего леса посредством поиска атрибутов, включённых в глобальный каталог, которые идентифицируются в схеме в качестве частного набора атрибутов. Сам глобальный каталог располагается на контроллерах доменов, назначенных в качестве серверов глобального каталога и, в свою очередь, реплицируется посредством репликации Multimaster. Несмотря на то, что глобальный каталог содержит полный список всех объектов леса, и серверы глобального каталога могут отвечать на все запросы без необходимости ссылки на другие контроллеры доменов, глобальный каталог не является ролью мастеров операций. О серверах глобального каталога вы можете почитать следующую статью: «Серверы глобальных каталогов» ;
• Взаимодействие мастеров операций с контроллерами домена только для чтения . Контроллеры домена только для чтения (Read Only Domain Controller) представляют собой особый, относительно новый тип контроллеров домена, которые целесообразно развёртывать в филиалах организации, не обеспеченных достаточным уровнем безопасности и квалифицированным ИТ-персоналом. Также как и в случае с планированием мастеров операций и серверами глобального каталога, контроллеры домена только для чтения представляют собой отдельную обширную тему, которую захватывать в данной статье нет никакого смысла. Но сразу стоит обратить внимание на то, что контроллеры домена только для чтения не могут выступать в качестве контроллера домена с ролью мастера операций;
• Решение проблем и ошибки, связанные с мастерами операций . Интересная и довольно объёмная тема, которая не будет рассмотрена, ввиду того, что в текущей статье рассматриваются общие понятия ролей мастеров операций.

Что было бы, если бы не существовало мастеров операций

Перед тем как представить себе ситуацию с контроллерами доменов Active Directory, на которых не было бы разграничений на контроллеры домена, выполняющие специфические операции и на остальные контроллеры домена, рассмотрим преимущества контроллеров домена, оснащённых ролями мастеров операции.
Прежде всего, как уже было указано во вводном разделе данной статьи, мастерами операций называются контроллеры домена, выполняющие в Active Directory особую роль, предназначенную для гарантии целостности и исключения конфликтов. Именно для этой цели на такие контроллеры доменов назначается специальная роль, и ввиду того, что у таких ролей нет жёсткой привязки к одному контроллеру домена, такие роли называются мастерами операций (Flexible Single Master Operation, FSMO, что произносится как fizz-mo). По сути, эти роли могут выполнять и другие контроллеры домена, но назначаться каждая роль должна лишь одному контроллеру домена, причём, в одном домене одновременно не могут выполняться действия, которые должны выполняться на контроллерах доменов мастеров операций.
Думаю, будет полезно узнать, какие протоколы используют мастера операций. Мастера операций используют три протокола:

• Облегчённый протокол доступа к каталогам (Lightweight Directory Access Protocol, LDAP);
• SMTP.

Теперь на минуту представим себе, что было бы, если бы в доменных службах Active Directory не существовало мастеров операций, то есть, если бы все контроллеры домена могли одновременно выполнять одинаковые действия.
Предположим, есть организация с одним лесом и пятью доменами. В каждом из доменов системные администраторы решили одновременно установить почтовый сервер Microsoft Exchange, причём, в одном домене администратор устанавливает 2007 версию данного почтового сервера, во втором – 2000, а в третьем Microsoft Exchange Server 2010 SP1. Все изменения в схеме домена и, соответственно, всего леса записываются на контроллер домена, к которому были подключены администраторы, а через какое-то время все изменения, внесённые в схему Active Directory, реплицируются на каждый контроллер домена в лесу организации.
Если кто-то захочет переименовать свой домен при помощи системной утилиты Rendom.exe так, как уже назван другой домен, а соответствующей роли FSMO не будет на предприятии, при обращении к которой администратор увидел бы предупреждающее сообщение, мол, «Что же ты делаешь-то? Такой домен ведь уже есть, хочешь сломать все на свете?» и домен будет переименован, после репликации просто невозможно было бы избежать фатальных проблем.
Возьмём ещё один пример… Опять же, в природе не существует мастеров операций. На клиентских машинах может сбиваться время, пользователи могут сами как бы невзначай изменять своё время, но все клиенты в домене по умолчанию должны синхронизировать время с ближайшими контроллерами домена. В этом случае, если нет определённого контроллера домена, так называемого ведущего источника времени, то время у каждого пользователя во всем домене может отличаться, что может быть критичным для некоторых бизнес-приложений.
Собственно, примеры корпоративного апокалипсиса в связи с отсутствием мастеров операций можно приводить бесконечно много. Суть одна, мастера операций просто обязаны быть, должны быть доступными и должны выполнять только те операции, которые им предназначены.
Всего доменные службы Active Directory включают в себя пять различных ролей мастеров операций, А именно, две роли используются на уровне леса: мастер именования доменов и мастер схемы , причём, в каждом лесу может быть не более одного контроллера домена, с назначениями каждой роли. В каждом домене предусмотрены только три роли мастеров операций: мастер относительного идентификатора RID , мастер инфраструктуры , а также эмулятор главного контроллера домена PDC . То есть, при установке самого первого контроллера домена в лесу, ему одновременно назначаются все пять ролей мастеров операций, а при создании нового домена Active Directory в существующем лесу, новому контроллеру домена присваиваются три роли уровня домена. FSMO в лесу и число потенциальных владельцев этих ролей можно рассчитать по формуле «(количество доменов * 3) + 2».
Например, если у вас есть лес Active Directory с четырьмя доменами, где есть дочерний и внучатый домен у одного из основных доменов, то такой лес будет содержать 14 ролей FSMO. То есть: одного мастера схемы, одного мастера именования доменов, четыре эмулятора PDC (для двух основных, дочернего и внучатого домена по одной роли), четыре хозяина RID для каждого домена, а также четыре мастера инфраструктуры для каждого домена.
На этом этапе, думаю, настало самое время рассмотреть каждую роль мастера операций уровня леса и уровня домена.

Роли мастеров операций уровня леса

Как я уже написал выше, для уровня леса Active Directory предусмотрены две роли мастеров операций, а именно:

• Мастер схемы;
• Мастер именования доменов

Роль мастера схемы

Перед тем как сказать несколько слов о роли мастера схемы, думаю, есть смысл, в двух словах рассказать, что же вообще такое «Схема Active Directory» .
– Видишь суслика?
- Нет.
- И я не вижу. А он есть!
К.Ф. «ДМБ»


Для многих начинающих администраторов, схему Active Directory можно проассоциировать с написанным выше выражением из известного кинофильма. Вроде бы, как и есть такая вещь как схема, но вот для чего она нужна, что она собой представляет, да и вообще, что это такое, никто не знает и не спешит об этом узнать.
Согласно терминологии, схема содержит определения каждого атрибута и класса, которые создаются и хранятся в лесу Active Directory. Думаю, вряд ли для кого-то окажется новостью, что доменные службы Active Directory хранят и в нужное время извлекают необходимую информацию многих корпоративных приложений. Это сделано для того, чтобы в случае необходимости, приложения обращались не к различным компонентам инфраструктуры предприятия, а к доменным службам Active Directory, информация о которых будет отреплицирована на все контроллеры домена. Стоит обратить внимание на то, что в каждом лесу Active Directory существует лишь одна схема, которая может реплицироваться на каждый контроллер домена в лесу. Поэтому, если нужно в организации развернуть несколько приложений, которые могут создать конфликты в схеме Active Directory, целесообразно развёртывать и поддерживать два отдельных леса.
Сама схема состоит из объектов classSchema и attributeSchema, которые запрашиваются при определении требуемого объекта в доменных службах. Сами классы представляют собой некие определения, расположенные в схеме, которые, в свою очередь, определяют группы атрибутов. Нужно помнить, что каждый класс может использовать множество атрибутов. И, в конце концов, для каждого атрибута, расположенного в доменных службах Active Directory, в схеме указывается тип данных в качестве синтаксиса самого атрибута. И, разумеется, значение каждого атрибута, включённого в экземпляр класса, должно соответствовать требованиям синтаксиса текущего атрибута.
Так как подробное рассмотрение схемы Active Directory выходит за рамки этой статьи, думаю, описанного выше определения более чем достаточно. Подробнее о схеме Active Directory будет рассказано в одной из следующих статей. Сейчас же рассмотрим, что собой представляет роль мастера схемы.
Контроллер домена, который является мастером схемы, отвечает за все изменения, которые вносятся в схему леса Active Directory. Нужно помнить, что контроллер домена, отвечающий за данную роль должен быть единственным во всем лесу, а все остальные контроллеры домена будут содержать лишь реплики схемы леса только для чтения. То есть, при внесении любых изменений в схему Active Directory вручную или при установке приложений, которые изменяют схему, администратору нужно выполнять изменения на контроллере домена, который управляет данной ролью. Для внесения изменений администратор должен подключиться к мастеру схемы и должен входить в группу безопасности «Администраторы схемы» . После обновления схемы она реплицируется с мастера схемы на все остальные контроллеры домена. При попытке модификации схемы не на контроллере домена, выполняющем роль мастера схемы, действие обычно завершается отказом и вам нужно после внесения изменений в схеме переслать их на контроллер домена с ролью мастера схемы. Соответственно, данная роль является критически важной, так как при попытке модификации схемы Active Directory с выведенным из строя мастером схемы, вы будете все время нарываться на ошибки. В свою очередь, располагаться роль мастера схемы может на любом назначенном для этой цели контроллере домена в лесу.
По умолчанию, роль мастера схемы присваивается первому контроллеру домена, который устанавливается в лесу и эту роль рекомендуется размещать вместе с ролью мастера именования доменов о которой будет рассказано ниже, на одном контроллере домена. Несмотря на рекомендации, вы можете в любое время переместить эту роль на любой контроллер домена при помощи оснастки «Схема Active Directory» или посредством утилиты командной строки Ntdsutil . О переносе ролей на другие контроллеры домена вы также узнаете в этой статье. Идентифицируется мастер схемы значением атрибута fSMORoleOwner корневого объекта раздела схемы.

Роль мастера именования доменов

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

• Добавление и удаление доменов . Во время выполнения такой операции как добавление или удаление дочернего домена средствами мастера установки Active Directory или утилиты командной строки, мастер установки обращается именно к мастеру именования доменов и запрашивает право на добавление или, соответственно, удаление последнего. Также мастер именования доменов отвечает за обеспечение того, чтобы домены в лесу владели уникальными NETBIOS-именами в пределах всего леса. Естественно, по вполне понятным причинам, в том случае, если мастер именования доменов будет недоступен, вы не сможете добавлять или удалять домены в лесу;
• Добавление и удаление перекрёстных ссылок . Как вы уже знаете, во время создания первого контроллера домена в лесу, в нем создаются разделы каталога схемы, конфигурации и домена. В это время, для каждого раздела каталогов в контейнере Partitions раздела конфигурации (CN=partitions,CN=configuration,DC=forestRootDomain) создаётся объект перекрёстных ссылок (класс crossRef). Объект перекрёстной ссылки определяет имя и расположение серверов, которые хранят каждый раздел каталога в лесу. При создании каждого последующего домена или раздела каталога приложений, инициируется создание объекта перекрёстных ссылок в контейнере Partitions.
• Добавление и удаление разделов каталогов приложений . Разделы каталогов приложений представляют собой специальные разделы, которые вы можете создавать на контроллерах домена Windows Server 2003, Windows Server 2008 или Windows Server 2008 R2 для обеспечения хранилища динамических данных приложений LDAP. Если у вас лес работает на уровне Windows Server 2000, то в таком лесу все недоменные данные ограничиваются конфигурацией и данными схемы, которые реплицируются на все контроллеры домена в лесу. В лесу Windows Server 2003/2008 и 2008R2 разделы каталога приложений обеспечивают хранение специфических данных приложений на контроллере домена, которые могут быть воспроизведены на любом контроллере домена в лесу.
• Подтверждение инструкций переименования доменов . Последнее, выполняемое мастером именования доменов действие, является подтверждением инструкций переименования доменов. Обычно домены принято переименовывать при помощи специальной утилиты командной строки. Так вот, при использовании утилиты Rendom.exe, которая предназначена для переименования доменов, для того чтобы переименовать домен, утилита должна иметь доступ к мастеру именования доменов. Помимо вышеперечисленных возможностей, мастер именования доменов также отвечает за подтверждение инструкций переименования доменов. При запуске указанного средства, на контроллере домена с ролью мастера именования доменов, в атрибут msDS-UpdateScript объекта контейнера Partitions (CN=partitions,CN=configuration,DC=forestRootDomain) раздела каталогов Configuration записывается XML-сценарий, содержащий инструкции переименования доменов. Стоит помнить, что контейнер Partitions можно обновлять только на контроллере домена, который содержит роль мастера именования доменов. В дополнение к значению атрибута msDS-UpdateScript, утилита Rendom.exe записывает новое DNS-имя каждого переименованного домена в атрибут msDS-DnsRootAlias объекта перекрёстной ссылки (класс crossRef), соответствующего этому домену. Опять же, поскольку объект перекрёстной ссылки хранится в контейнере Partitrions, данный объект может обновляться только на контроллере домена с ролью мастера именования доменов. Изменённые данные атрибутов msDS-UpdateScript и msDS-DnsRootAlias реплицируются на все контроллеры домена в лесу.

По умолчанию, роль мастера именования доменов получает первый контроллер домена в новом лесу, но вы в любой момент можете переместить данную роль при помощи оснастки «Active Directory – домены и доверие» или утилиты командной строки Ntdsutil.exe . Не стоит забывать о том, что рекомендуется располагать на одном контроллере домена роли мастера схемы и мастера именования доменов. Контроллер домена, которому присвоена роль мастера именования доменов, должен одновременно являться сервером глобального каталога. В противном случае некоторые операции могут завершиться неудачно. Идентифицируется мастер схемы значением атрибута fSMORoleOwner в контейнере Partitions.
Так же как и в случае с предыдущим мастером операций, если вы попробуете выполнить любую из приведённых выше операций при недоступном мастере операций, ваши действия завершаться ошибкой. Но так как все эти действия выполняются за продолжительный промежуток времени практически однократно, о том, что мастер именования доменов в непригодном состоянии, вы можете узнать в критически важный момент, поэтому периодически проверяйте доступность мастеров операций леса.

Роли мастеров операций уровня домена

В отличие от уровня леса, в каждом домене Active Directory предусмотрено три следующие роли мастеров операций:

• Мастер относительных идентификаторов RID
• Эмулятор главного контроллера домена PDC
• Мастер инфраструктуры

Рассмотрим подробно каждый из этих мастеров операций.

Мастер RID

Первым мастером операций для уровня домена, описанным в этой статье, будет мастер относительных идентификаторов (RID). Мастер RID используется для управления пулом идентификаторов RID с целью генерирования идентификаторов безопасности (SID) для таких принципалов безопасности как пользователи, группы и компьютеры, а также за перемещение объектов из одного домена в другой. Идентификатор SID принципала безопасности должен быть уникальным для всего домена, поэтому каждому принципалу безопасности присваивается уникальный идентификатор безопасности SID, который содержит идентификатор домена и относительный идентификатор RID, который является уникальным для каждого принципала безопасности. Во всех идентификаторах SID присутствуют четыре различных элемента. Например, согласно документации Microsoft, элементы идентификатора S1-5-Y1-Y2-Y3-Y4 предоставлены в следующей таблице:
Таблица 1. Структура элемента идентификатора

Так как принципалы безопасности может создавать любой контроллер домена, необходим механизм, гарантирующий уникальность SID-идентификаторов, генерируемых контроллером домена и поэтому мастер RID следит за тем, чтобы два контроллера домена не назначали одинаковые идентификаторы RID. Мастер RID присваивает блок относительных идентификаторов RID, которые называются пулом RID, каждому контроллеру в домене. Другими словами, мастер операций RID отвечает за поддержку пула относительных идентификаторов для использования контроллеров домена в домене и предоставления групп относительных идентификаторов для каждого контроллера домена. Когда к домену добавляется новый контроллер домена, мастер RID назначает этому контроллеру домена пул из 500 относительных запросов RID. Каждый раз, когда на контроллере домена создаётся новый принципал безопасности, для присвоения идентификатора новому объекту, контроллер домена назначает относительный идентификатор из своего пула. Когда число относительных идентификаторов RID в этом RID-пуле на любом контроллере домена опускается ниже 100, другими словами, приближается к нулевому рубежу, мастер RID выполняет запрос ещё одного блока RID. Выполнив запрос, мастер RID назначает контроллеру домена ещё один пул из 500 относительных идентификаторов RID.
Если говорить ещё точнее, то мастер RID не ведёт счёт номеров пула, а обслуживает высшее значение последнего выделенного диапазона. При получении нового запроса, увеличивается значение нового пула на единицу и 499 новых значений. После этого два значения отправляются запрашиваемому контроллеру домена для использования новых относительных идентификаторов RID. Если локальный пул RID контроллера домена пуст или мастер RID в течение некоторого времени недоступен, процесс создания учётных записей на некоторых контроллерах домена может прерваться и в журнале событий этого контроллера домена будет записано событие с кодом 16645. Этот код ошибки указывает на то, что присвоен максимальный идентификатор учётной записи из выделенных на контроллер домена и контроллер домена не смог получить новый пул идентификаторов от мастера RID. Таким же образом, при добавлении нового объекта в домен будет создано событие с кодом 16650, указывающее на то, что объект не может быть создан, так как служба каталогов не смогла выделить относительный идентификатор. Механизм запроса нового блока идентификаторов RID предназначен для предотвращения таких прерываний, поскольку запрос выполняется перед исчерпыванием всех доступных RID идентификаторов в пуле. Чтобы включить процесс создания учётных записей заново, нужно либо подключить к сети контроллер домена, который управляет ролью мастера RID, либо переместить эту роль ещё на один контроллер домена.
Также при процессе миграции объектов Active Directory между доменами, требуется наличие мастера RID, то есть, объект сможет мигрировать только в том случае, если в домене будет доступен мастер RID. Наличие активного текущего мастера операций предотвращает создание в разных доменах Active Directory двух объектов с идентичными идентификаторами. Во время осуществления миграции объектов из одного домена в другой, корпорация Microsoft рекомендует использовать утилиту Acrive Directory Migration Tool. По умолчанию, роль мастера RID получает первый контроллер домена, установленный в лесу. Вы можете в любое время переместить эту роль при помощи оснастки или средствами утилиты Ntdsutil.exe . Мастер RID идентифицируется значением атрибута fSMORoleOwner в объекте класса rIDManager в разделе Domain.

Эмулятор PDC

Контроллер домена с назначенным мастером операций эмулятор PDC (главный контроллер домена – Primary Domain Controller) выполняет функции основного контроллера домена для обеспечения обратной совместимости с операционными системами ниже Windows 2000. Во времена серверов-членов и клиентских компьютеров Windows NT 4.0, изменения в каталог могли вносить лишь главные контроллера домена PDC. Прежние инструменты, клиенты и утилиты, поддерживающие Windows NT 4.0, не рассчитаны на то, что все контроллеры домена Active Directory могут выполнять запись в каталог, и поэтому таким приложениям требуется подключение к PDC. Контроллер домена с ролью PDC-эмулятора регистрирует себя как главный контроллер домена PDC, специально для того, чтобы различные низкоуровневые приложения могли локализовать пишущий контроллер домена. Несмотря на то, что в наше время сервера и клиентские компьютеры с операционными системами ниже Windows 2000 встретить практически невозможно, эмулятор PDC все ещё остаётся важнейшей ролью мастеров операций. Помимо обратной совместимости с приложениями, работающими в среде Windows NT 4.0, эмулятор PDC выполняет следующие важные функции:

• Участие в репликации обновлений паролей домена . При изменении или сбросе пароля пользователя, контроллер домена, вносящий изменения, реплицирует это изменение на PDC-эмулятор посредством срочной репликации. Эта репликация гарантирует, что контроллеры домена быстро узнают изменённый пароль. В том случае, если пользователь пытается войти в систему сразу после изменения пароля, контроллер домена, отвечающий на этот запрос, может ещё не знать новый пароль. Перед тем как отклонить попытку входа, этот контроллер домена направляет запрос проверки подлинности на PDC-эмулятор, который проверяет корректность нового пароля и указывает контроллеру домена принять запрос входа. Это означает, что каждый раз при вводе пользователем неправильного пароля проверка подлинности направляется на PDC-эмулятор для получения окончательного заключения;
• Управление обновлениями групповой политики в домене . Как вы знаете, для управления большинства настройками в конфигурации компьютеров и пользователей вашей организации применяются групповые политики. В том случае, если объект групповой политики модифицируется на двух контроллерах домена приблизительно в одинаковое время, то впоследствии, могут возникать конфликты между двумя версиями, которые не разрешаются при репликации объектов групповых политик. Во избежание таких конфликтов, PDC-эмулятор действует следующим образом: при открытии объекта групповой политики, оснастка редактора управления групповой политики привязывается к контроллеру домена, выполняющего роль PDC и все изменения объектов GPO по умолчанию вносятся на PDC-эмулятор;
• Выполнение функции центрального браузера домена . Для обнаружения сетевых ресурсов клиенты используют Active Directory. При открытии окна «Сеть» в операционной системе отображается список рабочих групп и доменов. После того как пользователь откроет указанную рабочую группу или домен он сможет увидеть список компьютеров. Эти списки генерируются посредством службы браузера, и в каждом сетевом сегменте ведущий браузер создаёт список просмотра с рабочими группами, доменами и серверами данного сегмента. После чего центральный браузер объединяет списки всех ведущих браузеров для того, чтобы клиентские машины могли просмотреть весь список просмотра. Думаю, из всех функций эмулятора PDC у вас могут возникнуть вопросы, связанные непосредственно с центральным браузером домена, поэтому, данная тема будет подробно рассмотрена в отдельной статье;
• Обеспечение главного источника времени домена . Так как службы Active Directory, Kerberos, DFS-R и служба репликации файлов FRS используют штампы времени, во всех системах домена необходима синхронизация времени. PDC-эмулятор в корневом домене леса служит ведущим источником времени всего леса. Остальные контроллеры домена синхронизируют время с PDC-эмулятором, а клиентские компьютеры – со своими контроллерами доменов. Гарантию за соответствие времени несёт иерархическая служба синхронизации, которая реализована в службе Win32Time.

По умолчанию, роль мастера эмулятора PDC получает первый контроллер домена, установленный в лесу. Вы можете в любое время переместить эту роль при помощи оснастки «Active Directory – пользователи и компьютеры» или средствами утилиты Ntdsutil.exe . Мастер эмулятора PDC идентифицируется значением атрибута fSMORoleOwner в объекте класса rIDManager в корневом объекте раздела Domain.

Мастер инфраструктуры

В организациях, основанных на множестве доменов, объекты в одних доменах часто ссылаются на объекты в других. Мастер инфраструктуры подобен устройству, которое отслеживает членов группы из доменов. Мастер инфраструктуры отвечает за обновление ссылок «группа - пользователь» между доменами, тем самым обеспечивая отражение изменений имён объектов в информации о членствах в группах, локализованных в домене. Мастер инфраструктуры поддерживает обновляемый список таких ссылок, а затем реплицирует эту информацию на все контроллеры в домене. Следует знать, что во время добавления члена другого домена в группу целевого домена, к атрибуту member добавляется отличительное имя нового члена и если же контроллер домена члена такой группы недоступен, то в доменных службах создаётся объект-фантом, собственно, представляющий члена такой группы. Такой объект может содержать только SID члена, отличительное имя (DN), а также GUID объекта. В том случае, если мастер инфраструктуры недоступен, ссылки «группа - пользователь» между доменами не будут обновляться. Периодически мастер инфраструктуры сканирует учётные записи домена и проверяет членство в группах. Если учётная запись пользователя перемещается на новый домен, мастер инфраструктуры идентифицирует новый домен учётной записи пользователя и соответствующим образом обновляет группы.
Стоит обратить внимание на то, что роль мастера инфраструктуры не должна выполняться контроллером домена, который является сервером глобального каталога. В противном случае мастер инфраструктуры не будет обновлять сведения об объектах, так как он не содержит ссылок на объекты, которые не хранит. Это обусловливается тем, что сервер глобального каталога хранит частичные реплики всех объектов в лесу. В результате междоменные объектные ссылки в этом домене обновляться не будут, а в журнале событий данного контроллера домена появится соответствующее предупреждение. По умолчанию, роль мастера инфраструктуры получает первый контроллер домена, установленный в лесу. Вы можете в любое время переместить эту роль при помощи оснастки «Active Directory – пользователи и компьютеры» или средствами утилиты Ntdsutil.exe . Мастер инфраструктуры идентифицируется значением атрибута fSMORoleOwner в контейнере Infrastructure в разделе Domain.

Как можно определить, какой контроллер домена обладает ролью FSMO

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

Определение обладателей ролей мастеров операций средствами GUI

Прежде всего, нужно запомнить, что для идентификации мастеров операций в доменных службах Active Directory используются различные административные оснастки. Тяжелее всего идентифицировать мастера схемы. С него и начнём. Чтобы узнать, какой контроллер домена обладает ролью мастера схемы, выполните следующие действия:


Для идентификации остальных мастеров операций вам нужно выполнить существенно меньше действий. Чтобы найти, какой контроллер домена обладает правами мастера операций именования доменов, вам нужно:


А для идентификации оставшихся трёх ролей уровня домена вам нужно выполнить меньше всего действий. Другими словами, все оставшиеся роли мастеров операций можно найти в одном диалоговом окне. Для этого откройте оснастку «Active Directory – пользователи и компьютеры» , нажмите правой кнопкой мыши на своём домене и из контекстного меню выберите команду «Хозяева операций» . В отобразившемся диалоговом окне на соответствующих вкладках можно просмотреть имена контроллеров домена, которым назначены текущие роли. Диалоговое окно «Хозяева операций» можно посмотреть на следующей иллюстрации:

Рис. 4. Хозяева операций для уровня домена

Определение обладателей ролей мастеров операций средствами командной строки

Как и для большинства возможностей предоставляемых операционными системами Windows, вы можете определить всех обладателей ролей мастеров операций при помощи специальной утилиты командной строки. В доменных службах Active Directory для контроля определённых изменений используется утилита командной строки Ntdsutil . Для того чтобы просмотреть все контроллеры домена, оснащённые ролями мастеров операций при помощи этой утилиты, выполните следующие действия:


Также для просмотра FSMO-ролей вы можете воспользоваться утилитой Dcdiag с командой /test:Knowsofroleholders /v . Часть вывода данной команды вы можете увидеть ниже:

Рис. 6. Определение FSMO-ролей средствами утилиты Dcdiag

Захват и передача ролей мастеров операций

В Active Directory существуют такие понятия как передача и захват (также известный как отзыв) ролей мастеров операций. Прежде всего, следует узнать, что же это такое и какая у этих понятий разница.
Как уже было указано выше, изначально на первый контроллер домена в лесу устанавливаются все пять ролей мастеров операций. Обычно принято для повышения производительности и отказоустойчивости развёртывать в организации, в пределах одного домена несколько дополнительных контроллеров домена. И, соответственно, для того чтобы в будущем избежать конфликтов, рекомендуется сразу распределять роли мастеров операций на разные контроллеры доменов. Также, если вам нужно отключить контроллер домена, выполняющий роль мастера операций или вывести его из эксплуатации, вам следует перенести с него все FSMO-роли на другие контроллеры доменов.
В свою очередь, захват роли необходим в том случае, если контроллер домена, наделённый конкретными ролями мастеров операций, вышел из строя, и вы не успели вовремя перенести роли с этого DC. О рисках, которым вы можете подвергнуться в случае отказа контроллеров домена, обладающих ролями мастеров операций, рассказывалось немного ранее в данной статье. В этом случае у вас нет никакой возможности перенести FSMO-роль предпочтительным методом передачи ролей. Следовательно, приходится только захватывать маркёр операций посредством отзыва роли. Но стоит помнить, что захват роли является самым радикальным методом и выполнять его нужно только в том случае, когда обладатель ролей мастеров операций вышел из строя. Когда выполняется процесс захвата роли мастера операций, на существующем компьютере изменяется атрибут fsmoRoleOwner объекта, представляющий собой корневой каталог данных, без выполнения какой-либо синхронизации данных. Другие контроллеры домена, естественно, узнают о новом владельце роли FSMO по мере репликации произведённых изменений.
Рассмотрим процессы передачи и захвата ролей мастеров операций.
Для того чтобы передать FSMO-роль, выполните следующие действия:


Процесс захвата ролей мастеров операций немного сложнее передачи, так как для этого необходимо использовать утилиту Ntdsutil , о которой говорилось в предыдущем разделе. Для того чтобы захватить роль у вышедшего из строя контроллера домена, выполните следующие действия:

1. Откройте командную строку и в ней перейдите к утилите ntdsutil ;
2. Перейдите к управлению ролью NTDS, используя команду roles ;
3. Нужно установить подключение к контроллеру домену, который в будущем будет выполнять роль владельца мастера операций. Для этого выполните команду connections ;
4. В строке «server connections» введите connect to server и укажите требуемый контроллер домена;
5. Перейдите обратно к fsmo management , используя команду quit ;
6. Теперь в строке fsmo management укажите команду seize и нажмите на Enter ;
7. На этом, последнем, шаге вам нужно выбрать FSMO-роль, которая будет захвачена с неработающего контроллера домена.

Внимательный читатель может задаться следующим вопросом: а что же мне делать, если мёртвый контроллер домена удалось реанимировать и как мне вернуть на этот контроллер домена обратно владение захваченной ролью? Тут все относительно просто. Прежде всего, вам нужно знать, что если была отозвана роль эмулятора PDC или инфраструктуры, то вы сможете без особых проблем обратно передать роль мастера операций восстановленному контроллеру домена.
А вот в том случае, если захватывалась роль мастера схемы, именования доменов или относительных идентификаторов RID, то вам нужно будет выполнить следующие действия:

1. Физически отключить такой контроллер домена от сети;
2. Понизить роль контроллера домена до рядового сервера при помощи команды Dcpromo /forceremoval ;
3. Очистить метаданные для текущего контроллера домена. Чистить метаданные вы можете при помощи утилиты Ntdsutil с командой Metadata Cleanup ;
4. После удаления метаданных вам нужно подключить сервер к сети, присоединить к домену, а затем повысить сервер до контроллера домена;
5. На последнем шаге просто передайте роль этому контроллеру домена.

Размещение мастеров операций на контроллерах домена

В этом разделе я немного расскажу о рекомендациях по размещению всех ролей мастеров операций на контроллерах домена. Как таковых, таких рекомендаций не много, поэтому я постараюсь упростить данный раздел, как только можно.
Прежде всего, если у вас один лес, один домен и один контроллер домена, то все пять ролей мастеров операций будут размещены именно на этом контроллере домена, но в целях балансировки нагрузки рекомендуется передавать роли на другие контроллеры домена.
Основные рекомендации по размещению FSMO-ролей следующие:

• Размещайте роли мастера RID и PDC-эмулятора на одном контроллере домена . Совместное размещение этих ролей мастеров операций обусловлено соображениями балансировки нагрузки. Поскольку эти роли прямые партнёры по репликации, разместив эти роли на отдельных контроллерах домена, вам придётся для соответствующих двух систем устанавливать быстрое подключение и в Active Directory для них создавать явные объекты. Помимо этого, если у вас в организации присутствуют серверы, играющие роли резервных мастеров операций, на таких серверах эти роли также обязаны быть прямыми партнёрами;
• Размещайте роли мастеров схемы и именования доменов на одном контроллере домена . Как правило, роли мастера схемы и мастера именования доменов рекомендуется размещать на одном контроллере домена, который служит сервером глобального каталога. Роль мастера именования доменов, должна одновременно являться сервером глобального каталога, потому что при добавлении нового домена, мастер должен гарантировать, что в лесу нет объекта с тем же именем, что и у нового добавляемого домена. Если же контроллер домена с ролью мастера именования доменов не будет являться сервером глобального каталога, такие операции как создание внучатых доменов могут завершаться с ошибками. В связи с тем, что эти роли используются реже всего, вы должны проследить, чтобы контроллер домена, который ими управляет, был максимально защищён;
• Роль мастера инфраструктуры должна размещаться на контроллере домена, который не служит сервером глобального каталога . Обычно мастер инфраструктуры должен разворачиваться на контроллере домена, который не служит сервером глобального каталога, но имеет объект прямого подключения к одному из глобальных каталогов в лесу. Так как сервер глобального каталога хранит частичные реплики всех объектов в лесу, мастер инфраструктуры, размещённый на сервере глобального каталога, не будет выполнять обновления, потому что он не содержит ссылок на объекты, которые не хранит.

Руководствуясь этими тремя правилами, вы можете размещать мастера операций в своём лесу оптимальным образом.

Вместо заключения

Итак, данная статья подходит к концу. Из этой статьи вы узнали о том, что такое роли мастеров операций и для чего они нужны. Было рассмотрено несколько примеров, в которых описывалось, что бы происходило, если бы в доменных службах Active Directory не существовало мастеров операций и все контроллеры доменов были равноправными. Были подробно рассмотрены все пять FSMO-ролей, описаны методы идентификации ролей на контроллерах доменов. Также вы узнали о том, что такое передача и захват ролей мастеров операций и о том, как можно выполнить эти действия. Помимо этого вы познакомились с тремя правилами, которыми следует руководствоваться при выборе вариантов размещения мастеров операций на контроллерах домена в своей организации.

Передача и захват ролей FSMO

Определившись с назначением ролей FSMO рассмотрим варианты передачи ролей другому контроллеру домена, а также принудительное назначение, или «захват» роли в случае недоступности контроллера домена, который ее выполняет.

При создании домена, по умолчанию все роли назначаются первому контроллеру домена в лесу. Переназначение ролей требуется крайне редко. Microsoft рекомендует использовать передачу ролей FSMO в следующих случаях:

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

Захват ролей FSMO производится в следующих случаях:

Если в работе текущего обладателя роли FSMO возникли сбои, препятствующие успешному выполнению функций, присущих данной роли, и не дающие выполнить передачу роли;
На контролере домена, являвшемся обладателем роли FSMO , переустановлена или не загружается операционная система;
Роль контроллера домена, являвшегося обладателем роли FSMO , была принудительно понижена с помощью команды dcpromo /forceremoval .

Примечание. Начиная с Windows Server 2003 SP1 при выполнении команды dcpromo /forceremoval осуществляется проверка, имеет ли контроллер домена роль хозяина операций, является DNS-сервером или сервером глобального каталога. Для каждой из этих ролей будет получено уведомление с указаниями по выполнению соответствующих действий.

В том случае, если в домене два или более контроллеров, первым делом нам необходимо выяснить, кто является обладателем каждой из ролей FSMO . Это достаточно просто сделать с помощью команды netdom query fsmo

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

Добровольная передача ролей FSMO с помощью оснасток управления Active Directory

RID Master , PDC Emulator и Infrastructure Master ) используем оснастку Active Directory Пользователи и компьютеры (Users and Computers ). Для этого заходим на контроллер домена, которому хотим передать роли, запускаем оснастку и щелкнув правой клавишей мыши на нужном домене, выбираем пункт «Хозяева операций».

В открывшемся окне выбираем нужную нам роль (в нашем примере RID Master ) и нажимаем кнопку «Изменить».

И смотрим на результат. Дело сделано, роль передана другому серверу.

Перенос роли Domain Naming Master осуществляется из оснастки Active Directory Домены и доверие (Domains and Trust ). Запускаем оснастку, при необходимости подключаемся к нужному контроллеру домена, щелкаем правой клавишей мыши в корне оснастки и выбираем пункт меню «Хозяин операций».

Открывается знакомое окно, в котором надо нажать кнопку «Изменить», а затем подтвердить изменения так же, как и в предыдущем примере.

С ролью Schema Master дела обстоят несколько сложнее. Для передачи этой роли необходимо предварительно зарегистрировать в системе библиотеку управления схемой Active Directory . Делается это с помощью команды regsvr32 schmmgmt.dll , введенной в окне Выполнить (Run ).

Затем открываем консоль MMC и добавляем в нее оснастку Схема Active Directory .

Если по каким то причинам не удается передать роли с помощью графических оснасток, а также для любителей командной строки есть второй вариант:

Добровольная передача ролей fsmo при помощи Ntdsutil

ntdsutil.exe – утилита командной строки, предназначенная для обслуживания каталога Active Directory . Она представляет из себя мощный инструмент управления, и в число ее возможностей входит передача и захват ролей FSMO .

Для передачи ролей заходим на любой контролер домена, расположенный в том лесу, в котором следует выполнить передачу ролей FSMO . Рекомендуется войти в систему на контроллере домена, которому назначаются роли FSMO . Запускаем командную строку и вводим команды в такой последовательности:

• ntdsutil
• roles
• connections
• connect to server <имя сервера>

После успешного подключения к серверу мы получаем приглашение к управлению ролями (fsmo maintenance ), и можем начать передавать роли:

• transfer domain naming master — передача роли хозяина доменных имен.
• transfer infrastructure master — передача роли хозяина инфраструктуры;
• transfer rid master — передача роли хозяина RID ;
• transfer schema master — передача роли хозяина схемы;
• transfer pdc — передача роли эмулятора PDC .

Для завершения работы Ntdsutil вводим команду q и нажимаем Ввод.

Примечание. Начиная с Windows Server 2008R2 команда для передачи роли хозяина доменных имен transfer naming master.

В качестве примера передадим роль Infrastructure Master серверу SRV2 и проверим результат.

Ну и третий, самый печальный вариант развития событий:

Принудительное назначение ролей fsmo при помощи Ntdsutil

Принудительное назначение, или захват ролей производятся только в случае полного выхода из строя сервера, с невозможностью его восстановления. Если возможно, лучше восстановить работоспособность вышедшего из строя контроллера домена, которому назначены роли FSMO . Сама процедура захвата не особо отличается от передачи ролей. Заходим на контроллер домена, которому хотим передать роли и последовательно вводим в командной строке:

• ntdsutil
• roles
• connections
• connect to server <имя сервера>

Для захвата ролей FSMO используется команда seize

И еще несколько важных моментов, которые нужно учесть при передаче\захвате ролей FSMO :

Для передачи ролей уровня домена (RID Master , PDC Emulator и Infrastructure Master ) ваша учетная запись должна быть членом группы Администраторы домена (Domain admins ), а для передачи ролей уровня леса (Domain Naming Master и Schema Master ) — Администраторы предприятия (Enterprise Admins ).
По возможности не назначайте роль Infrastructure Master контроллеру домена, являющемуся сервером глобального каталога, поскольку в этом случае он не будет обновлять сведения об объектах. Причина такого поведения заключается в том, что сервер глобального каталога хранит частичные реплики всех объектов в лесу.
В случае захвата ролей FSMO контроллер домена, ранее исполнявший эти роли, ни в коем случае нельзя возвращать обратно, т.к. при его появлении в сети возникнет конфликт, что может вызвать проблемы в работе домена. Кроме того, его необходимо удалить из Active Directory. В Windows Server 2008 и 2008 R2 это можно сделать, просто удалив объект сервера в оснастке Active Directory Пользователи и компьютеры , а в Windows Server 2003 с помощью программы Ntdsutil , используя команду ntdsutil — metadata cleanup . Подробнее об этом можно почитать в техподдержке Microsoft

Служба каталогов Microsoft Windows Active Directory - центральное хранилище для всех объектов предприятия и соответствующих им атрибутов. Эта база данных имеет иерархическую структуру, она способна поддерживать несколько ведущих узлов и вмещать миллионы объектов. Поддержка нескольких ведущих узлов позволяет изменять базу данных с любого контроллера домена в пределах предприятия вне зависимости от состояния его подключения к сети.

Модель поддержки нескольких ведущих узлов в Windows 2000

База данных с поддержкой нескольких ведущих узлов (например, Active Directory) принимает изменения от любого контроллера домена в пределах предприятия, что потенциально может привести к возникновению конфликтов при репликации данных на остальные компьютеры. В качестве одного из методов устранения конфликтующих обновлений в Windows 2000 используется алгоритм «преимущество имеет запись, сделанная последней», в соответствии с которым принимается значение данных от измененного последним контроллера домена и отбрасываются значения на остальных контроллерах домена. Однако некоторые конфликты настолько сложны, что не могут быть решены таким способом. Их проще предотвратить, чем устранять постфактум.

Обработка некоторых типов изменений в Windows 2000 осуществляется методами, которые препятствуют конфликтам обновлений Active Directory.

Модель поддержки одного ведущего узла в Windows 2000

Чтобы предотвратить возникновение конфликтующих обновлений, Active Directory выполняет обновления определенных объектов, используя модель с поддержкой одного ведущего узла. Согласно этой модели только один контроллер домена во всем каталоге имеет право вносить обновления. Данный процесс подобен роли, которая присваивалась основному контроллеру домена (PDC) в ранних версиях Windows (например, в Microsoft Windows NT 3.51 и 4.0), по которой PDC отвечает за обработку всех обновлений в определенном домене.

Windows 2000 Active Directory расширяет модель с одним ведущим узлом, которая использовалась в ранних версиях Windows, для включения поддержки нескольких ролей и возможности передавать роли другим контроллерам в рамках предприятия. Поскольку роль Active Directory не имеет жесткой привязки к одному контроллеру домена, ее называют ролью FSMO (Flexible Single Master Operation, или операции одиночного гибкого хозяина). В Windows 2000 существует пять ролей FSMO:

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

Роль FSMO «Хозяин схемы»

Контроллер домена, выполняющий роль хозяина схемы, отвечает за обновление схемы каталога (т. е. контекста присвоения имен схемы или LDAP://cn=schema,cn=configuration,dc=). Вносить изменения в схему каталога может только этот контроллер домена. После обновления схемы она реплицируется с хозяина схемы на другие контроллеры домена в каталоге. В каталоге может быть только один хозяин схемы.

Роль FSMO «Хозяин именования доменов»

Контроллер домена, выполняющий роль хозяина именования доменов, отвечает за изменение пространства доменных имен каталога в рамках леса (т. е. контекста именования «разделы\конфигурация» или LDAP://CN=Partitions, CN=configuration, DC=). Только этот контроллер имеет право удалять и добавлять домены в каталог. Кроме того, он добавляет и удаляет перекрестные ссылки на домены во внешних каталогах.

Роль FSMO «Хозяин RID»

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

Когда контроллер домена создает основной объект-участник безопасности (например, пользователя или группу), он назначает ему идентификатор защиты (SID). Этот идентификатор состоит из SID домена (единый для всех идентификаторов защиты, созданных в одном домене) и относительного идентификатора (RID) (уникальный для каждого участника безопасности, созданного в одном домене).

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

Роль FSMO «Эмулятор PDC»

Эмулятор основного контроллера домена необходим для синхронизации времени в рамках предприятия. В состав Windows 2000 входит служба времени W32Time (время Windows), используемая протоколом проверки Kerberos. Все компьютеры под управлением Windows 2000 в рамках одного предприятия используют общее время. Для обеспечения корректной синхронизации времени служба времени Windows должна использовать иерархическую структуру отношений, которая контролирует полномочия и не допускает возникновения «циклов» в управлении.

Эмулятор PDC домена выступает в роли главного эмулятора домена. Эмулятор PDC в корне леса становится главным эмулятором в пределах предприятия. Его следует настроить на получение значения времени от внутреннего источника. При выборе источника времени обладатели роли FSMO эмулятора основного контроллера домена следуют иерархии доменов.

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

Произведенные другими контроллерами домена изменения паролей в первую очередь реплицируются на эмулятор PDC.

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

Случаи блокировки учетных записей обрабатывается на эмуляторе PDC.

Эмулятор PDC выполняет все функции серверного эмулятора PDC для Microsoft Windows NT 4.0, предыдущих версий эмуляторов на основе Windows NT 4.0 или клиентов более ранних версий.

Нет необходимости использовать данную часть роли эмулятора PDC, если все рабочие станции, серверы и контроллеры домена под управлением Windows NT 4.0 или более ранних версий обновляются до уровня Windows 2000. Эмулятор PDC выполняет все те же функции, что и в среде Windows 2000.

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

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

Клиенты под управлением Windows 2000 (рабочие станции, серверы) и клиенты более ранних версий, на которых установлен клиентский пакет распределенных служб, используют Active Directory для поиска сетевых ресурсов. Служба обозревателя Windows NT для них не требуется.

Роль FSMO «Инфраструктура»

Ссылка на объект одного домена в объекте другого домена определяется идентификатором GUID, SID (для участников безопасности) и различающимся именем (DN) объекта. Контроллер домена, выполняющий роль хозяина инфраструктуры, отвечает за обновление идентификаторов защиты и различающихся имен объектов в междоменных объектных ссылках.

Примечание.

Роль хозяина инфраструктуры (IM) не должна выполняться контроллером домена, который является сервером глобального каталога. В противном случае хозяин инфраструктуры не будет обновлять сведения об объектах, так как он не содержит ссылок на объекты, которых не хранит. Причина такого поведения заключается в том, что сервер глобального каталога хранит частичные реплики всех объектов в лесу. В результате междоменные объектные ссылки в этом домене обновляться не будут, а в журнале событий данного контроллера домена появится соответствующее предупреждение.

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

Нет похожих постов...