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

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

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

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

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

• AD DS — те самые контроллеры домена, классический Active Directory, на котором всё держится.
• AD CS (Certificate Services) — внутренний центр сертификации компании. Нужен для LDAPS, EAP-TLS на Wi-Fi, S/MIME-почты, подписи кода.
• AD FS (Federation Services) — единый вход (SSO) во внешние веб-сервисы по SAML/OIDC. В малом бизнесе встречается редко.
• AD LDS (Lightweight Directory Services) — отдельный LDAP-каталог под прикладные задачи без полноценного домена.
• AD RMS (Rights Management Services) — DRM для документов Office.
• Entra ID (бывший Azure AD) — облачный каталог Microsoft 365. С локальным AD не одно и то же, хоть многие и думают наоборот.

Если говорить про офис на 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):

• Schema Master (на уровне леса) — единственный DC, который принимает изменения схемы AD.
• Domain Naming Master (на уровне леса) — управляет добавлением и удалением доменов в лесу.
• RID Master (на уровне домена) — выдаёт пулы относительных идентификаторов другим DC для генерации SID новых объектов.
• PDC Emulator (на уровне домена) — авторитетный источник времени для домена, обработка изменений паролей, поддержка legacy-клиентов.
• Infrastructure Master (на уровне домена) — синхронизация межотдельных ссылок (важна в мультидоменном лесу).

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

# Где сейчас 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

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

• ADUC (dsa.msc) — Active Directory Users and Computers. Классическая консоль, быстрая для рутины: поиск пользователя, сброс пароля, отключение учётки, добавление в группу.
• ADAC (dsac.exe) — Active Directory Administrative Center. Современный интерфейс: поддерживает Recycle Bin, Fine-Grained Password Policies и показывает PowerShell-команду для каждой операции (фишка для обучения).
• GPMC (gpmc.msc) — Group Policy Management Console. Создание, привязка, тестирование GPO, моделирование RSoP.
• DSAC (dssite.msc) — Sites and Services. Управление сайтами, подсетями, межсайтовой репликацией.
• DNS Manager (dnsmgmt.msc) — управление DNS-зонами и записями.
• DHCP Manager (dhcpmgmt.msc) — управление областями DHCP и failover.
• PowerShell с модулем ActiveDirectory — мой основной инструмент для всего, что массовое.

Вдобавок ко всему, я всегда ставлю себе 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 дней.

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

• Расхождение времени между клиентом и DC более 5 минут — Kerberos падает (KRB_AP_ERR_SKEW). Поэтому строгая синхронизация времени критична.
• Учётная запись krbtgt подписывает все TGT. Если её хеш украден — рисуется Golden Ticket с правами Domain Admin на 10 лет вперёд. Защита: ротация пароля каждые 180 дней.
• SPN (Service Principal Name) привязывает Kerberos-аутентификацию к конкретному сервису на конкретном хосте. Дублирующиеся SPN ломают Kerberos.
• RC4-зашифрованные TGS — старая практика, использующаяся в атаках Kerberoasting. Для AES-only клиентов настраивается через параметр учётной записи.

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 и др.). Базовые правила, которые я внедряю:

• На каждом DC установлена роль DNS, зона домена реплицируется через AD (Active Directory Integrated).
• Reverse-зоны для всех внутренних подсетей.
• Включён scavenging с интервалом 7 дней — иначе зона забивается мёртвыми записями.
• Forwarders на 77.88.8.8 (Yandex) и 1.1.1.1 (Cloudflare) для офисов в РФ.
• Никогда не используем 8.8.8.8 в Москве — медленно и подвержено блокировкам.
• На клиентских DNS-настройках первичный — соседний DC, вторичный — этот же или 127.0.0.1 (на самих DC).

Диагностика — через 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 человек:

• SG_HelpDesk — сброс паролей и разблокировка учёток в OU=Sotrudniki, ввод компьютеров в домен в OU=Workstations.
• SG_GPO_Admins — управление GPO (создание, изменение), но не привязка к OU вне песочницы.
• SG_DNS_Admins — управление DNS-зонами без прав в AD.
• SG_DHCP_Admins — управление DHCP.
• SG_Backup_Operators — права на бэкап, не на восстановление.

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

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

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

• Account Logon → Credential Validation, Kerberos AS, Kerberos TGS — Success and Failure;
• Account Management → User/Computer/Group Management — Success and Failure;
• DS Access → Directory Service Changes — Success;
• Logon/Logoff → Logon, Special Logon, Account Lockout — Success and Failure;
• Object Access → File Share — Success and Failure;
• Privilege Use → Sensitive Privilege Use — Success;
• System → Security State Change, Security System Extension — Success.

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

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

• 4624 / 4625 — успешный/неудачный логон;
• 4768 / 4769 — выдача TGT / TGS (атаки Kerberoasting видны по запросам RC4 от современных клиентов);
• 4720 / 4722 / 4724 / 4726 — создание / включение / сброс пароля / удаление учётки;
• 4728 / 4732 — добавление в группу (Domain Admins, Schema Admins — критично);
• 4740 — блокировка учётки;
• 4756 / 4757 — добавление в Universal Group;
• 1102 — очистка журнала аудита (всегда инцидент);
• 4688 — создание процесса (с командной строкой);
• 4104 — выполнение PowerShell ScriptBlock.

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

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

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

• Регулярная (каждые 180 дней) ротация пароля krbtgt — два сброса с интервалом 10-24 часа. Используем штатный скрипт Microsoft New-KrbtgtKeys.ps1.
• При подозрении на компрометацию — немедленный двойной сброс. Все активные TGT инвалидируются, пользователи переавторизуются.
• Защищённая группа Protected Users (доступна с Windows Server 2012 R2). Учётки в этой группе не могут использовать NTLM, RC4, делегирование, кэширование учёток. Срок жизни TGT — 4 часа без обновления.
• Credential Guard на рабочих станциях с Windows 10/11 Enterprise — изолирует LSASS в защищённой памяти Hyper-V.
• Privileged Access Workstations (PAW) для админов — выделенные машины, минимально соединённые с интернетом и обычной почтой.

И ещё один важный момент: 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 делаем каждую неделю, месяц или квартал в любом домене, который находится у нас на обслуживании:

• Ежедневно: мониторинг репликации (автоматически в Wazuh), мониторинг ошибок Directory Service, проверка журналов LAPS на предмет ротации.
• Еженедельно: repadmin /replsummary, dcdiag /e /v, проверка свободного места на дисках NTDS, обновления Windows Defender и баз.
• Ежемесячно: установка cumulative update на DC по очереди с проверкой работоспособности, ревизия членов привилегированных групп.
• Ежеквартально: прогон PingCastle, тестовое восстановление одного DC из бэкапа, ротация паролей сервисных учёток (где не используются GMSA), фишинговая симуляция для пользователей.
• Каждые 180 дней: двойной сброс krbtgt, ревизия делегированных прав на OU.
• Раз в год: большой аудит, обновление документации по архитектуре, тренировка плана аварийного восстановления.

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 — это пока точечное решение, скорее для отдельных клиентов, у которых есть международное присутствие.