Вокруг FSMO ролей Active Directory существует некоторое количество мифов, которые происходят, как несложно догадаться, от банального непонимания темы.

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

Начнем с уровня леса:

Schema master

Схема содержит Классы (например, users, computers, groups) и Атрибуты (например, name, sIDHistory, title). Их использует не только Active Directory, но и некоторое корпоративное ПО (например, Exchange, System Center).

При обновлении уровня домена/леса (после обновления всех ОС контролеров домена разумеется), а также при установке ПО, в схему вносятся дополнительные Классы и Атрибуты, что, разумеется, не влияет на ПО, которое уже установлено. Поэтому не стоит бояться обновления схемы, несмотря на то, что это необратимое действие.

ЕСли Вы все-таки хотите перестраховаться, перед обновлением схемы, можно создать новый контролер, дождаться выполнения репликации и вывести его в offline. Если что-то пойдет не так, вы сможете его вернуть в online, назначить его schema master, предварительно навсегда выведя в offline контролер, на котором обновление прошло неудачно.

Схема едина для всего леса, хранится на каждом контролере домена, а реплицируется с контролера обладающего ролью Schema Master. При установке ПО, которое вносит измениния в схему, изменения будут вносится на контролер с ролью Schema master.

К этому контролеру будут обращаться другие контролеры в случае, если версия схемы на них будет отличаться.

Узнать текущую версию схемы используя PowerShell можно так (разумеется, вместо lab.local будт имя вашего домена):

Get-ADObject «cn=schema,cn=configuration,dc=lab,dc=local» -properties objectVersion

Актуальные на сегодняшний день версии:

69 = Windows Server 2012 R2

56 = Windows Server 2012

47 = Windows Server 2008 R2

44 = Windows Server 2008

31 = Windows Server 2003 R2

30 = Windows Server 2003

13 = Windows 2000

Другое ПО, изменяет другие объекты, например для Exchange Server это rangeUpper

Для того, чтобы использовать mmc оснастку Active Directory Schema (Схема Active Directory в русской локализации) необходимо выполнить:

regsvr32 schmmgmt.dll

Если контролер с ролью Schema Master будет недоступен, никто в пределах леса не сможет расширять схему (подымать уровень леса и устанавливать «тяжелое» ПО), а т.к. расширение схемы происходит очень редко, то жить без этой роли инфраструктура может годами.

Подробнее о Schema тут — http://msdn.microsoft.com/en-us/library/ms675085(v=vs.85).aspx

Domain naming master

Необходим в первую очередь для того, чтобы обеспечить уникальность NetBIOS имен доменов в пределах леса.

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

Кроме того, без Domain naming master не будет работать добавление и удаление разделов каталогов приложений, а также перекрестные ссылки — но это уже совсем экзотика, не думаю что есть смысл об этом писать в рамках этой статьи.

На уровне домена располагаются такие роли:

RID Master

Для каждого Security Principal в домене, генерируется уникальный идентификатор безопасности — SID. В отличии от GUID, SID может меняться, например, при миграции между доменами.

В пределах одного домена, SIDы будут отличаться последним блоком — он называется RID (относительный идентификатор).

При создании нового Security Principal, SID, и, соответственно, RID выдается тем контролером, на котором выполняется создание.

Для того, чтобы предотвратить создание одинаковых RID, каждому контролеру RID marster назначает пул (по-умолчанию 500, но значение можно изменить). Когда у контролера пул приближается к концу (по-умолчанию 100 адресов, также можно изменить) он обращается к RID master, который выдает еще 500 значений.

Всего доступно 2³⁰ (это 1,073,741,823) RIDов — на первый взгляд это очень много, но если принять во внимание тот факт, что RID не мог быть назначен повторно (создание — удаление — создание объета отнимало 2 RIDa) в ряде случаев разблокировали 31й бит и получали 2,147,483,647 RID’ов.

Об улучшениях, которые были сделаны в 2012 Вы можете подробно узнать тут — http://blogs.technet.com/b/askds/archive/2012/08/10/managing-rid-issuance-in-windows-server-2012.aspx

Посмотреть, что у Вас происходит сейчас можно так:

dcdiag.exe /test:ridmanager /v

Таким образом, если контролер с этой ролью будет недоступен, контролеры исчерпавшие выданные им RID-пулы не смогут создавать новых Security Principals.

PDC Emulator

Несмотря на то, что PDC/BDC это термины из далекого NT-прошлого, это наиболее важная FSMO роль в операционной деятельности.

Опустим описание того, как быть с NT машинами, и перейдем к реальным вещам:

1. Источник времени. Синхронизация времени важна для работы Kerberos (и не только), поэтому все контролеры (и, соответственно, клиенты) синхронизируют свое время с PDC, который должен синхронизироваться с внешним NTP. Подробнее о настройке времени в домене я уже писал, можно почитать тут.
2. Сохранение групповых политик по-умолчанию происходит на контролер с ролью PDC, и с него реплицируется на другие контролеры (начиная с 2008 используется DFS).
3. Репликация паролей. Коль уже смена пароля признана важной, реплицируется она не стандартным методом, а так называемым urgent (подробнее о репликации Active Directory — ищите мою статью поиском). Это значит, что контролер, на котором был сменен пароль, срочно реплицируется с контролером, который PDC Emulator. На практике выглядит так: пользователь вводит новый пароль, который ближайший контролер еще не знает. Этот контролер обратится к PDC, и тот подтвердит что пароль правильный, таким образом, предотвращается ряд проблем.

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

Infrastructure Master

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

Как узнать, кто сейчас владеет FSMO ролями?

netdom query fsmo

Как передать FSMO роли новому серверу?

Открываем на «старом» сервере командную строку и запускаем:

ntdsutil

roles

connections

connect to server %new server name%

q

Transfer schema master

Transfer naming master

Transfer PDC

Transfer RID master

Transfer infrastructure master

q

q

Чтобы убедится что все прошло успешно, и роли переданы, снова выполним netdom query fsmo .

Теперь можно удалить роль AD DS со старого сервера, предварительно указав верные настройки DNS для нового сервера.

Подробнее о переносе ролей можно почитать тут: http://support.microsoft.com/kb/255504

Что делать, если старый сервер вышел из строя, а FSMO роли нужно назначить новому? 

Процедкра аналогична передаче ролей, только вместо Transfer нужно использовать Seize (захват).

А где же Global Catalog?

Дело в том, что Global Catalog это не FSMO роль, а репозиторий данных предназначенный для того, чтобы пользователи и системы могли находить объекты по определенным атрибутам во всех доменах леса.

Это значит что контролер обозначенный как Global Catalog, хранит информацию не только о своем домене, но и частичную информацию о доменах своего леса.

Вот тут можно посмотреть, является ли контролер Global Catalog:

Разумеется, можно изменять состав атрибутов, по которым выполняется поиск, например из оснастки Active Directory Schema:

Таким образом, если контролер-Global Catalog будет недоступен, будут сложности с взаимодействием с ресурсами доменов леса.

Надеюсь озвученная информация будет полезной, а если нужна помощь — пишите мне на почту d.kagarlickij@outlook.com