Active Directory

Проектирование Active Directory начинается не с создания домена, а с разделения двух моделей. Логическая модель отвечает на вопрос, какие объекты существуют и кому доверяют:

• лес
• дерево
• домен
• OU
• пользователи
• группы

Физическая модель отвечает, где хранятся копии каталога и как репликация проходит по сети:

• сайты
• подсети
• контроллеры домена
• каналы связи

ЛОГИКА  ФИЗИКА
-- Лес academy.local +-- Site: Moscow
-- Домен academy.local | +-- DC01, DC02
-- OU=Users  +-- Site: Kazan
-- OU=Servers  | +-- DC03
-- Группы и GPO +-- Подсети и site links

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

Лес — верхняя граница каталога и доверия: его домены используют общую схему, конфигурацию и транзитивные двусторонние доверительные отношения. Дерево объединяет домены в непрерывном DNS-пространстве, например corp.example и eu.corp.example. Дерево редко является самостоятельной причиной для дизайна: оно полезно, когда DNS-иерархия действительно нужна.

Домен содержит собственную копию доменного раздела каталога, политики паролей по умолчанию и репликационную область. OU — контейнер внутри домена для делегирования, применения GPO и организации жизненного цикла. OU не создаёт границу безопасности и не имеет собственного SID-пространства.

Forest: skl.local
- Domain: skl.local ← доменная политика, SID domain
 +- OU=People  ← делегирование HR
 | +- OU=Students
 +- OU=Infrastructure ← GPO серверов
 +- CN=Users (по умолчанию) ← не проектный контейнер

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

Граница администрирования — место, где выдаются ограниченные права на объекты, обычно OU. Делегируйте не «полный контроль», а конкретные операции:

1. сброс пароля
2. создание пользователей в OU
3. подключение компьютеров
4. управление членством группы

Используйте отдельные административные учётные записи и документируйте владельца каждого делегирования.

Контроллер домена (DC) — не просто сервер с ролью AD DS, а авторитетная реплика каталога. База NTDS.dit хранит объекты и атрибуты; SYSVOL хранит реплицируемые файлы GPO и сценарии. Изменение, принятое одним DC, распространяется мультимастерной репликацией. Поэтому резервное копирование DC и проверка здоровья репликации — архитектурные, а не операционные детали.

Администратор -> DC01 -> NTDS.dit
  |
  репликация AD
  / \
  DC02 DC03
 Site A Site B

GPO-файлы: SYSVOL -- DFSR --> SYSVOL

Для отказоустойчивости размещают минимум два записываемых DC в основном сайте и обеспечивают независимые питание, хосты и сетевые пути. Два DC на одном физическом хосте не защищают от отказа этого хоста. Нельзя копировать NTDS.dit как обычный файл или откатывать снимок неподдерживаемым способом.

Глобальный каталог (GC) содержит полную копию объектов своего домена и частичный набор атрибутов объектов остальных доменов леса. Он нужен для поиска по лесу, универсальных групп и часто для входа пользователей. В одно-доменном лесу почти каждый DC обычно является GC; в многодоменном — рассчитывайте нагрузку и доступность GC в каждом важном сайте.

Мультимастерность не годится для операций, в которых две одновременные записи создали бы конфликт, поэтому существуют FSMO:

1. Schema Master меняет схему
2. Domain Naming Master добавляет и удаляет домены
3. RID Master выдаёт пулы RID
4. PDC Emulator служит точкой времени, паролей и совместимости
5. Infrastructure Master обновляет междоменные ссылки

Forest-wide: [Schema] [Domain Naming]
Domain-wide: [RID] [PDC Emulator] [Infrastructure]

Один владелец = одна последовательность для операции,
не «самый мощный DC» и не постоянная точка входа.

Роли FSMO можно объединить на хорошо защищённом, резервируемом DC малого леса, но это не освобождает от документации и плана переноса. Forest-wide роли размещают на доступном DC корневого домена. RID и PDC выбирают с учётом стабильности и наблюдаемости. Infrastructure Master не размещают на GC в многодоменном лесу, если не все DC являются GC; при «все DC — GC» это ограничение исчезает.

Read-Only Domain Controller (RODC) хранит только читаемую реплику и подходит для площадки с плохой физической защитой. Политика кэширования паролей должна разрешать только нужные группы; привилегированные учётные записи кэшировать нельзя. RODC не заменяет защищённый записываемый DC и не исправляет плохую сеть.

HQ: DC01 (PDC,RID,GC) + DC02 (GC)
Branch: RODC01 (GC, только разрешённый cache)

Площадка без охраны → RODC
Нужны локальные записи/администрация → защищённый writable DC

Начальная гипотеза для новой организации — один лес, один домен. Она минимизирует репликацию, число политик, стоимость поддержки, количество точек ошибки. Несколько доменов добавляют DNS, доверия, GC-зависимости, миграции, экспертную нагрузку. Сначала попытайтесь выразить требование через OU, делегирование, группы и fine-grained password policies.

Нужно изолировать недоверенную администрацию?
-- да --> отдельный ЛЕС
-- нет --> нужны разные доменные политики/репликация/namespace?
 +-- да --> оценить отдельный ДОМЕН
 +-- нет --> один ДОМЕН + OU + delegation + GPO

Мультидоменность оправдывают измеримым требованием, а не исторической структурой отделов. До утверждения решения опишите владельцев ролей, DNS-namespace, размещение GC, доверия, стратегию входа и сценарий восстановления.

Опасные шаблоны:

1. домен на отдел
2. один DC «потому что маленькая компания»
3. ежедневная работа под Domain Admin
4. DC как файловый/прикладной сервер
5. сайты не сопоставлены с подсетями
6. DNS клиента указывает на публичный резолвер

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

Сайт Active Directory — это модель сетевой связности, а не название города на организационной схеме. В сайт помещают IP-подсети, между которыми ожидается быстрая и постоянно доступная связь. Контроллеры домена относятся к сайту, а клиент определяет свой сайт по адресу интерфейса. Поэтому проектировщик обязан собрать актуальную таблицу VLAN, масок, маршрутов, пропускной способности, задержки и владельца канала. Без такой таблицы «автоматический» выбор контроллера становится случайным.

Site link выражает разрешённый путь репликации и его стоимость. Стоимость — относительное предпочтение, а не стоимость рубля, не число миллисекунд. Меньшее значение выбирается раньше. Интервал репликации на межсайтовой связи назначают по RPO, объёму изменений, доступности канала. Не следует уменьшать его до минимума только потому, что канал быстрый: сначала измерьте нагрузку, подтвердите резервирование и определите окно обслуживания.

Подсети  Сайты Каналы
10.10.0.0/16 --------> Moscow --10--> Kazan
10.20.0.0/16 --------> Kazan --80--> Branch
10.30.5.0/24 --------> Branch

Число на стрелке — относительная стоимость,
а не географическое расстояние.

Внутри сайта репликация предполагает надёжную LAN-связность; между сайтами Knowledge Consistency Checker строит топологию с учётом site links. Администратор не должен вручную создавать connection objects как постоянный способ управления топологией: такие объекты затрудняют диагностику, часто переживают исходную причину. Ручное соединение допустимо как документированное исключение и когда стандартная топология не отражает реальную сеть.

Active Directory является системой идентичности, поэтому её главный актив — не виртуальная машина DC, а возможность выпускать и проверять удостоверения. Захват учётной записи с полномочиями Domain Admin, Enterprise Admin или правом изменять критичные GPO способен дать атакующему устойчивый доступ даже после замены отдельного сервера. Проектирование должно начинаться с перечня привилегий, а не со списка должностей.

Разделяйте повседневную и административную идентичности. Обычная учётная запись читает почту и открывает документы; административная используется только на административной рабочей станции и только для назначенной области. Разделяйте уровни управления:

1. Tier 0 — инфраструктура идентичности
2. Tier 1 — серверы
3. Tier 2 — рабочие станции

Администратор низшего уровня не должен входить на DC, потому что это создаёт путь к компрометации более высокого уровня через кэш учётных данных и токены.

Tier 0: лес, DC, PKI, AAD Connect
 ↑ администрируется только с PAW
Tier 1: серверы и приложения
 ↑ отдельные учётные записи
Tier 2: рабочие станции пользователей

Запрещён путь: Tier 2 admin → интерактивный вход на DC

Группы Domain Admins и Enterprise Admins не являются «группами опытных специалистов». Их членство должно быть почти пустым, временным, контролируемым и оправданным конкретной операцией. Для повседневной делегации используйте OU, специальные группы операторов и точные ACL. Проверьте также вложенное членство: опасная привилегия часто приходит через универсальную или локальную группу, которую никто не считает частью админ-модели.

Get-ADGroupMember "Domain Admins" -Recursive
Get-ADGroupMember "Enterprise Admins" -Recursive
Get-ADDomainController -Filter * |
 Select-Object HostName,Site,IsGlobalCatalog,OperationMasterRoles

Архитектурное решение считается завершённым, когда его можно передать другой команде без устных пояснений. Для каждого леса зафиксируйте DNS-имя, владельца, назначение, доверия, число доменов, схему имён, DC, GC, FSMO, сайты, подсети, резервное копирование и процедуру восстановления. Для каждого решения запишите альтернативу, которую отклонили, и критерий отказа. Эта дисциплина особенно ценна через год, когда меняются люди и первоначальная логика исчезает.

Проверяйте дизайн сценариями отказа. Отключите один DC в тестовой среде: находят ли клиенты другой DNS, DC, применяются ли GPO, продолжается ли вход? Смоделируйте потерю WAN: остаётся ли филиал работоспособным в пределах заявленного RPO? Спросите, что произойдёт при компрометации аккаунта локальной поддержки. Если ответ — «он станет Domain Admin» и делегирование спроектировано неверно.

Сценарий  Ожидаемый результат
Потерян DC01 DC02 обслуживает DNS, LDAP, Kerberos
Потерян WAN филиала локальный DC/RODC даёт заявленные функции
Сменился сотрудник меняется группа, не ACL сотен ресурсов
Новый VLAN добавлен в Site/Subnet до выдачи адресов

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

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

Полезный приём — отделить решение от реализации. Решение описывает границу, владельца, допустимый риск, ожидаемое поведение при отказе; реализация перечисляет конкретные OU, DNS-зоны, контроллеры, группы или команды. Тогда изменение имени сервера не превращает архитектурный документ в ложный а новый инженер может проверить намерение до изменения конфигурации.

Методика проверки

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

Требование → вариант → риск → владелец
 ↓ ↓ ↓
 тестовый проверка решение об
 сценарий отказа эксплуатации

Документация обновляется после проверки,
а не до того, как факт подтверждён.

repadmin /replsummary
+dcdiag /e /c
+netdom query fsmo