Глава 5. Помещение операций Ролей хозяина

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

Таблица 5-1. Права доступа

Уровень леса	Уровень домена
Хозяин операций схемы	Хозяин операций эмулятора PDC (primary domain controller)
Хозяин операций именования домена	Хозяин операций RID (relative identifier)
N/ A	Хозяин операций инфраструктуры

Когда мы создаём самый первый лес Active Directory и самый первый домен Active Directory, все эти роли FSMO будут установлены в самом первом контроллере домена (что очевидно; другого места нет). Большинство инфраструктур Active Directory остаются как есть с установленной по умолчанию конфигурацией, даже несмотря на то, что они продолжают добавлять контроллеры. Удержание их в одном контроллере домена не является ошибкой, но если вы желаете извлечь из этого максимальную выгоду, существуют определённые рекомендации, которым стоит следовать.

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

Данная роль ограничена самим лесом. Это означает, что некий лес Active Directory может иметь лишь одного хозяина схемы. Обладатель данной роли это тот контроллер в имеющемся лесу, который способен обновлять схему Active Directory. Для внесения изменений схемы в имеющемся лесу ему также требуется иметь учётную запись пользователя, который является участником группы Администраторов схемы (Schema Admins group). После того как сделаны изменения схемы от имени владельца роли хозяина этой схемы, эти изменения будут реплицированы в прочие контроллеры домена в данном лесу.

В неком лесу Active Directory отыскать установленного владельца роли хозяина схемы можно при помощи такой команды:

Get-ADForest | select SchemaMaster
		

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

Get-ADForest | select DomainNamingMaster
		

Когда вы добавляете или удаляете какой- то контроллер домена, вы будете поддерживать контакт с имеющимся держателем роли хозяина операций имён домена через подключения RPC (Remote Procedure Call), а в случае отказа вам не будет дозволено добавлять или удалять соответствующий контроллер домена в данном лесу. Это роль для всего леса, причём в одном лесу может иметься только один держатель роли хозяина операций с именами доменов.

Роль хозяина операций имеющегося PDC (primary domain controller, Первичного контроллера домена) выступает установкой для всего домена, что подразумевает что всякий домен в определённом лесу будет иметь держателя роли хозяина операций PDC. Одним из наиболее часто задаваемых вопросов относительно Active Directory является: какая из ролей FSMO ответственна за синхронизацию времени? Ответом является PDC! В некой среде Active Directory он допускает максимальную разницу между сервером и клиентом в 5 минут для поддержки успешной аутентификации. Если она превышает 5 минут, устройства будут не способны добавляться в этот домен, пользователи не будут способны выполнять аутентификацию, а интегрированные с Active Directory приложения начнут швыряться ошибками, вызываемыми аутентификацией.

Важно чтобы контроллеры домена, компьютеры и серверы в контроллере домена Active Directory согласовывали свои часы:

Компьютеры в неком домене будут синхронизировать свои часы с имеющимся контроллером домена при аутентификации. Далее все имеющиеся контроллеры домена будут синхронизировать своё время с держателем роли domain PDC. Все держатели роли domain PDC будут выполнять синхронизацию своего времени с имеющимся держателем роли root domain PDC леса, а держатель роли root domain PDC леса будет синхронизировать своё время с неким external time source (внешним источником времени).

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

В своём домене Active Directory владельца роли PDC можно найти при помощи следующей команды:

Get-ADDomain | select PDCEmulator
		

Такой PDC также отвечает за управление изменением установленного GPO (Group Policy Object, Объекта групповой политики). При каждом просмотре или обновлении некого GPO это осуществляется из копии, хранимой в папке SYSVOL установленного PDC.

Данная роль хозяина RID (relative identifier, относительного идентификатора) является установкой для всего домена и каждый домен в своём лесу может обладать владельцами роли RID. Она отвечает за сопровождение некого пула относительных идентификаторов, которые будут применяться при создании объектов в этом домене. Абсолютно все объекты в неком домене обладают неким уникальным SID (security identifier, идентификатором безопасности). В процессе создания такого SID используется имеющееся значение RID. Конкретный SID является неким уникальным значением для представления какого- то объекта в Active Directory. Значение RID представляет собой инкрементальную часть такого значения SID. После того как определённое значение RID было применено для выработки SID, оно более не будет использоваться. Даже после удаления какого- то объекта из AD нет никакой возможности возврата обратно использованного значения RID. Когда определённый домен обладает множеством контроллеров домена, он назначит некий блок из 500 значений RID для каждого контроллера домена. После того как они используют более 50%, контроллеры домена запросят другой блок RID у владельца роли RID.

В конкретном домене Active Directory его владельца роли RID можно выявить применив такую команду:

Get-ADDomain | select RIDMaster
		

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

Эта роль также устанавливается для всего домена и она ответственна за репликацию изменений значений SID и DN (distinguished name, отличительных имён) по всем доменам. Значения SID и DN получают изменения по своему местоположению в имеющемся лесу. Следовательно, когда объекты перемещаются, требуется обновлять их новые значения в группах и ACL, располагающиеся в разных доменах. Именно об этом и заботится хозяин операций инфраструктуры. Это будет гарантировать что все изменённые объекты непрерывно имеют доступ к своим ресурсам.

В конкретном домене Active Directory обладателя роли хозяина операций инфраструктуры можно отыскать применив следующую команду:

Get-ADDomain | select InfrastructureMaster
		

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

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

Самый первый контроллер в самом первом лесу Active Directory будет удерживать все пять ролей FSMO. Все эти роли являются критически важными в устанавливаемой инфраструктуре Actrive Directory. Некоторые из них интенсивно используются, а какие- то применяются от случая к случаю.Некоторые владельцы ролей не могут позволять себе простои, а какие- то по- прежнему могут позволять себе наличие простоев. Таким образом, в зависимости от функций, влияния и ответственности они могут размещаться на различных контроллерах домена. Однако размещение ролей FSMO сильно зависит от характеристик имеющейся инфраструктуры. Давайте продолжим и рассмотрим некоторые из них более подробно.

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

В нашем следующем примере, в среде единственного леса - единственного домена rebeladmin.com в установленной инфраструктуре имеются три контроллера домена:

PDC01 известен как самый мощный (по ёмкости) и наиболее надёжный контроллер домена. Таким образом, PDC01 содержит все пять ролей FSMO. SDC01 и SDC02 также являются двумя серверами глобального каталога. В данном случае простое перемещение роли хозяина инфраструктуры в один из контроллеров домена не окажет существенного воздействия. В случае отказа PDC01 вторичные контроллеры домена будут способны потребовать владения ролями FSMO (такой процесс имеет название овладения ролями FSMO - seizing FSMO roles и подробнее будет описан далее в этой главе).

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

В нашем следующем примере Rebeladmin Corp. обладает тремя доменами. Корневым доменом леса выступает домен rebeladmin.net. Домен rebeladmin.com используется в их штаб- квартире в США, а rebeladmin.ca применяется как их Канадское подразделение:

Все эти три домена совместно используют один лес. Таким образом, роли всего леса, которыми являются Хозяин схемы (Schema master) и Хозяин имён доменов (Domain naming master) будут помещены в домене корня, rebeladmin.net. Он имеет три контроллера домена. PDC01 указывается как наиболее надёжный контроллер домена.

Роли Хозяина схемы (Schema master) и Хозяина имён доменов (Domain naming master) используют относительно малую мощность процессоров, ибо изменения для всего леса не происходят часто. Однако высокая доступность обязательна, поскольку все прочие действия доменов зависят от них. Наиболее потребляющей ролью FSMO выступает PDC, так как она будет реплицировать изменения, управлять синхронизацией времени и управлять изменениями GPO. По этой причине для PDC важен запуск на том контроллере домена, который обладает наивысшей вычислительной мощностью. Держатель роли PDC является самым большим потребителем своего хозяина RID (RID master), а следовательно, критически важно надёжное взаимодействие между этими двумя держателями ролей.

Во избежание проблем связанных с сетевыми задержками проблем вам предлагается держать PDC и RID вместе в одном контроллере домена. Итак, в конце концов, мы можем поместить четыре роли FMSO в PDC01. В среде со множеством доменов важны ссылки между доменами. Когда соответствующая учётная запись пользователя изменяет своё название в имеющемся корневом домене леса, это будет немедленно реплицировано во все имеющиеся контроллеры домена в данном домене корня леса. Если такой пользователь является частью группы в прочих доменах, им также требуется знать о таких новых значениях. Таким образом, SDC01 выполнен не как сервер глобального каталога и он держит роль Хозяина инфраструктуры (Infrastructure master). SDC02 удерживается в качестве контроллера домена резервной копии; когда умирает любой из держателей роли FSMO, он может потребовать овладения ролью. В некоторых инфраструктурах сам корневой домен леса не используется для активных действий. В таких случаях удержание множества контроллеров домена выступает некими накладными расходами управления.

Когда дело касается домена rebeladmin.com, он содержит лишь роли FSMO для своего домена. Хозяева PDC и RID запускаются с PDC01, а SDC01 запускает роль Хозяина инфраструктуры (Infrastructure master). SDC02 выступает контроллером домена, который может применяться в качестве держателя роли FSMO в случае отказа одного из имеющихся владельцев роли.

Домен rebeladmin.ca применяется в инфраструктуре регионального офиса. Он имеет менее 25 пользователей, причём большинство из них являются продавцами. По этой причине удержание нескольких контроллеров домена не может оправдываться фактами ёмкости или надёжности. Имеющаяся установка ограничена до двух контроллеров домена, причём PDC01 размещает все три роли FSMO данного домена. SDC01 удерживается в качестве резервной копии контроллера домена, который будет задействован в неком сценарии DR (disaster recovery, восстановления в случае аварии).

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

В инфраструктурах Active Directory могут иметься региональные офисы и удалённые площадки, которые подключаются при помощи соединений WAN. В большинстве случаев такие соединения WAN имеют ограниченную полосу пропускания. Эти удалённые площадки могут также размещать контроллеры домена. Когда обмен между площадками не обрабатывается оптимальным образом, это может приводить к узким местам. Rebeladmin Corp. управляется поставщиком услуг и имеет два офиса. Основная штаб квартира расположена в Торонто, а центр обработки базируется в Сиэтле, США. Они связаны через WAN подключение 512kb. В офисе Торонто имеется 20 пользователей, а в офисе Сиэтла работают 500 пользователей. Все они работают в инфраструктуре Active Directory с единым доменом.

Как я уже упоминал ранее, из всех имеющихся ролей FSMO именно PDC является наиболее используемой ролью FSMO. Устройства и пользователи поддерживают взаимодействие с PDC более часто нежели с прочими держателями ролей FSMO. При таком сценарии, когда мы поместим свой PDC в офис в Торонто, 500 пользователям и связанным с ними устройствам будет необходимо выполнять проход по соединению WAN для взаимодействия со своим PDC. Однако когда мы поместим его на площадке в Сиэтле, тогда тот обмен, который будет происходить через WAN подключение, будет ниже. В случае сценария с неким региональным офисом убедитесь что вы всегда помещаете свой PDC рядом с той площадкой, которая размещает самое большое число пользователей, устройств и ресурсов.

Применяемая для взаимодействия между площадками сетевая топология также имеет воздействие на выполнение размещения ролей FSMO. В нашем следующем примере установка Active Directory имеет три площадки Active Directory с некой единой инфраструктурой. Site Canada соединена с Site USA, а Site USA подключается к Site Europe. Однако Site Canada не имеет прямого соединения с Site Europe:

Теперь, когда роли FSMO размещены на Site Canada, Site Europe будет иметь проблемы взаимодействия с ними. Site Europe не будет способна выполнять никакие связанные с FSMO задачи. Согласно такой сетевой топологии наилучшим вариантом будет разместить все роли FSMO на Site USA, поскольку с ней имеют соединение обе площадки.

Общее число контроллеров домена, которое можно развернуть в инфраструктуре Active Directory зависит от размера бюджета и доступных ресурсов (вычислительных ресурсов, пространства, электрической мощности и возможности подключений).

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

Общая ёмкость имеющейся инфраструктуры Active Directory также оказывает воздействие на размещение ролей FSMO. При росте общего числа пользователей, устройств и прочих ресурсов, растёт также и деятельность, связанная с ролями FSMO. Когда имеется некая среда со множеством площадок, рекомендуется чтобы вы помещали роли FSMO на площадках, которые работают с высокой ёмкостью объектов Active Directory чтобы уменьшить объём воздействия репликации и проблемы с задержками.

Держатели ролей FSMO также вовлечены в обычные задачи Active Directory, такие как аутентификация пользователя. В больших средах Active Directory (с более чем 10 000 объектов), важно делать связанные с FSMO задачи более приоритетными, нежели обычные задачи Active Directory. В основном это оказывает воздействие на имеющийся эмулятор PDC, так как это наиболее активная роль FSMO. Существует возможность выставлять приоритеты действий контроллера домена изменяя значение веса (weight) его записи DNS SRV. Значением по умолчанию выступает 100, а его снижение уменьшит общее число запросов аутентификации пользователей. Рекомендуемым значением является 50.

Это можно выполнить, добавив некий новый ключ реестра в HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters. Этот ключ должен иметь некой значение DWORD с названием своей записи LdapSrvWeight.

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

Давайте рассмотрим как мы можем передавать установленные роли FSMO.

Прежде чем начинать, нам требуется проверить своего текущего держателя роли FSMO. Это можно сделать, выполнив следующую команду:

netdom query fsmo
		

В установленной инфраструктуре существует некий новый контроллер домена, добавленный под именем REBEL-SDC02, и я бы хотел переместить все роли FSMO своего домена, которыми являются роли PDC, RID и инфраструктуры на этот новый сервер:

Move-ADDirectoryServerOperationMasterRole -Identity REBEL-SDC02 -OperationMasterRole PDCEmulator, RIDMaster, InfrastructureMaster
		

Когда перемещение выполнено, мы можем проверить хозяев своих ролей снова:

Когда нам требуется переместить в некий новый хост все пять ролей FSMO, мы можем воспользоваться такой командой:

Move-ADDirectoryServerOperationMasterRole -Identity REBEL-SDC02 -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster
		

Приводимый ниже снимок экрана отображает полученный вывод для соответствующей команды netdom query fsmo:

Если нам требуется переместить отдельную роль FSMO, для такой индивидуальной роли можно применить команду Move-ADDirectoryServerOperationMasterRole.

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

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

Процесс овладения (seize) ролью FSMO следует применять только в бедственном случае, когда невозможно восстановить держателя необходимой роли FSMO. Некоторые из имеющихся ролей FSMO (RID, хозяин имён домена и хозяин схемы) всё ещё могут пребывать несколько часов в состоянии останова с минимальным воздействием на все дела. Таким образом, мы не применяем вариант овладения в качестве самой первой опции когда соответствующий держатель роли FSMO всё ещё способен восстановиться или исправиться.

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

В нашем следующем примере в нашей инфраструктуре имеются два контроллера домена. REBEL-SDC02 выступает держателем соответствующей роли FSMO, а REBEL-PDC-01 является дополнительным имеющимся контроллером домена. По причине аппаратного сбоя я не могу вернуть в рабочее состояние REBEL-SDC02 и мне требуется овладеть необходимыми ролями FSMO:

Для овладения такими родями можно воспользоваться следующей командой:

Move-ADDirectoryServerOperationMasterRole -Identity REBEL-PDC-01 -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster -Force

		

Данная команда потребует на завершение в фоновом режиме несколько минут, причём она попробует соединиться с соответствующим первоначальным держателем роли FSMO.

Единственным изменением в данной команде от передачи необходимой роли FSMO выступает в самом конце параметр -Force. В противном случае это была бы та же самая команда. При помощи Move-ADDirectoryServerOperationMasterRole -Identity REBEL-PDC-01 -OperationMasterRole <FSMO Role> -Force вы также можете овладевать индивидуальной ролью.

<FSMO Role> можно заменять на действительное значение роли FSMO.

После завершения данной команды мы можем проверить полученное состояние нового держателя роли FSMO:

Как мы можем видеть, REBEL-PDC-01 стал новым держателем ролей FSMO.

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

В своей следующей главе мы рассмотрим реальные сценарии развёртывания Active Directory и изучим как выполнять миграцию с более старых версий Active Directory в AD DS 2016.