Настройка политик паролей в Windows Server

Опубликовано 02.05.2026 · обновлено 24.05.2026

Политики паролей в Windows Server настраиваются через Group Policy (Default Domain Policy) или Fine-Grained Password Policies для отдельных групп пользователей. Минимальная длина, сложность, срок действия, история паролей контролируются одним набором параметров (но есть нюансы, о которых обычно не пишут).

Где хранятся политики паролей

Короче, есть два механизма.

Default Domain Policy действует на всех пользователей домена. Одна политика на всех. Настраивается через Group Policy Management.

Fine-Grained Password Policies (FGPP) позволяет задавать разные правила для разных групп. Появилось в Server 2008. Работает через Active Directory Administrative Center.

Тут такое дело: политика паролей из Default Domain Policy привязана к домену, а не к OU. Распространённая ошибка: создать отдельную GPO с политикой паролей на конкретный OU. Не сработает. Только Default Domain Policy или FGPP. Я видел админов, которые тратили часы, пытаясь понять, почему их «правильно настроенная» GPO с паролями не применяется к нужному OU. Потому что так не работает.

Настройка через Group Policy

Открываем Group Policy Management, находим Default Domain Policy, редактируем.

Путь: Computer Configuration, Policies, Windows Settings, Security Settings, Account Policies, Password Policy.

Параметры:

Enforce password history (Вести журнал паролей): сколько последних паролей запоминать (рекомендация: 24)
Maximum password age (Максимальный срок действия): через сколько дней менять пароль (90 дней классика, но NIST теперь говорит иначе)
Minimum password age (Минимальный срок действия): через сколько дней можно сменить пароль (1 день, чтобы не прокручивали историю)
Minimum password length (Минимальная длина): минимум символов (рекомендация: 12-14)
Password must meet complexity requirements (Пароль должен отвечать требованиям сложности): заглавные, строчные, цифры, спецсимволы
Store passwords using reversible encryption (Хранить пароли с обратимым шифрованием): всегда Disabled, если только не нужно для CHAP или Digest Authentication

Если честно, стандартные 8 символов это уже давно мало. Современные GPU ломают 8-символьный пароль за часы. Видеокарта RTX 4090 перебирает NTLM-хеши со скоростью 300 миллиардов в секунду. Вдумайтесь в эту цифру.

# Проверяем текущую политику паролей в домене
# Быстрый способ узнать что настроено
Get-ADDefaultDomainPasswordPolicy

# Меняем минимальную длину пароля на 12 символов
Set-ADDefaultDomainPasswordPolicy -Identity "contoso.local" -MinPasswordLength 12

# Меняем срок действия на 180 дней
Set-ADDefaultDomainPasswordPolicy -Identity "contoso.local" -MaxPasswordAge "180.00:00:00"

# Включаем историю паролей на 24
Set-ADDefaultDomainPasswordPolicy -Identity "contoso.local" -PasswordHistoryCount 24

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

Fine-Grained Password Policies

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

Мой знакомый Павел, сисадмин в банке из Нижнего Новгорода, настроил три уровня на своём Dell PowerEdge R640:

Администраторы: 16 символов, менять каждые 60 дней, блокировка после 3 попыток
Обычные сотрудники: 12 символов, менять каждые 90 дней, блокировка после 5 попыток
Сервисные учётки: 25 символов, не менять (но максимально сложный), блокировка после 3 попыток

# Создаём Fine-Grained Password Policy для админов
# Precedence определяет приоритет, меньше число = выше приоритет
New-ADFineGrainedPasswordPolicy -Name "Admin-Password-Policy" `
    -Precedence 10 `
    -MinPasswordLength 16 `
    -MaxPasswordAge "60.00:00:00" `
    -MinPasswordAge "1.00:00:00" `
    -PasswordHistoryCount 24 `
    -ComplexityEnabled $true `
    -LockoutThreshold 3 `
    -LockoutDuration "00:30:00" `
    -LockoutObservationWindow "00:30:00"

# Создаём политику для обычных пользователей
New-ADFineGrainedPasswordPolicy -Name "User-Password-Policy" `
    -Precedence 20 `
    -MinPasswordLength 12 `
    -MaxPasswordAge "90.00:00:00" `
    -MinPasswordAge "1.00:00:00" `
    -PasswordHistoryCount 12 `
    -ComplexityEnabled $true `
    -LockoutThreshold 5 `
    -LockoutDuration "00:15:00" `
    -LockoutObservationWindow "00:15:00"

# Привязываем политику к группе Domain Admins
Add-ADFineGrainedPasswordPolicySubject -Identity "Admin-Password-Policy" `
    -Subjects "Domain Admins"

# Привязываем к группе обычных пользователей
Add-ADFineGrainedPasswordPolicySubject -Identity "User-Password-Policy" `
    -Subjects "Domain Users"

# Проверяем какая политика действует на конкретного пользователя
Get-ADUserResultantPasswordPolicy -Identity "admin.petrov"

На самом деле FGPP настраивается и через GUI. Active Directory Administrative Center, System, Password Settings Container, New Password Settings. Но через PowerShell быстрее, особенно если нужно создать несколько политик.

Грубо говоря, FGPP привязывается к группам безопасности или к конкретным пользователям. К OU привязать нельзя. Поэтому продумайте структуру групп заранее.

Политика блокировки учётных записей

Рядом с политикой паролей есть Account Lockout Policy. Не менее важная штука.

Путь: Account Policies, Account Lockout Policy.

Account lockout threshold: количество неудачных попыток до блокировки (рекомендация: 5-10)
Account lockout duration: на сколько минут блокировать (15-30 минут)
Reset account lockout counter after: через сколько минут сбрасывать счётчик (15-30 минут)

Знаете что, я видел серверы с threshold в 3 попытки. Пользователи блокировались каждый понедельник утром, потому что забывали пароль за выходные. Helpdesk сходил с ума. 5-10 попыток оптимальный баланс между безопасностью и удобством.

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

# Находим источник блокировки через Event Viewer
# На PDC Emulator ищем событие 4740
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4740} -MaxEvents 10 |
    Select-Object TimeCreated, @{N='User';E={$_.Properties[0].Value}}, @{N='Source';E={$_.Properties[1].Value}}

# Быстрая разблокировка пользователя
Unlock-ADAccount -Identity "ivanov.ivan"

# Проверяем статус блокировки
Get-ADUser "ivanov.ivan" -Properties LockedOut, LockoutTime | Select-Object Name, LockedOut, LockoutTime

Аудит политик паролей

# Находим пользователей с паролями, которые не менялись больше 90 дней
# Полезно для аудита безопасности
$threshold = (Get-Date).AddDays(-90)
Get-ADUser -Filter {PasswordLastSet -lt $threshold -and Enabled -eq $true} `
    -Properties PasswordLastSet |
    Select-Object Name, SamAccountName, PasswordLastSet |
    Sort-Object PasswordLastSet

# Находим пользователей с "Срок действия пароля не ограничен"
# Это потенциальная дыра в безопасности
Get-ADUser -Filter {PasswordNeverExpires -eq $true -and Enabled -eq $true} `
    -Properties PasswordNeverExpires |
    Select-Object Name, SamAccountName

# Находим пользователей, которые никогда не меняли пароль
Get-ADUser -Filter {PasswordLastSet -eq 0 -and Enabled -eq $true} `
    -Properties PasswordLastSet |
    Select-Object Name, SamAccountName

Сервисные учётки с бессрочными паролями это нормально (но пароль должен быть длинным и сложным). Обычные пользователи с таким флагом это проблема. По факту, регулярный аудит паролей должен быть частью вашей рутины безопасности.

Проверка паролей по базам утечек

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

Microsoft предлагает Azure AD Password Protection. Оно работает и с локальным Active Directory (через прокси). Сервис проверяет новые пароли по глобальному списку запрещённых паролей Microsoft (который включает миллионы скомпрометированных паролей) плюс по вашему кастомному списку.

# Установка Azure AD Password Protection Proxy
# Скачайте с сайта Microsoft
# Установите на сервере с выходом в интернет

# На каждом DC установите DC Agent
# После установки агента перезагрузите DC

# Проверяем статус через PowerShell
Get-AzureADPasswordProtectionDCAgent
Get-AzureADPasswordProtectionProxy

Тут такое дело: без Azure AD Premium P1 или P2 можно использовать только глобальный список. Кастомные запрещённые слова (название компании, продукта и т.д.) требуют лицензию Azure AD Premium.

Практические советы по внедрению

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

Вот план постепенного перехода:

Предупредите пользователей за 2 недели: «Через 14 дней минимальная длина пароля увеличится до 12 символов»
Проведите обучение: покажите, как создавать парольные фразы
Включите новую политику
Подготовьте helpdesk к увеличению обращений в первую неделю
Через месяц проведите аудит и проверьте, все ли перешли на новые пароли

Ну и не забывайте про MFA (многофакторную аутентификацию). В 2026 году пароль сам по себе, каким бы длинным он ни был, это однофакторная защита. MFA через приложение Microsoft Authenticator или аппаратные ключи FIDO2 значительно повышает безопасность.

Типичные ошибки с политиками паролей

Вот список ошибок, которые я видел снова и снова:

Создание GPO с политикой паролей на OU вместо Default Domain Policy. Не работает
Установка Minimum password age = 0. Позволяет пользователям прокрутить историю паролей за 5 минут и вернуть старый пароль
Lockout threshold = 3 для обычных пользователей. Массовые блокировки каждый понедельник
Одинаковые правила для всех, от администратора домена до стажёра. Используйте FGPP
Забывают про сервисные учётки. Ставят срок действия 90 дней, и через 90 дней ночью падает критичный сервис, потому что пароль сервисной учётки истёк

Где купить лицензию

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

Знаете что? Даже самая строгая политика паролей не поможет, если пользователи записывают пароли на стикерах. А они будут, если пароль длинный и его нужно менять каждые 90 дней.

Современный подход: разрешить парольные фразы (длинные, но легко запоминаемые) и рекомендовать корпоративный парольный менеджер. KeePass, Bitwarden, 1Password for Business. Парольный менеджер хранит все пароли в зашифрованном хранилище, а пользователю нужно запомнить только один мастер-пароль.

Мой коллега Виктор из Ростова-на-Дону (админит сеть на 180 пользователей, основной сервер Dell PowerEdge R750xs на Xeon Silver 4314) внедрил Bitwarden Enterprise. Каждый сотрудник получил персональное хранилище паролей. Через три месяца количество обращений «забыл пароль» сократилось на 60%. Тут такое дело: люди перестали придумывать простые пароли, потому что им больше не нужно их запоминать. Парольный менеджер генерирует 20-символьные пароли и вставляет их автоматически.

# Скрипт для проверки "слабых" паролей в AD
# Использует модуль DSInternals (скачать с PowerShell Gallery)
# Install-Module DSInternals -Force

# Получаем хеши паролей из AD
$accounts = Get-ADReplAccount -All -Server "DC01.company.local" -NamingContext "DC=company,DC=local"

# Проверяем по словарю слабых паролей
# Скачайте словарь с HaveIBeenPwned (NTLM-хеши)
Test-PasswordQuality -Account $accounts -WeakPasswordHashesSortedFile "C:Toolspwned-passwords-ntlm.txt"

Короче, если вы никогда не проверяли пароли сотрудников по базам утечек, сделайте это. Результат может вас удивить. В типичной организации 15-25% паролей находятся в публичных базах утечек. Это значит, что злоумышленник может войти в вашу сеть, просто перебирая известные пароли.

А ещё не забывайте про gMSA (Group Managed Service Accounts). Это специальный тип учётных записей для служб, где пароль генерируется и ротируется автоматически самим Active Directory. Пароль длиной 240 символов, меняется каждые 30 дней, и его никто не знает, даже администратор. Для сервисов типа SQL Server Agent, IIS App Pools, Scheduled Tasks это идеальный вариант. По факту, gMSA полностью убирает проблему «забыли обновить пароль сервисной учётки».

# Создаём gMSA для сервиса SQL Server
New-ADServiceAccount -Name "gMSA-SQL" `
    -DNSHostName "gMSA-SQL.company.local" `
    -PrincipalsAllowedToRetrieveManagedPassword "SQL-Servers"

# Устанавливаем gMSA на целевом сервере
Install-ADServiceAccount -Identity "gMSA-SQL"

# Проверяем что gMSA работает
Test-ADServiceAccount -Identity "gMSA-SQL"

Для работы Active Directory и групповых политик нужна лицензия Windows Server. Ключик можно купить в keytrust24.store. Есть все актуальные версии: Windows Server 2022 Standard, Datacenter, а также Windows Server 2025. Активация моментальная, доставка ключа на email. А ещё CAL-лицензии для пользователей и устройств, без которых подключаться к серверу нелегально.

Где хранятся политики паролей

Настройка через Group Policy

Fine-Grained Password Policies

Политика блокировки учётных записей

Аудит политик паролей

Рекомендации NIST и современный подход

Проверка паролей по базам утечек

Практические советы по внедрению

Типичные ошибки с политиками паролей

Где купить лицензию

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

Читайте также

Все способы восстановления Windows 11: полный обзор

Монитор производительности Windows: руководство

Команда WMIC в Windows: справочник администратора