Отредактирована 18 октября 2026, 11:15Виталий Лещенко

Windows Server для самых маленьких. Часть 3: как устроен Active Directory

До Active Directory у каждого сервера Windows была своя база учётных записей — SAM, Security Account Manager — и пользователь с десятью серверами имел десять паролей. Домены Windows NT решили это наполовину: один сервер, PDC, держал базу, остальные контроллеры, BDC, получали копию только для чтения, а база оставалась плоским списком имён на 40 тысяч записей без какой-либо структуры и с собственным протоколом на всё. В Windows 2000 Microsoft заменила это каталогом, собранным из открытых стандартов: данные лежат в LDAP-каталоге, аутентификацию делает Kerberos, серверы находят через DNS, а репликация идёт между равными контроллерами без единственного хозяина. Так появился Active Directory, и за 26 лет его устройство почти не изменилось.

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

Лес, дерево, домен, OU

 Лес (forest)  corp.example.com
 ┌─────────────────────────────────────────────────────────────┐
 │  общая схема, общая конфигурация, Enterprise Admins         │
 │                                                             │
 │   Дерево 1                            Дерево 2              │
 │   corp.example.com  ◄── корневой      shop.example.net      │
 │     │   домен леса                                          │
 │     ├── eu.corp.example.com  ◄── дочерний домен             │
 │     └── us.corp.example.com                                 │
 │                                                             │
 │   Внутри домена corp.example.com:                           │
 │     OU=Departments                                          │
 │       ├── OU=Sales                                          │
 │       │     ├── CN=Alice                                    │
 │       │     └── CN=Bob                                      │
 │       └── OU=IT                                             │
 │     OU=Servers                                              │
 │     OU=Workstations                                         │
 └─────────────────────────────────────────────────────────────┘

Домен — единица администрирования и репликации. У него есть DNS-имя (corp.example.com), короткое NetBIOS-имя (CORP), своя база пользователей, компьютеров и групп, своя парольная политика и свои администраторы — группа Domain Admins. Контроллеры домена хранят полную копию его данных и реплицируют их между собой.

Дерево — цепочка доменов с непрерывным пространством имён: eu.corp.example.com — дочерний домен для corp.example.com. Между родителем и ребёнком автоматически создаётся двустороннее транзитивное доверие, поэтому пользователь любого домена дерева может получить доступ к ресурсам любого другого.

Лес — одно или несколько деревьев, у которых общие схема и конфигурация. Первый созданный домен — корневой домен леса, и это навсегда: переименовать можно, сделать корневым другой домен нельзя. В корневом домене живут две группы с полномочиями на весь лес: Enterprise Admins и Schema Admins. Лес — это граница безопасности: администратор любого домена леса технически может получить права в любом другом (через схему, конфигурацию или подделку SID в репликации), поэтому «отдельный домен для подразделения, которому мы не доверяем» не работает. Если нужна настоящая изоляция, нужен отдельный лес, и об этом разговор в части про несколько лесов.

Правило для начинающих: один лес, один домен. Дочерние домены нужны в двух случаях — когда юридически требуется отдельная парольная политика (с Windows Server 2008 это решается гранулярными политиками внутри одного домена) и когда подразделение так велико, что репликация его объектов по медленным каналам становится проблемой. Оба случая редки. Многодоменные леса, с которыми вы встретитесь, чаще всего построены в те годы, когда гранулярных политик ещё не было, или появились при слиянии компаний.

Организационное подразделение (OU, organizational unit) — контейнер внутри домена. OU нужны ровно для двух вещей: привязывать групповые политики и делегировать административные права. «Пользователи отдела продаж получают эти настройки, а их создаёт и сбрасывает им пароли вот этот человек» — это OU. Структура OU не влияет на безопасность доступа к ресурсам, не отражается в имени входа и не видна пользователю; это внутренняя организация каталога для администратора.

Рядом с OU есть контейнеры — CN=Users, CN=Computers, CN=Builtin, CN=System. Они создаются при установке домена, и к ним нельзя привязать групповую политику. Новые пользователи и компьютеры по умолчанию попадают в Users и Computers, и первое, что делает администратор, — переносит их в свои OU или перенаправляет умолчание командами redirusr и redircmp.

Имена

У каждого объекта в каталоге несколько имён, и они путаются.

Distinguished name, DN — путь к объекту в дереве, записанный от листа к корню:

CN=Alice,OU=Sales,OU=Departments,DC=corp,DC=example,DC=com

CN — common name объекта, OU — подразделение, DC — domain component: домен corp.example.com разбивается на три компонента. DN уникален в лесу и меняется, когда объект переносят в другую OU, поэтому ссылаться на объект по DN в скриптах плохая идея.

objectGUID — 128-битный идентификатор, который объект получает при создании и не меняет никогда, при любых переносах и переименованиях. Единственное надёжное имя.

objectSid — идентификатор безопасности. Есть только у субъектов безопасности (security principals): пользователей, компьютеров, групп, то есть у тех, кому можно выдавать права. SID состоит из SID домена и относительного идентификатора RID:

S-1-5-21-3623811015-3361044348-30300820-1104
│ │ │  └──────── SID домена ───────────┘ └ RID
│ │ └ NT Authority
│ └ версия
└ "S" — это SID

RID выдаются по порядку из пула, и некоторые зарезервированы: 500 — встроенный Administrator, 501 — Guest, 502 — krbtgt (учётная запись службы Kerberos, о ней в части 6), 512 — Domain Admins, 513 — Domain Users, 516 — Domain Controllers, 519 — Enterprise Admins. По SID выдаются права на файлы, разделы реестра и объекты каталога; в списке доступа (ACL) хранятся именно SID, а не имена, поэтому переименованный пользователь сохраняет все права, а удалённый и созданный заново с тем же именем — нет.

sAMAccountName — короткое имя входа, до 20 символов, уникальное в домене: alice. Используется в формате CORP\alice. Пришло из Windows NT, и часть программ работает только с ним.

userPrincipalName, UPN — имя входа в формате адреса: alice@corp.example.com. Уникально в лесу. Суффикс может отличаться от имени домена: администратор может добавить в лес альтернативный суффикс example.com, и пользователь будет входить как alice@example.com. Это важно для синхронизации с облаком, и мы к этому вернёмся в части про Entra ID.

Объекты, атрибуты, схема

Каталог — это база объектов. Каждый объект принадлежит к классу (user, computer, group, organizationalUnit, contact, …) и состоит из атрибутов: cn, givenName, sn, mail, memberOf, pwdLastSet, lastLogonTimestamp и ещё нескольких сотен. Какие классы бывают, какие атрибуты у каждого обязательны и допустимы, какого они типа и может ли атрибут иметь несколько значений, — определяет схема. Схема одна на лес, и это одна из причин, почему лес — граница: расширение схемы (Exchange добавляет сотни атрибутов, Entra Connect — несколько) действует на все домены леса сразу и не отменяется.

Класс computer — наследник класса user: компьютер в домене — это тоже учётная запись с паролем, который машина меняет сама раз в 30 дней, и с именем WS1$ (знак доллара в конце). Именно поэтому компьютер может аутентифицироваться в домене до того, как в него вошёл пользователь, и получать свои групповые политики.

Группы заслуживают отдельного разговора, потому что в них две независимых характеристики. Тип: security (есть SID, можно давать права) или distribution (только список рассылки для почты). И область действия:

Область	Кто может быть членом	Где можно давать права	Где хранится членство
Domain local	кто угодно из любого доверенного домена и леса	только в своём домене	в своём домене
Global	только субъекты своего домена	в любом домене леса и в доверяющих лесах	в своём домене
Universal	субъекты любого домена своего леса	где угодно	в глобальном каталоге

Из этих областей складывается классическое правило выдачи прав — AGDLP. Это аббревиатура цепочки, в которой каждая буква — звено, а порядок букв — кто в кого вкладывается:

A — Accounts, учётные записи: пользователи и компьютеры;
G — Global groups, глобальные группы: учётные записи складывают в них по роли — «Бухгалтеры», «Отдел продаж», «Серверы 1С»;
DL — Domain Local groups, доменно-локальные группы: глобальные группы складывают в них по ресурсу и уровню доступа — «Шара Finance: чтение», «Шара Finance: изменение»;
P — Permissions, разрешения: в список доступа ресурса (ACL папки, принтера, объекта каталога) добавляют только доменно-локальную группу.

 alice, bob ──► G «Бухгалтеры» ──► DL «Finance: изменение» ──► ACL папки \\fs1\Finance: Modify
 carol ───────► G «Аудиторы» ────► DL «Finance: чтение» ─────► ACL папки \\fs1\Finance: Read

Смысл в том, что за каждое звено отвечает своё знание. Кто кем работает, знает руководитель или отдел кадров, и это членство в глобальных группах. Кому какой ресурс положен, решает владелец ресурса, и это членство глобальных групп в доменно-локальных. ACL папки при этом не трогают никогда: его один раз настраивают на две доменно-локальные группы, а дальше доступ меняется только членством. Новый бухгалтер — одно добавление в «Бухгалтеры», и он получает всё, что положено бухгалтерам, на всех ресурсах сразу. Ушёл — одно удаление. Аудиторам на месяц нужно чтение — их группу на месяц кладут в «Finance: чтение». На вопрос «у кого есть доступ к Finance» отвечает состав одной группы, а не обход всех ACL на сервере.

Почему глобальные снаружи, а доменно-локальные внутри, следует из таблицы выше: глобальная группа может содержать только своих и годится для прав где угодно, а доменно-локальная принимает кого угодно, но годится только для своего домена — ровно то, что нужно группе, стоящей у ресурса. В лесу из нескольких доменов между G и DL добавляют универсальные группы (AGUDLP), чтобы собрать роли из разных доменов в одну. В одном домене вся цепочка кажется избыточной, и маленькие организации часто выдают права прямо глобальным группам. Смысл схемы проявляется с доверием между лесами, где только доменно-локальная группа может принять члена из чужого леса, и мы увидим это в части про доступ через доверие.

Разделы каталога

База контроллера не монолитна. Она разбита на разделы (naming contexts, NC, иногда «партиции»), и у каждого своя область репликации:

 Контроллер dc1.corp.example.com хранит:

 ┌─ CN=Schema,CN=Configuration,DC=corp,DC=example,DC=com ──────────────────────┐
 │  Schema NC: классы и атрибуты. Одна на лес, на каждом контроллере леса.     │
 ├─ CN=Configuration,DC=corp,DC=example,DC=com ────────────────────────────────┤
 │  Configuration NC: сайты, подсети, топология репликации, список доменов,    │
 │  разделы, расширения. Одна на лес, на каждом контроллере леса.              │
 ├─ DC=corp,DC=example,DC=com ─────────────────────────────────────────────────┤
 │  Domain NC: пользователи, компьютеры, группы, OU, GPO-контейнеры.           │
 │  Одна на домен, полностью на каждом контроллере этого домена.               │
 ├─ DC=DomainDnsZones,DC=corp,DC=example,DC=com ───────────────────────────────┤
 │  Application NC: зоны DNS, реплицируемые на контроллеры-DNS этого домена.   │
 ├─ DC=ForestDnsZones,DC=corp,DC=example,DC=com ───────────────────────────────┤
 │  Application NC: зона _msdcs, на контроллеры-DNS всего леса.                │
 └─────────────────────────────────────────────────────────────────────────────┘

Разделение нужно, чтобы не гонять по сети лишнее: контроллеру в eu.corp.example.com нужны схема и конфигурация леса, но не нужны пользователи us.corp.example.com. Application partitions появились в Windows Server 2003 для данных приложений с собственным кругом репликации; на практике их две, обе для DNS, и в части про DNS мы увидим, почему зоны лучше держать именно там.

Глобальный каталог (GC) — надстройка над этим. Контроллер с ролью GC хранит, помимо своего домена, частичную копию всех остальных доменов леса: не все атрибуты, а только помеченные в схеме как «в GC» (имена, SID, UPN, членство в универсальных группах). Нужен он для поиска по всему лесу (Outlook ищет адресатов именно в GC) и для входа: когда пользователь вводит alice@corp.example.com, контроллер должен выяснить, в каком домене леса живёт этот UPN, и спрашивает GC. Слушает GC на отдельном порту LDAP — 3268 (3269 с TLS). В лесу из одного домена все контроллеры делают GC, и первый контроллер получает эту роль автоматически.

Репликация между контроллерами — многохозяйская (multi-master): менять данные можно на любом контроллере, и изменение разойдётся на остальные. Исключений пять, они называются ролями FSMO, и им посвящена отдельная часть. Устройство репликации — сайты, топология, USN — тема части 10; пока достаточно знать, что она есть и что между контроллерами одного сайта изменение доходит за секунды.

Что лежит на диске

На контроллере каталог — это два места.

%SystemRoot%\NTDS — база данных:

C:\Windows\NTDS\
    ntds.dit          сама база, все разделы, формат ESE (Extensible Storage Engine, он же Jet Blue —
                      тот же движок, что у Exchange и Windows Search); от сотен мегабайт до гигабайт
    edb.log           журнал транзакций: изменение сначала пишется сюда, потом в базу
    edb00001.log …    старые журналы до их применения
    edb.chk           контрольная точка: до какого места журналы уже применены
    temp.edb          временное пространство

Это обычная транзакционная база: при сбое питания контроллер при старте докатывает журналы и остаётся согласованным. Внутри ntds.dit одна большая таблица объектов, где каждый атрибут — столбец, таблица связей для многозначных ссылочных атрибутов (членство в группах) и таблица дескрипторов безопасности. Напрямую в базу никто не ходит: все обращения идут через службу каталогов внутри процесса lsass.exe. Утилита ntdsutil умеет её проверять, сжимать и переносить, и мы вернёмся к ней в частях про резервное копирование и вывод контроллеров.

SYSVOL — общая папка %SystemRoot%\SYSVOL\sysvol\corp.example.com, доступная по сети как \\corp.example.com\SYSVOL и \\dc1\SYSVOL:

\\corp.example.com\SYSVOL\corp.example.com\
    Policies\
        {31B2F340-016D-11D2-945F-00C04FB984F9}\     Default Domain Policy
            GPT.INI                                 версия политики
            Machine\                                настройки компьютера: registry.pol, скрипты, шаблоны безопасности
            User\                                   настройки пользователя
        {6AC1786C-016F-11D2-945F-00C04fB984F9}\     Default Domain Controllers Policy
    scripts\                                        сценарии входа; это же \\corp.example.com\NETLOGON

Групповая политика живёт в двух местах: контейнер в каталоге (CN={GUID},CN=Policies,CN=System,…) с именем, версией и ссылками, и папка в SYSVOL с самими настройками. Клиент читает первое по LDAP, второе — по SMB. Реплицируется SYSVOL не службой каталога, а DFS-R (Distributed File System Replication), независимо от базы, и расхождение версий «в каталоге 15, в SYSVOL 14» — одна из классических проблем, которую мы научимся диагностировать.

Как клиент находит контроллер

Рабочая станция ws1 включается и должна аутентифицировать себя и пользователя. Ни одного адреса контроллера у неё нет — только имя домена. Дальше работает DC Locator, часть службы Netlogon, и работает он через DNS.

Контроллер при старте регистрирует в DNS набор SRV-записей (их формат разобран в части 12 сетевой серии):

_ldap._tcp.corp.example.com.                              SRV 0 100 389 dc1.corp.example.com.
_ldap._tcp.dc._msdcs.corp.example.com.                    SRV 0 100 389 dc1.corp.example.com.
_ldap._tcp.Office._sites.dc._msdcs.corp.example.com.      SRV 0 100 389 dc1.corp.example.com.
_kerberos._tcp.corp.example.com.                          SRV 0 100  88 dc1.corp.example.com.
_kerberos._tcp.dc._msdcs.corp.example.com.                SRV 0 100  88 dc1.corp.example.com.
_kpasswd._tcp.corp.example.com.                           SRV 0 100 464 dc1.corp.example.com.
_gc._tcp.corp.example.com.                                SRV 0 100 3268 dc1.corp.example.com.
_ldap._tcp.pdc._msdcs.corp.example.com.                   SRV 0 100 389 dc1.corp.example.com.
_ldap._tcp.<GUID домена>.domains._msdcs.corp.example.com. SRV 0 100 389 dc1.corp.example.com.
<GUID NTDS Settings контроллера>._msdcs.corp.example.com. CNAME dc1.corp.example.com.

Логика имени: _служба._протокол.[роль.]_msdcs.домен. dc._msdcs — все контроллеры, pdc._msdcs — тот, у которого роль PDC-эмулятора, gc._msdcs — глобальные каталоги, <сайт>._sites — контроллеры конкретного сайта, <GUID домена>.domains — контроллеры домена по его GUID (на случай переименования домена). Последняя запись, CNAME, — по одной на каждый контроллер: имя в ней — GUID объекта NTDS Settings этого контроллера (его ещё называют DSA GUID), и именно по этой записи контроллеры находят партнёров репликации, о чём в части 10. В домене с четырьмя контроллерами таких CNAME четыре. Поддомен _msdcs (Microsoft DC services) — тот самый, что лежит в разделе ForestDnsZones.

Клиент спрашивает _ldap._tcp.dc._msdcs.corp.example.com, получает список, посылает каждому контроллеру короткий LDAP ping (запрос без привязки к RootDSE по UDP 389 с фильтром по домену), первый ответивший говорит, в каком сайте находится клиент, судя по его адресу, и клиент повторяет поиск уже с _sites, чтобы найти ближайший контроллер. Результат кешируется; смотреть его:

C:\> nltest /dsgetdc:corp.example.com
           DC: \\dc1.corp.example.com
      Address: \\192.168.1.10
     Dom Guid: 7a1b2c3d-4e5f-6071-8293-a4b5c6d7e8f9
     Dom Name: corp.example.com
  Forest Name: corp.example.com
 Dc Site Name: Office
Our Site Name: Office
        Flags: PDC GC DS LDAP KDC TIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE FULL_SECRET WS DS_8 DS_9 DS_10 DS_13 KEYLIST
The command completed successfully

Флаги — то, что контроллер сообщил о себе в ответ на LDAP ping: он PDC, глобальный каталог, KDC, источник времени, доступен на запись, в том же сайте, что и клиент. Отсюда следует правило, которое объясняет половину проблем «домен не работает»: клиент домена должен использовать DNS-сервер, который знает зону домена. Публичный DNS провайдера про _ldap._tcp.dc._msdcs.corp.example.com не слышал, и машина с таким DNS в домен не войдёт, какой бы правильной ни была остальная сеть. Поэтому контроллеры почти всегда и DNS-серверы, и этому посвящена часть 7.

Протоколы

Теперь можно сложить картину целиком. Пользователь Alice входит на ws1:

 ws1                          DNS           dc1 (KDC, LDAP, SMB)
  │                            │                 │
  ├─ SRV _ldap._tcp.dc._msdcs ►│                 │   1. DC Locator: где контроллеры
  │◄───── dc1, 192.168.1.10 ───┤                 │
  ├─ LDAP ping (UDP 389) ──────────────────────► │   2. жив ли, какой сайт
  │◄──── сайт Office, флаги ─────────────────────┤
  ├─ Kerberos AS-REQ (ws1$) ───────────────────► │   3. машина получает свой TGT
  │◄──── AS-REP, TGT ────────────────────────────┤
  ├─ Kerberos AS-REQ (alice) ──────────────────► │   4. пользователь получает TGT
  │◄──── AS-REP, TGT ────────────────────────────┤
  ├─ TGS-REQ (ldap/dc1) ───────────────────────► │   5. билет на LDAP контроллера
  │◄──── TGS-REP ────────────────────────────────┤
  ├─ LDAP search: OU пользователя, gPLink ─────► │   6. какие GPO применять
  │◄──── список GPO, версии ─────────────────────┤
  ├─ TGS-REQ (cifs/dc1) ───────────────────────► │   7. билет на файлы контроллера
  ├─ SMB \\dc1\SYSVOL\…\Policies ──────────────► │   8. скачать настройки политик
  │◄──── registry.pol, скрипты ──────────────────┤
  ├─ RPC/Netlogon, SAMR, DRS при надобности ───► │   9. служебные вызовы

Пять протоколов, и у каждого своя роль.

LDAP (Lightweight Directory Access Protocol, RFC 4511) — доступ к данным каталога: привязка (bind, аутентификация клиента), поиск с фильтром, чтение атрибутов, изменение. Порт 389 (TCP и UDP для ping), 636 с TLS (LDAPS), 3268 и 3269 для глобального каталога. Всё, что читает или меняет объекты — оснастки, модуль ActiveDirectory через ADWS, Linux-машины через sssd, приложения с «интеграцией с AD» — говорит по LDAP. Часть 5 посвящена ему целиком.

Kerberos (RFC 4120) — аутентификация. Клиент один раз доказывает контроллеру, что знает пароль, и получает билет TGT; дальше для каждой службы он предъявляет TGT и получает сервисный билет, не отправляя пароль никуда. Порт 88 (UDP и TCP), 464 для смены пароля. Контроллер в роли Kerberos называется KDC (Key Distribution Center). Служба идентифицируется SPN — именем вида cifs/dc1.corp.example.com, ldap/dc1.corp.example.com, HTTP/web.corp.example.com, и билет выдаётся на конкретное SPN. Часть 6.

NTLM — аутентификация по схеме «вызов-ответ», пришедшая из Windows NT: сервер посылает случайное число, клиент шифрует его хешем пароля, сервер через защищённый канал Netlogon просит контроллер проверить. Три поездки на каждое соединение, пароль не передаётся, но хеш пароля эквивалентен паролю, и протокол уязвим к ретрансляции. Kerberos вытеснил NTLM, но тот остаётся запасным вариантом: когда клиент обращается к серверу по IP-адресу, а не по имени (нет SPN), когда сервер не в домене, когда контроллер недоступен, а сервер кеширует проверку. В журналах безопасности аутентификация NTLM там, где ожидался Kerberos, — признак неправильной настройки, и мы научимся это находить.

SMB (Server Message Block) — файлы и именованные каналы. Порт 445. Через SMB клиент читает SYSVOL и NETLOGON, пользователи ходят на файловые серверы, а поверх именованных каналов SMB (\PIPE\netlogon, \PIPE\samr, \PIPE\lsarpc) работает часть RPC-вызовов. Актуальная версия SMB 3.1.1 с шифрованием и подписью; SMB1 из Windows Server удалён; если его требует старое устройство, лучше обновить устройство, чем возвращать протокол без подписи и шифрования. Подпись SMB с 2025 года обязательна по умолчанию для исходящих соединений, что ломает подключение к совсем старым NAS.

RPC (Remote Procedure Call, реализация MSRPC поверх DCE/RPC) — вызовы процедур между службами Windows. Репликация каталога между контроллерами (интерфейс DRS), защищённый канал Netlogon, управление учётными записями (SAMR), политики безопасности (LSARPC), управление службами и журналами удалённо — всё это RPC. Устроен он в два шага: клиент спрашивает Endpoint Mapper на порту 135, на каком порту слушает нужный интерфейс, и получает номер из динамического диапазона 49152–65535. Для файрвола между сетями это неудобно: открывать весь диапазон не хочется. Решение — зафиксировать порты репликации и Netlogon в реестре (ключи TCP/IP Port для NTDS и DCTcpipPort для Netlogon) или ограничить диапазон динамических портов через netsh int ipv4 set dynamicport tcp start=49152 num=1000. Об этом вспомним в части про сайты.

Сводная таблица портов контроллера, которую стоит держать под рукой:

Порт	Протокол	Зачем
53 TCP/UDP	DNS	разрешение имён и поиск контроллеров
88 TCP/UDP	Kerberos	аутентификация
123 UDP	NTP	время (SNTP с подписью для членов домена)
135 TCP	RPC Endpoint Mapper	поиск портов служб RPC
389 TCP/UDP	LDAP	каталог; UDP — только LDAP ping
445 TCP	SMB	SYSVOL, NETLOGON, именованные каналы RPC
464 TCP/UDP	Kerberos kpasswd	смена пароля
636 TCP	LDAPS	LDAP с TLS
3268, 3269 TCP	LDAP GC	глобальный каталог, без TLS и с TLS
5985, 5986 TCP	WinRM	PowerShell Remoting
9389 TCP	ADWS	веб-службы AD для модуля ActiveDirectory и центра администрирования
49152–65535 TCP	RPC dynamic	репликация, Netlogon, SAMR, LSARPC и прочее
137–139	NetBIOS	только для совсем старых клиентов; в современной сети не нужны

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

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

Поиск контроллера через DNS, в чистом виде:

PS C:\> Resolve-DnsName _ldap._tcp.dc._msdcs.corp.example.com -Type SRV

Name                                    Type   TTL   Section    NameTarget              Priority Weight Port
----                                    ----   ---   -------    ----------              -------- ------ ----
_ldap._tcp.dc._msdcs.corp.example.com   SRV    600   Answer     dc1.corp.example.com    0        100    389
_ldap._tcp.dc._msdcs.corp.example.com   SRV    600   Answer     dc2.corp.example.com    0        100    389

Тот же поиск силами Netlogon, со всей логикой сайтов: nltest /dsgetdc:corp.example.com выше, и список всех контроллеров домена — nltest /dclist:corp.example.com.

Кто вы с точки зрения домена:

PS C:\> whoami /user

USER INFORMATION
----------------

User Name  SID
========== =============================================
corp\alice S-1-5-21-3623811015-3361044348-30300820-1104

PS C:\> whoami /groups /fo list | Select-String -Pattern 'Group Name|SID' | Select-Object -First 6

Group Name: Everyone
SID:        S-1-1-0
Group Name: BUILTIN\Users
SID:        S-1-5-32-545
Group Name: CORP\Domain Users
SID:        S-1-5-21-3623811015-3361044348-30300820-513

RID 1104 у пользователя — одна из первых созданных учётных записей (пул начинается с 1000, несколько уходит на встроенные объекты); 513 у Domain Users — тот зарезервированный, из таблицы выше. S-1-5-32-545 — встроенная группа Users локальной машины: S-1-5-32 — это BUILTIN, и такой SID одинаков на всех компьютерах мира.

Билеты Kerberos, выданные в текущем сеансе:

PS C:\> klist

Current LogonId is 0:0x3e7a1

Cached Tickets: (3)

#0>     Client: alice @ CORP.EXAMPLE.COM
        Server: krbtgt/CORP.EXAMPLE.COM @ CORP.EXAMPLE.COM
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
        Start Time: 10/15/2026 9:02:11 (local)
        End Time:   10/15/2026 19:02:11 (local)
        Renew Time: 10/22/2026 9:02:11 (local)

#1>     Client: alice @ CORP.EXAMPLE.COM
        Server: cifs/dc1.corp.example.com @ CORP.EXAMPLE.COM
        ...
#2>     Client: alice @ CORP.EXAMPLE.COM
        Server: ldap/dc1.corp.example.com/corp.example.com @ CORP.EXAMPLE.COM
        ...

Билет #0 с сервером krbtgt/… — тот самый TGT, живёт 10 часов и продлевается неделю; #1 и #2 — сервисные билеты на SMB и LDAP контроллера, полученные при входе в точности по схеме выше. Что означает каждое поле, разберём в части 6.

И последнее — что о себе рассказывает контроллер любому, кто спросит, без аутентификации. Это объект RootDSE, корень дерева LDAP, и он отвечает по 389 порту всем:

PS C:\> (Get-ADRootDSE -Server dc1.corp.example.com) | Select-Object dnsHostName, defaultNamingContext, configurationNamingContext, schemaNamingContext, namingContexts, domainFunctionality, forestFunctionality, isGlobalCatalogReady

dnsHostName                : dc1.corp.example.com
defaultNamingContext       : DC=corp,DC=example,DC=com
configurationNamingContext : CN=Configuration,DC=corp,DC=example,DC=com
schemaNamingContext        : CN=Schema,CN=Configuration,DC=corp,DC=example,DC=com
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=DomainDnsZones,DC=corp,DC=example,DC=com,
                             DC=ForestDnsZones,DC=corp,DC=example,DC=com}
domainFunctionality        : Windows2016Domain
forestFunctionality        : Windows2016Forest
isGlobalCatalogReady       : TRUE

Пять разделов из схемы выше, уровни леса и домена (их смысл — в части про замену контроллеров), готовность глобального каталога. С этого объекта начинает любой клиент LDAP, и с него мы начнём разговор о LDAP изнутри.

Теперь ясно, что должно получиться. Осталось это создать.

Дальше — часть 4: первый контроллер домена. Установка роли AD DS, Install-ADDSForest и его параметры, что происходит во время повышения, что появляется на диске и в DNS после перезагрузки, проверка dcdiag, и почему первый контроллер — самый важный сервер организации.

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

Windows Server с нуля — редакции, Server Core, установка, первые команды PowerShell, имя, сеть, время, обновления, роли.
Диски и сеть: diskpart, netsh и их PowerShell-замены — разметка дисков и сетевой стек через старые утилиты и модули Storage, NetTCPIP, NetSecurity, и что умеют только утилиты.
Как устроен Active Directory (эта статья) — лес, домен, OU, объекты, разделы каталога, глобальный каталог, SYSVOL, DC Locator и протоколы домена.