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

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

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

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

Event ID 4820: A Kerberos Ticket Granting Ticket (TGT) was denied — причины и решение

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

Описание события безопасности Event ID 4820

Событие Event ID 4820 регистрируется в журнале безопасности (Security Log) контроллера домена Windows Server, когда служба распределения ключей Kerberos KDC (Key Distribution Center) отклоняет запрос учетной записи на получение начального билета TGT (Ticket Granting Ticket) из-за применения политик ограничения аутентификации (Authentication Policies) или бункеров (Authentication Silos).

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

  • Пользователь или служба не могут войти в домен и получают ошибку аутентификации KDC_ERR_POLICY (0x24).
  • В журнале Security на контроллере домена появляется запись со статусом сбоя и кодом Event ID 4820.
  • Проблема возникает избирательно при попытке входа на определенный сервер или рабочую станцию.

Таблица основных полей события

ПараметрОписание
Target Account NameИмя учетной записи пользователя или компьютера, запросившего билет TGT.
Target DomainДоменное имя учетной записи.
Failure CodeКод причины отказа (например, 0x12 или 0x24).
Policy Name / SiloИмя политики аутентификации или хранилища (Silo), заблокировавшего выпуск билета.

Пошаговое устранение блокировки TGT Kerberos

Обратите внимание: Политики аутентификации (Authentication Policies) введены в Windows Server 2012 R2 / 2016 для защиты учетных записей с высокими привилегиями от атак Pass-the-Hash и Silver Ticket. Не отключайте политики целиком без анализа архитектуры доступа.

  1. Проверка принадлежности пользователя к хранилищу (Authentication Silo):
    Запустите консоль PowerShell от имени администратора домена и проверьте, какие ограничения наложены на учетную запись:
    Get-ADUser -Identity "ИмяПользователя" -Properties msDS-AssignedAuthNPolicy, msDS-AssignedAuthNPolicySilo
  2. Анализ правил политики доступа:
    Получите параметры назначенной политики, чтобы узнать, с каких хостов разрешена аутентификация:
    Get-ADAuthenticationPolicy -Filter *
    Get-ADAuthenticationPolicySilo -Filter *
  3. Добавление рабочей станции в список разрешенных:
    Если пользователю разрешен вход только с доверенных компьютеров, добавьте SPN или имя устройства в разрешенные объекты Silo через оснастку Active Directory Administrative Center (ADAC) в разделе Authentication Policies.
  4. Временный перевод политики в режим аудита (Audit Mode):
    Для локализации проблемы без остановки бизнес-процессов переведите политику в режим аудита:
    Set-ADAuthenticationPolicy -Identity "StrictAdminPolicy" -EnforceAudit $true
  5. Очистка кэша Kerberos на клиенте:
    На рабочей станции пользователя сбросьте кэшированные тикеты:
    klist purge
💡 Практика специалистов: При внедрении политик Protected Users и Authentication Silos всегда активируйте флаг EnforceAudit минимум на 14 дней для выявления скрытых сценариев сервисных учетных записей, иначе критические службы могут внезапно потерять доступ.

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

Почему событие 4820 фиксируется только на контроллерах домена?

Служба KDC (Key Distribution Center), выпускающая билеты TGT, работает исключительно на контроллерах домена Active Directory, поэтому генерация события 4820 происходит только в их локальном журнале Security.

Чем отличается Event ID 4820 от ошибки предварительной аутентификации 4768?

Событие 4768 со сбоем фиксирует неправильный ввод пароля или рассинхронизацию времени, тогда как 4820 фиксирует целенаправленный отказ контроллера домена на основе настроенных политик Authentication Policies и Silos.

Как вернуть пользователя к стандартной процедуре входа без ограничений Silo?

Удалите назначение хранилища выполнив команду: Set-ADAccountAuthenticationPolicySilo -Identity 'ИмяПользователя' -Remove, либо через оснастку ADAC.

Требуется ли перезагрузка контроллера домена при изменении Authentication Policies?

Нет, изменения вступают в силу после репликации объектов Active Directory между контроллерами домена и сброса кэша билетов Kerberos на клиенте.

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