Устранение неполадок Kerberos в Интернете Обозреватель

Эта статья поможет вам изолировать и устранить причины различных ошибок при доступе к веб-сайтам, настроенным для использования проверки подлинности Kerberos в Интернете Обозреватель. Количество потенциальных проблем почти столько же, сколько и средств, доступных для их решения.

Распространенный симптом при сбое Kerberos

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

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

Не авторизовано
Ошибка HTTP 401. Запрошенный ресурс требует проверки подлинности пользователя.

На сервере Microsoft IIS (IIS) журналы веб-сайтов содержат запросы, заканчивающиеся кодом состояния 401.2, например следующий журнал:

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken  
DateTime IP GET /whoami.aspx - 80 – IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 2 5 1270  
DateTime IP GET /whoami.aspx - 80 - IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 2 5 8

Кроме того, на экране отображается код состояния 401.1, например следующий журнал:

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken  
DateTime IP GET /whoami.aspx - 80 - IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 2 5 105  
DateTime IP GET /whoami.aspx - 80 - IP Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+WOW64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729;+.NET+CLR+3.5.30729) - 401 1 2148074245 18

Определение того, используется ли Kerberos

При устранении неполадок проверки подлинности Kerberos рекомендуется упростить конфигурацию до минимума. То есть один клиент, один сервер и один сайт IIS, работающий на порте по умолчанию. Кроме того, можно выполнить некоторые основные действия по устранению неполадок. Например, используйте тестовую страницу для проверки используемого метода проверки подлинности. Если вы используете ASP.NET, вы можете создать эту ASP.NET тестовую страницу проверки подлинности.

Если вы используете классическую версию ASP, можно использовать следующую страницу Testkerb.asp:

<%
    authType=UCase(Request.ServerVariables("AUTH_TYPE"))
    authHeader=Request.ServerVariables("HTTP_AUTHORIZATION")
    response.write " Authentication Method : " & authType & "<BR>"
    LenAuthHeader = len(authHeader)
    response.write " Protocol : "
    if Len(authType ) =0 then response.write " Anonymous" else if authType<>"NEGOTIATE" then response.write authType else if LenAuthHeader>1000 then response.write "Kerberos" else response.write  "NTLM"
%>

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

• Fiddler
• HttpWatch
• Сетевой монитор
• Средства разработчика в браузере

Дополнительные сведения о том, как можно создать такие трассировки, см. в разделе Трассировка на стороне клиента.

При использовании Kerberos запрос, отправляемый клиентом, имеет большой размер (более 2000 байт), так как заголовок HTTP_AUTHORIZATION содержит билет Kerberos. Следующий запрос предназначен для страницы, которая использует проверку подлинности Windows на основе Kerberos для проверки подлинности входящих пользователей. Размер запроса GET составляет более 4000 байт.

Если используется подтверждение NTLM, запрос будет гораздо меньше. В следующей записи на стороне клиента показан запрос проверки подлинности NTLM. Запрос GET гораздо меньше (менее 1400 байт).

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

Что следует проверка, если проверка подлинности Kerberos завершается ошибкой

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

Клиент и сервер находятся в одном домене

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

• Клиент и сервер не в одном домене, но в двух доменах одного леса.
• Клиент и сервер находятся в двух разных лесах.

Эти возможные сценарии рассматриваются в разделе Почему происходит сбой делегирования Kerberos между моими двумя лесами, хотя раньше он работал в этой статье.

Настроена ли служба IIS для использования встроенной проверки подлинности

Включена встроенная проверка подлинности в Интернете Обозреватель

Разрешается ли используемый URL-адрес в зону безопасности, для которой могут быть отправлены учетные данные

Всегда запустите эту проверка для следующих сайтов:

• Сайты, сопоставленные с зоной "Локальная интрасеть" браузера.
• Сайты в зоне "Доверенные сайты".

Вы можете проверка, в какую зону браузер решит включить сайт. Для этого откройте меню Файл интернет-Обозреватель, а затем выберите Свойства. В окне Свойства отобразится зона, в которую браузер решил включить сайт, на который вы просматриваете.

Можно проверка, разрешен ли автоматический вход в зону, в которую включен сайт. Для этого откройте меню Internet Обозреватель и выберите вкладку Безопасность. После выбора нужной зоны нажмите кнопку Настраиваемый уровень, чтобы отобразить параметры и убедиться, что выбран параметр Автоматический вход. (Как правило, эта функция включена по умолчанию для зон интрасети и доверенных сайтов.

Настроен ли сервер IIS для отправки заголовка WWW-Authenticate: Negotiate

Если службы IIS не отправляют этот заголовок, используйте консоль диспетчера IIS, чтобы задать заголовок Negotiate с помощью свойства конфигурации NTAuthenticationProviders . Дополнительные сведения см. в разделе Поставщики> проверки <подлинности Windows. Вы можете получить доступ к консоли с помощью параметра Поставщики сведений о проверке подлинности Windows в диспетчере IIS.

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

По умолчанию Kerberos не включен в этой конфигурации. Чтобы изменить это поведение, необходимо задать DisableLoopBackCheck раздел реестра. Дополнительные сведения см. в статье базы знаний 926642.

Может ли клиент получить билет Kerberos

Вы можете использовать средство Списка Kerberos (KLIST), чтобы убедиться, что клиентский компьютер может получить билет Kerberos для заданного имени субъекта-службы. В этом примере имя субъекта-службы (SPN) — http/web-server.

При сбое запроса билета Kerberos проверка подлинности Kerberos не используется. Может возникнуть резервный вариант NTLM, так как запрошенное имя субъекта-службы неизвестно для контроллера домена. Если контроллер домена недостижим, откат NTLM не происходит.

Сведения об объявлении имени субъекта-службы см. в следующей статье:

Использование имен субъектов-служб при настройке веб-приложений, размещенных в службах IIS.

Использует ли веб-сервер порт, отличный от по умолчанию (80)

По умолчанию интернет-Обозреватель не включает сведения о номере порта в имя субъекта-службы, используемое для запроса билета Kerberos. Это может быть проблемой, если вы используете IIS для размещения нескольких сайтов в разных портах и удостоверениях. В этой конфигурации проверка подлинности Kerberos может работать только для определенных сайтов, даже если все имена субъектов-служб были правильно объявлены в Active Directory. Чтобы устранить эту проблему, необходимо задать FEATURE_INCLUDE_PORT_IN_SPN_KB908209 значение реестра. (Сведения о том, как объявить ключ, см. в разделе Интернет-Обозреватель ключей функций.) Этот параметр заставляет Обозреватель Интернета включать номер порта в имя субъекта-службы, которое используется для запроса билета Kerberos.

Использует ли интернет-Обозреватель ожидаемое имя субъекта-службы

Если для доступа к веб-сайту используется псевдоним (CNAME), Интернет Обозреватель сначала использует разрешение DNS для разрешения имени псевдонима в имя компьютера (ANAME). Затем имя компьютера используется для создания имени субъекта-службы и запроса билета Kerberos. Даже если URL-адрес, введенный в адресной строке интернет-Обозреватель, равен http://MYWEBSITE, интернет-Обозреватель запрашивает имя субъекта-службы для HTTP/MYSERVER, если MYWEBSITE является псевдонимом (CNAME) MYSERVER (ANAME). Это поведение можно изменить с помощью FEATURE_USE_CNAME_FOR_SPN_KB911149 раздела реестра. (Сведения о том, как объявить ключ, см. в разделе Интернет-Обозреватель ключей функций.)

Трассировка сетевого монитора — это хороший метод проверка имени субъекта-службы, связанного с билетом Kerberos, как показано в следующем примере:

- Http: Request, GET /whoami.aspx , Using GSS-API Authorization
    Command: GET
  - URI: /whoami.aspx
     Location: /whoami.aspx
    ProtocolVersion: HTTP/1.1
    Accept:  image/gif, image/jpeg, image/pjpeg, application/x-ms-application, application/xaml+xml, application/x-ms-xbap, */*
    Accept-Language:  en-US,en;q=0.5
    UserAgent:  Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 10.0; WOW64; Trident/7.0; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729)
    Accept-Encoding:  gzip, deflate
    Host:  web-server
    Connection:  Keep-Alive
  - Authorization: Negotiate
   - Authorization:  Negotiate YIILcAYGKwYBBQUCoIILZDCCC2CgMDAuBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHgYKKwYBBAGCNwICCqKCCyoEggsmYIILIgYJKoZIhvcSAQICAQBuggsRMIILDaADAgEFoQMCAQ6iBwMFACAAAACjggRtYYIEaTCCBGWgAwIBBaEOGwxPREVTU1kuTE9DQUyiKjAooAMCAQKhITAfGwRIVFRQG
      WhiteSpace:  
    - NegotiateAuthorization:
       Scheme: Negotiate
     - GssAPI: 0x1
      - InitialContextToken:
       + ApplicationHeader:
       + ThisMech: SpnegoToken (1.3.6.1.5.5.2)
       - InnerContextToken: 0x1
        - SpnegoToken: 0x1
         + ChoiceTag:
         - NegTokenInit:
          + SequenceHeader:
          + Tag0:
          + MechTypes: Prefer MsKerberosToken (1.2.840.48018.1.2.2)
          + Tag2:
          + OctetStringHeader:
          - MechToken: 0x1
           - MsKerberosToken: 0x1
            - KerberosInitToken:
             + ApplicationHeader:
             + ThisMech: KerberosToken (1.2.840.113554.1.2.2)
             - InnerContextToken: 0x1
              - KerberosToken: 0x1
                 TokId: Krb5ApReq (0x100)
               - ApReq: KRB_AP_REQ (14)
                + ApplicationTag:
                + SequenceHeader:
                + Tag0:
                + PvNo: 5
                + Tag1:
                + MsgType: KRB_AP_REQ (14)
                + Tag2: 0x1
                + ApOptions:
                + Tag3:
                - Ticket: Realm: ODESSY.LOCAL, Sname: HTTP/web-server.odessy.local
                 + ApplicationTag:
                 + SequenceHeader:
                 + Tag0:
                 + TktVno: 5
                 + Tag1:
                 + Realm: ODESSY.LOCAL
                 + Tag2: 0x1
                 + Sname: HTTP/web-server.odessy.local
                 + Tag3: 0x1
                 + EncPart:
                + Tag4:

Соответствует ли удостоверение пула приложений учетной записи, связанной с номером субъекта-службы

При отправке билета Kerberos из Интернета Обозреватель на сервер IIS он шифруется с помощью закрытого ключа. Закрытый ключ — это хэш пароля, который используется для учетной записи пользователя, связанной с номером субъекта-службы. Таким образом, только приложение, работающее под этой учетной записью, может декодировать билет.

Ниже приведена сводка алгоритма проверки подлинности Kerberos.

1. Интернет-Обозреватель определяет имя субъекта-службы с помощью URL-адреса, введенного в адресной строке.

2. Имя субъекта-службы передается через API SSPI (InitializeSecurityContext) в системный компонент, отвечающий за безопасность Windows (процесс локальной службы подсистемы центра безопасности (LSASS). На этом этапе можно увидеть, что код Обозреватель Интернета не реализует код для создания билета Kerberos. Интернет-Обозреватель вызывает только API SSPI.

3. LSASS использует переданное имя субъекта-службы для запроса билета Kerberos в контроллер домена. Если контроллер домена может обслуживать запрос (известное имя субъекта-службы), он создает билет Kerberos. Затем он шифрует билет с помощью ключа, созданного на основе хэша пароля учетной записи пользователя для учетной записи, связанной с имям субъекта-службы. Затем LSASS отправляет запрос клиенту. Что касается Интернет-Обозреватель, билет является непрозрачным BLOB-объектом.

4. Интернет-Обозреватель инкапсулирует билет Kerberos, предоставленный LSASS, в Authorization: Negotiate заголовке, а затем отправляет билет на сервер IIS.

5. IIS обрабатывает запрос и направляет его в правильный пул приложений с помощью указанного заголовка узла.

6. Пул приложений пытается расшифровать билет с помощью API SSPI/LSASS и выполнения следующих условий:

   • Если билет можно расшифровать, проверка подлинности Kerberos будет выполнена успешно. Доступны все службы, связанные с билетом (олицетворение, делегирование, если билет разрешает это, и т. д.).

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

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

• Сетевая служба
• ApplicationPoolIdentity
• Другая системная учетная запись, например LOCALSYSTEM или LOCALSERVICE

Но эти удостоверения не рекомендуется, так как они являются угрозой безопасности. В этом случае билет Kerberos создается с помощью имени субъекта-службы по умолчанию, созданного в Active Directory при добавлении в домен компьютера (в данном случае сервера, на котором запущены службы IIS). Это имя субъекта-службы по умолчанию связано с учетной записью компьютера. В iis учетная запись компьютера сопоставляется с сетевой службой или ApplicationPoolIdentity.

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

• SETSPN http/mywebsite UserAppPool1
• SETPN http/mywebsite UserAppPool2

Эта конфигурация не будет работать, так как не существует детерминированного способа узнать, будет ли билет Kerberos для имени участника-службы http/mywebsite зашифрован с помощью пароля UserAppPool1 или UserAppPool2. Эта конфигурация обычно приводит к KRB_AP_ERR_MODIFIED ошибкам. Чтобы определить, находитесь ли вы в этом сценарии неправильного дублирования имен субъектов-служб, используйте средства, описанные в следующей статье:

Почему вы по-прежнему можете иметь дублирующиеся имена субъектов-служб в AD 2012 R2 и AD 2016

Начиная с Windows Server 2008, можно также использовать обновленную версию SETSPN для Windows, которая позволяет обнаруживать повторяющиеся имена субъектов-служб с помощью setspn –X команды при объявлении нового имени субъекта-службы для целевой учетной записи. Дополнительные сведения см. в разделе Setspn.

Мы также рекомендуем ознакомиться со следующими статьями:

• Проблемы с проверкой подлинности Kerberos — проблемы с именем субъекта-службы (SPN) — часть 1

• Проблемы с проверкой подлинности Kerberos — проблемы с именем субъекта-службы (SPN) — часть 2

• Проблемы с проверкой подлинности Kerberos — проблемы с именем субъекта-службы (SPN) — часть 3

Завершается ли ошибка проверки подлинности Kerberos в IIS 7 и более поздних версиях, даже если она работает в IIS 6

Проверка подлинности в режиме ядра — это функция, появилась в IIS 7. Он предоставляет следующие преимущества:

• Производительность повышается, так как переходы между режимами ядра и пользователем больше не выполняются.
• Декодирование билетов Kerberos выполняется с помощью учетной записи компьютера, а не удостоверения пула приложений. Это изменение позволяет иметь несколько пулов приложений, работающих с разными удостоверениями без необходимости объявлять имена субъектов-служб.

Почему происходит сбой делегирования, хотя проверка подлинности Kerberos работает

В этом сценарии проверка следующие элементы:

• Зона Обозреватель Интернета, используемая для URL-адреса. Делегирование Kerberos разрешено только для зон интрасети и доверенных сайтов. (Иными словами, интернет-Обозреватель задает ISC_REQ_DELEGATE флаг при вызове InitializeSecurityContext только в том случае, если определена зона интрасети или доверенных сайтов.)

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

Если делегирование по-прежнему не удается, рассмотрите возможность использования Configuration Manager Kerberos для IIS. Это средство позволяет диагностировать и исправлять конфигурации IIS для проверки подлинности Kerberos и связанных имен субъектов-служб в целевых учетных записях. Дополнительные сведения см. в README.md. Скачать средство можно здесь.

Почему при использовании проверки подлинности Kerberos возникает плохая производительность

Kerberos — это протокол проверки подлинности на основе запросов в более ранних версиях Windows Server, таких как Windows Server 2008 с пакетом обновления 2 (SP2) и Windows Server 2008 R2. Это означает, что клиент должен отправить билет Kerberos (который может быть довольно большим blob-объектом) с каждым запросом, сделанным на сервер. Это противоречит методам проверки подлинности, которые используют NTLM. По умолчанию NTLM основан на сеансе. Это означает, что браузер будет проверять подлинность только одного запроса, когда открывает TCP-подключение к серверу. Каждый последующий запрос к одному и тому же TCP-подключению больше не потребует проверки подлинности, чтобы запрос был принят. В более новых версиях IIS, начиная с Windows 2012 R2 и далее, Kerberos также основан на сеансах. Только первый запрос на новое TCP-подключение должен пройти проверку подлинности на сервере. Последующие запросы не должны включать билет Kerberos.

Это поведение можно изменить с помощью свойства authPersistNonNTLM , если используется IIS 7 и более поздних версий. Если для свойства задано значение true, Kerberos будет основан на сеансе. В противном случае он будет основан на запросах. Он будет иметь более высокую производительность, так как мы должны включать больший объем данных для отправки на сервер каждый раз. Дополнительные сведения см. в разделе Проверка подлинности Kerberos на основе запросов и сеансов (или параметр AuthPersistNonNTLM).

Почему не удается выполнить делегирование Kerberos между моими двумя лесами, хотя раньше оно работало

Рассмотрим следующий сценарий.

• Пользователи приложения находятся в домене в лесу A.
• Приложение находится в домене в лесу B.
• У вас есть отношения доверия между лесами.

В этом сценарии делегирование Kerberos может перестать работать, даже если раньше оно работало и вы не вносили никаких изменений ни в леса, ни в домены. Проверка подлинности Kerberos по-прежнему работает в этом сценарии. Сбой только делегирования.

Эта проблема может возникнуть из-за обновлений системы безопасности для Windows Server, выпущенных корпорацией Майкрософт в марте 2019 г. и июле 2019 г. Эти обновления отключили неограниченное делегирование Kerberos (возможность делегировать маркер Kerberos из приложения серверной службе) через границы леса для всех новых и существующих отношений доверия. Дополнительные сведения см. в разделе Обновления делегирования TGT через входящие отношения доверия в Windows Server.

Ключи функций Обозреватель Интернета

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

• HKEY_USERS\<UserSID>\Software\Microsoft\Internet Explorer\Main\FeatureControl — если он определен на уровне пользователя.
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\ — если он определен на уровне компьютера.

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

• для всех пользователей на компьютере
• только для определенной учетной записи

Эти ключи должны быть созданы по соответствующему пути. Внутри ключа должно быть объявлено значение DWORD с именем iexplorer.exe . Значение по умолчанию для каждого ключа должно быть равно true или false в зависимости от требуемого параметра компонента. По умолчанию значение как ключей функций, FEATURE_INCLUDE_PORT_IN_SPN_KB908209 так и FEATURE_USE_CNAME_FOR_SPN_KB911149, равно false. Для полноты ниже приведен пример экспорта реестра путем переключения раздела компонента для включения номеров портов в билет Kerberos в значение true:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_INCLUDE_PORT_IN_SPN_KB908209]
"iexplore.exe"=dword:00000001

Дополнительная информация

Страницы диагностики для устранения неполадок встроенной проверки подлинности Windows