Справочник системных ошибок и решений

Windows Server, Active Directory, 1С:Предприятие, СУБД, Linux, Cisco, MikroTik, Asterisk.

⚠️ Важная информация Все материалы, инструкции, команды и скрипты на сайте предоставлены исключительно в ознакомительных целях. Их применение может повлиять на работу операционной системы, программного обеспечения, баз данных, сетевого оборудования и других компонентов инфраструктуры. Перед выполнением действий создайте резервную копию и по возможности протестируйте изменения в безопасной среде. Пользователь самостоятельно оценивает риски и несет ответственность за результат. При отсутствии необходимых знаний обратитесь к квалифицированному ИТ-специалисту.

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

Event ID 4823: NTLM authentication was required but not allowed — решение

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

Описание ошибки Event ID 4823

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

Типичные признаки проблемы

  • Пользователи группы Protected Users не могут подключиться к ресурсам, не поддерживающим Kerberos.
  • Приложения выдают ошибки The authentication mechanism is not supported.
  • Событие регистрируется на целевом сервере или контроллере домена при попытке обращения по NetBIOS-имени или IP-адресу вместо FQDN.

Как устранить блокировку NTLM (Event ID 4823)

Важно: Члены группы безопасности Protected Users не имеют права использовать NTLM, Digest Authentication и CredSSP по дизайну безопасности Windows Server.

  1. Проверка членства учетной записи в Protected Users:
    Проверьте, входит ли пользователь в защищенную группу:
    (Get-ADUser -Identity "ИмяПользователя" -Properties MemberOf).MemberOf -match "Protected Users"
    Если сервису требуется NTLM, используйте выделенную сервисную учетную запись вне этой группы.
  2. Настройка исключений NTLM в групповых политиках:
    Если блокировка вызвана политикой Restrict NTLM, добавьте целевой сервер в список доверенных исключений:
    Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> Network security: Restrict NTLM: Add server exceptions in this domain.
  3. Перевод обращений приложений на протокол Kerberos:
    Убедитесь, что клиентские подключения используют полное доменное имя (FQDN) вместо IP-адреса, так как при обращении по IP Kerberos не работает и Windows откатывается на NTLM.
  4. Регистрация корректного SPN:
    Проверьте наличие Service Principal Name для целевого узла:
    setspn -L ИмяСервера
💡 Практика специалистов: Самая частая причина события 4823 в гибридных средах — старые скрипты монтирования дисков с путями вида '\\192.168.1.10\share'. Замена IP на FQDN имя полностью восстанавливает доступ по Kerberos.

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

Почему обращение по IP-адресу вызывает событие 4823?

Kerberos не может построить SPN на основе сырого IP-адреса и пытается выполнить откат (fallback) до NTLM. Если NTLM запрещен политикой, возникает событие 4823.

Безопасно ли временно удалять учетную запись из Protected Users?

Это снижает уровень защиты, но допустимо на время перевода сервиса на современную аутентификацию Kerberos или gMSA.

Как определить, какое приложение пытается использовать NTLM?

Изучите поле 'Calling Process Name' или сопоставьте временные метки события 4823 с логами приложений (Application Log).

Поддерживают ли сетевые диски DFS работу без NTLM?

Да, пространства имен DFS полностью поддерживают Kerberos при условии использования полных FQDN путей к общим папкам.

Полезные материалы
Рекомендуем