Поделиться через

Руководство по устранению неполадок проверки подлинности Kerberos

В этом руководстве приведены основные понятия, которые необходимо следовать при устранении неполадок с проверкой подлинности Kerberos.

Это важно

В этой статье приведены общие рекомендации. Возможно, вам придется адаптировать процедуры и примеры, представленные здесь для работы с конкретной конфигурацией.

Контрольный список по устранению неполадок

Протокол Kerberos зависит от нескольких компонентов инфраструктуры и служб. Если любой из этих компонентов или служб недоступен или не работает, могут возникнуть проблемы с проверкой подлинности.

1. Проверка событий и журналов

Проверьте журналы событий, чтобы узнать о проблеме. Используйте средство просмотра событий, чтобы просмотреть журналы безопасности и системы в системах, участвующих в операции проверки подлинности:

  • Клиент проверки подлинности
  • Целевой сервер или служба
  • Контроллер домена

В частности, найдите любые события из источников, которые могут относиться к проверке подлинности Kerberos или службам, которые он использует, например следующие источники:

  • Kerberos
  • Центр распространения ключей (KDC)
  • LSA (LsaSrv)
  • Netlogon

На целевом сервере проверьте журнал безопасности для аудита сбоев. Такие сбои могут показать, что протокол Kerberos используется при сбое проверки подлинности.

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

Событие или ошибка Сведения об устранении неполадок
Идентификатор события 4, ошибка KERB_AP_ERR_MODIFIED Клиент не смог расшифровать служебный билет. Так как эта ошибка может вызвать несколько проблем, проверьте наличие связанных событий. Например, эта строка может означать, что часы клиента и целевого сервера не синхронизированы или что SPN не является уникальным. В среде с несколькими доменами имя учетной записи службы может не быть уникальным в лесу (или других доверенных лесах).
Дополнительные сведения см. в статьях «Клиент Kerberos получил ошибку KRB_AP_ERR_MODIFIED с сервера» и «Kerberos создает ошибку KDC_ERR_S_PRINCIPAL_UNKNOWN или ошибку KDC_ERR_PRINCIPAL_NOT_UNIQUE».
Идентификатор события 4, ошибка KERB_AP_ERR_SKEW Убедитесь, что часы компьютера синхронизированы
Идентификатор события 14 Ошибка "Неподдерживаемый тип шифрования" при доступе к ресурсу в доверенном домене
Идентификатор события 16 или идентификатор события 27 Идентификатор события KDC 16 или 27 регистрируется при отключении DES для Kerberos
Ошибки идентификатора события 27 KDC в контроллерах домена Windows Server 2003
Ошибка 1069 Сбой входа в службу из-за неправильно заданных SPN
Идентификатор события 5719, ошибка 1311 или ошибка 1355 Идентификатор события 5719, ошибка 1311 или ошибка 1355 — контроллер домена или домен не найден

Если вы убедитесь, что проблема устранена, сначала исправьте эту проблему, а затем повторите попытку проверки подлинности перед продолжением.

2. Проверка инфраструктуры

a. Убедитесь, что клиентское приложение и целевая служба не на одном компьютере

По умолчанию, если клиентское приложение и целевая служба установлены на одном компьютере, Kerberos отключен. Если вы не можете установить клиентское приложение и целевую службу на отдельных компьютерах, необходимо изменить определенные параметры безопасности в Windows. Кроме того, может потребоваться изменить раздел реестра. Дополнительные сведения о проблемах, связанных с этим сценарием, и о конкретных параметрах, влияющих на него, см. в сообщении об ошибке при попытке доступа к серверу локально.

Если вы внесли какие-либо изменения, повторите попытку проверки подлинности перед продолжением.

б. Убедитесь, что клиентский компьютер, целевой сервер и серверы ресурсов присоединены к соответствующим доменам.

При необходимости присоединитесь к клиентскому компьютеру или целевому серверу с соответствующим доменом. Затем повторите попытку проверки подлинности.

Примечание.

В этом контексте "соответствующие домены" — это домены в одном лесу или в пределах набора лесов, имеющих отношения доверия.

с. Проверка работоспособности целевого сервера и его вспомогательных служб

Убедитесь, что выполняются приложения или интерфейсные службы (например, веб-службы) и внутренние службы (например, служба SQL Server).

Примечание.

Может появиться сообщение, похожее на сообщение "Служба вызвала ошибку 1069: служба не запущена из-за сбоя входа". Если вы получите это сообщение, см. статью "Сбой входа в службу из-за неправильного задания имен субъектов-служб".

д. Убедитесь, что доступны правильные порты

Проверьте все брандмауэры (включая брандмауэр Windows на каждом компьютере) между клиентским компьютером, контроллером домена и целевым сервером. Убедитесь, что трафик разрешен на следующих портах.

Примечание.

В этом списке используется формат сервера:порт клиента,порт сервера.

  • DHCP: 67 (UDP), 67 (UDP)
  • DNS: 49152 -65535 (TCP, UDP), 53 (TCP, UDP)
  • HTTPS, включая проверку подлинности на основе сертификатов: 443 (TCP), 443 (TCP)
  • Kerberos: 49152 -65535 (TCP, UDP), 88 (TCP, UDP)
  • Изменение пароля Kerberos: 49152 -65535 (TCP), 464 (TCP, UDP)
  • LDAP, включая указатель контроллера домена: 49152 -65535 (TCP, UDP), 389 (TCP, UDP)
  • ПРОТОКОЛ SSL LDAP: 49152 -65535 (TCP), 636 (TCP)
  • SMB: 49152 -65535 (TCP, UDP), 445 (TCP)
  • Схема конечных точек RPC: 49152 -65535 (TCP), 135 (TCP)
  • RPC для LSA, SAM, NetLogon: 49152 -65535 (TCP), 49152-65535 (TCP)
  • W32Time: 49152 -65535 (UDP), 123 (UDP)

При внесении изменений в любые параметры брандмауэра повторите попытку проверки подлинности.

д) Убедитесь, что доступны контроллеры домена

Когда клиент пытается связаться со службой или приложением (называемым целевым сервером), клиент и целевой сервер требуют контроллера домена для упрощения проверки подлинности, авторизации и делегирования.

На клиентском компьютере откройте окно командной строки с повышенными привилегиями и выполните следующую команду:

nltest /dsgetdc:<DomainName> /force /kdc

Примечание.

В этой команде <DomainName> представляет имя домена компьютера, из который выполняется запрос.

Команда nltest извлекает список доступных контроллеров домена (хотя список может не включать все доступные контроллеры домена). Запишите полные доменные имена и IP-адреса этих контроллеров домена для использования в последующих процедурах.

Если клиент или целевой сервер не может связаться с контроллером домена, вы получите сообщение, похожее на следующее (иногда помеченное как "ошибка 1355"):

указанный домен не существует, либо к нему нет доступа.

Если вы получите это сообщение, ознакомьтесь с идентификатором события 5719, ошибкой 1311 или ошибкой 1355 — контроллером домена или доменом, не найденным для получения дополнительных сведений об устранении неполадок. В противном случае перейдите к этому контрольному списку.

е) Убедитесь, что DNS работает между клиентом и целевым сервером

На клиентском компьютере откройте окно командной строки администрирования и выполните следующую команду:

nslookup <TargetName>

Примечание.

В этой команде <TargetName> представляет имя NetBIOS целевого сервера.

Если команда nslookup корректно определяет имя целевого сервера, то конфигурация DNS правильная. Если команда не может определить имя целевого сервера, выполните следующие действия, чтобы проверить конфигурацию сетевого адаптера клиентского компьютера:

  1. На клиентском компьютере выполните следующую команду:

    ipconfig /all

  2. В выходных данных команды определите, какой сетевой адаптер используется. Проверьте следующие параметры адаптера:

    • IP-адрес клиента

    • Маска подсети

    • Шлюз по умолчанию

    • DNS-суффикс для подключения

    • IP-адреса DNS-сервера

      Запишите IP-адреса и запишите, какой DNS-сервер предпочтителен и который является вторичным. Эта информация полезна для последующего устранения неполадок.

    Если какие-либо из этих параметров неверны, исправьте их или обратитесь к администратору DNS за помощью. Если вы внесли какие-либо изменения, запустите nslookup <TargetName> еще раз.

Если DNS по-прежнему не работает правильно, выполните следующие действия:

  1. Выполните следующую команду на клиентском компьютере:

    nslookup <ClientName> <DNSIPAddress>

    Примечание.

    В этой команде <ClientName> представляет имя NetBIOS клиентского компьютера, а <DNSIPAddress> представляет IP-адрес одного DNS-сервера, который настроен для использования клиентом. Во-первых, используйте IP-адрес предпочтительного DNS-сервера, записанного в предыдущей процедуре. Если команда не работает, повторите попытку с помощью IP-адреса дополнительного DNS-сервера клиента.

    Например, если имя клиентского компьютера — client1, а IP-адрес предпочтительного DNS-сервера клиента — 10.0.0.1, выполните следующую команду:

    nslookup client1 10.0.0.1

  2. Выполните ту же команду с целевого сервера. Теперь она похожа на следующую команду:

    nslookup <TargetName> <DNSIPAddress>

    Примечание.

    В этой команде <TargetName> представляет имя NetBIOS целевого сервера, а <DNSIPAddress> представляет IP-адрес одного DNS-сервера, который настроен на использование целевого сервера. Во-первых, используйте IP-адрес предпочтительного DNS-сервера, записанного в предыдущей процедуре. Если команда не работает при первом запуске, повторите попытку с помощью IP-адреса дополнительного DNS-сервера целевого сервера.

    Например, если имя целевого сервера — WebServer1, а IP-адрес предпочтительного DNS-сервера целевого сервера — 10.0.0.1, выполните следующую команду:

    nslookup WebServer1 10.0.0.1

    В следующей таблице приведены возможные результаты nslookup запросов и их последствия.

    Целевой запрос
    Удается    		 Целевой запрос
    проваливается
    Запрос клиента
    Завершается успешно    		 Нет проблемы с DNS Проблема, затрагивающая целевой или по крайней мере один DNS-сервер
    Запрос клиента
    Сбой    		 Проблема, которая влияет на клиент или по крайней мере один DNS-сервер Проблема с одним или несколькими DNS-серверами

Если результаты запроса указывают на наличие проблемы с DNS, ознакомьтесь со следующими статьями:

Если вам удалось устранить проблему DNS, но проблема с Kerberos осталась, попробуйте следующие способы устранения неисправностей.

ж. Убедитесь, что часы компьютера синхронизированы

Клиентский компьютер или целевой сервер могут кэшировать билеты для дальнейшего использования. Однако каждый билет имеет метки времени, определяющие срок жизни (TTL). Служба Центра распространения ключей Kerberos, которая выполняется на контроллерах домена, задает метки времени.

Разница в времени между контроллером домена и клиентским компьютером или целевым сервером должна быть меньше пяти минут. Как правило, если часы не синхронизированы, Windows может автоматически синхронизировать их. Существует два случая, в которых может потребоваться принять меры:

  • Часы не синхронизируются более чем на 48 часов.
  • Часы вне синхронизации не используют контроллер домена в своем домене в качестве сервера времени или не используют тот же сервер времени, что и эти контроллеры домена.

Чтобы устранить эту проблему, затронутый компьютер должен повторно проверить сеть на серверы времени, а затем повторно выполнить синхронизацию собственных часов. Чтобы включить эти действия, откройте окно командной строки администрирования и выполните следующую команду:

w32tm /resync /computer:<Target> /rediscover

Примечание.

В этой команде <Target> представляет компьютер, который вы настраиваете. Параметр /rediscover указывает компьютеру проверить сеть в поисках новых или обновленных источников времени.

Дополнительные сведения о параметрах, доступных для w32tm команды, см. в средствах и параметрах службы времени Windows: параметры командной строки для W32Time.

При повторной синхронизации часов повторите попытку проверки подлинности.

х. Проверка состояния обновления Windows

Убедитесь, что все контроллеры домена, клиентский компьютер и целевой сервер имеют соответствующие обновления Windows.

Если вы установили какие-либо обновления, перезапустите затронутые компьютеры и повторите попытку проверки подлинности.

и. Проверка состояния обновления приложения

Убедитесь, что клиентские и серверные приложения обновлены на клиентском компьютере и целевом сервере. При установке обновлений перезапустите затронутые компьютеры и повторите попытку проверки подлинности.

ж. Перезагрузите компьютеры

Если вы еще не перезагрузили клиентский компьютер, целевой сервер или контроллер домена, перезапустите их. После перезагрузки компьютеров повторите попытку проверки подлинности.

Если ваша инфраструктура ОК, и у вас по-прежнему возникла проблема, перейдите к более сложным процедурам устранения неполадок.

3. Сбор данных трассировки и билета

В следующих процедурах используется бесплатное средство сетевого монитора . Скачайте и установите средство на клиентском компьютере и целевом сервере. Пример использования сетевого монитора для сбора данных трассировки и идентификации сообщений Kerberos см. в статье об ошибках Kerberos в сетевых захватах.

a. Сбор одновременных трассировок сети

На клиентском компьютере выполните следующие действия.

  1. Выполните одно из следующих действий:

    • Перезапустите компьютер клиента.
    • Выйдите из учетной записи, которую вы используете для устранения неполадок, а затем снова войдите.
    • Закройте клиентское приложение и снова откройте его.

  2. Запустите трассировку. Для этого выполните следующие действия.

    1. Нажмите кнопку "Пуск" и введите netmon.
    2. В результатах поиска щелкните правой кнопкой мыши Microsoft Network Monitor 3.4 и выберите "Запуск от имени администратора " (в окне управления учетными записями пользователей выберите "Да ").
    3. В сетевом мониторе нажмите кнопку "Пуск".

  3. Откройте окно командной строки администратора и выполните следующие команды в последовательности:

    ipconfig /flushdns
nbtstat -RR
klist purge
klist -li 0x3e7 purge

На целевом сервере выполните следующие действия.

  1. Откройте сетевой монитор от имени администратора и нажмите кнопку "Пуск".

  2. Откройте окно командной строки администратора и выполните следующие команды в последовательности:

    ipconfig /flushdns
nbtstat -RR
klist purge
klist -li 0x3e7 purge

Попробуйте воспроизвести вашу проблему, а затем остановите и сохраните трассировки на клиентском компьютере и целевом сервере. Для этого в сетевом мониторе нажмите кнопку "Остановить", а затем нажмите кнопку "Сохранить как".

б. Сведения о билете

После воспроизведения ошибки и остановки трассировки проверьте токены Kerberos, созданные в ходе записи трассировочных данных. В командной строке на клиентском компьютере и на целевом сервере выполните следующую команду:

klist tickets

Эта команда создает список билетов. Эти сведения можно скопировать в другое приложение (например, Блокнот), чтобы использовать его в последующих процедурах устранения неполадок.

4. Проверьте данные трассировки сообщений Kerberos

С помощью сетевого монитора можно просматривать, фильтровать и искать данные в файлах записи. В частности, найдите события, помеченные с помощью KerberosV5. Эти события предоставляют сведения о состоянии. Кроме того, они могут перечислять или имена, или IP-адреса контроллеров домена, с которыми был установлен контакт, и имя основного сервиса (SPN) службы, которую клиент пытался достичь.

Описания событий, содержащие строки, похожие на следующие, являются частью типичных функций Kerberos:

  • KerberosV5:KRB_Error -KDC_ERR_PREAUTH_REQUIRED
  • Запрос KerberosV5:AS
  • Ответ KerberosV5:AS
  • Запрос KerberosV5:TGS
  • Ответ KerberosV5:TGS
  • Запрос KerberosV5:AP
  • Ответ KerberosV5:AP

Примечание.

Вы также можете использовать сетевой монитор для проверки данных трассировки билетов в HTTP-запросах GET. Если сведения о билете отсутствуют в запросе GET, возникла проблема с использованием проверки подлинности Kerberos.

Описания событий, содержащие строки, похожие на следующие, означают, что возникла проблема. В следующем списке перечислены некоторые из наиболее распространенных ошибок. Если вы видите одну из этих строк, запишите все имена серверов, IP-адреса и имена субъектов-служб для последующего использования.

  • KDC_ERR_PRINCIPAL_NOT_UNIQUE или KDC_ERR_S_PRINCIPAL_UNKNOWN. Запрошенный SPN связан с несколькими учетными записями или не связан ни с одной учетной записью. Сведения об устранении любой из этих проблем см. в статье Kerberos, где возникает ошибка KDC_ERR_S_PRINCIPAL_UNKNOWN или KDC_ERR_PRINCIPAL_NOT_UNIQUE.

  • KRB_AP_ERR_MODIFIED. Клиент не смог расшифровать служебный билет. Несколько проблем могут вызвать эту ошибку. Просмотрите данные трассировки для других ошибок, сопровождающих KRB_AP_ERR_MODIFIED. Проверьте журналы событий для идентификатора события 4 и других связанных событий, как описано в разделе 1. Проверьте события и журналы.

  • ERB_AP_ERR_SKEW. Часы клиента и целевого сервера не синхронизируются. Дополнительные сведения см. в разделе "Убедитесь, что часы компьютера синхронизированы".

  • KDC_ERR_ETYPE_NOTSUPP. Один или несколько компонентов, участвующих в проверке подлинности, используют тип шифрования, отключенный для других компонентов. Дополнительные сведения о компонентах и типах шифрования, описанных в 1, см. в журналах событий . Проверьте события и журналы.

Распространенные проблемы и решения

HTTP 400 — проблема с неправильным запросом (заголовок запроса слишком длинный)

Если пользователь принадлежит большому количеству групп (например, более 1000 групп), Kerberos может запретить пользователю доступ, так как он не правильно обрабатывает запрос. Дополнительные сведения об этой проблеме см. в следующих статьях:

Проблемы службы

Проблемы со службами, как правило, связаны с именем главного объекта службы (SPN) и учетной записью службы. Например, SPN (имя субъекта-службы) может быть неверным, отсутствовать, быть настроенным в неправильной учетной записи или настроенным для нескольких учетных записей. Контрольный список устранения неполадок в этой статье . Сбор одновременных трассировок сети выше в этой статье. Если вы уже определили общую проблему с SPN, прочтите следующие статьи:

Проблемы единого входа (SSO)

Единый вход — это метод проверки подлинности, позволяющий пользователям входить с помощью одного набора учетных данных в несколько систем или приложений в одной интрасети. Для корректной работы как целевая служба (или внешний компонент целевой службы), так и клиент должны иметь правильные настройки. Сведения об устранении неполадок с этими параметрами см. в статье "Устранение неполадок с единым входом Kerberos".

Проблемы с делегированием

Если целевая служба имеет отдельные интерфейсные и внутренние компоненты, Kerberos может делегировать учетные данные клиента (включая разрешения на доступ) учетной записи службы. В простых терминах клиент обращается к интерфейсной службе, а затем интерфейсная служба обращается к серверной службе от имени клиента.

Kerberos поддерживает три типа делегирования:

  • Неограниченное делегирование. После доступа клиента к интерфейсной службе интерфейсная служба может получить доступ к любой другой службе от имени клиента. Эта конфигурация является самой простой для реализации, но также является наименее безопасной. Не рекомендуется поощрять неограниченное делегирование, так как оно не ограничивает, с какими службами может взаимодействовать проверенная учетная запись.
  • Ограниченное делегирование. Интерфейсная служба поддерживает список служб, к которым он может обращаться от имени клиента.
  • Ограниченное делегирование на основе ресурсов (RBCD). Серверная служба поддерживает список разрешений внешних служб, которые могут запрашивать доступ к серверной службе от имени клиента.

Примечание.

Если при использовании ограниченного делегирования вместе с CIFS возникает проблема, см. Ошибка ACCESS_DENIED: сбой ограниченного делегирования для CIFS.

Это важно

  • Не настраивайте ограниченное делегирование и RBCD на одном наборе внешних и внутренних серверов.

    Ограниченное делегирование и RBCD — это разные конфигурации, и они взаимоисключающие. Когда интерфейсная служба запрашивает запрос на серверную службу, KDC сначала проверяет интерфейсную службу для ограниченного делегирования. Если ограниченное делегирование не настроено для интерфейсной службы, KDC проверяет серверную службу для ограниченного делегирования на основе ресурсов. Из-за этой последовательности ограниченное делегирование имеет приоритет над делегированием на основе ресурсов.

  • По умолчанию Microsoft Edge не поддерживает неограниченное делегирование. Если вы используете неограниченное делегирование, см. статью Неограниченная аутентификация Kerberos с двойной передачей данных в Microsoft Edge (Chromium) для получения дополнительной информации о необходимой конфигурации.

  • Не рекомендуется использовать неограниченное делегирование, так как оно не ограничивает, с какими службами может взаимодействовать проверенная учетная запись.

Поддерживаемые типы топологий

Различные типы делегирования предъявляют разные требования к вашей топологии. В следующей таблице перечислены три распространенных типа топологии и типы делегирования (если таковые) поддерживаются для каждого типа.

Тип топологии Неограниченное делегирование Ограниченное делегирование RBCD
Все службы находятся в одном домене Поддерживается (не рекомендуется) Поддерживается Поддерживается
Интерфейсные и серверные службы находятся в разных доменах Поддерживается (не рекомендуется) Не поддерживается Поддерживается
Интерфейсные и серверные службы находятся в разных (доверенных) лесах Поддерживается* (не рекомендуется) Не поддерживается Поддерживается*

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

Устранение неполадок с определенными типами делегирования

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

Использование тестового сценария анализа логов для устранения проблем аутентификации Kerberos

Дополнительные сведения о тестировании и устранении неполадок Kerberos см. в статье "Использование сценария тестирования анализа журналов" для устранения неполадок проверки подлинности Kerberos.