Блог Виталия Лещенко
Виталий Лещенко

Windows Server для самых маленьких. Часть 17: Что такое роли FSMO?

Все части серии «Windows Server для самых маленьких»

В части 10 каталог был многохозяйским: любой контроллер принимает любое изменение, а конфликты решаются по версии и времени. Для пользователей и групп это работает. Но есть операции, где конфликт недопустим в принципе: два контроллера, одновременно выдавшие двум новым пользователям один и тот же RID, создали бы две учётные записи с одним SID, и ни одна версия с меткой времени этого не исправит. Для таких операций в каталоге есть единственный владелец — контроллер, который один имеет право их выполнять. Таких операций пять, они называются FSMO (Flexible Single Master Operations), а их владельцы — operations masters, или хозяева операций.

«Flexible» — потому что роль не привязана к серверу: её можно передать любому контроллеру, и это — вторая половина части.

Пять ролей

Две роли — на лес, три — на каждый домен. В лесу из одного домена их пять; в лесу из трёх доменов — одиннадцать. Все пять получает первый контроллер леса при Install-ADDSForest (часть 4), три доменные — первый контроллер каждого нового домена.

Роль Область Что делает Где хранится владелец
Schema Master лес изменения схемы fSMORoleOwner объекта CN=Schema,CN=Configuration,…
Domain Naming Master лес добавление и удаление доменов и разделов приложений fSMORoleOwner объекта CN=Partitions,CN=Configuration,…
PDC Emulator домен время, пароли, блокировки, групповые политики fSMORoleOwner корня домена DC=corp,DC=example,DC=com
RID Master домен выдача пулов относительных идентификаторов, перенос объектов в другой домен fSMORoleOwner объекта CN=RID Manager$,CN=System,…
Infrastructure Master домен обновление ссылок на объекты других доменов fSMORoleOwner объекта CN=Infrastructure,…

Атрибут fSMORoleOwner содержит DN объекта NTDS Settings владельца — того самого, что делает сервер контроллером с точки зрения остальных (часть 4). Он реплицируется как любой атрибут, и все контроллеры знают владельца каждой роли.

Schema Master. Только на нём можно изменить схему: добавить класс или атрибут, сделать атрибут неработающим. Установщик Exchange, adprep /forestprep перед вводом первого контроллера новой версии, Update-LapsADSchema из части 15 — все они находят владельца и пишут на него. Пока он недоступен, схему нельзя расширить; всё остальное в лесу этого не замечает. Расширять схему может только член группы Schema Admins; по умолчанию в ней одна учётная запись — Administrator корневого домена леса.

Domain Naming Master. Добавление домена в лес, удаление домена, создание и удаление раздела приложения, добавление его реплики на контроллер (например, когда DNS-сервер подключается к DomainDnsZones) — через него. Недоступен — нельзя добавить домен или раздел. Больше ни на что не влияет. В Windows 2000 этот контроллер обязан был быть глобальным каталогом, с Windows Server 2003 — нет.

PDC Emulator. Самая нагруженная роль, и единственная, чьё отсутствие заметят пользователи. Название — от Primary Domain Controller из доменов NT: в Windows 2000 эта роль притворялась PDC для старых BDC и клиентов, и имя осталось, а обязанности накопились:

  • источник времени для домена — вершина иерархии из части 12;
  • пароли: смена пароля на любом контроллере в первую очередь реплицируется на PDC, а контроллер, у которого проверка пароля не прошла, переспрашивает PDC, прежде чем отказать окончательно (часть 10);
  • блокировки: неудачные попытки входа со всех контроллеров пересылаются на PDC, и блокировка учётной записи обрабатывается там; счётчик badPwdCount не реплицируется, у каждого контроллера он свой, а полный — у PDC;
  • групповые политики: консоль GPMC и редактор политик по умолчанию работают с PDC, чтобы два администратора не правили одну политику на разных контроллерах;
  • SDProp: процесс защиты административных учётных записей через AdminSDHolder (часть 5) раз в 60 минут запускается именно на PDC;
  • старые приложения и часть инструментов, которым нужен «главный» контроллер для записи, обращаются к нему.

Недоступен — время в домене без вершины (событие 129 у членов домена, часть 12), новый пароль до репликации работает не на всех контроллерах, блокировки не сходятся в одну точку, GPMC сообщает, что PDC недоступен, и предлагает выбрать другой контроллер. Домен живёт, но хуже, и через несколько часов это начинают замечать.

RID Master. SID объекта — SID домена плюс RID (часть 3), и RID должен быть уникален во всём домене, хотя объекты создаются на любом контроллере. Решение: RID Master выдаёт каждому контроллеру пул — по умолчанию 500 идентификаторов, — и контроллер расходует свой пул, не спрашивая никого. Когда в пуле остаётся меньше порога, контроллер заранее просит следующий. Новый контроллер без пула не начнёт работать как контроллер: прежде чем объявить себя клиентам, он получает первый пул. Ещё одна обязанность RID Master — перенос объекта в другой домен леса. Недоступен — контроллеры продолжают создавать объекты из своих пулов, и первый, у кого пул кончится, перестанет создавать пользователей, компьютеры и группы с ошибкой «The directory service was unable to allocate a relative identifier.». В домене, где создают десять учётных записей в день, это случится через месяцы; в домене, где скрипт создаёт тысячи, — через часы.

Пулы видны в каталоге. Общий остаток домена — атрибут rIDAvailablePool объекта CN=RID Manager$:

PS C:\> $pool = (Get-ADObject 'CN=RID Manager$,CN=System,DC=corp,DC=example,DC=com' -Properties rIDAvailablePool).rIDAvailablePool
PS C:\> [PSCustomObject]@{ NextRid = $pool -band 0xFFFFFFFFL; MaxRid = $pool -shr 32 }

NextRid     MaxRid
-------     ------
   8100 1073741823

rIDAvailablePool — 64-битное число: младшие 32 бита — первый ещё не выданный RID, старшие — верхняя граница, 2³⁰ − 1 = 1073741823 (с Windows Server 2012 её можно поднять до 2³¹ − 1, об этом ниже). Маска записана как 0xFFFFFFFFL: без суффикса L PowerShell читает 0xFFFFFFFF как Int32 со значением −1, и -band возвращает число целиком. Всё, что ниже NextRid, уже роздано пулами; RID меньше 1000 закреплены за встроенными учётными записями и группами (500 — Administrator, 512 — Domain Admins) и в пулы не попадают.

Пул каждого контроллера хранится в объекте CN=RID Set под его учётной записью компьютера (ссылка на него — атрибут rIDSetReferences). Текущий пул — rIDPreviousAllocationPool, следующий свободный RID в нём — rIDNextRID, и оба атрибута не реплицируются: каждый контроллер хранит только свои значения, поэтому читать их нужно на самом контроллере, через -Server:

PS C:\> Get-ADDomainController -Filter * | Sort-Object Name | ForEach-Object {
    $ridSet = Get-ADObject "CN=RID Set,$($_.ComputerObjectDN)" -Server $_.HostName -Properties rIDPreviousAllocationPool, rIDNextRID
    [PSCustomObject]@{ DC = $_.Name; PoolStart = $ridSet.rIDPreviousAllocationPool -band 0xFFFFFFFFL; PoolEnd = $ridSet.rIDPreviousAllocationPool -shr 32; NextRid = $ridSet.rIDNextRID }
}

DC  PoolStart PoolEnd NextRid
--  --------- ------- -------
DC1      6100    6599    6213
DC2      5600    6099    5658
DC3      7100    7599    7150
DC4      7600    8099    7606

Без -Server модуль прочитает все четыре объекта на одном контроллере, и у трёх чужих NextRid окажется пустым или нулём. Пулы по 500, и каждый контроллер израсходовал из своего от 6 до 113 идентификаторов. Следующий пул контроллер получает заранее и держит в rIDAllocationPool — этот атрибут того же объекта реплицируется; пока запасного пула нет, он совпадает с rIDPreviousAllocationPool. dcdiag /test:ridmanager проверяет то же самое и сообщает, если контроллер не может связаться с RID Master, — вывод в «Смотрим руками».

Infrastructure Master. В группе домена corp состоит пользователь из домена eu.corp. Контроллеры corp хранят ссылку на него — фантом, объект с DN, GUID и SID, но без остальных атрибутов, — и если пользователя в eu.corp переименуют или перенесут, фантом устареет. Infrastructure Master периодически сверяет фантомы с глобальным каталогом и обновляет их. Отсюда известное правило: Infrastructure Master не должен быть глобальным каталогом, если не все контроллеры домена — глобальные каталоги. У GC фантомов нет (он хранит частичные копии всех доменов), ему нечего сверять, и он ничего не делает. В лесу из одного домена фантомов нет вовсе; в домене, где все контроллеры — GC (а это сегодня норма), ссылки обновляет каждый GC сам. А в лесу с включённой корзиной Active Directory (часть 20) каждый контроллер сам обновляет свои ссылки на объекты других доменов, и у роли не остаётся работы. Владельца Microsoft всё равно советует держать живым, иначе средства мониторинга будут сообщать об ошибках.

У роли есть двойник в каждом разделе приложений: CN=Infrastructure,DC=DomainDnsZones,… и CN=Infrastructure,DC=ForestDnsZones,… со своим fSMORoleOwner. На них опираются понижение контроллера, который отдаёт содержимое DNS-разделов владельцу, и adprep /rodcprep, который раздаёт права для RODC. В число пяти ролей они не входят, и ни Move-ADDirectoryServerOperationMasterRole, ни ntdsutil их не переносят: в домене из примера все пять ролей когда-то переехали с dc2 на dc1, а двойники так и остались на dc2 (вывод ниже). Если такой владелец выведен из домена аварийно, fSMORoleOwner указывает на удалённый объект NTDS Settings (в DN видно \0ADEL:), и тогда понижение другого контроллера останавливается с ошибкой «…unable to determine the ownership of floating single-master operation roles», а adprep /rodcprep пишет «Adprep could not contact a replica for partition DC=DomainDnsZones,…». Лечится прямой записью атрибута — в «Смотрим руками».

Кто владеет

Несколько способов, и все показывают одно:

PS C:\> netdom query fsmo
Schema master               dc1.corp.example.com
Domain naming master        dc1.corp.example.com
PDC                         dc1.corp.example.com
RID pool manager            dc1.corp.example.com
Infrastructure master       dc1.corp.example.com
The command completed successfully.

PS C:\> Get-ADForest | Select-Object SchemaMaster, DomainNamingMaster

SchemaMaster         DomainNamingMaster
------------         ------------------
dc1.corp.example.com dc1.corp.example.com

PS C:\> Get-ADDomain | Select-Object PDCEmulator, RIDMaster, InfrastructureMaster

PDCEmulator          RIDMaster            InfrastructureMaster
-----------          ---------            --------------------
dc1.corp.example.com dc1.corp.example.com dc1.corp.example.com

PS C:\> Get-ADDomainController -Filter * | Select-Object Name, OperationMasterRoles

Name OperationMasterRoles
---- --------------------
DC2  {}
DC1  {SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster…}
DC3  {}
DC4  {}

PowerShell 7 обрезает коллекцию в таблице многоточием; полный список — Select-Object -ExpandProperty OperationMasterRoles. Владельца PDC находит и Locator — так его ищут клиенты и сами контроллеры:

PS C:\> Get-ADDomainController -Discover -Service PrimaryDC | Select-Object Name, HostName, Site

Name HostName               Site
---- --------               ----
DC1  {dc1.corp.example.com} Office

PS C:\> nltest /dsgetdc:corp.example.com /pdc | Select-String 'DC:|Flags:'

           DC: \\dc1.corp.example.com
        Flags: PDC GC DS LDAP KDC TIMESERV GTIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE FULL_SECRET WS DS_8 DS_9 DS_10 KEYLIST DS_13

И dcdiag — с ним видно, что о владельцах знает конкретный контроллер:

PS C:\> dcdiag /s:dc1 /test:knowsofroleholders /v | Select-String 'Role .* Owner|passed test KnowsOfRoleHolders'

         Role Schema Owner = CN=NTDS Settings,CN=DC1,CN=Servers,CN=Office,CN=Sites,CN=Configuration,DC=corp,DC=example,DC=com
         Role Domain Owner = CN=NTDS Settings,CN=DC1,CN=Servers,CN=Office,CN=Sites,CN=Configuration,DC=corp,DC=example,DC=com
         Role PDC Owner = CN=NTDS Settings,CN=DC1,CN=Servers,CN=Office,CN=Sites,CN=Configuration,DC=corp,DC=example,DC=com
         Role Rid Owner = CN=NTDS Settings,CN=DC1,CN=Servers,CN=Office,CN=Sites,CN=Configuration,DC=corp,DC=example,DC=com
         Role Infrastructure Update Owner = CN=NTDS Settings,CN=DC1,CN=Servers,CN=Office,CN=Sites,CN=Configuration,DC=corp,DC=example,DC=com
         ......................... DC1 passed test KnowsOfRoleHolders

Тест показывает знание одного контроллера и не сравнивает его с остальными; с ключом /e он проходит по всем контроллерам леса, и расхождение между ними в том, кто владелец, — признак проблем репликации. Domain Owner здесь — Domain Naming Master, Infrastructure Update Owner — Infrastructure Master.

Роли хранятся в атрибутах, и их можно прочитать напрямую — только так видны двойники Infrastructure:

PS C:\> 'CN=Schema,CN=Configuration', 'CN=Partitions,CN=Configuration', '', 'CN=RID Manager$,CN=System', 'CN=Infrastructure', 'CN=Infrastructure,DC=DomainDnsZones', 'CN=Infrastructure,DC=ForestDnsZones' | ForEach-Object {
    $dn = if ($_) { "$_,DC=corp,DC=example,DC=com" } else { 'DC=corp,DC=example,DC=com' }
    [PSCustomObject]@{ Object = $_; Owner = (Get-ADObject $dn -Properties fSMORoleOwner).fSMORoleOwner -replace '^CN=NTDS Settings,CN=([^,]+),.*', '$1' }
}

Object                              Owner
------                              -----
CN=Schema,CN=Configuration          DC1
CN=Partitions,CN=Configuration      DC1
                                    DC1
CN=RID Manager$,CN=System           DC1
CN=Infrastructure                   DC1
CN=Infrastructure,DC=DomainDnsZones DC2
CN=Infrastructure,DC=ForestDnsZones DC2

Пустая строка — корень домена, то есть PDC. Двойники в DNS-разделах принадлежат dc2 — это и есть след давнего переноса ролей, о котором выше.

Перенос

Перенос (transfer) — штатная операция при живом владельце: новый владелец просит роль у старого, старый записывает нового в fSMORoleOwner и передаёт ему объект роли (для RID Master — вместе с состоянием пула), а дальше изменение расходится репликацией. Занимает секунды, пользователи ничего не замечают.

PS C:\> Move-ADDirectoryServerOperationMasterRole -Identity dc2 -OperationMasterRole PDCEmulator, RIDMaster, InfrastructureMaster

Командлет спрашивает подтверждение (-Confirm:$false отключает вопрос) и по умолчанию ничего не выводит; результат проверяется тем же netdom query fsmo. Роли принимают имена или номера от 0 до 4 (PDCEmulator, RIDMaster, InfrastructureMaster, SchemaMaster, DomainNamingMaster), -Identity — контроллер, которому передают, по имени или объектом из Get-ADDomainController: с полным DNS-именем в -Identity командлет, по документации, не работает. Команда выполняется с любой машины в домене: модуль сам свяжется с контроллерами. Старый способ — ntdsutil roles connections "connect to server dc2" q "transfer pdc" q q, где после connect to server указывается новый владелец, — делает то же самое и до сих пор работает. Остальные роли в ntdsutil называются rid master, infrastructure master, naming master и schema master.

Новый владелец начинает выполнять роль не сразу, а после первой успешной входящей репликации раздела, где роль хранится: так он получает всё, что старый владелец успел изменить.

После переноса PDC — обязательные действия из части 12: внешний источник времени на новом PDC, на старом вернуть иерархию. И проверить, что w32tm /query /source на остальных контроллерах через несколько минут показывает новый PDC.

Как перенос выглядит в каталоге — по метаданным репликации атрибута:

PS C:\> repadmin /showobjmeta dc1 "DC=corp,DC=example,DC=com" | Select-String fSMORoleOwner

24632420                                Office\DC2  28914334 2025-01-13 00:55:12    9 fSMORoleOwner

Колонки — локальный USN на dc1, контроллер, где изменение родилось, его USN там, время и версия атрибута. Роль сейчас у dc1, а последнее изменение fSMORoleOwner родилось на dc2: при переносе нового владельца записывает старый, и dc1 получил себя владельцем по репликации. При захвате, наоборот, изменение рождается на новом владельце.

Захват

Владелец умер — диск, пожар, виртуальная машина, которой больше нет, — и не вернётся. Перенос невозможен: не у кого забирать. Остаётся захват (seize): новый владелец записывает себя в fSMORoleOwner в одностороннем порядке.

PS C:\> Move-ADDirectoryServerOperationMasterRole -Identity dc2 -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster -Force -Confirm:$false

С -Force командлет сначала пытается перенести роль и захватывает её, только если перенос невозможен. Тот же ntdsutil с seize вместо transfer: seize pdc, seize rid master, seize naming master и так далее.

При захвате RID Master новый владелец сдвигает границу невыданных RID вперёд — Move-ADDirectoryServerOperationMasterRole на 30 000, ntdsutil на 10 000, — чтобы не выдать пул, который старый владелец мог раздать, но не успел реплицировать. Каждый лишний захват сжигает эти идентификаторы.

Правила захвата, от которых зависит, останется ли домен целым:

Не спешить. Контроллер, выключенный на час, не повод захватывать: PDC без владельца час терпит, остальные роли — недели. Захватывают, когда известно, что владелец не вернётся.

После захвата старый владелец в сеть не возвращается. Включившись, контроллер-владелец сначала ждёт входящей репликации и, если узнаёт из неё, что роль у другого, уступает её. Но если репликации с ним нет — он отрезан, а в изолированной части сети живут свои клиенты, — каждый из двух продолжит считать роль своей. Для PDC и Infrastructure Master это не страшно: они не создают постоянных данных. Для Schema Master это два места, где можно менять схему, для Domain Naming Master — два источника доменов и разделов, для RID Master — два источника пулов, и рано или поздно два контроллера получат один пул и создадут объекты с одинаковыми SID. Поэтому порядок такой: захват, затем очистка метаданных старого контроллера из каталога (часть 19), затем — если железо живо — переустановка с нуля или принудительное понижение, а не включение старой системы и не восстановление её из резервной копии.

Захватывать на контроллер, который был прямым партнёром репликации старого владельца. У него самая свежая копия раздела роли: для RID Master это означает, что он знает, какие пулы уже выданы; для PDC — что у него последние пароли.

В журнале Directory Service о ролях пишут два события: 2091 — владелец роли по каталогу удалён или не существует, и 2092 — контроллер владеет ролью, но не считает её действительной, потому что после перезапуска ещё ни разу не реплицировал раздел роли с партнёрами. 2092 появляется и после обычной перезагрузки владельца и пропадает с первой успешной репликацией; если ситуация не проходит, значит, репликации нет, а с ней — и роли.

Размещение

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

Что всё-таки стоит учитывать (рекомендации Microsoft):

  • PDC — на лучшем железе, в надёжном главном сайте, где есть другие контроллеры того же домена: к нему чаще всего обращаются.
  • RID Master — на том же контроллере, что PDC.
  • Schema Master и Domain Naming Master — на PDC корневого домена леса.
  • Infrastructure Master не на GC — только в многодоменном лесу без корзины Active Directory, где не все контроллеры — GC. Иначе — где угодно.
  • Контроллер только для чтения ролей не держит, и Move-ADDirectoryServerOperationMasterRole с ним не работает.
  • У владельца должен быть прямой партнёр репликации в том же сайте — кандидат на перенос или захват.
  • При выводе контроллера из домена (часть 19) роли переносятся заранее, переносом, а не захватом.

Смотрим руками

Что видят контроллер и Locator, когда ищут владельцев. Тест FsmoCheck ищет через Locator глобальный каталог, PDC, источники времени и KDC — то, что нужно контроллеру для работы:

PS C:\> dcdiag /s:dc1 /test:fsmocheck /v | Select-String 'Name:|Flags:'

         GC Name: \\dc1.corp.example.com
         Locator Flags: 0xe007f3fd
         PDC Name: \\dc1.corp.example.com
         Locator Flags: 0xe007f3fd
         Time Server Name: \\dc1.corp.example.com
         Locator Flags: 0xe007f3fd
         Preferred Time Server Name: \\dc1.corp.example.com
         Locator Flags: 0xe007f3fd
         KDC Name: \\dc1.corp.example.com
         Locator Flags: 0xe007f3fd

Preferred Time Server — контроллер с флагом надёжного источника времени, то есть PDC из части 12. Сами роли этот тест не проверяет. Иерархия времени держится на PDC — остальные контроллеры берут время у него:

PS C:\> Invoke-Command dc1, dc2, dc3, dc4 { [PSCustomObject]@{ Source = (w32tm /query /source).Trim() } } | Select-Object PSComputerName, Source

PSComputerName Source
-------------- ------
dc3            dc1.corp.example.com
dc2            dc1.corp.example.com
dc1            3.pool.ntp.org,0x8
dc4            dc1.corp.example.com

Если PDC выключить, контроллеры теряют этот источник (событие 129, часть 12), Locator перестаёт находить PDC, а Get-ADDomainController -Discover -Service PrimaryDC и nltest /pdc отвечают ошибкой. Пользователи по-прежнему входят — Kerberos выдают все контроллеры, — но пароль, только что сменённый на одном контроллере, на другом до репликации не сработает, а переспросить тому не у кого.

Как владелец подтверждает роль после перезагрузки — событие 2092 на dc1, записанное через минуту после старта службы:

PS C:\> Invoke-Command dc1 { Get-WinEvent -FilterHashtable @{LogName='Directory Service'; Id=2092} -MaxEvents 1 } | Select-Object -ExpandProperty Message

This server is the owner of the following FSMO role, but does not consider it valid. For the partition which contains the FSMO, this server has not replicated successfully with any of its partners since this server has been restarted. Replication errors are preventing validation of this role.

Operations which require contacting a FSMO operation master will fail until this condition is corrected.

FSMO Role: DC=corp,DC=example,DC=com

User Action:

1. Initial synchronization is the first early replications done by a system as it is starting. A failure to initially synchronize may explain why a FSMO role cannot be validated. This process is explained in KB article 305476.
2. This server has one or more replication partners, and replication is failing for all of these partners. Use the command repadmin /showrepl to display the replication errors.  Correct the error in question. For example there maybe problems with IP connectivity, DNS name resolution, or security authentication that are preventing successful replication.
3. In the rare event that all replication partners are expected to be offline (for example, because of maintenance or disaster recovery), you can force the role to be validated. This can be done by using NTDSUTIL.EXE to seize the role to the same server. This may be done using the steps provided in KB articles 255504 and 324801 on http://support.microsoft.com.

The following operations may be impacted:
Schema: You will no longer be able to modify the schema for this forest.
Domain Naming: You will no longer be able to add or remove domains from this forest.
PDC: You will no longer be able to perform primary domain controller operations, such as Group Policy updates and password resets for non-Active Directory Domain Services accounts.
RID: You will not be able to allocation new security identifiers for new user accounts, computer accounts or security groups.
Infrastructure: Cross-domain name references, such as universal group memberships, will not be updated properly if their target object is moved or renamed.

FSMO Role — DN объекта роли; корень домена — роль PDC (для Schema Master там был бы CN=Schema,CN=Configuration,…). После него 2092 на dc1 больше не появлялось: роль подтвердилась первой же успешной репликацией. Третий пункт — способ подтвердить роль, когда партнёров нет вовсе: захватить её на тот же контроллер.

Что видит контроллер, который не владеет RID Master, — dcdiag /test:ridmanager на dc2:

PS C:\> dcdiag /s:dc2 /test:ridmanager /v | Select-String 'rid'

      Starting test: RidManager
         * Available RID Pool for the Domain is 8100 to 1073741823
         * dc1.corp.example.com is the RID Master
         * DsBind with RID Master was successful
         * rIDAllocationPool is 5600 to 6099
         * rIDPreviousAllocationPool is 5600 to 6099
         * rIDNextRID: 5658
         ......................... DC2 passed test RidManager

DsBind with RID Master was successful — контроллер связался с владельцем по RPC; запасного пула пока нет (rIDAllocationPool равен rIDPreviousAllocationPool), из текущего израсходовано 58 идентификаторов из 500. Если RID Master недоступен, dcdiag сообщает, что связаться не удалось, контроллер работает на остатке текущего пула, а когда исчерпает его — в журнал System от источника Directory-Services-SAM пишется событие 16645 («The maximum account identifier allocated to this domain controller has been assigned…»), и создание объектов на нём останавливается до получения нового пула. Новые пулы запрашиваются и выдаются с событиями 16647 и 16648, неудачный запрос — 16651.

С Windows Server 2012 RID Master следит и за общим пространством RID: на каждые 10 % израсходованного пишет предупреждение 16658, при 90 % включает защиту — событие 16657, и новые пулы перестают выдаваться, пока администратор не снимет блок атрибутом msDS-RIDPoolAllocationEnabled; 31-й бит, удваивающий пространство до 2³¹ − 1, разблокируется отдельно (событие 16655). Это случалось в доменах, где скрипты создавали и удаляли объекты миллионами, а пулы сжигались лишними захватами и восстановлениями.

И наконец, двойники Infrastructure Master. Если dc2, владельца двойников из примера выше, выведут из домена аварийно, fSMORoleOwner в DNS-разделах будет указывать на удалённый объект. Назначить владельцем живой контроллер, на котором есть эти разделы и который был прямым партнёром старого, — записью атрибута на нём самом:

PS C:\> $owner = (Get-ADDomainController dc1).NTDSSettingsObjectDN
PS C:\> Set-ADObject 'CN=Infrastructure,DC=DomainDnsZones,DC=corp,DC=example,DC=com' -Server dc1 -Replace @{ fSMORoleOwner = $owner }
PS C:\> Set-ADObject 'CN=Infrastructure,DC=ForestDnsZones,DC=corp,DC=example,DC=com' -Server dc1 -Replace @{ fSMORoleOwner = $owner }

Объект NTDS Settings с \0ADEL в имени — удалённый, tombstone из части 5; роль разделов приложений осталась указывать на него, а пять обычных ролей эти разделы не затрагивают. Прямая запись в fSMORoleOwner здесь — способ, который описывает и Microsoft (так делает её скрипт fixfsmo.vbs), и он же показывает, что роль — это всего лишь атрибут.

Источники

Мы научились находить владельцев, переносить и захватывать роли и знаем, что ломается без каждой. Но в большинстве случаев, когда «домен не работает», дело не в ролях, а в репликации, DNS или времени, и признаки похожи. Следующая часть — о том, как отличить одно от другого.

Дальше — часть 18: диагностика. Порядок проверки от dcdiag к repadmin и журналам; nltest и netlogon.log; типичные причины и их признаки: время, DNS, защищённый канал; lingering objects и как их вычищать; USN rollback — откат контроллера к снимку и что делает каталог, обнаружив его; срок жизни tombstone и контроллер, который не реплицировался полгода.

Оставить комментарий могут только зарегистрированные пользователи.

Войдите на сайт или зарегистрируйтесь, чтобы оставить комментарий.

© 2006-2026 Виталий Лещенко