Очистка Active Directory от исторического мусора: заброшенные контроллеры домена, осиротевшие SID и забытые доверительные отношения

Active Directory давно перестала быть просто «каталогом пользователей». Сегодня это кровеносная система корпоративной инфраструктуры, которая питает всё в ней происходящее – от аутентификации и авторизации до работы групповых политик, делегирования прав и интеграции с бизнес-приложениями. Но, как и любой сложный организм, каталог со временем обрастает «шрамами»: заброшенными контроллерами домена, осиротевшими SID, группами-призраками и доверительными отношениями, о которых уже никто не помнит.

В условиях импортозамещения эта проблема обретает новую остроту. Переход на отечественные службы каталогов редко происходит по модели «отключил старое — включил новое» Реальность – это гибридные среды, где MS AD и Linux-каталоги сосуществуют месяцами, а иногда годами. В таком контексте исторический мусор становится уже не столько техническим долгом, сколько готовым вектором для атак (например, lateral movement, обхода сегментации и компрометации нового периметра) до завершения миграции.

Так почему же «гигиена» MS AD критична перед переездом, какие подводные камни ждут при выстраивании доверительных отношений, как харденить контроллеры и почему без системного анализа привилегий любая генеральная уборка обречена на повторение? Давайте разберёмся.

Почему MS AD с историческим мусором нельзя запускать в миграцию?

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

Так, например, заброшенные контроллеры домена и «вечные» учетки становятся лакомыми объектами со стороны атакующего. Неправильно выведенные из эксплуатации контроллеры домена, своевременно не получавшие патчи и обновления безопасности, не синхронизируют реплики, становятся точками отказа или векторами для атак через устаревшие протоколы. Учетные записи, у которых отключена необходимость смены пароля или у которых пароль не менялся больше полугода-года, становятся золотой жилой для Kerberoasting и AS-REP Roasting.

При миграции или удалении объектов их SID остаются в ACL файловых хранилищ, GPO, реестре делегирования. Если атрибут SIDHistory не очищен после переезда, злоумышленник может использовать его для эскалации привилегий, взяв на себя права из старого домена. Таким образом, осиротевший SID снова обретает семью, только уже неблагополучную с точки зрения ИБ.

Опыт анализа корпоративных сред в большинстве случаев, к сожалению, показывает «заброшенность» (по тем или иным причинам) служб каталогов со стороны ИТ-подразделений:

• десятки и сотни пустых групп или групп с одним пользователем, которые являются по сути кладбищем прав доступа, и чаще всего без каких-либо опознавательных знаков;
• огромное число групп с максимальным количеством пользователей, которые часто являются legacy-объектами, куда десятилетиями добавляют сотрудников «на всякий случай»;
• большое количество групп с административными аккаунтами, что в чистом виде является показателем избытка привилегий и прямого риска горизонтального перемещения;
• циклическая вложенность групп, которая ломает аудит эффективных прав и делает невозможным точный расчет поверхности атаки и, соответственно, ее минимизацию.

Что можно посоветовать перед миграцией?

В первую очередь, исходя из лучших практик, рекомендуется:

• сократить состав группы Администраторы домена (в зависимости от размера инфраструктуры это может быть 5-10 учетных записей), внедрить MFA, отключить настройку не требовать смены пароля у рядовых пользователей;
• закрыть векторы атак DCSync, RBCD, Shadow Credentials, избавиться от избыточных GenericAll/GenericWrite на критичные группы и контейнеры (например, Domain Users, Authenticated Users);
• включить Audit account management и Audit logon events на всех контроллерах домена, настроить сбор и анализ событий 4727–4756 (изменение групп).

Без этого база для миграции будет содержать «дыры», которые атакующий найдет быстрее, чем вы успеете перенести пользователей в новый каталог.

Доверительные отношения в гибридной среде – точки приложения векторов атаки

Переезд на отечественные решения почти всегда требует настройки доверительных отношений или кросс-доменных доверительных отношений Kerberos. И здесь начинаются самые сложные моменты.

Что ломается чаще всего:

• синхронизация времени – Kerberos допускает дрейф не более 5 минут. Разница в настройках NTP между MS AD и отечественной службой каталогов может привести к постоянным KRB_AP_ERR_SKEW и падению аутентификации;
• DNS и резолвинг realm — отсутствие корректных SRV-записей (_kerberos._tcp, _ldap._tcp) или кэширующих записей в DNS приводит к таймаутам и fallback на NTLM, что сводит на нет криптографическую защиту;
• SID Filtering и PAC Validation — по умолчанию внешние доверия фильтруют SIDHistory. Если фильтр отключен «для совместимости», то миграционные SID становятся вектором эскалации. Кроме того, Linux-реализации Kerberos (Heimdal/MIT) по-разному обрабатывают PAC (Privilege Attribute Certificate), что может вызывать ошибки авторизации в legacy-приложениях;
• заброшенные доверительные отношения — доверительные отношения к поглощенным площадкам, тестовым контурам или выведенным из эксплуатации дочерним доменам часто остаются в статусе Transitive или Bidirectional. Это неявный доступ в сегмент, который уже не контролируется службами ИБ, в т.ч. SOC.

Что можно посоветовать для реализации «здоровых» доверительных отношений?

Практика показывает, что не лишним будет выполнение следующих рекомендаций:

• перевод доверия в режим Selective Authentication;
• включение SID Filtering на всех внешних и лесных довериях;
• валидация PAC на принимающей стороне;
• перевод всех legacy доверительных отношений в Unidirectional или закрытие с обязательной очисткой SIDHistory;
• прогон сценария атак (например, попытку эскалации через нефильтрованный SIDHistory) в тестовом контуре перед поднятием доверия в продакшене.

Новые контроллеры домена – новые поверхности атак

Отечественные и любые другие реализации контроллеров доменов являются зрелыми решениями, но они не являются быстрой заменой для MS AD. Их архитектура, модели делегирования и механизмы аудита отличаются, что требует собственного харденинга. Гибридная среда удваивает поверхность атаки, если не применять единые метрики гигиены к обоим контурам. Поэтому, помимо очистки MS AD и подготовки к миграции, рекомендуется выполнять ряд простых и в то же время эффективных мер по защите новых Linux каталогов. Рассмотрим их подробнее.

Так, например, порт 389 (LDAP) должен быть закрыт для внешних сетей, работать только LDAPS (636) с валидными сертификатами. Анонимный bind обязан быть отключен (nsslapd-allow-anonymous-access: off), иначе каталог превращается в открытую карту инфраструктуры.

Далее, необходимо принудительно контролировать доступ. SELinux/AppArmor в режиме enforcing на всех серверах каталогов должны быть не опцией, а базовым требованием. Без этого обход через уязвимые сервисы или мисконфиги правил доступа (ACI) становится тривиальным.

Во многих Linux службах каталогов ACI часто настраиваются вручную. Широкие ACI на userPassword, krbPrincipalKey или ldap:///anyone дают прямой путь к эскалации привилегий. Рекомендуется и далее реализовывать строгий принцип наименьших прав и регулярный аудит изменений каталога.

Отключение аудита последних успешных входов лишает аналитиков важного контекста для расследования инцидентов. В этом плане поможет контроль версий служб каталогов (должны быть закрыты известные CVE) и корректный маппинг SPN, иначе Kerberoasting на сервисные аккаунты становится штатным сценарием. Также, нужно всегда понимать выполнять инвентаризацию SPN и при переносе в новый каталог есть отличная возможность «начать все с чистого листа» (в т.ч. задать сложные пароли, внедрить gMSA-аналоги, настроить аудит запросов аутентификации).

Дополнительно, до подключения каталога в продуктив, рекомендуется выполнять обязательную ротацию паролей, внедрить поддержку OTP или подобных сервисов, настроить loginShell=/sbin/nologin для сервисных аккаунтов, nsAccountLock для уволенных.

Что еще можно и нужно делать, чтобы содержать инфраструктуру в чистоте?

Ручная выгрузка Get-ADUser, фильтрация по LastLogonDate и ­массовое отключение учеток — путь к инцидентам. Отключить «лишнюю» учетку, которая тянет legacy-ERP или сервис-аккаунт резервного копирования, легко. Восстановить бизнес-процесс — сложно и дорого.

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

Переход на модель RBAC или ABAC также поможет безопасно отсечь исторических наслоения в правах доступа. Независимо от применяемой модели разграничения доступа нужно оценивать права в каталоге в связке с файловыми серверами и приложениями. Так, если снизить количество дублирующих доступ групп, снизить количество «одиноких» групп (без членов, без описания, старше года), то это уже позволит значительно сократить поверхность атаки без ручного перебора.

Заключение

Заброшенный контроллер домена, осиротевший SID или забытое доверительное отношение — это не просто технический долг. Это готовый плацдарм для атакующего, который уже изучил вашу инфраструктуру и ищет слабое звено. В условиях перехода на отечественные службы каталогов цена ошибки удваивается: вы защищаете не только старый контур, но и закладываете фундамент безопасности нового периметра.

Очистка Active Directory начинается не с PowerShell-скриптов, а с принятия простого факта: каталог – это живой организм, требующий постоянного ухода, метрик и бизнес-контекста. Без анализа ACL, без привязки к реальным процессам любая «генеральная уборка» превратится в бесконечный цикл борьбы с legacy. Вручную это делать долго и опасно, нужен системный аналитический подход.

Начинайте с аудита, стройте роли, автоматизируйте контроль, фиксируйте (документируйте) процесс «уборки» и принятые исключения (почему ту или иную группу нельзя удалить, исключить права доступа у той или иной учетной записи). Чистый AD – это не когда всё работает, это когда вы точно знаете, почему и за счёт чьих прав оно работает, и можете доказать это любому аудитору или специалисту информационной безопасности.

Авторы: Николай Перетягин, менеджер по продукту Dataplan, NGR Softlab, Андрей Шабалин, руководитель группы анализа данных NGR Softlab.