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

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

Распространенные признаки при сбое Kerberos

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

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

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

Снимок экрана: ошибка HTTP 401.

На сервере служб Microsoft 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, вы можете использовать следующую страницу Тесткерб. 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"
%>

Вы также можете использовать такие средства, как Fiddler, HttpWatch, Network Monitor или инструменты разработчика в браузере, чтобы определить, используется ли Kerberos. Для получения дополнительных сведений о том, как можно создавать такие трассировки, ознакомьтесь со статьей клиентской трассировки.

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

Снимок экрана: количество запросов превышает 4 000 байт.

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

Снимок экрана: запросов менее 1 400 байт.

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

Что нужно проверить, не проходит ли проверка подлинности Kerberos

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

— Это клиент и сервер в том же домене;

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

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

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

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

Свойства браузера

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

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

свойства IE

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

Местная интрасеть

Примечание

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

— Это сервер IIS, настроенный на отправку заголовка WWW-Authenticate: Negotiate

Снимок экрана с заголовками.

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

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

Примечание

По умолчанию свойство нтаусентикатионпровидерс не задано. Это приводит к тому, что IIS отправляет как согласованные заголовки, так и заголовки Windows NT LAN Manager (NTLM).

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

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

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

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

Примечание

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

средство klist

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

Чтобы объявить SPN, Узнайте, как использовать SPN при настройке веб-приложений, размещенных в службах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 для сопоставления имени псевдонима с именем компьютера (АНАМЕ). Затем имя компьютера используется для сборки SPN и запроса билета Kerberos. Таким образом, даже если URL-адрес, указанный в адресной строке Internet Explorer, является URL-адресом http://MYWEBSITE , то Internet Explorer запрашивает имя SPN для HTTP/MYSERVER, если мивебсите является псевдонимом MYSERVER (CNAME) MYSERVER (анаме). Это поведение можно изменить с помощью 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 определяет SPN, используя URL-адрес, введенный в адресную строку.

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

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

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

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

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

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

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

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

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

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

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

  • SETSPN HTTP/мивебсите UserAppPool1
  • SETSPN HTTP/мивебсите UserAppPool2

Эта конфигурация не будет работать, так как невозможно определить, будет ли билет Kerberos для имени участника-службы HTTP/мивебсите шифроваться с помощью пароля UserAppPool1 или UserAppPool2. Такая конфигурация обычно приводит к возникновению ошибок KRB_AP_ERR_MODIFIED. Чтобы определить, находится ли вы в этом (некорректном) сценарии SPN, вы можете использовать средства, описанные в статье причина, по которой вы по-прежнему можете дублировать имена участников-служб в ad 2012 R2 и ad 2016. Начиная с Windows Server 2008, вы также можете использовать обновленную версию программы SETSPN для Windows, которая позволяет обнаруживать повторяющиеся SPN с помощью setspn –X команды при объявлении нового имени участника-службы для целевой учетной записи. Дополнительные сведения можно найти в статье setspn.

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

Не удается выполнить проверку подлинности Kerberos в IIS 7 и более поздних версиях, несмотря на то что она работает в IIS 6

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

Предположим, что у вас есть сценарий, в котором пользователи приложения находятся в домене в лесу A, ваше приложение расположено в домене в лесу B, и у вас есть отношение доверия между лесами. Вы можете обнаружить, что делегирование Kerberos перестало работать даже в том случае, если оно использовалось ранее и вы не внесли никаких изменений ни в одном из лесов или доменов. Обратите внимание, что проверка подлинности Kerberos по-прежнему работает в этом сценарии. Это только делегирование, которое не удается выполнить. Эта проблема может возникнуть из-за обновлений для системы безопасности до Windows Server, выпущенных корпорацией Майкрософт в марте 2019 и 2019 июля. Эти обновления отключают неограниченное делегирование Kerberos (возможность делегировать токен Kerberos из приложения в фоновую службу) через границы лесов для всех доверий (новый и существующий). Дополнительные сведения см. в статье Updates to делегирования 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