Event ID 4822 Windows Server, AD и Роли

Event ID 4822: NTLM authentication failed — диагностика сбоев NTLM

Обновлено: 28.08.2026 · Официальная документация ↗

Причины появления Event ID 4822

Событие Event ID 4822 генерируется подсистемой LSA (Local Security Authority), когда попытка проверки подлинности по устаревшему протоколу NTLM завершается неудачей. Это может свидетельствовать о неверном пароле, несоответствии минимального уровня безопасности LM/NTLM (LmCompatibilityLevel), либо об атаке подбора учетных данных (Brute-Force/Password Spraying).

Симптоматика в инфраструктуре

Клиенты старых ОС или сторонних утилит (сканеры, Linux-клиенты SMB) не могут подключиться к ресурсам домена.
В журнале Applications and Services Logs -> Microsoft -> Windows -> NTLM -> Operational и Security фиксируется отказ.
В теле события указаны имя пользователя, рабочая станция-источник и код статуса ошибки (например, 0xC000006D).

Методика устранения сбоев NTLM аутентификации

Рекомендация: Протокол NTLM уязвим к атакам Relay. Рекомендуется постепенно выводить его из эксплуатации в пользу Kerberos, используя аудит NTLM.

Расшифровка кода ошибки статуса NTLM:
Проверьте поле Status в деталях события:
- 0xC000006A: Неверный пароль.
- 0xC000006E: Учетная запись заблокирована или отключена.
- 0xC0000234: Учетная запись временно заблокирована из-за превышения попыток входа.
Проверка уровня совместимости NTLM в групповых политиках:
Откройте редактор GPO и перейдите в ветку:
Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> Network security: LAN Manager authentication level.
Убедитесь, что на клиенте и сервере установлены совместимые параметры (рекомендуется: Send NTLMv2 response only. Refuse LM & NTLM).
Проверка ограничений NTLM (Restrict NTLM):
Проверьте состояние политики Network security: Restrict NTLM: Incoming NTLM traffic через реестр:
```
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" -Name "AuditReceiptNTLMTraffic","RestrictSendingNTLMTraffic" -ErrorAction SilentlyContinue
```
Анализ источника запросов через PowerShell:
Соберите статистику сбоев NTLM для выявления атакующих IP-адресов:
```
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4822} -MaxEvents 50 | Format-Table TimeCreated, Message -Wrap
```

💡 Практика специалистов: При включении политики 'Network security: Restrict NTLM' всегда проверяйте системные учетные записи локальных служб и кластеров, которые часто по умолчанию используют NTLM Loopback.

Частые вопросы (FAQ)

Почему происходит сбой NTLM, если пароль пользователя верный?

Сбой может происходить, если сервер настроен отклонять NTLMv1, а устаревшее клиентское приложение способно работать только по NTLMv1.

Как отличить легитимный сбой NTLM от атаки взлома?

При атаках фиксируется массовое появление событий 4822 за короткий интервал времени от одного источника с перебором имен учетных записей (Password Spraying).

Можно ли полностью отключить генерацию событий 4822?

Событие перестанет генерироваться, если отключить аудит отказов входа или полностью заблокировать NTLM трафик в домене.

Где включить детальный аудит использования NTLM?

В GPO: Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> Network security: Restrict NTLM: Audit NTLM authentication in this domain.