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

Устранение ошибок Kerberos в Internet Explorer

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

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

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

Снимок экрана: запрос учетных данных.

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

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

Снимок экрана: ошибка H T T P 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 составляет более 4 000 байт.

Снимок экрана: запросы, превышающие 4000 байт.

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

Снимок экрана: запросы, которые меньше 1400 байт.

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

Сведения о том, завершается ли проверка подлинности Kerberos

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

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

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

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

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

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

Снимок экрана: параметр проверки подлинности Windows.

Включена встроенная проверка подлинности в Internet Explorer

Выберите параметр

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

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

  • Сайты, соответствующие зоне локальной интрасети браузера.
  • Сайты в зоне надежных сайтов.

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

Проверьте зону в свойствах Internet Explorer.

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

Проверьте, выбран ли автоматический вход.

Примечание.

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

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

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

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

Параметры поставщиков в проверке подлинности.

Примечание.

По умолчанию свойство NTAuthenticationProviders не задано. Это приводит к тому, что СЛУЖБЫ IIS отправляют заголовки "Согласование" и "Windows NT LAN Manager" (NTLM).

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

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

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

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

Примечание.

KLIST — это собственное средство Windows с Windows Server 2008 для серверных операционных систем и Windows 7 с пакетом обновления 1 для клиентских операционных систем.

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

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

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

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

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

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

Использует ли Internet Explorer ожидаемое имя субъекта-службы

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

Трассировка сетевого монитора — это хороший метод проверки имени субъекта-службы, связанного с билетом 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:

Соответствует ли удостоверение пула приложений учетной записи, связанной с spN

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

Следующая процедура представляет собой сводку по алгоритму проверки подлинности Kerberos:

  1. Internet Explorer определяет имя участника-службы с помощью URL-адреса, введенного в адресную строку.

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

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

  4. Internet Explorer инкапсулирует билет 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.

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

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

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

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

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

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

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

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

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

Предупреждение

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

  • Отключите проверку подлинности в режиме ядра. (Не рекомендуется с точки зрения производительности.)
  • Задайте значение true для useAppPoolCredentials. Это обеспечивает преимущество проверки производительности проверки подлинности в режиме ядра, позволяя декодировать билет Kerberos под удостоверением пула приложений. Дополнительные сведения см. в разделе "Проверка подлинности системы безопасности><".

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

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

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

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

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

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

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

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

Примечание.

Не рекомендуется использовать проверку подлинности Kerberos на всех объектах. Использование проверки подлинности Kerberos для получения сотен изображений с помощью условных запросов GET, которые, скорее всего, создают 304 не измененных ответов, как попытка убить летать с помощью молотка. Такой метод также не обеспечит очевидные преимущества безопасности.

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

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

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

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

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

Ключи функций Internet Explorer

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

  • 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