Модернизация Active Directory - усиливаем базовую безопасность.

В первой части модернизации Active Directory я рассматривал не обновление Windows Server, а более фундаментальную задачу: приведение домена Active Directory в технически исправное состояние. До ввода новых контроллеров пришлось восстановить репликацию SYSVOL, вернуть публикацию NETLOGON, исправить иерархию времени и убедиться, что резервное копирование контроллеров действительно выполняется с обработкой гостевой ОС.

После этого возникает закономерный вопрос: если репликация работает, dcdiag проходит, SYSVOL одинаков на обоих DC и резервные копии создаются — можно ли наконец добавлять новые контроллеры и выводить старые?

Пока нет.

Исправный домен и защищённый домен — это разные состояния.

Ранее в рамках модернизации домена я провел первичный аудит безопасности Active Directory. Автоматизированный health check показал максимальный итоговый риск PingCastle — 100 из 100 и 31 правило риска с ненулевым баллом. Это не означает, что домен уже взломан, но показывает, что в инфраструктуре одновременно сохранилось несколько потенциально опасных путей атаки.

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

При этом важно не превратить hardening в набор команд из интернета. В инфраструктуре работают реальные пользователи, серверы, 1С, RDS, файловые ресурсы, принтеры и стороннее ПО. Любое изменение протоколов аутентификации может оказаться не только защитной мерой, но и причиной простоя.

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

Что показал исходный аудит

После восстановления репликации и времени мы получили технически стабильную исходную точку. Теперь результаты security-аудита можно рассматривать не как общий список предупреждений, а как план конкретных изменений.

Среди наиболее важных находок:

Находка	Что обнаружено	Почему это важно
Устаревшие контроллеры домена	Два DC семейства Windows Server 2012/2012 R2	Старая ОС существенно ограничивает дальнейшее усиление безопасности и требует отдельного плана миграции
Признаки отсутствия защиты от старых критических уязвимостей	Сканер отметил риски MS17-010 и MS14-068	Необходимо проверить фактический уровень обновлений, а не полагаться только на вывод автоматического отчёта
SMBv1	Протокол включён на обоих DC	Лишняя поверхность атаки и зависимость от давно устаревшего протокола
LM/NTLMv1	Политика допускает устаревшие варианты аутентификации	Повышается риск компрометации учётных данных, но отключение требует предварительной инвентаризации зависимостей
krbtgt	Пароль не менялся более четырёх лет	При компрометации ключевого материала Kerberos появляется риск длительного сохранения доступа через поддельные TGT
Привилегированные учётные записи	Старые бессрочные пароли, разрешённая делегация, использование встроенного администратора	Компрометация одной учётной записи может сразу затронуть весь домен
Windows LAPS	Не обнаружен	Локальные административные пароли сложнее централизованно и безопасно ротировать
LDAP signing	Не требуется принудительно	Остаются сценарии неподписанных LDAP-подключений
Print Spooler и RPC на DC	Служба доступна удалённо, обнаружены интерфейсы принудительной аутентификации	На контроллерах остаются сервисы, которые обычно не нужны для основной роли AD DS
Аудит	Не собирается часть важных событий	Даже устранённая уязвимость мало помогает, если дальнейшие атаки невозможно вовремя обнаружить
Active Directory Recycle Bin	Отключена	Ошибочно удалённые объекты восстанавливать сложнее
Неактивные объекты	Около трети компьютерных учётных записей отмечены как неактивные	Старые объекты усложняют контроль инфраструктуры и могут сохранять ненужные права

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

Например, вывод по MS17-010 или MS14-068 нельзя превращать в утверждение «контроллер точно уязвим», не проверив точную версию ОС, установленные накопительные обновления и фактический статус Extended Security Updates. Именно поэтому health check должен заканчиваться ручной верификацией.

Почему сначала hardening, а только потом новые контроллеры

Можно было бы сразу развернуть Windows Server 2022/2025, повысить новые серверы до контроллеров домена и считать проблему старой ОС решённой.

Но новый DC реплицирует существующий Active Directory.

Он получит те же:

• учётные записи и группы;
• ACL и делегирование;
• GPO;
• настройки Kerberos;
• DNS-зоны;
• сервисные аккаунты;
• ошибки в структуре привилегий;
• устаревшие объекты.

То есть новая Windows Server не создаёт новый безопасный домен. Она подключается к существующему.

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

Основной приоритет — обновления и план вывода Windows Server 2012

Два действующих контроллера относятся к поколению Windows Server 2012/2012 R2.

Основная расширенная поддержка Windows Server 2012 завершилась ещё 10 октября 2023 года. На момент подготовки материала действует последний год Extended Security Updates, который заканчивается 13 октября 2026 года.

Это означает, что стратегия «оставим старые DC ещё на несколько лет и просто будем ставить обновления» уже не является нормальным долгосрочным вариантом.

Но миграция должна выполняться после проверки здоровья AD DS — именно этому и была посвящена первая часть.

Перед вводом новых контроллеров я хочу зафиксировать:

1. фактический уровень обновлений каждого старого DC;
2. состояние репликации AD DS и SYSVOL;
3. корректность DNS;
4. роли FSMO и Global Catalog;
5. работоспособность резервного копирования;
6. список сервисов, которые обращаются к DC по устаревшим протоколам.

После этого старые контроллеры можно выводить поэтапно, а не использовать обновление ОС «поверх» существующей проблемы как способ её замаскировать.

SMBv1 и NTLMv1: сначала найти зависимости, потом запрещать

SMBv1 включён на обоих контроллерах. Здесь направление очевидно: протокол необходимо убрать.

Но даже очевидное изменение должно иметь контрольную проверку.

Сначала нужно выяснить, кто действительно использует SMBv1. В небольших инфраструктурах такими клиентами иногда оказываются старые МФУ, сетевые сканеры, архивное ПО или давно забытый сервер.

Если зависимости отсутствуют, SMBv1 можно отключать и удалять как компонент. Если зависимость есть — её необходимо либо модернизировать, либо изолировать и убрать отдельно.

С NTLMv1 ситуация ещё показательнее. Простое переключение политики на NTLMv2-only выглядит правильно, но способно неожиданно отключить старое приложение, оборудование или службу.

Поэтому последовательность должна быть такой:

аудит → поиск клиента → устранение зависимости → запрет устаревшего протокола → контроль журналов и бизнес-сервисов.

Microsoft также рекомендует сначала выявлять системы, которые продолжают использовать NTLMv1, и только после этого переходить к запрету.

Такой подход медленнее одной настройки в GPO, но гораздо безопаснее для работающей инфраструктуры.

Уменьшаем поверхность атаки самих контроллеров

Контроллер домена не должен быть универсальным сервером.

Чем меньше на нём дополнительных ролей, служб и сетевых интерфейсов, тем меньше возможностей использовать DC как промежуточную точку атаки.

Исходный отчёт показал две связанные проблемы:

• удалённо доступный Print Spooler;
• RPC-интерфейсы, пригодные для сценариев принудительной аутентификации.

Если контроллер не используется как сервер печати, работу Spooler необходимо отдельно обосновать. Отключение службы на DC — распространённая мера уменьшения поверхности атаки, но и здесь нужно проверить локальные особенности инфраструктуры.

Отдельная задача — просмотреть доступность RPC, сетевые правила и роли самих DC. Цель не в том, чтобы «закрыть все порты», потому что Active Directory активно использует RPC. Нужно отделить штатный трафик AD DS от лишних сервисов и убедиться, что контроллер выполняет только те функции, которые действительно нужны.

LDAP signing: опасно включать без предварительного аудита

Исходный health check показал, что контроллеры допускают LDAP-аутентификацию без обязательной подписи.

На современном домене логичное состояние — требовать защищённое взаимодействие. Но перевод контроллеров сразу в режим обязательной подписи может отключить старые приложения, NAS, МФУ, системы контроля доступа или другое ПО, которое выполняет LDAP bind устаревшим способом.

Поэтому здесь особенно важен этап наблюдения.

До включения enforcement нужно собрать события LDAP, определить клиентов с неподписанными bind-запросами и исправить их конфигурацию. В актуальной документации Microsoft для этого предусмотрен отдельный сценарий мониторинга событий Directory Service.

Только когда источник каждого несовместимого подключения понятен, можно переходить от аудита к требованию подписи.

Это характерный пример того, почему безопасность Active Directory нельзя свести к чек-листу «включить десять GPO».

Правильный вопрос звучит не «какое значение поставить?», а «что перестанет работать после изменения и как я это проверю до переключения?»

Привилегированные учётные записи требуют отдельной ревизии

Автоматический отчёт выявил сразу несколько проблем вокруг администраторов:

• пароли двух привилегированных аккаунтов старше трёх лет;
• у привилегированных учётных записей разрешена делегация;
• есть бессрочные пароли;
• использовалась встроенная учётная запись Administrator;
• группа Schema Admins не пуста;
• часть администраторов не защищена дополнительными механизмами вроде Protected Users.

Это уже не одна настройка, а архитектура административного доступа.

В нормальной модели повседневная учётная запись сотрудника не должна одновременно быть его постоянной учётной записью Domain Admin. Сервисная учётная запись тем более не должна получать доменные административные права «на всякий случай».

На этом этапе необходимо разобрать каждое постоянное членство в привилегированных группах и ответить на несколько вопросов:

• кому действительно нужен Domain Admin;
• какие права используются постоянно, а какие — только во время обслуживания;
• есть ли сервисы, работающие от высокопривилегированных аккаунтов;
• какие учётные записи допускают делегирование;
• какие пароли не ротировались годами;
• почему кто-то постоянно находится в Schema Admins или Enterprise Admins.

Отдельно нужно тестировать совместимость с Protected Users: эта группа усиливает защиту учётных данных, но одновременно запрещает ряд старых механизмов аутентификации. Поэтому включать туда всех администраторов одним действием без проверки зависимостей тоже неправильно.

krbtgt: простой на вид сброс, который нельзя делать небрежно

Одна из самых заметных находок отчёта — пароль учётной записи krbtgt не менялся 1543 дня.

krbtgt используется Kerberos для защиты Ticket Granting Ticket. Если ключевой материал этой учётной записи будет скомпрометирован, злоумышленник может использовать его для формирования поддельных Kerberos-билетов — сценария, известного как Golden Ticket.

Но вывод «пароль старый — срочно поменяем» здесь недостаточен.

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

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

После восстановления AD DS и SYSVOL эта операция становится управляемой: есть исходная диагностика, рабочие резервные копии и возможность проверить распространение изменения по всем DC.

LAPS, аудит и восстановление — защита должна работать не только до атаки

В отчёте не обнаружен LAPS.

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

Windows LAPS решает именно эту задачу: пароль локального администратора становится уникальным для устройства и автоматически ротируется. В современных версиях Windows механизм встроен в ОС и может хранить резервную копию пароля в Active Directory при соответствующей настройке прав.

Но LAPS — только одна часть.

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

Без этого даже хорошо настроенный домен остаётся плохо наблюдаемым.

Ещё одна находка — выключенная Active Directory Recycle Bin. Она не является защитой от злоумышленника сама по себе, но сильно улучшает эксплуатационную устойчивость: случайно удалённый объект можно восстановить вместе со связанными атрибутами и членством в группах.

Включение Recycle Bin необратимо, поэтому перед изменением всё равно нужен preflight: функциональный уровень, резервное копирование и проверка репликации.

Что я не хочу делать на этом этапе

Важная часть модернизации — понимать не только что делать, но и что пока делать рано.

Я не хочу:

• одновременно менять десятки параметров безопасности;
• запрещать NTLMv1 и неподписанный LDAP без аудита клиентов;
• сбрасывать krbtgt, пока есть вопросы к репликации;
• поднимать функциональный уровень ради красивой цифры;
• переносить все FSMO-роли и сразу выключать старые DC;
• считать снижение PingCastle Score доказательством защищённости.

Каждое существенное изменение должно иметь четыре элемента:

исходное состояние → изменение → проверка → возможность отката или понятный план восстановления.

Именно такая схема позволяет модернизировать рабочий домен без превращения безопасности в лотерею.

Почему после этого будет отдельный пентест

PingCastle и подобные health-check инструменты хорошо отвечают на вопрос:

Какие опасные настройки и потенциальные пути компрометации видны в Active Directory?

Но это всё ещё не ответ на другой вопрос:

Может ли атакующий с обычной пользовательской учётной записью последовательно использовать эти условия и получить контроль над доменом?

Для этого нужен уже не health check, а пентест.

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

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

Это позволит проверить не абстрактные предупреждения, а реальные цепочки:

• какие данные о домене доступны обычному пользователю;
• какие отношения доверия и ACL создают пути повышения привилегий;
• есть ли опасные сервисные учётные записи;
• возможны ли сценарии Kerberoasting;
• какие варианты делегирования используются;
• нет ли неожиданных путей через GPO;
• как устроена AD CS и её шаблоны сертификатов;
• можно ли из обычной учётной записи получить локального администратора на сервере;
• существуют ли цепочки от рабочей станции к привилегированной сессии и далее к Domain Admin;
• какие из первоначальных находок действительно эксплуатируемы, а какие являются только конфигурационным риском.

Для анализа связей я планирую использовать в том числе графовую модель Active Directory — например, BloodHound. Она позволяет увидеть не отдельное слабое место, а цепочку из нескольких вполне обычных разрешений, которая в совокупности приводит к критическому объекту.

Сам стенд при этом должен считаться чувствительной системой. Копия Active Directory содержит реальные отношения между объектами и потенциально чувствительный материал аутентификации, поэтому она должна быть полностью отделена от production: отдельная виртуальная сеть, отсутствие маршрута к рабочей инфраструктуре, контролируемый доступ и уничтожение стенда после завершения исследования.

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

Как будет выглядеть критерий успеха

Цель модернизации — не получить «зелёный отчёт».

Я буду считать этот этап успешным, когда можно доказать несколько вещей:

1. контроллеры полностью обновлены либо подготовлены к выводу;
2. SMBv1 больше не нужен;
3. использование NTLMv1 и неподписанного LDAP выявлено и устранено либо локализовано;
4. на DC нет необоснованной дополнительной поверхности атаки;
5. привилегированные группы и сервисные учётные записи приведены к понятной модели;
6. пароль krbtgt безопасно ротирован по штатной процедуре;
7. внедрена управляемая ротация локальных административных паролей;
8. важные события безопасности централизованно собираются;
9. резервные копии и процедуры восстановления проверяемы;
10. повторный health check показывает не просто меньший балл, а исчезновение конкретных подтверждённых рисков.

И только после этого имеет смысл окончательно переводить домен на новые контроллеры, выводить Windows Server 2012/2012 R2 и повышать функциональный уровень.

Вместо вывода

В первой части этого кейса основная работа была почти незаметной для пользователя: SYSVOL, DFSR, NETLOGON, W32Time, VSS, резервные копии.

Во второй становится заметен ещё один важный принцип:

Модернизация Active Directory — это не замена старой Windows Server на новую. Это последовательное удаление старых технических долгов и путей компрометации.

Сначала нужно сделать домен предсказуемым. Затем — уменьшить поверхность атаки. После этого — проверить, какие пути атаки остались на самом деле. И только потом считать инфраструктуру готовой к следующему поколению контроллеров.

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