Active Directory

Site AD представляет хорошо связанную IP-сеть, а не город, юридическое лицо или организационное подразделение. Subnet связывает IP-диапазон с site. Эта связь сообщает клиенту, какой DC считать локальным, и помогает AD построить топологию репликации через WAN.

IP клиента: 10.20.34.57/24
AD Subnet: 10.20.34.0/24 --> Site: Moscow-HQ
   |
   +--> DC01, DC02 выбираются как локальные

Без subnet:
клиент может выбрать DC из другого site и идти по WAN.

Ведите реестр маршрутизируемых подсетей и владельцев. Новая VLAN без объекта subnet в AD часто проявляется как медленный вход, неожиданный DC или лишний WAN-трафик, а не как явная ошибка.

При входе клиент определяет свой site по IP, использует DNS SRV-записи и механизм DC Locator, чтобы найти контроллер предпочтительного site. Если локального DC нет, выбирается ближайший site по стоимости site links.

Client 10.70.5.20
 |
 +--> Subnet 10.70.5.0/24 --> Site Vladivostok
   |
   +--> запрос _ldap._tcp.Vladivostok._sites.dc._msdcs.corp.example
   |
   +--> локальный DC или ближайший site

nltest /dsgetsite
nltest /dsgetdc:corp.example /force
ipconfig /all
Resolve-DnsName -Type SRV "_ldap._tcp.Moscow-HQ._sites.dc._msdcs.corp.example"

Внутри site AD предполагает быстрый надёжный канал: репликация изменений запускается уведомлениями вскоре после записи. Между sites топология учитывает site links, стоимость и расписание; репликация рассчитана на более дорогие или менее стабильные WAN-каналы.

Intrasite (LAN):
 DC01 --- уведомление ---> DC02 --- уведомление ---> DC03
 низкая задержка, частые изменения

Intersite (WAN):
 Moscow-DC === site link === Vlad-DC
 расписание + интервал + стоимость

Не объявляйте WAN «одним site», только чтобы изменения шли быстрее.

Отдельно проектируйте репликацию SYSVOL (DFSR) и AD: они связаны для работы GPO, но диагностируются разными журналами и командами.

Site link описывает логическую связность нескольких sites. Cost — относительное предпочтение пути, не пропускная способность в Мбит/с. Меньшая стоимость выбирается как более желательный маршрут. Schedule определяет доступные часы, replication interval — период межсайтовой репликации.

 cost 50  cost 20
Moscow =============== Novosibirsk ================= Vladivostok
 \    /
 \================= cost 200 ==========================/

Ожидаемый путь Moscow -> Vladivostok: через Novosibirsk
Не назначайте cost по названию города или «красоте» схемы.

Get-ADReplicationSiteLink -Filter * -Properties Cost, ReplicationFrequencyInMinutes, SitesIncluded |
 Select-Object Name, Cost, ReplicationFrequencyInMinutes, SitesIncluded

Knowledge Consistency Checker (KCC) автоматически строит connection objects, формируя отказоустойчивую топологию. По умолчанию KCC пересчитывает топологию примерно каждые 15 минут; точный результат зависит от изменений, служб и состояния каталога. Не создавайте ручные connections без понятной причины.

Site Moscow  Site Vladivostok
 DC01 ----\  /---- DC11
 \__ KCC connection _____/
 DC02 ----/ (bridgehead)

Bridgehead — DC, выбранный для межсайтовой репликации
для конкретного транспорта; это роль в топологии, не титул сервера.

Ручной connection object оправдан как временное контролируемое исключение, например при сложной сети или диагностике. Он добавляет операционный долг: после изменения DC, link или маршрута его надо пересматривать.

repadmin /showrepl *
repadmin /replsummary
Get-ADReplicationConnection -Filter * |
 Select-Object Name, ReplicateFromDirectoryServer, ReplicateToDirectoryServer, AutoGenerated

Предположим, у организации три узла: Москва (два DC), Новосибирск (один DC), Владивосток (один DC), а прямой канал Москва—Владивосток резервный, дорогой. Каждая локальная VLAN описана subnet, а site links отражают измеренные пути и договорённые окна.

[Moscow-HQ]  [Novosibirsk]  [Vladivostok]
10.10.0.0/16 10.20.0.0/16  10.30.0.0/16
DC01, DC02  DC03  DC04
 | cost 40, always | cost 60, always |
 +==========================+=============================+
 \_____________ резерв: cost 250, ночное окно ___________/

Нормальный маршрут: Москва -> Новосибирск -> Владивосток
Резерв не должен стать предпочтительным из-за меньшего cost.

Мониторинг должен различать кратковременную задержку WAN и устойчивую ошибку. Смотрите последние успешные попытки, число ошибок, очередь репликации, DNS и события Directory Service/DFSR. Одна успешная проверка не отменяет проблему, если партнёр систематически отстаёт.

repadmin /replsummary
repadmin /showrepl DC04 /errorsonly
repadmin /queue DC04
dcdiag /test:DNS /v

# Сводка репликационных метаданных конкретного объекта
repadmin /showobjmeta DC01 "CN=Alice,OU=Users,DC=corp,DC=example"

Диагностика ошибки:
DNS? --> разрешите имя партнёра и проверьте SRV
Сеть/RPC? --> маршрут, firewall, портовая политика
Время? --> Kerberos и синхронизация часов
Топология? --> site link, connection, KCC
Каталог? --> repadmin, Directory Service events
SYSVOL? --> DFSR events, отдельно от AD replication

Наиболее частая ошибка — один site для всей компании. Она скрывает WAN от AD: клиенты выбирают удалённые DC как локальные, а репликация идёт по предположениям LAN. Обратная ошибка — отдельный site для каждой маленькой подсети без отдельного канала: топология разрастается без пользы.

Топология Sites and Services — это договор AD с реальной сетью. Она должна отвечать на два независимых вопроса: какой DC является локальным для клиента с данным IP и каким путём должны сходиться изменения между DC. Если схема описывает названия филиалов, но не описывает маршрутизируемые подсети и стоимость каналов, она декоративна: DC Locator и KCC не могут извлечь из неё правильное решение.

Инвентаризация перед созданием site

VLAN 110: 10.10.110.0/24 -> Moscow-HQ
VLAN 210: 10.20.210.0/24 -> Novosibirsk
VLAN 310: 10.30.310.0/24 -> Vladivostok
VPN pool: 10.90.0.0/16 -> отдельное проектное решение

Адрес без subnet в AD = клиент без достоверной site affinity.

Site не равен физическому зданию. Два корпуса с быстрой надёжной связностью могут быть одним site; один кампус с маршрутом через дорогой спутниковый канал — двумя sites. Аналогично, не всякая новая VLAN требует site: если она находится за тем же LAN, использует те же DC, ей достаточно объекта subnet, связанного с существующим site. Выбор должен следовать измеряемым свойствам сети — задержке, доступности, ширине канала и правилам эксплуатации.

Клиентский выбор DC:

10.30.310.45 -> subnet 10.30.310.0/24 -> Site Vladivostok
 -> DNS SRV: _ldap._tcp.Vladivostok._sites.dc._msdcs
 -> DC04 local

Если DC04 недоступен:
 -> ближайший site по site-link cost
 -> не «случайный DC из списка»

Intrasite-репликация рассчитана на LAN: партнёры уведомляют друг друга о записи, и конвергенция идёт быстро. Intersite-репликация использует запланированные связи и интервалы; это сознательный компромисс между свежестью данных и ценой WAN. Нельзя лечить задержку между городами помещением всех DC в один site. Такое действие отключает предположения о WAN и может перенести постоянный тяжёлый трафик на канал, который не рассчитан на него.

Правильная модель WAN:
Moscow DC01/DC02 ==(cost 40)== Novosibirsk DC03 ==(cost 60)== Vlad DC04
 \__________________(cost 250, резерв)_____________________/

Неправильная модель:
Site=CORP-ALL: DC01 ---- WAN ---- DC04
 AD ожидает LAN, хотя его нет.

Cost не измеряет скорость в Мбит/с и не является временем задержки. Это относительное предпочтение маршрута для построения топологии. Назначайте его после того, как сеть подтвердила рабочие и резервные пути. Одинаковый cost всем links не делает дизайн «нейтральным»: он делает выбор маршрута менее объяснимым. Расписание link должно отражать реальное окно доступности, но нельзя закрывать его настолько, что парольные изменения, новые группы и объекты дни не доходят до удалённого DC.

KCC строит connection objects так, чтобы топология оставалась связной и переносила отказ партнёра. Его периодический пересчёт (по умолчанию порядка 15 минут) не означает, что нужно ждать ровно пятнадцать минут после каждого изменения; это планировочная работа, а не SLA доставки объекта. Bridgehead — DC, выбранный для межсайтового обмена в конкретной топологии. Не назначайте «главный bridgehead» вручную по привычке: это связывает дизайн с сервером, который может быть выведен из эксплуатации.

KCC строит, администратор проверяет:

Moscow: DC01 <--> DC02
 \
 \ intersite connection
  \
  DC03 (Novosibirsk) <--> DC04 (Vladivostok)

Ручная connection допустима как документированное исключение,
а не как постоянная замена работы KCC.

Здоровье репликации анализируют по партнёрам и времени последней успешной репликации, а не по факту существования объектов в консоли. Сначала repadmin /replsummary даёт обзор, затем /showrepl показывает конкретную пару и ошибку. Ошибка DNS, RPC/firewall, времени, топологии или состояния базы имеет разные признаки. Попытка «принудительно реплицировать всё» до определения слоя может создать нагрузку и скрыть настоящую периодичность сбоя.

repadmin /replsummary
repadmin /showrepl DC04 /verbose
repadmin /queue DC04
nltest /dsgetsite
nltest /dsgetdc:corp.example /force
dcdiag /test:Advertising /test:DNS /v

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

Жизненный цикл настройки AD

Потребность -> модель угроз/ограничений -> pilot
 |   |
 v   v
владелец <- документация <- измерение <- внедрение
 |   |
 +-------- пересмотр / удаление --------+

«Создано без ошибки» не является критерием качества.
Критерий: известны ожидаемый эффект, границы и способ доказать эффект.

Разделяйте плоскости управления. Идентичность отвечает за то, кто предъявляет учётную запись; аутентификация — как система проверяет это предъявление; авторизация — какие операции разрешены; сеть — куда может дойти трафик; журнал событий — как восстановить картину. Попытка заменить одну плоскость другой создаёт ложное чувство защиты. Например, группа AD не заменяет сегментацию сети, а firewall не заменяет разрешение на объект.

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

# Полезный минимум перед и после изменения:
Get-Date
whoami /all
Get-ADDomainController -Filter * | Select-Object HostName, Site, IPv4Address

# Сохраняйте вывод с номером заявки, а не только в истории консоли.
New-Item -ItemType Directory -Force -Path C:\Temp\AD-Change |
 Out-Null

Качественная документация отделяет факт от предположения. Факт: команда показала конкретный DC, версию или ошибку в указанное время. Предположение: эта ошибка объясняет наблюдаемое поведение. Для предположения нужен следующий тест, который может как подтвердить, так, опровергнуть его. Такой подход особенно важен в AD: один пользователь может попасть на другой контроллер домена, другой site или иметь старый токен и поэтому единичный удачный тест не описывает состояние всей среды.

Минимальная запись в журнале изменений

Время: 2026-07-14 15:00 UTC+3
Объект: имя, GUID и область действия
Гипотеза: какую причину проверяем
До: сохранённый отчёт / экспорт
Действие: одна обратимая операция
После: тот же тест, другой пользователь/узел при необходимости
Откат: условие, команда и ответственный

Такую запись можно передать дежурной смене без устных пояснений.

Права на изменение AD должны быть минимальными и раздельными. Человек, который утверждает нужду в политике или trust, не обязательно должен быть тем, кто имеет право менять все GPO, связи sites или объекты безопасности. Делегируйте операции на конкретную OU, группу или набор объектов, используйте отдельную привилегированную учётную запись и проверяйте членство в группах администрирования так же регулярно, как и рабочие ACL. Широкое членство в Domain Admins ради одной административной операции почти всегда является признаком недоработанного процесса.

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