29 октября 2026, 16:57Виталий Лещенко

Windows Server для самых маленьких. Часть 21: Как устроены несколько доменов и лесов?

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

Коротко

Домены одного леса делят схему, конфигурацию, глобальный каталог и группу Enterprise Admins и связаны автоматическим двусторонним транзитивным доверием, по которому Kerberos ходит направляющими билетами. Своё у домена — пользователи, Domain Admins, политики и раздел, который целиком реплицируется только на его контроллеры, а на глобальные каталоги — частичной копией. Граница безопасности — лес, а не домен: контроллер любого домена может изменить общие разделы и выпустить билет с SID администраторов леса. Второй лес нужен, когда чужой администрации не доверяют; дочерний домен создают Install-ADDSDomain.

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

Что общего у доменов леса

Лес corp.example.com с дочерним доменом eu.corp.example.com и вторым деревом shop.example.net:

 Лес corp.example.com
 ┌─────────────────────────────────────────────────────────────────────────┐
 │ Схема ──────────── одна на всех: класс, добавленный для Exchange в      │
 │                    corp, есть и в eu, и в shop                          │
 │ Конфигурация ───── одна: сайты, подсети, связи сайтов, разделы,         │
 │                    шаблоны сертификатов, авторизованные DHCP-серверы    │
 │ Глобальный каталог общий: GC любого домена знает имена, SID и частичный │
 │                    набор атрибутов всех объектов трёх доменов           │
 │ Доверие ────────── автоматическое, двустороннее, транзитивное:          │
 │                    corp ↔ eu (родитель-ребёнок), corp ↔ shop (корень    │
 │                    дерева); eu доверяет shop через corp                 │
 │ Enterprise Admins  группа корневого домена с правами на всё             │
 │ Schema Admins ──── то же для схемы                                      │
 │ UPN-суффиксы ───── список на лес: суффикс example.com годится в любом   │
 │                    домене, а сам UPN уникален во всём лесу              │
 │ Разделы DNS ────── ForestDnsZones и зона _msdcs корня: в ней записи     │
 │                    GC и контроллеров всех доменов леса                  │
 │ Функциональный уровень леса, корзина AD, KDS Root Key для gMSA          │
 └─────────────────────────────────────────────────────────────────────────┘

 Домен corp.example.com      Домен eu.corp.example.com     Домен shop.example.net
 ┌──────────────────────┐    ┌──────────────────────┐      ┌──────────────────────┐
 │ свои пользователи,   │    │ свои                 │      │ свои                 │
 │ компьютеры, группы   │    │                      │      │                      │
 │ свой SID домена      │    │ свой                 │      │ свой                 │
 │ свой krbtgt          │    │ свой                 │      │ свой                 │
 │ свои Domain Admins   │    │ свои                 │      │ свои                 │
 │ свои GPO             │    │ свои                 │      │ свои                 │
 │ своя парольная       │    │ своя                 │      │ своя                 │
 │   политика           │    │                      │      │                      │
 │ свои контроллеры,    │    │ свои                 │      │ свои                 │
 │   минимум два        │    │                      │      │                      │
 │ DomainDnsZones       │    │ своя                 │      │ своя                 │
 └──────────────────────┘    └──────────────────────┘      └──────────────────────┘

Каталог леса делится на разделы (naming contexts), и каждый реплицируется по своим правилам. Схема и конфигурация — на все контроллеры леса. Раздел домена DC=eu,DC=corp,… — полностью только на контроллеры eu, а на глобальные каталоги остальных доменов — частичной копией: объекты со всеми атрибутами, помеченными в схеме isMemberOfPartialAttributeSet (имя, SID, UPN, почта, телефон, отдел и ещё несколько сотен), и членство только универсальных групп — у глобальных и доменно-локальных групп в GC есть сам объект, но нет членов. Разделы приложений DomainDnsZones (свой у каждого домена) и ForestDnsZones (один на лес) хранят зоны DNS и реплицируются только на контроллеры с DNS-сервером, которые перечислены в их crossRef; в глобальный каталог они не попадают.

Домен — единица репликации данных: пользователи европейского подразделения целиком хранятся только на контроллерах eu. Домен — единица администрирования: у него свои Domain Admins, свои политики, своя парольная политика. Домен — единица именования: EU\alice и CORP\alice — разные люди.

Но контроллеры всех доменов стоят в одних сайтах, подчиняются одной конфигурации, и у всех у них один список администраторов, которые могут всё: Enterprise Admins корневого домена.

Зачем были нужны дочерние домены

Четыре причины из 2000 года, и что с ними стало:

Репликация по медленным каналам. В Windows 2000 наименьшей единицей репликации был атрибут целиком: добавление одного члена в группу пересылало весь атрибут member, поэтому группы больше 5000 членов не поддерживались, а крупный домен за медленным каналом обходился дорого. Отдельный домен в филиале держал его данные дома. С уровнем леса Windows Server 2003 значения связанных атрибутов реплицируются по отдельности (linked-value replication), между сайтами репликация идёт со сжатием и по расписанию (часть 10), а в филиале стоит RODC (часть 11). Причина ушла.

Разные парольные политики. До 2008 года политика паролей была одна на домен: нужна строгая для администраторов и мягкая для цеха — два домена. С Windows Server 2008 есть гранулярные политики (часть 13). Причина ушла.

Административное разделение. Подразделение хочет своих администраторов, которые не могут трогать чужое. Делегирование на OU даёт то же самое внутри домена, а отдельный домен даёт это лишь на бумаге, о чём ниже. Причина ушла.

Юридические требования к размещению данных. Персональные данные сотрудников европейской компании не должны храниться на серверах за пределами ЕС. Раздел домена eu целиком реплицируется только на контроллеры eu, и это единственный механизм в каталоге, который даёт такую гарантию — с оговоркой: частичная копия (имя, почта, телефон, отдел — всё из частичного набора атрибутов) уезжает на все глобальные каталоги леса. Эта причина осталась, и это главная причина, по которой сегодня создают дочерние домены.

Цена дочернего домена: минимум два контроллера на домен (отказоустойчивость не делится между доменами), глобальные каталоги с частичными копиями всех доменов, правила областей групп (часть 3), отдельный набор политик, отдельные Domain Admins, которых тоже нужно контролировать, и путь Kerberos через два-три KDC при каждом обращении в чужой домен.

Почему домен — не граница безопасности

Администратор дочернего домена eu не должен иметь прав в corp. У него их и нет — по спискам доступа. Но у него есть контроллер домена, а на контроллере — доступные на запись копии разделов схемы и конфигурации, общих для всего леса. Под учётной записью SYSTEM контроллер может изменить в них что угодно, и изменение реплицируется на контроллеры корневого домена как обычное: каждый контроллер леса доверяет каждому другому контроллеру леса.

У него есть ключ krbtgt своего домена. С ним можно выпустить себе билет, в PAC которого, кроме собственных групп, записан SID группы Enterprise Admins корневого домена. Внутри леса такие SID не фильтруются: спецификация PAC отбрасывает «чужие» привилегированные SID только на доверии к другому лесу, на внешнем доверии и на доверии, помеченном карантином (о фильтрации SID — в следующей части). Корневой домен примет этот билет так же, как билет настоящего администратора леса. То же даёт запись этого SID в sIDHistory объекта на собственном контроллере.

Ни один из этих путей не требует ничего, кроме прав Domain Admins дочернего домена и желания. Microsoft формулирует это так: каждый лес — отдельный экземпляр каталога и граница безопасности, а домен — граница администрирования. Администратор любого домена леса технически способен стать администратором леса, и защищают от этого только доверие к этому человеку и аудит. Если доверия нет — подразделение, подрядчик, купленная компания с собственными администраторами, — второй домен ничего не даёт. Нужен второй лес.

Когда нужен второй лес

Отдельная администрация, которой не доверяют безусловно. Купленная компания до интеграции, подрядчик, совместное предприятие.
Схема. Два продукта с несовместимыми расширениями схемы, два Exchange (один лес — одна организация Exchange), приложение, требующее схему, которую не хотят в основном лесу.
Тестовый лес для расширений схемы и изменений, которые нельзя отменить (часть 5): копия структуры, на которой проверяют LDIF-файл перед загрузкой в рабочий.
Периметр. Лес для серверов в DMZ с односторонним доверием к внутреннему, чтобы взлом веб-сервера не давал ничего внутри.
Административный лес. Отдельный лес для учётных записей администраторов основного леса (модель ESAE, «красный лес»): рабочие станции и учётные записи уровня 0 из части 15 живут там, основной лес доверяет ему односторонне. Microsoft больше не рекомендует эту модель по умолчанию и считает её особой конфигурацией для исключительных случаев — изолированных сред без облачных служб; существующие административные леса, если они работают так, как задумано, выводить не требуется.

Цена второго леса: нет общего глобального каталога (Outlook не найдёт адресата из другого леса без отдельной настройки), нет автоматического доверия, приложения, рассчитанные на один лес, не работают поверх двух, синхронизация с Entra ID усложняется, и каждая пара лесов — это доверие, которое нужно настроить, обслуживать и защищать.

Kerberos между доменами

Пользователь alice@eu.corp.example.com открывает \\fs1.corp.example.com\share. У её KDC в eu нет ключа FS1$ — он в другом домене. KDC eu не находит SPN cifs/fs1.corp.example.com в своём разделе, спрашивает глобальный каталог, в каком домене леса он зарегистрирован, и выдаёт направляющий билет (referral): TGT для realm CORP.EXAMPLE.COM, зашифрованный ключом доверия между доменами. С ним она идёт в KDC corp:

 ws-eu (alice@EU)          KDC eu                     KDC corp                  fs1 (corp)
   │                          │                          │                         │
   ├─ TGS-REQ cifs/fs1.corp ─►│                          │                         │
   │                          │ не мой realm →           │                         │
   │◄─ TGS-REP: TGT для CORP, │                          │                         │
   │   {…}K_trust(eu→corp) ───┤                          │                         │
   ├─ TGS-REQ cifs/fs1.corp с этим TGT ─────────────────►│                         │
   │                          │                          │ расшифровать ключом     │
   │                          │                          │ доверия; alice из EU,   │
   │                          │                          │ группы из PAC + её      │
   │                          │                          │ членство в группах corp │
   │◄─ TGS-REP: билет на fs1 {…}K_fs1$ ──────────────────┤                         │
   ├─ AP-REQ ─────────────────────────────────────────────────────────────────────►│

Ключ доверия — общий пароль двух доменов. Он хранится в объекте доверия (trusted domain object, TDO) в CN=System и в учётной записи доверия — пользователе EU$ с флагом INTERDOMAIN_TRUST_ACCOUNT в CN=Users домена corp (и CORP$ — в eu). Пароль меняется автоматически раз в 30 дней, как пароль компьютера: смену начинает эмулятор PDC доверяющего домена, а двустороннее доверие — это два односторонних, и пароль каждого направления меняется отдельно. С каждым шагом realm добавляется в поле transited билета, и конечная служба видит, через какие домены прошла аутентификация. Путь между доменами разных деревьев (us.eu.corp.example.com → shop.example.net) идёт по доверию родитель-ребёнок до корня леса и от него вниз, через три-четыре KDC; сокращающее доверие (shortcut trust) между двумя удалёнными доменами спрямляет его.

Группы складываются в PAC по дороге. Глобальные группы eu и универсальные группы леса контроллер eu записал ещё при входе (универсальные — узнав членство из GC). Доменно-локальные группы corp, в которые входит alice, добавляет KDC corp, когда выдаёт билет на fs1. Правила областей из части 3 — следствие этого механизма.

Создание дочернего домена

Контроллер dc-eu1 подготовлен как в части 1, DNS-клиент указывает на контроллер corp. Повышение в новый домен — третий командлет из модуля ADDSDeployment, которого мы ещё не использовали; выполняется он, как в части 4, на консоли самого сервера:

PS C:\> Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
PS C:\> Install-ADDSDomain -NewDomainName eu -ParentDomainName corp.example.com -DomainType ChildDomain -NewDomainNetbiosName EU -DomainMode WinThreshold -Credential (Get-Credential CORP\alice.admin) -InstallDns -CreateDnsDelegation -SiteName Office -SafeModeAdministratorPassword (Read-Host -AsSecureString) -Force

Для дочернего домена -NewDomainName — одна метка (eu), полное имя складывается с -ParentDomainName. Учётная запись должна быть в Enterprise Admins: создание домена — операция уровня леса, и она выполняется через владельца роли Domain Naming Master (часть 17). -DomainMode не может быть ниже уровня леса, выше — может. -CreateDnsDelegation создаёт в зоне corp.example.com делегирование eu на новый контроллер. Что происходит, помимо обычного повышения:

в CN=Partitions появляется объект crossRef для DC=eu,DC=corp,DC=example,DC=com с именем, равным NetBIOS-имени домена (EU), dnsRoot, nETBIOSName и собственным функциональным уровнем в msDS-Behavior-Version;
создаётся раздел домена с новым SID, собственными krbtgt, Administrator, Domain Admins и остальными встроенными объектами, и раздел приложений DomainDnsZones домена eu для его зоны DNS;
в CN=System обоих доменов создаются объекты trustedDomain друг на друга, а в CN=Users — учётные записи доверия EU$ и CORP$: двустороннее транзитивное доверие родитель-ребёнок со сгенерированным паролем;
контроллер eu регистрирует записи уровня леса — свой CNAME <GUID>._msdcs, запись _ldap._tcp.<GUID домена>.domains и, если он GC, записи gc — в зоне _msdcs.corp.example.com корня леса, а записи своего домена (_ldap._tcp.dc._msdcs.eu.corp.example.com и другие) — в зоне eu.corp.example.com;
первый контроллер по умолчанию становится глобальным каталогом (отключает это -NoGlobalCatalog), а все GC леса начинают держать частичную копию нового домена.

Новое дерево — тот же командлет с -DomainType TreeDomain -NewDomainName shop.example.net -ParentDomainName corp.example.com: -NewDomainName здесь полное имя, которое не является потомком существующего, а доверие — tree-root с корнем леса вместо parent-child. Зона shop.example.net должна разрешаться из всего леса — её кладут в раздел ForestDnsZones.

В выводе знакомых командлетов после этого Get-ADForest показывает в Domains оба домена, а в GlobalCatalogs — и dc-eu1; у Get-ADDomain corp.example.com в ChildDomains появляется eu.corp.example.com, а в SubordinateReferences — раздел DC=eu,…; Get-ADTrust -Filter * на стороне corp показывает доверие eu.corp.example.com с Direction BiDirectional, IntraForest True и TrustAttributes 32 (бит WITHIN_FOREST).

Три доменные роли FSMO у нового домена — на его первом контроллере; две лесные остались в corp. Второй контроллер для eu — Install-ADDSDomainController -DomainName eu.corp.example.com, как в части 10, и без него домен eu — домен с одной копией данных.

Жизнь с несколькими доменами

Поиск. Get-ADUser -Server eu.corp.example.com ищет в eu; -Server corp.example.com:3268 — во всём лесу через глобальный каталог, но только по атрибутам частичного набора. При входе по UPN контроллер ищет его сначала в своём домене, затем в GC, потому что домен из UPN не следует: alice@example.com может быть в любом домене. Сам суффикс example.com — не имя домена леса, поэтому его сначала добавляют в список альтернативных суффиксов леса (uPNSuffixes контейнера CN=Partitions, командлет Set-ADForest -UPNSuffixes @{Add='example.com'}); без этого UPN может оканчиваться только на имя одного из доменов леса.

Группы. Глобальная группа eu может быть членом доменно-локальной группы corp, и это основной способ дать пользователям eu доступ к ресурсам corp. Универсальные группы с членами из обоих доменов хранятся в GC вместе с членством, и их изменения реплицируются по всему лесу — удобно для почтовых списков, дорого для групп с тысячами членов, которые часто меняются.

Перенос объектов. Пользователя можно перенести из eu в corp внутри леса: Move-ADObject -Identity $dn -TargetPath 'OU=Sales,OU=Departments,DC=corp,DC=example,DC=com' -Server dc-eu1.eu.corp.example.com -TargetServer dc1.corp.example.com. Оба сервера должны быть владельцами роли RID Master в своих доменах (-TargetServer — полным именем), иначе командлет отвечает «The requested operation could not be performed because the directory service is not the master for that type of operation». Пароль переезжает вместе с объектом, объект получает новый SID в новом домене, старый записывается в sIDHistory, и права на ресурсы, выданные на старый SID, продолжают работать. Перенос между лесами устроен иначе — отдельными средствами миграции — и в серии не разбирается.

Политики и делегирование — на уровне домена, в каждом свои. Политику, которая должна быть одинаковой в обоих, копируют: Copy-GPO -SourceName 'Workstations Baseline' -SourceDomain eu.corp.example.com -TargetName 'Workstations Baseline' -TargetDomain corp.example.com (с -MigrationTable, если в ней есть SID и пути исходного домена).

Администраторы. Domain Admins eu при вводе машины в домен попадают в её локальную группу Administrators — на машинах eu, и только там. Enterprise Admins входят во встроенную группу Administrators каждого домена леса, то есть в администраторы всех контроллеров. По умолчанию в Enterprise Admins только Administrator корневого домена; группу держат пустой и добавляют в неё на время операций, которые её требуют: создание домена, авторизация DHCP, расширение схемы.

Переименование. Домен внутри леса можно переименовать утилитой rendom и даже переставить в другое место дерева (сменить родителя); после этого каждый член переименованного домена перезагружают дважды. Перенести домен в другой лес или объединить леса так нельзя, а в лесу с Exchange 2007 и 2010 переименование не поддерживается. Это операция уровня «один раз в жизни леса», и обычно проще создать новый домен и перенести в него объекты.

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

У нашего леса пока один домен, и на нём хорошо видно всё, что потом размножится. Команды выполняются на рабочей станции ws1 в PowerShell 7. Лес и домен:

PS C:\> Get-ADForest | Select-Object Name, RootDomain, Domains, ApplicationPartitions, GlobalCatalogs, UPNSuffixes, Sites

Name                  : corp.example.com
RootDomain            : corp.example.com
Domains               : {corp.example.com}
ApplicationPartitions : {DC=DomainDnsZones,DC=corp,DC=example,DC=com, DC=ForestDnsZones,DC=corp,DC=example,DC=com}
GlobalCatalogs        : {dc2.corp.example.com, dc1.corp.example.com, dc3.corp.example.com, dc4.corp.example.com}
UPNSuffixes           : {}
Sites                 : {Office, Branch}

PS C:\> Get-ADDomain | Select-Object DNSRoot, NetBIOSName, ParentDomain, ChildDomains, DomainMode, SubordinateReferences

DNSRoot               : corp.example.com
NetBIOSName           : CORP
ParentDomain          :
ChildDomains          : {}
DomainMode            : Windows2016Domain
SubordinateReferences : {DC=DomainDnsZones,DC=corp,DC=example,DC=com, DC=ForestDnsZones,DC=corp,DC=example,DC=com, CN=Configuration,DC=corp,DC=example,DC=com}

UPNSuffixes пуст: альтернативных суффиксов нет, и UPN пользователей оканчиваются на corp.example.com. SubordinateReferences — разделы, которые лежат «под» разделом домена в дереве имён: оба раздела DNS и конфигурация; у корня леса с дочерним доменом здесь же был бы DC=eu,….

Разделы, которые хранит контроллер, — в namingContexts его RootDSE:

PS C:\> (Get-ADRootDSE).namingContexts
DC=corp,DC=example,DC=com
CN=Configuration,DC=corp,DC=example,DC=com
CN=Schema,CN=Configuration,DC=corp,DC=example,DC=com
DC=ForestDnsZones,DC=corp,DC=example,DC=com
DC=DomainDnsZones,DC=corp,DC=example,DC=com

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

Каждый раздел описан объектом crossRef в CN=Partitions конфигурации:

PS C:\> Get-ADObject -SearchBase (Get-ADForest).PartitionsContainer -LDAPFilter '(objectClass=crossRef)' -Properties nCName, nETBIOSName, systemFlags, msDS-Behavior-Version, msDS-NC-Replica-Locations | Format-Table nCName, nETBIOSName, systemFlags, msDS-Behavior-Version, @{n='Replicas'; e={$_.'msDS-NC-Replica-Locations'.Count}} -AutoSize

nCName                                               nETBIOSName systemFlags msDS-Behavior-Version Replicas
------                                               ----------- ----------- --------------------- --------
CN=Configuration,DC=corp,DC=example,DC=com                                 1                              0
CN=Schema,CN=Configuration,DC=corp,DC=example,DC=com                       1                              0
DC=ForestDnsZones,DC=corp,DC=example,DC=com                                5                              4
DC=DomainDnsZones,DC=corp,DC=example,DC=com                                5                              4
DC=corp,DC=example,DC=com                            CORP                  3 7                            0

systemFlags — биты из спецификации: 1 — раздел этого леса (а не внешний), 2 — раздел домена, 4 — раздел не реплицируется в глобальный каталог. Конфигурация и схема — 1, домен — 3 (1 + 2), разделы DNS — 5 (1 + 4), то есть разделы приложений. Список контроллеров с копией (msDS-NC-Replica-Locations) есть только у разделов приложений — четыре контроллера с DNS; домен, схема и конфигурация лежат на всех контроллерах своего домена и леса по определению. Функциональный уровень (msDS-Behavior-Version) записан только у домена: 7 — Windows Server 2016. Уровни доменов независимы, но ни один не может быть ниже уровня леса. Имена объектов crossRef в таблице не показаны: у домена это NetBIOS-имя CORP, у разделов DNS — GUID, у схемы и конфигурации — Enterprise Schema и Enterprise Configuration.

Партнёры репликации — по каждому разделу отдельно:

PS C:\> repadmin /showrepl dc1 | Select-String '^(DC|CN)=|via RPC'
DC=corp,DC=example,DC=com
    Branch\DC3 via RPC
    Office\DC2 via RPC
CN=Configuration,DC=corp,DC=example,DC=com
    Office\DC2 via RPC
    Branch\DC3 via RPC
CN=Schema,CN=Configuration,DC=corp,DC=example,DC=com
    Office\DC2 via RPC
    Branch\DC3 via RPC
DC=ForestDnsZones,DC=corp,DC=example,DC=com
    Branch\DC3 via RPC
    Office\DC2 via RPC
DC=DomainDnsZones,DC=corp,DC=example,DC=com
    Office\DC2 via RPC
    Branch\DC3 via RPC

Разделы приложений здесь видны; Get-ADReplicationPartnerMetadata -Partition * их не показывает — только домен, конфигурацию и схему.

Частичный набор атрибутов — это атрибуты схемы с isMemberOfPartialAttributeSet:

PS C:\> $schema = (Get-ADRootDSE).schemaNamingContext
PS C:\> (Get-ADObject -SearchBase $schema -LDAPFilter '(objectClass=attributeSchema)').Count
3952
PS C:\> (Get-ADObject -SearchBase $schema -LDAPFilter '(&(objectClass=attributeSchema)(isMemberOfPartialAttributeSet=TRUE))').Count
697
PS C:\> (Get-ADObject -SearchBase $schema -LDAPFilter '(&(objectClass=attributeSchema)(isMemberOfPartialAttributeSet=TRUE)(!(lDAPDisplayName=msExch*)))').Count
310

Схема этого леса расширена для Exchange, и больше половины атрибутов в частичном наборе — его (msExch*). Что это значит на практике, видно, если прочитать один объект через порт GC 3268 и через обычный LDAP:

PS C:\> $dn = (Get-ADUser Administrator).DistinguishedName
PS C:\> $gc = Get-ADObject $dn -Server dc1:3268 -Properties *
PS C:\> $dc = Get-ADObject $dn -Server dc1 -Properties *
PS C:\> $gc.PropertyNames.Count; $dc.PropertyNames.Count
39
53
PS C:\> $dc.PropertyNames | Where-Object { $_ -notin $gc.PropertyNames }
accountExpires
adminCount
badPasswordTime
badPwdCount
codePage
countryCode
isCriticalSystemObject
lastLogoff
lastLogon
lockoutTime
logonCount
logonHours
msDS-SupportedEncryptionTypes
msExchPreviousRecipientTypeDetails

Через порт 3268 даже контроллер собственного домена отдаёт только частичный набор: счётчики входов, блокировка, срок действия учётной записи — не для глобального поиска.

Области встроенных групп:

PS C:\> Get-ADGroup -Filter "Name -eq 'Administrators' -or Name -eq 'Domain Admins' -or Name -eq 'Enterprise Admins' -or Name -eq 'Schema Admins' -or Name -eq 'Domain Users'" | Sort-Object Name | Format-Table Name, GroupScope, DistinguishedName -AutoSize

Name               GroupScope DistinguishedName
----               ---------- -----------------
Administrators    DomainLocal CN=Administrators,CN=Builtin,DC=corp,DC=example,DC=com
Domain Admins          Global CN=Domain Admins,CN=Users,DC=corp,DC=example,DC=com
Domain Users           Global CN=Domain Users,CN=Users,DC=corp,DC=example,DC=com
Enterprise Admins   Universal CN=Enterprise Admins,CN=Users,DC=corp,DC=example,DC=com
Schema Admins       Universal CN=Schema Admins,CN=Users,DC=corp,DC=example,DC=com

PS C:\> Get-ADGroupMember Administrators | Where-Object objectClass -eq 'group' | Select-Object Name

Name
----
Domain Admins
Enterprise Admins

Enterprise Admins и Schema Admins — универсальные: они существуют только в корневом домене, а действовать должны во всём лесу. Domain Admins — глобальная группа своего домена. Administrators — доменно-локальная встроенная группа; Enterprise Admins входит в неё в каждом домене леса, отсюда их права на все контроллеры.

Зона _msdcs корня леса и записи глобальных каталогов в ней:

PS C:\> Get-DnsServerZone -ComputerName dc1 -Name _msdcs.corp.example.com | Format-Table ZoneName, ReplicationScope, DirectoryPartitionName -AutoSize

ZoneName                ReplicationScope DirectoryPartitionName
--------                ---------------- ----------------------
_msdcs.corp.example.com Forest           ForestDnsZones.corp.example.com

PS C:\> Get-DnsServerResourceRecord -ComputerName dc1 -ZoneName _msdcs.corp.example.com -RRType Srv | Where-Object HostName -like '*gc' | Format-Table HostName, @{n='Target'; e={$_.RecordData.DomainName}}, @{n='Port'; e={$_.RecordData.Port}} -AutoSize

HostName                    Target                Port
--------                    ------                ----
_ldap._tcp.Branch._sites.gc dc4.corp.example.com. 3268
_ldap._tcp.Branch._sites.gc dc3.corp.example.com. 3268
_ldap._tcp.Office._sites.gc dc1.corp.example.com. 3268
_ldap._tcp.Office._sites.gc dc2.corp.example.com. 3268
_ldap._tcp.gc               dc3.corp.example.com. 3268
_ldap._tcp.gc               dc2.corp.example.com. 3268
_ldap._tcp.gc               dc1.corp.example.com. 3268
_ldap._tcp.gc               dc4.corp.example.com. 3268

Зона лежит в ForestDnsZones, то есть на DNS-серверах всех доменов леса. В ней же зарегистрировался бы dc-eu1, если он GC, — и клиенты corp нашли бы глобальный каталог в eu, если ближе никого нет.

Наконец, домены леса глазами nltest:

PS C:\> nltest /domain_trusts /forest
List of domain trusts:
    0: CORP corp.example.com (NT 5) (Forest Tree Root) (Primary Domain) (Native)
The command completed successfully

/forest ограничивает список доменами своего леса. Строка — наш домен: корень дерева (Forest Tree Root), домен этой машины (Primary Domain), NT 5 — домен Active Directory. С дочерним доменом в списке появилась бы вторая строка, EU eu.corp.example.com, с флагами Direct Outbound и Direct Inbound (прямое доверие в обе стороны) и атрибутом withinforest. У объекта trustedDomain такого доверия trustDirection 3 — двустороннее, trustType 2 — Active Directory, trustAttributes 32 — бит WITHIN_FOREST; у доверия к другому лесу вместо него будет бит FOREST_TRANSITIVE (8). А в кеше билетов alice после обращения к fs1 (klist) — три билета: свой TGT krbtgt/EU.CORP.EXAMPLE.COM @ EU.CORP.EXAMPLE.COM, направляющий krbtgt/CORP.EXAMPLE.COM @ EU.CORP.EXAMPLE.COM, выданный KDC eu (realm после @ — кто выдал), и сервисный cifs/fs1.corp.example.com @ CORP.EXAMPLE.COM, выданный уже KDC corp.

Источники

Understanding the Active Directory Logical Model и Appendix A: Reviewing Key AD DS Terms — лес, домен как раздел и единица администрирования, лес как граница безопасности;
Determining the Number of Forests Required — когда нужен отдельный лес и почему один лес дешевле;
Enhanced Security Admin Environment (ESAE) architecture mainstream retirement — административный лес как особая конфигурация;
How Domain and Forest Trusts Work — TDO, смена пароля доверия раз в 30 дней, parent-child и tree-root, сокращающие доверия, обработка направляющих билетов;
[MS-PAC]: SID Filtering and Claims Transformation — какие SID фильтруются на каких довериях, отсутствие фильтрации внутри леса, карантин;
[MS-ADTS]: trustAttributes — биты WITHIN_FOREST, FOREST_TRANSITIVE и остальные;
[MS-ADTS]: Cross-Ref Objects и [MS-ADTS]: System Flags — объекты crossRef и биты systemFlags разделов;
Global catalog replication — частичный набор атрибутов и членство групп в GC;
How the Active Directory Replication Model Works — репликация атрибутами в Windows 2000, предел в 5000 членов, linked-value replication;
Active Directory security groups — области групп, Enterprise Admins и Schema Admins;
User Naming Attributes — UPN, его уникальность в лесу, upnSuffixes, проверка по GC, sIDHistory при переносе между доменами;
Active Directory Domain Services Functional Levels — уровень домена не ниже уровня леса;
Install-ADDSDomain — параметры создания дочернего домена и нового дерева;
Get-ADForest, Get-ADDomain, Get-ADTrust и Set-ADForest — свойства леса, домена и доверий, суффиксы UPN;
Move-ADObject — перенос между доменами леса через владельцев RID Master;
Copy-GPO — копирование политики между доменами леса;
Get-ADReplicationPartnerMetadata — партнёры репликации из PowerShell;
Administering Active Directory Domain Rename и Restart Member Computers — что умеет переименование домена, ограничения Exchange, две перезагрузки членов домена;
Verify SRV DNS records have been created — записи контроллера в _msdcs;
Nltest — /domain_trusts и его ключи.

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

Дальше — часть 22: доверие между лесами. Типы доверий — внешнее, между лесами, сокращающее, с realm; направление и транзитивность; что должен уметь DNS каждого леса о другом; netdom trust и классы .NET вместо отсутствующего командлета создания доверия, и проверка; фильтрация SID и выборочная аутентификация; маршрутизация суффиксов имён и что происходит, когда в двух лесах один UPN-суффикс.