Администрирование · 18 мин чтения · Семёнов Е.С., руководитель ITfresh

Полный гайд по администрированию Active Directory в 2026

Active Directory исполняется 26 лет. Технология, появившаяся вместе с Windows 2000, до сих пор остаётся стандартом де-факто для управления учётками и компьютерами в офисах от десяти до десятков тысяч мест. Я веду домены клиентов с 2010 года и за это время видел, как одни и те же ошибки повторяются в каждом втором проекте. Этот гайд — концентрированная выжимка того, что должен знать сисадмин малого бизнеса про AD в 2026 году: от концепции леса до восстановления после атаки Golden Ticket.

Зачем нужен AD и где он живёт в стеке Microsoft

Active Directory Domain Services (AD DS) — это центральная база данных, которая хранит учётные записи, компьютеры, группы, политики и настройки безопасности. Каждый компьютер в домене знает, к кому идти за проверкой пароля, какие политики применять и где искать общие ресурсы. Без AD каждая Windows-машина — это остров.

В стеке Microsoft есть несколько связанных, но разных технологий, которые часто путают:

В офисе 30-50 человек я разворачиваю обычно AD DS + при необходимости AD CS. Остальное — точечно под конкретные задачи.

Лес, домены, деревья: иерархия объектов

Вершина AD — лес (Forest). Внутри леса один или несколько доменов, каждый домен — независимая административная единица. Деревья (Trees) — это группы доменов с непрерывным DNS-пространством имён (corp.company.ru и sales.corp.company.ru). В малом и среднем бизнесе всегда один лес и один домен — этого достаточно.

Внутри домена живут объекты: пользователи (User), компьютеры (Computer), группы (Group), организационные единицы (OU), сервисные аккаунты (Managed Service Account, MSA), принтеры, контакты. У каждого объекта есть distinguished name (DN), guID и SID. Всё пространство имён хранится в файле NTDS.dit на каждом контроллере домена и реплицируется между ними.

Сайты (Sites) — отдельная сущность, описывающая физическую топологию. Один сайт = один офис = один или несколько IP-подсетей. Между сайтами AD реплицируется по расписанию и через выбранный мост (bridgehead). В офисе 30 человек обычно один сайт Default-First-Site-Name. Если у заказчика два офиса с медленным каналом — создаём два сайта, привязываем подсети, настраиваем расписание.

Контроллеры домена и FSMO-роли

Контроллер домена (DC) — это сервер, на котором установлена роль AD DS. В нормальной инфраструктуре их минимум два, в больших — десятки. Каждый DC хранит полную копию домена и обслуживает запросы клиентов.

Однако пять операций требуют единственного исполнителя в каждый момент времени — это FSMO-роли (Flexible Single Master Operations):

Команды, которые я держу в шпаргалке:

# Где сейчас FSMO
netdom query fsmo

# Подробная информация о ролях леса и каждого домена
Get-ADForest | Select-Object SchemaMaster, DomainNamingMaster
Get-ADDomain  | Select-Object PDCEmulator, RIDMaster, InfrastructureMaster

# Запланированный перенос (graceful)
Move-ADDirectoryServerOperationMasterRole -Identity "DC02" `
  -OperationMasterRole PDCEmulator,RIDMaster,InfrastructureMaster

# Аварийный захват (seize) — DC1 умер и не вернётся
Move-ADDirectoryServerOperationMasterRole -Identity "DC02" `
  -OperationMasterRole PDCEmulator -Force

В офисе 30-50 человек я обычно держу все пять ролей на одном DC, чаще на DC01. Это упрощает диагностику. Главное — задокументировать и знать, как переносить.

Структура OU и групп: как не запутаться

Organizational Units (OU) — это контейнеры внутри домена, на которые можно вешать GPO и делегировать управление. Я никогда не оставляю объекты в дефолтных контейнерах CN=Users и CN=Computers, потому что на них нельзя привязать политику.

Базовый шаблон, который я разворачиваю у клиентов:

DC=corp,DC=client,DC=ru
├── OU=Sotrudniki
│     ├── OU=Buhgalteria
│     ├── OU=Prodazhi
│     ├── OU=IT
│     └── OU=Rukovodstvo
├── OU=Workstations
│     ├── OU=Buhgalteria
│     ├── OU=Prodazhi
│     └── OU=Mobilnye (для ноутбуков с Always-On VPN)
├── OU=Servers
│     ├── OU=FileServers
│     ├── OU=1C
│     └── OU=Apps
├── OU=Groups
├── OU=ServiceAccounts
└── OU=PrivilegedAccounts
      ├── OU=AdminUsers
      └── OU=AdminWorkstations

Группы безопасности раздаю по модели AGDLP (Account → Global → Domain Local → Permission). Глобальные группы (GG_*) содержат пользователей по подразделениям. Domain Local группы (DL_*) назначаются на ресурсы. Это позволяет менять права на ресурсы, не трогая структуру пользователей.

Пример: у бухгалтерии должен быть полный доступ к шаре Buh, у юристов — только чтение определённых папок. Я создаю DL_Share_Buh_Modify (на NTFS даю права Modify) и DL_Share_Buh_Read. В DL_Share_Buh_Modify добавляю GG_Buhgalteria, в DL_Share_Buh_Read — GG_Yuristy. Если завтра приходит новый бухгалтер, я добавляю его в GG_Buhgalteria — и он автоматически получает все нужные права.

Инструменты администратора AD

RSAT (Remote Server Administration Tools) ставится на Windows 11 одной командой PowerShell:

Get-WindowsCapability -Online | Where-Object { $_.Name -like "Rsat*" } |
  Add-WindowsCapability -Online

Основные консоли, которыми я пользуюсь каждый день:

Дополнительно я ставлю PingCastle (бесплатный аудитор AD), Sysinternals Suite (особенно AccessChk, PsExec, Process Monitor), ADRecon для отчётов по состоянию домена и BloodHound Community Edition для визуализации цепочек атак.

Важно: все доменные операции я выполняю с jump-сервера, который входит в условный Tier 0 — отдельный сегмент, не выходит в интернет, нет почты, нет браузера, минимум софта. Это базовая практика, защищающая от того, чтобы Domain Admin'а не словили на обычной рабочей станции через фишинг.

Kerberos и протоколы аутентификации

Kerberos — основной протокол аутентификации в современном AD. Принцип простой: пароль никогда не уходит по сети. Клиент один раз получает Ticket Granting Ticket (TGT) у Key Distribution Center (роль на каждом DC), а затем меняет TGT на сервисные тикеты (TGS) для конкретных ресурсов. Срок жизни TGT по умолчанию 10 часов, TGS — 10 часов, обновлений TGT — 7 дней.

Технические детали, которые важны на практике:

NTLM — устаревший протокол, до сих пор поддерживаемый для совместимости. NTLMv1 откровенно опасен (хеши быстро ломаются на GPU), NTLMv2 терпим, но уязвим к relay-атакам. Включаем аудит NTLM через GPO (Network Security: Restrict NTLM: Audit NTLM authentication in this domain), смотрим логи и постепенно отключаем legacy-клиентов.

Групповые политики (GPO)

GPO — основной инструмент централизованной настройки. Привязывается к сайту, домену или OU. Применяется в порядке Local → Site → Domain → OU (классический LSDOU), позже выполненная политика переопределяет более раннюю.

Типовые GPO в моём проекте под малый бизнес:

  1. Password Policy на корне домена. Длина 12, сложность, история 12, срок 180 дней, блокировка после 10 неудач.
  2. AD Hardening Baseline на корне. Отключение SMBv1, NTLMv1, LLMNR, NetBIOS, включение SMB Signing.
  3. Workstation Baseline на OU=Workstations. SmartScreen, Defender Tamper Protection, BitLocker (для ноутбуков), AppLocker для рабочих станций бухгалтерии.
  4. Server Baseline на OU=Servers. Жёсткий аудит, RDP только из административной подсети, отключение Print Spooler там, где он не нужен (профилактика PrintNightmare).
  5. Mapped Drives через GPP. Item-Level Targeting по группам безопасности.
  6. Printers через GPP с фильтром по группам.
  7. LAPS Settings — Windows LAPS в режиме Active Directory.
  8. Audit Policy — Advanced Audit Policy Configuration с подкатегориями.

Тестирование политик выполняю через моделирование (GPMC → Group Policy Modeling) и применение на тестовой OU перед привязкой к боевой. Принудительное обновление:

Invoke-GPUpdate -Computer "PC-TEST-01" -RandomDelayInMinutes 0 -Force

# С локальной машины
gpupdate /force /sync

# Получить отчёт RSoP
gpresult /h C:\rsop.html /scope computer
gpresult /h C:\rsop_user.html /scope user

Не забываем: GPO применяется к компьютеру при загрузке и каждые 90 минут (с jitter), к пользователю — при логоне и каждые 90 минут. Loopback Processing нужен, когда хотим политики «как для пользователя из этой OU» применять ко всем, кто залогинился на этот компьютер (актуально для терминальных серверов).

Репликация: как DC синхронизируются

В одном сайте репликация запускается каждые 15 секунд после изменения и идёт по топологии, которую генерирует KCC (Knowledge Consistency Checker). Между сайтами — по расписанию (по умолчанию каждые 180 минут) через bridgehead.

Команды для контроля:

# Сводка по репликации
repadmin /replsummary

# Подробно по каждому DC
repadmin /showrepl
repadmin /showrepl * /csv > replication.csv

# Принудительная репликация на конкретный DC
repadmin /syncall DC01 /AdeP

# Полная диагностика
dcdiag /e /v /c

Ключевая ошибка, которую вижу в практике, — Tombstone Lifetime. Если DC отключён больше Tombstone Lifetime (по умолчанию 180 дней в современных AD), его уже нельзя вернуть в репликацию — только metadata cleanup и переподнятие. Поэтому DC, которые не используются, либо корректно демотируем (Uninstall-ADDSDomainController), либо метим в календарь на удаление.

SYSVOL реплицируется отдельно через DFSR (или старый FRS, если домен мигрировал с очень древних версий). Проверка состояния DFSR:

Get-DfsrState
Get-DfsrMembership -GroupName "Domain System Volume"
dfsrdiag PollAD
dfsrdiag SyncNow /partner:DC02 /RGName:"Domain System Volume"

DNS как нервная система AD

AD без правильного DNS не работает. Все клиенты находят DC через SRV-записи в зоне домена (_ldap._tcp.dc._msdcs.corp.company.ru и др.). Базовые правила, которые я внедряю:

Диагностика — через nslookup и Resolve-DnsName:

Resolve-DnsName -Name corp.company.ru -Server DC01 -Type A
Resolve-DnsName -Name "_ldap._tcp.dc._msdcs.corp.company.ru" -Type SRV
nslookup -type=ALL _msdcs.corp.company.ru

Делегирование прав без раздачи Domain Admin

Самая частая ошибка, которую я лечу у клиентов: «эникею выдали Domain Admin, потому что иначе он не мог сбрасывать пароли пользователям». Это категорически неправильно. Делегирование позволяет дать права на конкретные операции в конкретных OU.

Через ADUC: правый клик на OU → Delegate Control → выбираем группу (например, SG_HelpDesk) → отмечаем нужные действия (Reset user passwords and force password change at next logon). После этого помощник без всяких прав в Domain Admins может сбрасывать пароли пользователям только в указанной OU.

Стандартные роли, которые я выделяю в офисе 50 человек:

Доменные администраторы (Domain Admins) — две учётки максимум. Enterprise Admins — только для фактических лесных операций (повышение FFL, добавление домена), всё остальное время эта группа должна быть пустой.

Аудит и расследование инцидентов

Включаем расширенный аудит через GPO, путь Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration. Минимальный набор подкатегорий:

Размер журнала Security увеличиваем до 1-2 GB на каждом сервере. Без увеличения он переполняется за считанные часы и важные события теряются.

Ключевые Event ID, на которые я настраиваю алертинг в Wazuh:

Защита от Golden Ticket и компрометации krbtgt

Учётная запись krbtgt — корень доверия Kerberos. Её хеш используется для подписи всех TGT. Если злоумышленник получает доступ к контроллеру домена и снимает дамп — он создаёт Golden Ticket с правами Domain Admin на любой срок (по умолчанию инструменты вроде mimikatz ставят 10 лет).

Защита и реакция:

Дополнительно: AdminSDHolder — специальный объект, который каждые 60 минут восстанавливает дескрипторы безопасности на критичных встроенных группах (Domain Admins, Enterprise Admins и др.). Если кто-то нелегально расширил права — система сама их откатит. Это работает на уровне ACL объектов, а не учёток в группах, но создаёт дополнительный барьер.

Резервное копирование и восстановление

System State Backup на каждом DC ежесуточно через Windows Server Backup или Veeam B&R на выделенный бэкап-сервер за пределами домена:

wbadmin start systemstatebackup -backupTarget:\\backup-srv\ad-backup -quiet

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

AD Recycle Bin включаем один раз и навсегда:

Enable-ADOptionalFeature -Identity "Recycle Bin Feature" `
  -Scope ForestOrConfigurationSet -Target "corp.company.ru"

# Восстановление случайно удалённого пользователя
Get-ADObject -Filter 'SamAccountName -eq "ivanov"' -IncludeDeletedObjects -Properties * |
  Restore-ADObject

Authoritative Restore (форсированное восстановление с приоритетом над репликацией) делается только в режиме DSRM (Directory Services Restore Mode). Это ситуация, когда у вас откатили нужное состояние на одном DC, а оно реплицировалось на остальные, и нужно силой пересинхронизировать всех на «правильную» версию.

Что нового в Windows Server 2022 и 2025

Функциональный уровень леса не повышался с Windows Server 2016 — все новые фичи едут отдельно. Windows Server 2022 принёс secured-core server и SMB encryption AES-256. Windows LAPS встроен в 22H2/2019/2022/2025. Server 2025 даёт SMB over QUIC, AES-256 в Kerberos по умолчанию, hot-patching, dMSA. Новые домены ставлю на Windows Server 2022 как самый стабильный выбор; Server 2025 — точечно под клиентов с конкретными новыми фичами.

Регулярные операции администратора

Что я делаю каждую неделю / месяц / квартал в любом домене на обслуживании ITfresh:

FAQ

Какие инструменты обязательно ставить администратору AD на рабочую станцию?
RSAT (Remote Server Administration Tools) для Windows 11 — устанавливается через Optional Features или Add-WindowsCapability. В минимальный комплект входят: ADUC, ADAC, GPMC, DNS Manager, DHCP Manager, Sites and Services. Дополнительно я ставлю PingCastle для аудита, ADRecon для отчётов и Sysinternals Suite. Все доменные операции выполняю с jump-сервера в Tier 0, не с обычной рабочей станции.

Чем отличаются ADUC и ADAC?
ADUC (Active Directory Users and Computers, dsa.msc) — классическая консоль из эпохи Windows 2000, привычная и быстрая для рутинных операций. ADAC (Active Directory Administrative Center, dsac.exe) — современная консоль с поддержкой Recycle Bin, Fine-Grained Password Policies, истории PowerShell-команд каждой операции. Я использую обе: ADUC для скорости, ADAC для FGPP и восстановления удалённых объектов.

Как часто нужно проверять репликацию AD?
В малом офисе с двумя-тремя контроллерами автоматический мониторинг через Wazuh, Zabbix или PRTG — обязателен. Алерт на ошибки реплики и на расхождение по USN. Вручную раз в неделю я прогоняю repadmin /replsummary и dcdiag /e /v. Перед любыми изменениями (повышение FFL, добавление DC) — обязательно проверка, что репликация в норме.

Что такое FSMO-роли и зачем их знать?
Flexible Single Master Operations — пять ролей, которые в каждый момент времени принадлежат только одному DC: Schema Master, Domain Naming Master, RID Master, PDC Emulator, Infrastructure Master. PDC Emulator используется для синхронизации времени и обработки изменений паролей, RID Master выдаёт пулы SID для новых объектов. Если умрёт держатель FSMO — часть операций перестанет работать. Знать, кто что держит, и уметь перенести (Move-ADDirectoryServerOperationMasterRole) — обязательный навык.

Стоит ли в 2026 году ещё пользоваться Active Directory или переходить в Entra ID?
Для российского малого бизнеса в 2026 году on-premise AD остаётся базой: облачные сервисы Microsoft работают с ограничениями, законодательство по локализации данных требует локального хранения. AD никуда не уходит и активно поддерживается — Windows Server 2025 принёс ряд улучшений в Kerberos, LAPS и групповую политику. Гибридные сценарии с Entra ID — точечно, для отдельных клиентов с международным присутствием.

Передайте администрирование AD профессионалам

Семёнов Е.С. и команда ITfresh: полный аутсорсинг IT для юрлиц до 50 рабочих мест в Москве. Берём на сопровождение существующие домены, разворачиваем новые, чиним «наследие» предыдущих подрядчиков.