U-SERVER
Безопасность серверов

Парольная политика, блокировка учётных записей и MFA в Windows Server

Как настроить политики паролей и блокировки локальных и доменных учётных записей Windows Server, проверить результат и выбрать MFA-схему для административного доступа.

17 минут
абстрактная иллюстрация политики доступа и многофакторной защиты
На автономном сервере требования к паролям и блокировку учётной записи задают локальной политикой безопасности. Для доменных пользователей Active Directory базовую политику задают доменной GPO, а отдельным пользователям или группам можно назначать fine-grained password policy. Многофакторная аутентификация не включается одной настройкой Windows Server: её выбирают для конкретного канала доступа, например для RDP через RD Gateway, RADIUS/NPS и поддерживаемого MFA-провайдера.

Сначала определите, к каким учётным записям относится политика

Источник политики зависит не от способа входа, а прежде всего от типа учётной записи и роли сервера.

СценарийГде задавать основные параметрыНа кого действует
Автономный серверЛокальная политика безопасности или локальная GPOЛокальные учётные записи этого сервера
Сервер — член доменаЛокальная политика для локальных аккаунтов; доменная политика для пользователей ADЛокальные аккаунты сервера и доменные пользователи — по разным источникам политики
Контроллер доменаДоменная политика паролей и блокировкиДоменные учётные записи; локальной базы SAM на контроллере домена нет
Отдельные требования для части доменных пользователейPassword Settings Object (PSO), или fine-grained password policyКонкретные пользователи AD или глобальные security-группы AD

Парольная аутентификация локального пользователя проверяется локальной базой SAM сервера. Поэтому локальные Password Policy и Account Lockout Policy применяются к локальным аккаунтам автономного сервера или сервера — члена домена. Если сервер состоит в домене, доменная GPO может переопределить конфликтующие локальные параметры для компьютера.

Для обычного доменного пользователя пароль и блокировку обычно определяет доменная политика Active Directory. Политика, привязанная только к OU с пользователем, не становится доменной парольной политикой. Базовые параметры домена настраивают в GPO, действующей на уровне домена; во многих средах для этого используют Default Domain Policy, но организация может выбрать иной документированный GPO-процесс.

Названия оснасток и доступные пункты

Названия разделов GPO, оснасток, командлетов и отображаемых статусов зависят от версии Windows Server, роли хоста, установленных средств RSAT и доменных политик. Типичные пути ниже применимы к поддерживаемым версиям Windows Server, но перед массовым изменением сверяйте их с официальной документацией Microsoft для своей версии и проверяйте итоговую, а не только открытую в редакторе настройку.

Подготовьте изменение и аварийный доступ

Безопасная подготовка к изменению политики

Выполните эти действия до изменения локальной политики, доменной GPO или PSO.

  1. 1
    Составьте список затронутых учётных записей
    Разделите локальные и доменные аккаунты. Отдельно отметьте привилегированные учётные записи, служебные учётные записи, задания планировщика, службы IIS, агенты резервного копирования, интеграции и скрипты, которые используют пароль. Для каждой записи зафиксируйте владельца, способ входа и последствия блокировки.
  2. 2
    Подготовьте независимый путь восстановления
    Проверьте вход отдельной аварийной учётной записью либо доступ через локальную консоль, гипервизор или BMC. Аварийная запись должна быть защищена, иметь известного владельца, контролируемое хранение реквизитов и регулярную проверку. Не проверяйте её впервые после того, как заблокировали основного администратора.
  3. 3
    Определите процедуру разблокировки
    Назначьте ответственного, канал подтверждения личности и время реакции. Для доменной учётной записи заранее убедитесь, что у ответственного есть права на разблокировку в AD. Для локальной — проверьте доступ администратора к самому серверу. Зафиксируйте, где искать причину неудачных входов, а не только как снять блокировку.
  4. 4
    Сохраните исходное состояние и выберите способ проверки
    Запишите действующие параметры, GPO и исключения. Базовую парольную политику рабочего домена нельзя пилотировать на отдельной OU обычной областью действия GPO: проверяйте её в отдельном тестовом домене либо меняйте в согласованное окно. Для ограниченной проверки пользовательского эффекта параметров можно применить временный PSO к тестовым пользователям, но такая проверка не подтверждает обработку базовой доменной GPO. После изменения проверяйте вход из отдельной сессии, не закрывая действующий административный сеанс.

Не подчиняйте все записи одинаковой блокировке без проверки

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

Какие параметры согласовать в политике паролей и блокировки

ПараметрЧто регулируетЧто согласовать
Политика паролейМинимальную длину, сложность, историю, минимальный возраст и другие правила создания пароляДлина и запрет повторного использования не заменяют друг друга; требования должны быть выполнимы для интерактивных и управляемых сервисных сценариев
Срок действия пароляКогда требуется сменить парольПлановую смену нужно увязать с владельцем, автоматизацией, хранением секретов и процедурой обновления зависимостей
Account lockout thresholdЧисло неверных попыток до блокировкиС порогом, источниками неудачных входов и вероятностью распылённого подбора паролей — проверки одного пароля для многих учётных записей — или ошибок пользователя
Account lockout durationКак долго длится блокировкаС допустимым простоем и тем, есть ли круглосуточная процедура разблокировки
Reset account lockout counter afterЧерез какое время без новых ошибок сбрасывается счётчик неверных попытокС порогом и длительностью блокировки, чтобы ошибки не накапливались неожиданно

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

В документации Microsoft для Account Lockout Policy порог блокировки допускает значения от 0 до 999: значение 0 отключает блокировку по числу неудачных попыток. Длительность блокировки допускает значение 0 для блокировки до ручной разблокировки либо значение в минутах до 99 999. Период сброса счётчика задаётся в минутах от 1 до 99 999; при включённом пороге длительность блокировки должна быть не меньше периода сброса счётчика. Это диапазоны интерфейса политики, а не рекомендуемые значения.

Блокировка — одновременно защита и риск отказа в доступе

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

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

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

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

  1. 1
    Проверьте текущую локальную политику
    Откройте консоль PowerShell или командную строку от имени администратора и выполните net accounts. Команда должна вывести текущие параметры длины, истории, возраста пароля и блокировки для локального компьютера. Если значения отличаются от ожидаемых, не меняйте их вслепую: проверьте, не управляет ли ими доменная GPO.
  2. 2
    Измените Password Policy и Account Lockout Policy
    В типичной конфигурации откройте secpol.msc, затем раздел Account Policies с подразделами Password Policy и Account Lockout Policy. Задайте согласованный набор параметров, сохраните изменение и запишите прежние и новые значения в журнал изменения. На сервере под доменным управлением изменение в локальной оснастке может быть заменено при следующей обработке GPO.
  3. 3
    Обновите политики и проверьте результат
    Выполните обновление компьютерной политики, снова запустите net accounts и сопоставьте вывод с утверждёнными значениями. Если вывод вернулся к прежним параметрам или не соответствует локальному редактору, найдите применённую доменную GPO через gpresult и переносите изменение в корректный источник политики.
  4. 4
    Проверьте сценарий входа без потери сеанса
    В отдельном тестовом подключении проверьте вход локальной тестовой записью, смену пароля при необходимости и ожидаемую реакцию на ошибку. Не имитируйте многократные неверные входы для рабочей привилегированной или служебной записи. При неожиданной блокировке используйте заранее подготовленный административный доступ и устраните источник неверного пароля.
Показывает параметры учётных записей, действующие для локального компьютера. Запускайте в повышенной консоли.
net accounts
Вывод:
Ожидаемый результат: вывод содержит параметры password history, minimum password length, maximum password age, lockout threshold, lockout duration и lockout observation window.
Запрашивает повторное применение компьютерных и пользовательских GPO. После выполнения повторите `net accounts` и проверьте отчёт `gpresult`.
gpupdate /force
Вывод:
Ожидаемый результат: сообщения об успешном обновлении политик компьютера и пользователя. Если для обработки отдельных параметров требуется запуск системы или вход пользователя, команда может предложить перезагрузку либо выход из сеанса.

Настройка доменной политики для пользователей Active Directory

Изменение доменной Password Policy и Account Lockout Policy

Работайте из административной станции или контроллера домена с необходимыми правами и установленными средствами управления GPO.

  1. 1
    Определите источник базовой политики домена
    В Group Policy Management найдите GPO с Account Policies, связанную с корнем домена, и проверьте порядок связей, наследование и обработку этой GPO контроллерами домена. Не пытайтесь назначить базовую парольную политику доменных пользователей через GPO, привязанную только к OU с пользователями: такая область применения не создаёт отдельную парольную политику для них.
  2. 2
    Измените согласованный набор параметров
    В Computer Configuration откройте Windows Settings, Security Settings, Account Policies и настройте Password Policy и Account Lockout Policy. Изменяйте связанные параметры вместе: при включённом пороге проверьте длительность блокировки и период сброса счётчика. Сохраните название GPO, дату, инициатора, причину и план отката.
  3. 3
    Проверьте репликацию и результирующую политику домена
    Дождитесь репликации AD и SYSVOL и обработки политики контроллерами домена либо выполните согласованное обновление политики на них. Затем запустите net accounts /domain и, если доступен модуль ActiveDirectory, Get-ADDefaultDomainPasswordPolicy. Результат должен отражать базовую политику домена, а не только сохранённые в редакторе GPO значения.
  4. 4
    Диагностируйте обработку GPO на контроллере домена
    Если результирующие значения не изменились, создайте отчёт gpresult /h на контроллере домена либо используйте Group Policy Results для контроллера. Проверьте связь GPO с доменом, порядок обработки, security filtering, WMI-фильтры, наследование, репликацию AD и SYSVOL. Отчёт сервера-члена используйте отдельно, если нужно выяснить, какая политика Account Policies действует на его локальные учётные записи.
Показывает базовые параметры учётных записей домена на компьютере, присоединённом к Active Directory. Выполняйте с доступом к домену.
net accounts /domain
Вывод:
Ожидаемый результат: вывод содержит доменные параметры. При ошибке подключения к домену проверьте DNS, доступность контроллера домена и контекст запуска.
Получает базовую доменную парольную политику через модуль PowerShell ActiveDirectory, если модуль установлен и у текущей учётной записи есть доступ к AD.
Get-ADDefaultDomainPasswordPolicy
Вывод:
Ожидаемый результат: свойства политики, включая длину, историю, возраст пароля и параметры блокировки. Ошибка отсутствия командлета означает, что нужно установить или запустить средства RSAT/AD PowerShell либо использовать административную станцию.
Создаёт HTML-отчёт о применённых GPO в текущем каталоге. Запускайте команду в повышенной консоли и проверяйте раздел Computer Details.
gpresult /h .\gpresult.html
Вывод:
Ожидаемый результат: в отчёте перечислены применённые и отклонённые GPO с причиной. Если нужная GPO отклонена, исправьте причину до повторной проверки.

Fine-grained password policy: когда нужна и как проверить результат

Fine-grained password policy нужна, когда базовая политика домена не подходит всем: например, для отдельной группы администраторов, пользователей с иным регуляторным требованием или временной группы миграции. Она реализуется объектом Password Settings Object (PSO) в контейнере Password Settings Container и задаёт параметры паролей и блокировки отдельно от базовой доменной политики.

PSO назначают непосредственно пользователям Active Directory или глобальным security-группам AD. Его нельзя применить к локальным учётным записям сервера, OU, компьютеру, distribution-группе или универсальной и доменно-локальной группе как к целевому объекту политики. При назначении группе эффект получают её пользователи согласно правилам Active Directory.

Если пользователю применимы несколько PSO, Active Directory выбирает политику с наименьшим числом в поле precedence. Непосредственное назначение пользователю имеет приоритет перед политиками, полученными через членство в группе; при одинаковом precedence между применимыми групповыми PSO результат может определяться GUID объекта. Поэтому не используйте одинаковые значения precedence как способ задать неопределённый приоритет.

Введение PSO без скрытых исключений

  1. 1
    Опишите цель и целевой объект
    Сформулируйте, чем PSO отличается от базовой политики и почему этого нельзя решить обычной доменной политикой. Выберите существующую или отдельную глобальную security-группу с понятным владельцем. Не добавляйте в неё служебные и аварийные записи только ради удобства.
  2. 2
    Создайте PSO документированным средством AD
    Используйте Active Directory Administrative Center или командлеты модуля ActiveDirectory, доступные в вашей поддерживаемой версии Windows Server. Задайте уникальное и осмысленное precedence, все параметры пароля и блокировки, затем назначьте PSO пользователю либо глобальной security-группе.
  3. 3
    Проверьте результирующую политику пользователя
    Для тестового пользователя выполните Get-ADUserResultantPasswordPolicy -Identity <пользователь>. Сравните результат с ожидаемым PSO и проверьте членство в группах, если команда показывает другой объект или не возвращает назначенную политику.
  4. 4
    Документируйте исключение и пересмотр
    Сохраните DN или имя PSO, precedence, назначенные объекты, владельца, причину, дату пересмотра и процедуру удаления. При изменении состава целевой группы повторно проверяйте результирующую политику хотя бы для одного представителя.
Показывает результирующую fine-grained password policy для указанного доменного пользователя. Команда требует модуля ActiveDirectory и доступа к домену.
Get-ADUserResultantPasswordPolicy -Identity test.user
Вывод:
Ожидаемый результат: свойства назначенного PSO. Если PSO не применяется, проверьте прямое назначение, тип и членство группы, precedence и репликацию Active Directory.

Как обнаружить блокировки и неудачные входы

Проверяйте не только факт блокировки, но и её источник: сохранённый старый пароль в службе, задаче, мобильном клиенте, RDP-клиенте или скрипте будет повторно блокировать запись после ручной разблокировки. В журнале безопасности Windows событие 4625 обычно фиксирует неудачный вход на системе, где он был обработан; событие 4740 фиксирует блокировку учётной записи, часто на контроллере домена, который её выполнил. Для доменных сценариев также полезны события Kerberos и NTLM, например 4771 и 4776, если соответствующий аудит включён.

Наличие и состав событий зависят от роли хоста, типа входа и настроек аудита. Подробную настройку Security Event Log, Advanced Audit Policy, хранение и разбор событий смотрите в статье «Аудит Windows Server: Security Log, Advanced Audit Policy и PowerShell».

Выводит заблокированные доменные пользовательские учётные записи при наличии модуля ActiveDirectory и прав на чтение AD.
Search-ADAccount -LockedOut -UsersOnly
Вывод:
Ожидаемый результат: список заблокированных доменных пользователей либо отсутствие вывода. До `Unlock-ADAccount` найдите источник неверных попыток в событиях, иначе блокировка может повториться.

Что такое MFA и почему её нельзя включить одной настройкой Windows Server

MFA требует подтверждений из независимых факторов: знания, владения или биометрии. Пароль и одноразовый код из приложения либо пароль и аппаратный ключ — разные факторы. Два пароля, два SMS-кода или повторный запрос того же пароля сами по себе не образуют MFA; это может быть двухэтапная проверка, но не многофакторная аутентификация.

МеханизмДля чего нуженДобавляет ли MFA для прямого входа на Windows Server
NLAПредварительная проверка учётных данных до полного RDP-сеансаНет. NLA меняет этап аутентификации RDP, но само по себе не добавляет второй фактор
Credential GuardЗащита секретов Windows от извлечения из процессов ОСНет. Это защита учётных данных на устройстве
Remote Credential GuardЗащита от передачи пароля и производных секретов на удалённый RDP-хостНет. Это режим делегирования и защиты реквизитов для RDP
Windows Hello for BusinessАутентификация с привязанным к устройству ключом, который пользователь разблокирует PIN-кодом или биометриейВ поддерживаемой модели может обеспечивать MFA, но это не универсальная настройка целевого сервера. Возможность входа зависит от модели развёртывания, доверия, клиента и канала подключения
Смарт-карта и сертификатный входАутентификация с сертификатом и закрытым ключом на смарт-картеСмарт-карта с PIN сочетает факторы владения и знания и может обеспечивать MFA. Для прямого или RDP-входа нужны поддерживаемые PKI, сертификаты, клиент и настройки входа
Entra MFA и Conditional AccessПолитики доступа и дополнительная проверка в поддерживаемых облачных и интегрированных потоках входаСами по себе не защищают обычный прямой RDP-вход на локальный сервер. Нужен поддерживаемый поток входа или посредник, для которого документирована интеграция

Для RDP MFA относится к точке, которая фактически выполняет или дополняет аутентификацию. Поэтому формулировка «включить MFA для Windows Server» недостаточна: нужно определить, подключается ли администратор напрямую к серверу, через RD Gateway, VPN, bastion host, PAM-систему или иной шлюз.

Как выбрать поддерживаемую MFA-схему для административного доступа

Канал доступаДокументируемая схема MFAЧто проверить до внедрения
RDP через RD GatewayRD Gateway передаёт запросы на RADIUS/NPS; NPS интегрируется с поддерживаемым MFA-провайдером, например с Microsoft Entra MFA NPS Extension при соблюдении условий поддержкиСовместимость версий RD Gateway, NPS, RADIUS и провайдера; требования к лицензиям и регистрации пользователей; поддерживаемые методы MFA; тайм-ауты, отказоустойчивость, журналирование и аварийный доступ. Политики Conditional Access не применяются к запросам, которые обрабатывает NPS Extension
Прямой RDP к серверуНе считать Entra MFA прямой заменой серверной аутентификации; использовать поддерживаемый шлюз, VPN с MFA, bastion host, смарт-карту или другой документированный механизмГде проверяется дополнительный фактор и остаётся ли прямой парольный RDP доступным в обход выбранного решения
Вход через VPNMFA на VPN-шлюзе или у его поставщика идентификацииСвязь MFA с разрешениями после подключения: VPN сам по себе не ограничивает доступ к нужному серверу и порту
Веб-консоль, BMC или сторонняя система управленияВстроенная схема MFA конкретного продукта либо интеграция с поддерживаемым IdP или RADIUSПоддерживаемые версии прошивки и провайдера, локальный аварийный доступ, роли, журналирование и изоляция сети управления

Схема с RD Gateway, RADIUS/NPS и MFA-провайдером требует как минимум RD Gateway, NPS как RADIUS-сервера, сетевой связности между компонентами и документированной интеграции выбранного провайдера. Для Microsoft Entra MFA NPS Extension дополнительно проверяют поддерживаемую версию NPS, требования к Microsoft Entra tenant, лицензированию и разрешённым методам проверки. Conditional Access относится к Entra ID и требует соответствующей лицензии; его условия нельзя переносить на локальный прямой RDP-вход без поддерживаемого посредника.

Не создавайте обход MFA при миграции

Если после внедрения MFA остаётся доступный из тех же сетей прямой RDP к целевому серверу с паролем, атакующий может обойти RD Gateway и второй фактор. Выбранную архитектуру нужно сопоставить с правилами сети, разрешёнными источниками и группами Remote Desktop Users. Вопросы сегментации и bastion host раскрыты в статье «Сегментация серверной сети: VPN, bastion host и защищённый административный доступ».

Проверка выбора MFA до развёртывания

  1. 1
    Зафиксируйте канал и целевой ресурс
    Запишите, откуда администратор приходит: интернет, корпоративная сеть, VPN или bastion host; куда подключается: RD Gateway, RDP-хост, веб-консоль или BMC; и какая идентичность используется: AD, Entra ID, локальная учётная запись или внешняя IdP.
  2. 2
    Проверьте матрицу поддержки поставщика
    В официальной документации Microsoft, RD Gateway/NPS и выбранного MFA-провайдера сопоставьте версии компонентов, поддерживаемый протокол, методы MFA, требования к TLS и сертификатам, сетевые порты, лицензирование и ограничения. Не заменяйте эту проверку предположением, что поддержка Entra MFA означает поддержку любого RDP-подключения.
  3. 3
    Спланируйте отказ второго фактора
    Определите, что произойдёт при недоступности провайдера, RADIUS/NPS, интернета, устройства пользователя или метода подтверждения. Согласуйте контролируемую аварийную процедуру с ограниченным сроком и аудитом; она не должна превращаться в постоянный парольный обход.
  4. 4
    Проведите пилот и проверьте отсутствие обхода
    Протестируйте успешный и неуспешный вход, отклонение второго фактора, вход аварийной записью по утверждённой процедуре и регистрацию событий. Затем убедитесь, что сетевые правила и настройки RDP не оставляют прямой путь, обходящий шлюз с MFA.

Пошаговая настройка RDP, NLA, RD Gateway и MFA зависит от версии компонентов и выбранного провайдера, поэтому вынесена в статью «Защита RDP на Windows Server: NLA, MFA и ограничение доступа». Ограничение сетевых источников доступа описано в «Windows Defender Firewall: правила, PowerShell и журналирование», а хранение и ротация паролей служебных записей — в «Управление секретами сервера: хранение, выдача, ротация и отзыв доступов».

Термины в статье

Credential Guard — функция Windows, изолирующая учётные данные и производные секреты с помощью виртуализации, чтобы ограничить их извлечение из процессов ОС.
NLA — механизм предварительной аутентификации RDP, проверяющий учётные данные пользователя до создания полного удалённого графического сеанса.
RDP — протокол удалённого доступа к графическому сеансу Windows, передающий экран, ввод и перенаправляемые ресурсы между клиентом и хостом.
Remote Credential Guard — режим защиты учётных данных в RDP, при котором пароль и производные секреты пользователя не передаются на удалённый компьютер.
Аварийная учётная запись — специально защищённая привилегированная учётная запись для восстановления доступа при отказе штатных средств администрирования или аутентификации.
Блокировка учётной записи — временное или административное запрещение входа для аккаунта, обычно после заданного числа неудачных попыток аутентификации.
Локальная политика безопасности — хранящиеся на компьютере параметры безопасности Windows, действующие для этого узла; доменные GPO могут переопределять конфликтующие настройки.
Многофакторная аутентификация — метод проверки личности, требующий подтверждений из двух или более независимых факторов: знания, владения или биометрии.
Парольная аутентификация — способ проверки личности, при котором пользователь подтверждает владение секретным паролем, передавая его или производное от него значение.
Политика блокировки учётных записей — набор параметров аутентификации, задающий порог неверных входов, длительность блокировки и период сброса счётчика.
Политика паролей — набор обязательных правил создания, хранения, смены и проверки паролей учётных записей в информационной системе.
Привилегированная учётная запись — учётная запись с правами управления системами, данными или политиками доступа, превышающими полномочия обычного пользователя.
Служебная учётная запись — учётная запись для запуска приложений, служб или автоматизированных задач, а не для интерактивной работы конкретного пользователя.
Срок действия пароля — заданный политикой период использования пароля, после которого система требует его смены или прекращает аутентификацию с прежним значением.

Вопросы по теме

Все вопросы и ответы

Можно ли включить MFA для RDP одной политикой Windows Server?

Нет. Windows Server не включает MFA одной локальной или доменной настройкой. Для административного RDP-доступа MFA проектируют для конкретного канала: например, через RD Gateway, RADIUS/NPS и поддерживаемого MFA-провайдера. NLA само по себе вторым фактором не является: оно лишь переносит проверку учётных данных на этап до полного RDP-сеанса.

Может ли RDP заблокировать учётную запись из-за неверного пароля?

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

Можно ли задать отдельную парольную политику доменных пользователей через OU?

Нет. GPO, привязанная только к OU с пользователями, не становится отдельной доменной парольной политикой. Базовые правила паролей и блокировки для доменных пользователей задают GPO, действующей на уровне домена. Если отдельные требования нужны части пользователей, применяют Password Settings Object (PSO), назначенный пользователям или глобальным security-группам AD.

Где искать причину повторной блокировки доменной учётной записи?

Начните с журналов событий и источников, где мог сохраниться старый пароль: служб, задач планировщика, RDP-клиентов, мобильных клиентов и скриптов. Событие 4625 обычно фиксирует неудачный вход на обработавшей его системе, а 4740 — блокировку, часто на контроллере домена. Для доменных сценариев также могут помочь события 4771 и 4776, если настроен аудит.

Можно ли назначить PSO на OU или локальную учётную запись?

Нет. Fine-grained password policy через PSO назначают только непосредственно пользователям Active Directory или глобальным security-группам AD. PSO нельзя применить к OU, компьютеру, локальной учётной записи сервера, distribution-группе, универсальной или доменно-локальной группе. Для локальных аккаунтов действуют локальные Password Policy и Account Lockout Policy сервера.