Fine-Grained Password Policy в AD 2008R2: разные правила для разных групп

Долгое время в Active Directory была одна беда с парольными политиками: либо одна политика на весь домен, либо городи отдельные домены ради разграничения. До Windows Server 2008 - именно так. В Server 2008 Microsoft добавила Fine-Grained Password Policy, она же Password Settings Objects, она же PSO. Функция существует уже несколько лет, но в реальных инфраструктурах встречается редко - большинство живёт на дефолтной Domain Password Policy и не трогает лишнего.

Мы так жили тоже, пока не пришло понимание, что администраторские учётки с теми же требованиями к паролю, что у рядовых пользователей - это не «достаточно», а «дыра, которую мы просто не видим».

Откуда растут ноги

Триггером стали не абстрактные соображения о безопасности, а конкретная ситуация у клиента на аудите: в AD обнаружились несколько привилегированных учёток с паролями, не менявшимися больше года, без блокировки по числу попыток. Технически это соответствовало текущей политике домена, потому что политика была написана «под пользователей» - 8 символов, блокировка после 5 неудачных попыток. Для обычного сотрудника - терпимо. Для domain admin - катастрофа.

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

PSO решает именно это противоречие.

Как устроен механизм

Fine-Grained Password Policy работает через объекты типа msDS-PasswordSettings в разделе System\Password Settings Container. Каждый такой объект содержит полный набор парольных атрибутов - длина, сложность, история, возраст, параметры блокировки - и привязывается к конкретным пользователям или глобальным группам безопасности.

Если к пользователю привязано несколько PSO, применяется тот, у которого выше приоритет (меньше число в атрибуте msDS-PasswordSettingsPrecedence). Если PSO нет - падает в дефолтную Domain Password Policy. Логика простая, главное не запутаться с приоритетами.

Важный момент: PSO применяется к глобальным группам безопасности, а не к OU. Если привыкли управлять делегированием через OU - это непривычно, но управляемо.

Что настроили

Создали два PSO через ADSI Edit (PowerShell-командлеты New-ADFineGrainedPasswordPolicy тоже работают, но на части инсталляций с ними возникали вопросы с правами - ADSI Edit надёжнее и нагляднее).

PSO для администраторов - приоритет 10 (применяется первым):

• минимальная длина пароля: 14 символов
• требования сложности: включены
• минимальный возраст пароля: 1 день
• максимальный возраст: 60 дней
• история паролей: 24
• порог блокировки: 3 неудачные попытки
• окно наблюдения: 30 минут
• длительность блокировки: 0 (только ручная разблокировка)

Привязан к глобальной группе Domain Admins и отдельной группе Tier0-Admins, в которую вошли все учётки с правами схемы, PKI и резервного копирования.

PSO для рядовых пользователей - приоритет 20 (применяется если нет более приоритетного):

• минимальная длина: 8 символов
• остальное совпадает с существующей доменной политикой
• порог блокировки: 5 попыток
• длительность блокировки: 15 минут (автоматически)

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

Нюансы, которые выяснились

Проверка применённого PSO. Через Get-ADUserResultantPasswordPolicy можно посмотреть, какой PSO реально применён к конкретному пользователю. Первое время делали это для каждой новой привилегированной учётки - убеждались, что приоритеты отработали правильно.

Сервисные учётки. Обнаружилось, что несколько сервисных учёток (агенты резервного копирования, мониторинг) входили в Domain Admins по инерции - кто-то когда-то добавил «чтобы точно работало». Вынесли их в отдельную группу с минимальными правами, PSO с длинным паролем и без ротации (пароли у сервисных учёток не должны меняться сами собой - это поломает службы).

Блокировка администраторских учёток. Порог в 3 попытки и ручная разблокировка - это серьёзно. Обязательно нужна учётка-«ключ», которая хранится офлайн и может разблокировать заблокированного администратора. Иначе один неловкий момент - и доступ к домену потерян.

Аудит блокировок. На контроллерах доменов включили аудит событий 4740 (Account Locked Out) и 4625 (Failed Logon) с пересылкой в лог-агрегатор. Без этого администраторская блокировка с порогом в 3 попытки - это слепая зона.

Что в итоге

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

Следующий шаг - разобраться с тем, кто и как обращается к привилегированным учёткам. PSO отвечает на вопрос «насколько сложен пароль», но не на вопрос «кто, когда и откуда вошёл». Это уже история про аудит входов и использование Privileged Access Workstation, но про это - отдельно.