Как защитить пароли Active Directory от утечек

Что будем делать

Защиту паролей разделим на две задачи:

1. Аудит — определим учётные записи, использующие пароли, которые присутствуют в базе известных утечек.
2. Предотвращение — запретим устанавливать такие пароли при их смене или сбросе.

Для этого будем использовать Lithnet Password Protection for Active Directory и данные Have I Been Pwned Pwned Passwords.

Как работает Lithnet Password Protection

Lithnet Password Protection расширяет стандартные механизмы защиты паролей Active Directory и позволяет проверять устанавливаемые пароли по дополнительным правилам.

В рассматриваемом сценарии мы будем использовать его для:

• работы с локальным хранилищем известных скомпрометированных паролей;
• сравнения паролей с данными HIBP;
• блокировки известных скомпрометированных паролей при смене пароля;
• блокировки таких паролей при административном сбросе пароля.

Устанавливаем Lithnet Password Protection

Начинаем с установки Lithnet Password Protection for Active Directory.

Подключаемся к контроллеру домена с административными правами.

Актуальный релиз Lithnet Password Protection рекомендуется получать из официального репозитория проекта:

Lithnet Password Protection — Releases

Запускаем установщик и выполняем установку необходимых компонентов.

На каких контроллерах нужно устанавливать компонент

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

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

Загружаем базу скомпрометированных паролей HIBP

Теперь необходимо подготовить локальное хранилище известных скомпрометированных паролей.

Используем данные сервиса Have I Been Pwned — Pwned Passwords.

Официальные ресурсы:

• Pwned Passwords;
• Have I Been Pwned API.

В используемой в нашем примере версии Lithnet синхронизация запускается командой:

Sync-HashesFromHibp

Открываем PowerShell с необходимыми административными правами и выполняем команду.

Sync-HashesFromHibp

Начнётся получение данных и формирование локального хранилища.

Что показывает результат синхронизации

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

OperationStart          : 1/23/2024 7:13:35 PM
OperationFinish         : 1/23/2024 8:30:35 PM
Duration                : 01:17:00.2187755
PagesRetrieved          : 1048576
PagesWithChanges        : 1048576
PagesUnchanged          : 0
NewHashesImported       : 931856448
ExistingHashesDiscarded : 0
TotalHashesProcessed    : 931856448

Основные параметры:

• OperationStart / OperationFinish — начало и окончание операции;
• Duration — продолжительность синхронизации;
• PagesRetrieved — количество обработанных страниц данных;
• PagesWithChanges — количество страниц, в которых были обнаружены изменения;
• NewHashesImported — количество импортированных записей;
• TotalHashesProcessed — общее количество обработанных записей.

В нашем конкретном запуске было обработано более 931 миллиона записей.

Проверяем локальное хранилище Lithnet

После завершения синхронизации проверяем, что локальное хранилище действительно создано.

В версии Lithnet из нашего примера файлы находятся в каталоге:

C:\Program Files\Lithnet\Active Directory Password Protection\Store\v3\p

В нашем тестовом окружении размер хранилища составлял:

12,2 ГБ

Сам факт наличия файлов также не заменяет проверку состояния самого компонента. После настройки желательно убедиться по журналам и тестовой смене пароля, что фильтр действительно работает.

Как обновлять базу HIBP

Однократной загрузки базы недостаточно: новые компрометации появляются постоянно.

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

Для этого можно создать задачу Windows Task Scheduler, которая будет запускать:

Sync-HashesFromHibp

с выбранной организацией периодичностью.

Проверяем существующие пароли Active Directory

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

Для их поиска в нашем примере используется отдельный скрипт:

Скачать Audit-Passwords.ps1

В нашем примере сохраняем скрипт в:

C:\scripts

Перед запуском проверяем содержимое файла и при необходимости снимаем блокировку загруженного файла.

Подробнее: Как исправить ошибку «Отсутствует цифровая подпись» при запуске скрипта PowerShell.

После проверки запускаем скрипт:

C:\scripts\Audit-Passwords.ps1

После завершения в нашем варианте скрипта создаётся отчёт:

C:\scripts\get-pwned-users.csv

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

Что делать с найденными учётными записями

Если аудит обнаружил пользователей с небезопасными паролями, недостаточно просто сохранить CSV-отчёт.

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

Особое внимание стоит уделить:

• привилегированным административным учётным записям;
• учётным записям с доступом к критичным системам;
• сервисным учётным записям;
• пользователям с удалённым доступом;
• учётным записям, для которых отсутствует MFA.

Запрещаем устанавливать скомпрометированные пароли

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

В нашем примере параметры Lithnet распространяются через Group Policy.

Создаём GPO для контроллеров домена

Открываем:

Group Policy Management

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

Domain Controllers

В нашем примере политика называется:

LithnetPP

Открываем созданную политику на редактирование.

Включаем блокировку скомпрометированных паролей

В версии Lithnet из нашего примера параметр находится по пути:

Computer Configuration
→ Policies
→ Administrative Templates
→ Lithnet
→ Password Protection for Active Directory
→ Default Policy

Открываем:

Reject passwords found in the compromised password store

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

Enabled

В нашем сценарии включаем проверку для:

• Enable for password set operations;
• Enable for password change operations.

После настройки убеждаемся, что политика действительно применяется к необходимым контроллерам домена.

Например:

gpupdate /force

И проверяем результирующую политику:

gpresult /r /scope computer

Проверяем блокировку небезопасного пароля

После применения настроек обязательно проверяем работу фильтра.

Тестировать можно несколькими способами:

• создать тестового пользователя;
• выполнить административный Reset Password;
• изменить пароль тестового пользователя обычным способом.

В нашем примере открываем Active Directory Users and Computers, выбираем тестового пользователя и нажимаем:

Reset Password

Для теста выбираем заведомо распространённую комбинацию, присутствующую в базе HIBP.

Проверить наличие тестовой комбинации в базе можно через:

HIBP Pwned Passwords

В нашем тесте используется:

Password01

При попытке установить запрещённый пароль Active Directory отклоняет операцию.

Теперь повторяем тест с уникальным тестовым паролем, который соответствует остальным требованиям доменной политики и отсутствует в базе запрещённых комбинаций.

Если настройка выполнена правильно, допустимый пароль устанавливается, а скомпрометированный — отклоняется.

Не забываем про обычную политику паролей

Lithnet Password Protection дополняет, а не отменяет стандартные механизмы Active Directory.

Поэтому необходимо отдельно контролировать:

• минимальную длину пароля;
• историю паролей;
• политику блокировки учётных записей;
• Fine-Grained Password Policies, если они используются;
• защиту привилегированных аккаунтов;
• MFA для сервисов и систем, которые её поддерживают.

А что насчёт Microsoft Entra Password Protection

Если организация использует Microsoft Entra ID и гибридную инфраструктуру, стоит отдельно рассмотреть Microsoft Entra Password Protection для локальной Active Directory.

Это другой механизм защиты, и его архитектура отличается от Lithnet.

Не следует автоматически устанавливать одновременно несколько password filter решений без проверки их совместимости и понимания порядка обработки паролей.

FAQ

Что означает обнаружение пароля пользователя в HIBP?

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

Передаются ли пароли пользователей Active Directory на сайт HIBP?

В рассматриваемой конфигурации Lithnet используется локальное хранилище данных Pwned Passwords. Конкретный механизм синхронизации и проверки зависит от версии продукта, поэтому перед внедрением необходимо ознакомиться с документацией используемого релиза.

Нужно ли регулярно обновлять базу скомпрометированных паролей?

Да. База известных утечек постоянно изменяется, поэтому локальное хранилище следует периодически синхронизировать.

Достаточно ли установить Lithnet только на один контроллер домена?

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

Почему Windows не пишет, что пароль заблокировал именно Lithnet?

Пользователь может получить стандартное сообщение Active Directory о несоответствии пароля требованиям политики. Для точной диагностики необходимо учитывать остальные правила паролей и проверять журналы соответствующего компонента.

Заменяет ли Lithnet стандартную парольную политику Active Directory?

Нет. Он дополняет существующие механизмы. Стандартные требования Active Directory к паролям, история паролей и другие политики продолжают действовать.

Нужно ли принудительно менять все найденные скомпрометированные пароли?

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

Заключение

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

Lithnet Password Protection позволяет дополнить стандартную защиту Active Directory проверкой по базе известных компрометаций. Сначала можно провести аудит существующих учётных записей, а затем запретить установку небезопасных паролей при их смене и сбросе.

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

И главное — пароль должен оставаться только одним из уровней защиты. Для критичных систем и административных учётных записей используйте MFA, минимально необходимые привилегии и постоянный мониторинг событий безопасности.

Также рекомендую статью Как установить доменные службы Active Directory на Windows Server.