Учётки не блокируются при подборе, либо блокируются от сканера: как выбрать порог

Короткий ответ

LockoutThreshold = 0 в политике домена значит: подбор пароля не блокирует учётку. Это плохо при открытом NTLM/RDP. Обратная крайность: порог 3 и Observation 30 минут при mapped drive со старым паролем или МФУ — само-DoS отдела. Цель для contoso.example: включить lockout с разумными числами (часто 10–15 попыток, duration 15 минут, observation 15 минут — пример, не догма), аудит 4740, найти источники ложных блокировок, закрыть RDP с WAN.

Не ставьте threshold 1. Не отключайте lockout «потому что директор злится» без поиска кто стучится. Fine-grained PSO для админов может быть жёстче, чем для пользователей.

Симптомы и как отличить

• Get-ADDefaultDomainPasswordPolicy LockoutThreshold 0.
• Либо наоборот: десятки 4740 в час, пользователи «меня не пускает».
• 4625 Status/Sub Status о lockout vs bad password — разные.
• После смены пароля старые телефоны/Outlook/MAC продолжают стучаться.

Возможные причины

1. Default Domain Policy никогда не трогали.
2. Сознательно выключили после эпидемии блокировок.
3. PSO перекрывает для части пользователей (смотрите Fine Grained).

Массовые блокировки (частые источники):

1. Сохранённый пароль в планировщике, службе, МФУ, смартфоне.
2. Сканер уязвимостей / lockout-tool в VLAN.
3. Порог 3 при пользователях с несколькими устройствами.
4. Два DC и клиентский retry (реже как единственная причина).
5. Linux/Mac с устаревшим паролем к SMB.

Диагностика

Get-ADDefaultDomainPasswordPolicy -Identity contoso.example |
  Select-Object LockoutThreshold, LockoutDuration, LockoutObservationWindow, MaxPasswordAge, MinPasswordLength
Get-ADFineGrainedPasswordPolicy -Filter * | Format-Table Name, LockoutThreshold, Precedence

Локально на WS-042 (не путать с доменом):

net accounts

События на DC01:

Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 4740 } -MaxEvents 20 |
  Select-Object TimeCreated, Message

Разбор: имя пользователя + Caller Computer. Идите на этот хост: задачи, службы, mapped drives, Outlook. LockoutStatus (старая утилита Microsoft) или Search-ADAccount -LockedOut.

Search-ADAccount -LockedOut | Select-Object Name, LockedOut, LastLogonDate
Unlock-ADAccount -Identity 'ivanov'  # только после понимания источника

Решение

Сценарий A. Lockout выключен, периметр относительно спокойный

В Default Domain Policy (или выделенной PSO/политике паролей):

Пример стартовых значений для обсуждения с бизнесом:

• Account lockout threshold: 10
• Account lockout duration: 15 minutes
• Reset account lockout counter after: 15 minutes

Set-ADDefaultDomainPasswordPolicy -Identity contoso.example -LockoutThreshold 10 -LockoutDuration 00:15:00 -LockoutObservationWindow 00:15:00

Пилот лучше PSO на тестовую группу, затем домен.

Сценарий B. Слишком жёстко, отдел лежит

Поднимите threshold (например с 3 до 10), найдите Caller Computer из 4740, вычистите старые пароли. МФУ: обновите учётку или заведите отдельную svc с мониторингом. Сканер: исключите production-учётки из brute-шаблонов, сканируйте lab.

Не выключайте threshold в 0 как финал.

Сценарий C. Админы vs пользователи

PSO: для Helpdesk-LAPS / privileged — более короткий duration или иной порог по политике компании. Для service accounts часто lockout 0 осознанно + невозможность интерактивного входа + длинный пароль/gMSA. Документируйте исключения. gMSA не вводят пароль руками — предпочтительнее служб с человеческим паролем.

Сценарий D. RDP/NTLM с улицы

Lockout не спасает открытый 3389: атакующий выберет не lockout, а password spray ниже порога. Закройте периметр, снизьте NTLM. Lockout — слой, не периметр.

В contoso.example после включения lockout прогоните неделю только наблюдение 4740, не меняя порог дважды за день. Типичный ложный источник — МФУ в VLAN печати и смартфон с почтой. Caller Computer в 4740 на DC01 важнее, чем «unlock всем из OU». Для gMSA lockout обычно не про ваш сценарий: не применяйте PSO пользователей на группы служб вслепую. Если RDP всё ещё с WAN, lockout станет оружием DoS — сначала периметр, потом порог. Зафиксируйте значения Default Domain Policy и всех PSO в регламенте, чтобы helpdesk не крутил net accounts на WS-042 вместо домена.

Как проверить, что проблема устранена

• Get-ADDefaultDomainPasswordPolicy показывает ненулевой threshold.
• Тестовая учётка (не боевая): N неверных паролей → 4740 → после duration вход возможен.
• Массовые 4740 упали после чистки Caller Computer.
• Helpdesk знает runbook unlock + поиск источника.
• 4767 (unlock) коррелирует с тикетами.

Если не помогло

• PSO с меньшим precedence перебивает домен — смотрите Get-ADUser ivanov -Properties msDS-ResultantPSO.
• Локальная учётка WS-042\Administrator не слушает доменный lockout — это SAM + LAPS.
• Linux BIND/LDAP simple — другой счётчик.
• Observation меньше duration — читайте документацию порядка параметров; задавайте согласованно через cmdlet/GPO, не конфликтующими кликами.

Профилактика

• Алерт всплеска 4740.
• Регламент смены пароля: обновить почту/телефон/МФУ в тот же день.
• Service accounts → gMSA.
• Не публиковать 3389.
• Связка с парольной длиной и banned list.

FAQ

Рекомендация Microsoft «не использовать lockout»?

Есть дискуссии про password spray vs lockout-DoS. Практический компромисс SMB: умеренный порог + закрытый периметр + MFA где можно. Нулевой порог при открытом NTLM — плохо.

Duration 0

Блокировка до unlock админом. Для DA break-glass иногда да, для всех пользователей — нагрузка на helpdesk и риск настоящего DoS атакующим.

Счётчик на каждом DC свой?

Поведение с несколькими DC нужно учитывать: клиент может ударить разные DC. Поэтому порог 3 опаснее, чем кажется. 10–15 устойчивее к retry.

4625 0xC0000234

Типичный код «учётка заблокирована» в 4625. Сверяйте с таблицей Microsoft Status. Для поиска источника всё равно 4740.

Нужен ли lockout на локальном SAM ПК?

net accounts локально — отдельная политика. Для парка важнее LAPS и запрет общего пароля, чем одинаковый lockout SAM.

Fine-grained только в AD DS?

PSO — фича AD DS (не NT-домен). Применяйте к группам/пользователям, проверяйте resultant PSO.