Сколько Хозяинов Инфраструктуры у вас есть на самом деле?


Как все мы знаем, в мультимастерной Active Directory (а это означает, что все контроллеры домена равны, но некоторые равнее), существуют определенные роли, т.н. «single-master», т.е. кто-то, кто заботится о том, чтобы определенные действия выполнялись определенными уникальными контроллерами. Есть пять таких Flexible Single Master Operations (FSMO): два уникальных для леса, и три, которые являются уникальными в домене.

FSMO роли в лесу:

  • SchemaMaster:  предполагает, что должен быть кто-то, кто за все отвечает (сюрприз!), а точнее за все обновления, которые  будут внесены в схему- гарант уникальности этих изменений.
  • Domain Naming Master: Те же операции в масштабах леса, связанные с именованием доменов и разделов приложений, которые тоже должны быть уникальны.

FSMO в домене:

  • PDCEmulator: Пожалуй, самая важная роль в домене, заправляющая сменой паролей пользователей в домене, службой времени, тесно связан с интегрированным в AD пространством имен DFS., и т.д.
  • RIDMaster: Должен быть всегда в твердой уверенности, что RID (последняя часть SID’a) всегда уникален в пределах домена, и выдает пачку RID’ов каждому контроллеру для выдачи уже непосредственно субъектам безопасности, если же пул RID у контроллера наполовину пустой (или наполовину полный), контроллер запрашивает себе добавку непосредственно у держателя данной роли
  • InfrastructureMaster: Зорко следит за изменениями состава групп в лесу между доменами(подсматривая в глобальный каталог), и если находится какой-нибудь объект не из нашего домена,ИМ создает фантом, для того, чтобы все КД знали, что ссылка на объект рядом и не волновались. Но об этом подробно мы поговорим далее. Замечательно и полно обо всех этих ребятах очень хорошо написал Руслан в базе знаний УЦ ATRAINING.

Если мы посмотрим на базу данных AD(которая не реплицируется, ибо AD сама заботится о репликации)т.е. базу данных локального хранилища для контроллера домена, мы увидим две главные таблицы БД: таблицу данных и таблицу ссылок. Каждая строка в таблице данных представлена единственным объектом, на который ссылается «Distinguished Name Tag (DNT)». Это уникальный идентификатор для каждого объекта в базе данных каждого контроллера домена (поскольку контроллеры в домене имеют одинаковые значения объекта и DNT и реплицируют БД на уровне приложения, а не на уровне БД). Однако, есть еще и таблица ссылок. Она содержит все данные обо всех ссылках на объекты.

Поэтому все «членства в группах» и «член групп» хранятся  вместе с DNT. И если контроллеру домена необходимо перечислить членов группы, он просто заглядывает в таблицу ссылок для объекта «ссылка-источник» и перечисляет их цели, и если искомый член группы входит в другую группу, контроллер «распахивает» и их тоже, чтобы дойти до самых последних вопросов. Но вспомним о том, что группы (как и другие ссылки) могут содержать в себе объекты из других доменов. И как же на них сослаться, если они не представлены строкой и не имеют DNT в БД домена? Вот об этом и позаботится Infrastructure-Master.Его задача- создание фантомных объектов, на которые ссылаются парни из нашего двора домена, но которые живут в другом домене. Поэтому эти объекты создаются, как «маленькие версии» тех объектов  в домене, на который они ссылаются.

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

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

Так сколько держателей ролей FMSO есть в лесу?

  • один Schema-Master.
  • один Domain Naming Master.
  • Число  PDC-Emulator равно числу доменов.
  • Число  RID- равно числу доменов.
  • Число Infrastructure Master равно …

Сколько Infrastructure master у нас есть?

Обычный ответ на этот вопрос «столько же, сколько и доменов». Неправильно!

А теперь начинается самая интересная часть статьи.

У нас действительно есть один IM на домен, и это верно. Но вспомните, что в Windows Server 2003 впервые были представлены разделы приложений, и мы могли делать перекрестные ссылки (даже между разделами, но не доменами) Однако, если «доменный IM» не держал бы на себе копию раздела приложений, которая имеет отдельную и конфигурируемую область репликации, как бы он узнал об этих перекрестных ссылках на разделы? Никак, в такой ситуации это было бы невозможно.

Поэтому у нас есть один IM в домене, плюс один на раздел приложений.

И поэтому если по умолчанию  у нас лес уровня Windows Server 2003 и выше, с разделами приложений по умолчанию (для DNS это зоны forestDnsZone и domainDnsZone), давайте представим что у нас пять доменов в нашем лесу, тогда у нас будет:

  • 1 Schema Master
  • 1 Domain Naming Master
  • 5 PDC-Emulator
  • 5 RID-Masters
  • 11 Infrastructure Master (5 Domain Infrastructure Master + 1 для forestDnsZone + 5 для domainDnsZone каждого домена – однако они м.б. и на одном КД)

А где я могу посмотреть на разделы приложений Infrastructure master?

Чтобы посмотреть внутрь раздела, нам понадобится скальпель- adsiedit.msc, или ldp.exe. Подключитесь к разделу приложений и откройте свойства объекта cn=Infrastructure, и взгляните на свойства атрибута fSMORoleOwner. Они указывают на NTDSSettings-Object – сервер, который держит эту роль. Именно сюда лихо прыгают добрые утилиты вроде ntdsutil, когда вы размахивая шашкой пытаетесь передать роль другому контроллеру. Другой способ, не менее интересный, будет заключаться в команде:

dsquery * “cn=Infrastructure,dc=domainDnsZones,dc=example,dc=com” -attr fSMORoleOwner

47

Если вы хотите посмотреть, какие разделы есть в лесу, то поможет команда:

dsquery * “cn=partitions,cn=configuration,dc=example,dc=com” -attr nCName

48

И, наконец, если мы хотим увидеть только разделы приложений, добавим фильтр (systemflags=5), который означает, что мы  ищем все разделы приложений, которые не реплицируются в глобальный каталог, как в случае с разделами приложений (Примечание: Эти разделы могут быть на стороне глобального каталога, расположенного на ИМ)

dsquery * “cn=partitions,cn=configuration,dc=example,dc=com” -filter "(systemflags=5)" -attr nCName

49

Или все предыдущие  команды, введенные одной строкой:

for /f %i in ('dsquery * "cn=partitions,cn=configuration,dc=sberbank,dc=ru"
-filter "(systemflags=5)" -attr nCName ^| find /v "nCName"') do
@echo %i && dsquery * cn=Infrastructure,%i -attr fSMORoleOwner

50

А какое мне дело до разделов приложений хозяина инфраструктуры?

Об этом легко вспомнить, когда вы соберетесь подготавливать лес для RODC, и запустите команду adprep /rodcprep. Этой командой задаются разрешения для репликации контента контроллерами домена только для чтения. Так как RODC не входят в группу КОНТРОЛЛЕРЫ ДОМЕНА ПРЕДПРИЯТИЯ (ENTERPRISE DOMAIN CONTROLLERS), по умолчанию у них нет достаточных разрешений. Поскольку RODC может держать интегрированную в Active Directory зону DNS, ему также требуются разрешения и на разделы приложений. Поскольку мы не можем быть уверены, что определенный контроллер держит все разделы приложений — для domainDnsZone это справедливо, если у вас имеется множество доменов, и несправедливо в случае, когда IM держит разделы приложений в своем домене (например, он не является DNS сервером, и соответственно, не держит зоны domainDnsZone своего домена, Microsoft решила выбирать сервер IM командой adprep /rodcprep.

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

Однако, первый контроллер в лесу также держит «хозяина инфраструктуры разделов приложений» (назовем его AP-IM) и «хозяина инфраструктуры доменов» (D-IM), который держит зоны forestDnsZone и domainDnsZone корневого домена леса. Когда администратор унижает эти контроллеры, они передают роли FSMO, поскольку они считают что делают очень полезное и нужное дело. Однако, если вы используете MMC или ntdsutil для передачи ролей (хохохо), (KB 324801, 255504 , и моя модная статья на технете) роль AP-IM  в этом случае не будет передана автоматически.

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

Критично ли, если хозяин инфраструктуры раздела приложений более недоступен?

Конечно, да, все взорвется, не понятно, что ли. Вам надо срочно на платную консультацию без очереди 🙂

В большинстве случаев – нет. Поскольку разделы приложений по умолчанию используются только DNS, и хранят только DNS зоны и объекты узлов dnsNode-Objects, представленные записями.Они не используют ссылки, поэтому им нет дела до каких-то там хозяев инфраструктур и его разделов приложений. Однако, вам придется применить исправление, описанное в KB 949257, для запуска «adprep /rodcprep». Вы также можете сделать это вручную, зажмурившись измените атрибут fSMORoleOwner по пути cn=Infrastructure,dc=< dn -вашего-раздела-приложений > на distinguishedName объекта NTDSSettings-Object сервера, который вы выбрали для этой миссии.

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

PS. Поводом к разбирательству во всей этой запутанной истории стал звонок моего коллеги, который заметил несоответствие  серверов хозяина инфраструктуры в отчетах SCOM, а потом умел удовольствие убедиться в этом визуально — зная, какой сервер держит данную роль, он весьма удивился «неправильному» отображению информации в ADUC.

На самом же деле причина здесь в том, что  Active Directory Users and Computers цепляется, как и NTDSUtil по умолчанию за доменный раздел, а LDIFDE при запуске зацепится за DomainDnsZones, отображение информации будет разным. Уже сейчас можно прыгнуть на свою инфраструктуру, и поглядеть, какое имя отдаст  в выводе команда. Спорю, вы удивитесь!

http://technet.microsoft.com/en-us/library/cc961941.aspx

http://msdn.microsoft.com/en-us/library/windows/desktop/ms675713(v=vs.85).aspx

http://support.microsoft.com/kb/2696188

«The directory service is missing mandatory configuration information, and is unable to determine the ownership of floating single-master operation roles.» и все такое…

PS. Если Вы, мой читатель, модных и передовых взглядов человек, то спешу обрадовать Вас:

Включив AD Recycle Bin, каждый контроллер, не несущий на себе глобальный каталог так же зорко следит за меж доменными ссылками, и «FSMO размещение IM» теряет всякий смысл.

Реклама

2 thoughts on “Сколько Хозяинов Инфраструктуры у вас есть на самом деле?

Добавить комментарий

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

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s