FGPP в Active Directory: разные политики паролей для разных ролей

Семёнов Евгений Сергеевич, директор АйТи Фреш. Стандартная Default Domain Policy гонит всех пользователей под одну гребёнку: 8 символов, смена раз в 90 дней, три попытки до блокировки. Для простого менеджера это может быть избыточно, для администратора Domain Admins — откровенно слабо. Именно на стыке этой проблемы и живёт Fine-Grained Password Policy (FGPP).

Кому вообще нужны разные политики паролей

У нас на практике FGPP первый раз серьёзно приземлился году в 2019: клиент — строительный подрядчик на 110 рабочих мест. Пароли админов они держали такими же, как у обычных пользователей, а на одну сервисную учётку SQL Server пришлось вовсе отключить требование смены — сотни процессов использовали её пароль в коде. После ночного инцидента с перебором RDP я разделил политики на три группы.

• Администраторы — минимум 14 символов, смена раз в 30 дней, блокировка через 3 попытки.
• Обычные сотрудники — 10 символов, смена раз в 90 дней, блокировка через 5 попыток.
• Сервисные учётки — 20 символов, без обязательной смены, блокировка через 10 попыток.

Всё это работает с Windows Server 2008 и выше. Привязка PSO — только на группу безопасности или конкретного юзера, на OU нельзя (это ключевой момент, который до сих пор сбивает с толку тех, кто привык к GPO).

Предварительная проверка домена

Функциональный уровень леса и домена должен быть 2008 R2 или выше. Права на создание PSO — у Domain Admins либо делегированные на контейнер CN=Password Settings Container,CN=System,DC=....

(Get-ADDomain).DomainMode
(Get-ADForest).ForestMode

# Кто вообще может писать в контейнер PSO?
Get-Acl "AD:CN=Password Settings Container,CN=System,DC=corp,DC=local" |
  Select-Object -ExpandProperty Access

PSO для администраторов: жёстко, но осмысленно

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

New-ADFineGrainedPasswordPolicy -Name "PSO-Admins" `
  -DisplayName "PSO-Admins (строгая)" `
  -Precedence 10 `
  -MinPasswordLength 14 `
  -PasswordHistoryCount 24 `
  -ComplexityEnabled $true `
  -ReversibleEncryptionEnabled $false `
  -MaxPasswordAge "30.00:00:00" `
  -MinPasswordAge "1.00:00:00" `
  -LockoutThreshold 3 `
  -LockoutDuration "00:30:00" `
  -LockoutObservationWindow "00:30:00" `
  -ProtectedFromAccidentalDeletion $true

Add-ADFineGrainedPasswordPolicySubject -Identity "PSO-Admins" `
  -Subjects "Domain Admins","Enterprise Admins","Schema Admins"

История в 24 пароля плюс MinPasswordAge в один день закрывают классический трюк «поменяю пароль 24 раза подряд и вернусь к любимому».

PSO для обычных пользователей и сервисников

Средняя политика для Domain Users — 10 символов, сложность включена, смена раз в 90 дней. Ставится с более высоким Precedence, чтобы проиграть конфликт с PSO-Admins для тех, кто попал и туда, и туда.

New-ADFineGrainedPasswordPolicy -Name "PSO-Users" `
  -Precedence 50 `
  -MinPasswordLength 10 -PasswordHistoryCount 12 `
  -ComplexityEnabled $true `
  -MaxPasswordAge "90.00:00:00" -MinPasswordAge "1.00:00:00" `
  -LockoutThreshold 5 -LockoutDuration "00:15:00" -LockoutObservationWindow "00:15:00" `
  -ProtectedFromAccidentalDeletion $true

Add-ADFineGrainedPasswordPolicySubject -Identity "PSO-Users" -Subjects "Domain Users"

Для сервисных учёток — отдельная группа SVC-Accounts, длинный пароль и MaxPasswordAge = 0 (не истекает). При этом обязательно мониторим попытки входа и ротацию через gMSA, где возможно.

New-ADGroup -Name "SVC-Accounts" -GroupScope Global -GroupCategory Security `
  -Path "OU=Groups,DC=corp,DC=local"

New-ADFineGrainedPasswordPolicy -Name "PSO-Service" `
  -Precedence 30 `
  -MinPasswordLength 20 -PasswordHistoryCount 10 `
  -ComplexityEnabled $true `
  -MaxPasswordAge "0.00:00:00" -MinPasswordAge "0.00:00:00" `
  -LockoutThreshold 10 -LockoutDuration "01:00:00" -LockoutObservationWindow "01:00:00"

Add-ADFineGrainedPasswordPolicySubject -Identity "PSO-Service" -Subjects "SVC-Accounts"

Как выбирается эффективная политика

Если пользователь попал в несколько групп с разными PSO, срабатывает одна — с наименьшим Precedence. При равенстве — PSO с меньшим GUID (фактически рандом). Проверять всегда через командлет Get-ADUserResultantPasswordPolicy, а не «на глазок».

Get-ADUserResultantPasswordPolicy -Identity "a.ivanov"
Get-ADFineGrainedPasswordPolicy -Filter *
Get-ADFineGrainedPasswordPolicySubject -Identity "PSO-Admins"

# Подсветим юзеров, у которых вообще нет PSO
Get-ADUser -Filter * -Properties msDS-ResultantPSO |
  Where-Object { -not $_."msDS-ResultantPSO" } |
  Select SamAccountName

Реальный кейс: медклиника в ЮАО Москвы

Январь 2026. Пришёл клиент — сеть клиник, 72 рабочих места, один DC Server 2022 и второй Server 2019. Аудит показал: Default Domain Policy — 8 символов, без блокировки вообще, треть сотрудников живёт с паролем Qwerty12! пять лет. По требованию безопасности их страховой компании надо было развести политики и внедрить MFA на VPN. За два дня мы подняли четыре PSO (Admins, Doctors, ResearchService, SVC), синхронизировали через скрипт Get-ADGroupMember с OU-принадлежностью, написали внутреннюю инструкцию. Стоимость — 34 500 рублей за работу и документацию. Через месяц инцидентов с заблокированными учётками стало на 40% меньше — пользователи начали вводить пароли внимательнее, а не пытаться угадать.

Современные требования NIST вместо старых догм

NIST SP 800-63B и свежие Microsoft Security Baseline заметно разошлись с тем, что 15 лет назад считалось «хорошей политикой». Ключевое отличие — отказ от периодической принудительной смены паролей в пользу длины и MFA.

Если бизнес требует формальной периодичности (например, аудит 152-ФЗ), делаю компромисс: 180 дней для обычных, 30 — для привилегированных, MFA везде.

Аудит и мониторинг

Без логирования FGPP не имеет смысла. Включаем Audit Account Management и Audit Logon через GPO, события летят в Security Log. Ключевые ID, которые я мониторю в SIEM или через простой PowerShell-сбор:

• 4723 — пользователь сменил свой пароль.
• 4724 — админ сбросил чужой пароль.
• 4740 — учётку заблокировали.
• 4767 — разблокировали.
• 4771 — Kerberos pre-auth failed (чаще всего — подбор пароля).

Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    ID        = 4740
    StartTime = (Get-Date).AddDays(-1)
} | Select TimeCreated,
    @{n='Account';e={$_.Properties[0].Value}},
    @{n='Source' ;e={$_.Properties[1].Value}} |
  Format-Table -AutoSize

FAQ — частые вопросы по FGPP

Можно ли повесить PSO на OU?

Нет, Password Settings Object цепляется только к группе безопасности или конкретному пользователю. Чтобы политика действовала на всех в OU — создайте группу, добавьте туда объекты и привяжите PSO к ней. Синхронизацию с OU легко повесить на ежечасный PowerShell.

Какой PSO выиграет, если их несколько?

Активным окажется PSO с наименьшим значением Precedence — чем меньше число, тем выше приоритет. При равенстве Precedence выбирается объект с меньшим objectGUID, то есть фактически случайно. Результат смотрим через Get-ADUserResultantPasswordPolicy.

FGPP управляет паролем DSRM?

Нет, DSRM-пароль живёт отдельно и задаётся при промоушене DC. Меняется через ntdsutil: set dsrm password. К FGPP и к политикам домена он отношения не имеет, это локальная учётка для режима восстановления.

Как перейти с Default Domain Policy на FGPP без простоя?

Перенос безболезненный: сначала создаёте PSO-Baseline с теми же параметрами, что и сейчас в Default Domain Policy, и вешаете на Domain Users. Потом отдельно делаете PSO для администраторов и сервисников. Пользователи почувствуют новые правила только при следующей смене пароля.