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 для администраторов и сервисников. Пользователи почувствуют новые правила только при следующей смене пароля.