次の方法で共有

Internet Explorer での Kerberos エラーのトラブルシューティング

この記事は、Internet Explorer で Kerberos 認証を使用するように構成されている Web サイトにアクセスするときのさまざまなエラーの原因を特定して修正するのに役立ちます。 潜在的な問題の数は、それらを解決するために使用できるツールの数とほぼ同じ数です。

Kerberos が失敗した場合の一般的な症状

Windows 統合認証が構成されており、Kerberos 認証プロトコルを使用する予定の Web サイトにアクセスしようとするとします。 この状況では、次のように、ブラウザーから資格情報の入力がすぐに求められます。

資格情報の入力を求めるプロンプトのスクリーンショット。

有効なユーザー名とパスワードを入力しますが、もう一度メッセージが表示されます (合計 3 つのプロンプト)。 その後、目的のリソースへのアクセスが許可されていないことを示す画面が表示されます。 画面には、次のエラーのような HTTP 401 状態コードが表示されます。

権限なし
HTTP エラー 401。 要求されたリソースには、ユーザー認証が必要です。

H T T P エラー 401 のスクリーンショット。

Microsoft インターネット インフォメーション サービス (IIS) サーバーの Web サイト ログには、次のログなど、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 認証エラーのトラブルシューティングを行う場合は、最小限に抑えて構成を簡略化することをお勧めします。 つまり、既定のポートで実行されている 1 つのクライアント、1 つのサーバー、および 1 つの 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 を使用すると、 HTTP_AUTHORIZATION ヘッダーに Kerberos チケットが含まれているため、クライアントによって送信される要求は大きくなります (2,000 バイトを超える)。 次の要求は、Kerberos ベースの Windows 認証を使用して受信ユーザーを認証するページ用です。 GET 要求のサイズが 4,000 バイトを超えています。

4,000 バイトを超える要求のスクリーンショット。

NTLM ハンドシェイクが使用されている場合、要求ははるかに小さくなります。 次のクライアント側キャプチャは、NTLM 認証要求を示しています。 GET 要求ははるかに小さい (1,400 バイト未満)。

1,400 バイト未満の要求のスクリーンショット。

Kerberos 認証が失敗していると判断したら、指定された順序で次の各項目を確認します。

Kerberos 認証が失敗したかどうかを確認する事項

次のセクションでは、Kerberos 認証が失敗したかどうかを確認するために使用できる内容について説明します。

クライアントとサーバーが同じドメインにあるか

Kerberos チケットはドメイン コントローラー (DC) によって配信されるため、Kerberos を使用するにはドメインが必要です。 高度なシナリオは、次の場合にも可能です。

  • クライアントとサーバーは同じドメイン内ではなく、同じフォレストの 2 つのドメインにあります。
  • クライアントとサーバーは 2 つの異なるフォレストにあります。

これらの考えられるシナリオについては、 で説明します。この記事の「2 つのフォレスト間で Kerberos の委任は失敗しますが 」セクションを参照してください。

統合認証を使用するように IIS が構成されているか

Windows 認証設定のスクリーンショット。

Internet Explorer で統合認証が有効になっている

[インターネット オプション] ページの [統合 Windows 認証を有効にする] オプションを選択します。

使用されている URL は、資格情報を送信できるセキュリティ ゾーンに解決されますか?

次のサイトでは、常にこのチェックを実行します。

  • ブラウザーのローカル イントラネット ゾーンに一致するサイト。
  • 信頼済みサイト ゾーン内のサイト。

ブラウザーでサイトを含めるゾーンを確認できます。 これを行うには、Internet Explorer の File メニューを開き、 Properties を選択します。 Properties ウィンドウには、ブラウザーが参照先のサイトを含めることにしたゾーンが表示されます。

Internet Explorer のプロパティでゾーンを確認します。

サイトが含まれているゾーンで自動ログオンが許可されているかどうかを確認できます。 これを行うには、Internet Explorer の Internet オプション メニューを開き、 Security タブを選択します。目的のゾーンを選択した後、 Custom レベル ボタンを選択して設定を表示し、 自動ログオン が選択されていることを確認します。 (通常、イントラネット ゾーンと信頼済みサイト ゾーンでは、この機能は既定で有効になっています)。

[自動ログオン] が選択されているかどうかを確認します。

Note

この構成は一般的ではありません (クライアントが DC にアクセスできる必要があるため)、Kerberos はインターネット ゾーンの URL に使用できます。 この場合、既定の設定が変更されない限り、ブラウザーは常にユーザーに資格情報の入力を求めます。 Kerberos 委任は、インターネット ゾーンでは機能しません。 これは、Internet Explorer では、イントラネットおよび信頼済みサイト ゾーン内の URL に対してのみ Kerberos 委任が許可されるためです。

WWW-Authenticate: Negotiate ヘッダーを送信するように IIS サーバーが構成されているか

IIS サーバーが WWW-Authenticate: Negotiate ヘッダーを送信するように構成されているかどうかを確認します。

IIS がこのヘッダーを送信しない場合は、IIS マネージャー コンソールを使用して、 NTAuthenticationProviders 構成プロパティを使用して Negotiate ヘッダーを設定します。 詳細については、「 Windows 認証プロバイダー <プロバイダー>を参照してください。 コンソールには、IIS マネージャーの Windows 認証の詳細の Providers 設定からアクセスできます。

認証のプロバイダー設定。

Note

既定では、 NTAuthenticationProviders プロパティは設定されていません。 これにより、IIS はネゴシエート ヘッダーと Windows NT LAN Manager (NTLM) ヘッダーの両方を送信します。

クライアントとサーバーが同じコンピューターにインストールされているか

既定では、Kerberos はこの構成では有効になっていません。 この動作を変更するには、 DisableLoopBackCheck レジストリ キーを設定する必要があります。 詳細については、 KB 926642を参照してください。

クライアントは Kerberos チケットを取得できますか

Kerberos List (KLIST) ツールを使用して、クライアント コンピューターが特定のサービス プリンシパル名の Kerberos チケットを取得できることを確認できます。 この例では、サービス プリンシパル名 (SPN) は http/web-server です。

Note

KLIST は、サーバー側オペレーティング システム用の Windows Server 2008 以降、クライアント側オペレーティング システム用の Windows 7 Service Pack 1 以降のネイティブ Windows ツールです。

KLIST ツールを使用して、クライアント コンピューターが特定のサービス プリンシパル名の Kerberos チケットを取得できることを確認します。

Kerberos チケット要求が失敗した場合、Kerberos 認証は使用されません。 要求された SPN が DC に対して不明であるため、NTLM フォールバックが発生する可能性があります。 DC に到達できない場合、NTLM フォールバックは発生しません。

SPN を宣言するには、次の記事を参照してください。

インターネット インフォメーション サービスでホストされている Web アプリケーションを構成するときに SPN を使用する方法。

Web サーバーは既定以外のポートを使用しますか (80)

既定では、Internet Explorer には、Kerberos チケットの要求に使用される SPN のポート番号情報は含まれません。 IIS を使用して異なるポートと ID で複数のサイトをホストする場合は、問題になる可能性があります。 この構成では、すべての SPN が Active Directory で正しく宣言されている場合でも、Kerberos 認証は特定のサイトでのみ機能します。 この問題を解決するには、 FEATURE_INCLUDE_PORT_IN_SPN_KB908209 レジストリ値を設定する必要があります。 ( を参照してください。Internet Explorer の機能キー セクションでキーを宣言する方法について説明します)。この設定により、Internet Explorer は Kerberos チケットの要求に使用されるポート番号を SPN に含めます。

Internet Explorer で予期される SPN が使用される

エイリアス名 (CNAME) を使用して Web サイトにアクセスする場合、Internet Explorer は最初に DNS 解決を使用してエイリアス名をコンピューター名 (ANAME) に解決します。 その後、コンピューター名を使用して SPN をビルドし、Kerberos チケットを要求します。 Internet Explorer のアドレス バーに入力された URL が http://MYWEBSITEされている場合でも、MYWEBSITE が MYSERVER (ANAME) のエイリアス (CNAME) である場合、Internet Explorer は HTTP/MYSERVER の SPN を要求します。 この動作は、 FEATURE_USE_CNAME_FOR_SPN_KB911149 レジストリ キーを使用して変更できます。 ( を参照してください。Internet Explorer の機能キー キーを宣言する方法について説明します)。

ネットワーク モニター トレースは、次の例のように、Kerberos チケットに関連付けられている SPN を確認するのに適した方法です。

- 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:

アプリケーション プール ID が SPN に関連付けられているアカウントと一致しますか

Kerberos チケットが Internet Explorer から IIS サーバーに送信されると、チケットは秘密キーを使用して暗号化されます。 秘密キーは、SPN に関連付けられているユーザー アカウントに使用されるパスワードのハッシュです。 そのため、このアカウントで実行されているアプリケーションのみがチケットをデコードできます。

Kerberos 認証アルゴリズムの概要を次に示します。

  1. Internet Explorer は、アドレス バーに入力された URL を使用して SPN を決定します。

  2. SPN は、セキュリティ サポート プロバイダー インターフェイス (SSPI) API (InitializeSecurityContext) を介して、Windows セキュリティを担当するシステム コンポーネント (ローカル セキュリティ機関サブシステム サービス (LSASS) プロセス) に渡されます。 この段階では、Internet Explorer コードで Kerberos チケットを構築するためのコードが実装されていないことがわかります。 Internet Explorer は SSPI API のみを呼び出します。

  3. LSASS は、渡された SPN を使用して、DC に Kerberos チケットを要求します。 DC が要求 (既知の SPN) を処理できる場合は、Kerberos チケットが作成されます。 次に、SPN に関連付けられているアカウントのユーザー アカウント パスワードのハッシュから構築されたキーを使用してチケットを暗号化します。 LSASS は、クライアントにチケットを送信します。 Internet Explorer に関する限り、チケットは不透明な BLOB です。

  4. Internet Explorer は、LSASS によって提供される Kerberos チケットを Authorization: Negotiate ヘッダーにカプセル化し、IIS サーバーにチケットを送信します。

  5. IIS は要求を処理し、指定されたホスト ヘッダーを使用して適切なアプリケーション プールにルーティングします。

  6. アプリケーション プールは、SSPI/LSASS API を使用し、次の条件に従ってチケットの暗号化を解除しようとします。

    • チケットを復号化できる場合、Kerberos 認証は成功します。 チケットに関連付けられているすべてのサービス (偽装、チケットで許可されている場合の委任など) を利用できます。

    • チケットを復号化できない場合は、Kerberos エラー (KRB_AP_ERR_MODIFIED) が返されます。 このエラーは、チケットが転送中に何らかの方法で変更されたことを示す一般的なエラーです。 そのため、チケットを復号化することはできません。 このエラーは、Windows イベント ログにも記録されます。

SPN を明示的に宣言しない場合、Kerberos 認証は次のいずれかのアプリケーション プール ID でのみ機能します。

  • Network Service
  • ApplicationPoolIdentity
  • LOCALSYSTEM や LOCALSERVICE などの別のシステム アカウント

ただし、これらの ID はセキュリティ リスクであるため、推奨されません。 この場合、Kerberos チケットは、コンピューター (この場合は IIS が実行されているサーバー) がドメインに追加されたときに Active Directory で作成される既定の SPN を使用して構築されます。 この既定の SPN は、コンピューター アカウントに関連付けられています。 IIS では、コンピューター アカウントはネットワーク サービスまたは ApplicationPoolIdentity にマップされます。

アプリケーション プールで一覧表示されている ID 以外の ID を使用する必要がある場合は、SPN を宣言します ( SETSPN を使用)。 次に、アプリケーション プール ID に使用されるアカウントに関連付けます。 一般的な間違いは、アカウントが異なる類似の SPN を作成することです。 例えば次が挙げられます。

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

http/mywebsite SPN の Kerberos チケットが UserAppPool1 または UserAppPool2 パスワードを使用して暗号化されるかどうかを判断する決定的な方法がないため、この構成は機能しません。 この構成では、通常、KRB_AP_ERR_MODIFIED エラーが生成されます。 この不適切な重複 SPN のシナリオに参加しているかどうかを確認するには、次の記事に記載されているツールを使用します。

AD 2012 R2 と AD 2016 で重複する SPN を引き続き使用できる理由

Windows Server 2008 以降では、ターゲット アカウントの新しい SPN を宣言するときに、 setspn –X コマンドを使用して重複する SPN を検出できるようにする、Windows 用 SETSPN の更新バージョンを使用することもできます。 詳細については、「 Setspn」を参照してください。

また、次の記事を確認することをお勧めします。

IIS 6 で動作する場合でも、IIS 7 以降のバージョンでは Kerberos 認証は失敗します

カーネル モード認証は、IIS 7 で導入された機能です。 これには次の利点があります。

  • カーネル モードからユーザー モードへの切り替えが行われなくなったため、パフォーマンスが向上します。
  • Kerberos チケットのデコードは、アプリケーション プール ID ではなくマシン アカウントを使用して行われます。 この変更により、SPN を宣言しなくても、複数のアプリケーション プールを異なる ID で実行できます。

警告

SPN が特定のユーザー アカウント (アプリケーション プール ID としても使用) に対して宣言されている場合、カーネル モード認証では、コンピューター アカウントを使用するため、Kerberos チケットの暗号化を解除できません。 この問題は、Web ファームのシナリオで一般的です。 このシナリオでは、通常、(仮想) NLB ホスト名の SPN を宣言します。 この問題を回避するには、次のいずれかの方法を使用します。

  • カーネル モード認証を無効にします。 (パフォーマンスの観点からは推奨されません。
  • useAppPoolCredentials を true に設定します。 これにより、カーネル モード認証のパフォーマンス上の利点が維持される一方で、Kerberos チケットをアプリケーション プール ID でデコードできます。 詳細については、「 Security Authentication <authentication>」を参照してください。

Kerberos 認証が機能するのに委任が失敗する理由

このシナリオでは、次の項目を確認します。

  • URL に使用される Internet Explorer ゾーン。 Kerberos の委任は、イントラネット ゾーンと信頼済みサイト ゾーンに対してのみ許可されます。 (つまり、Internet Explorer は、InitializeSecurityContextを呼び出すときにISC_REQ_DELEGATE フラグを設定します。これは、決定されたゾーンがイントラネットサイトまたは信頼済みサイトである場合のみです)。

  • サイトをホストしている IIS アプリケーション プールのユーザー アカウントには、Active Directory 内で Trusted for delegation フラグが設定されている必要があります。

委任が失敗する場合は、KERBERos Configuration Manager for IIS の使用を検討してください。 このツールを使用すると、Kerberos 認証とターゲット アカウントの関連付けられている SPN の IIS 構成を診断して修正できます。 詳細については、 README.mdを参照してください。 このツールは、こちらからダウンロードできます。

Kerberos 認証を使用するとパフォーマンスが低下する理由

Kerberos は、Windows Server 2008 SP2 や Windows Server 2008 R2 などの古いバージョンの Windows Server の要求ベースの認証プロトコルです。 つまり、クライアントは、サーバーに対して行われる各要求で Kerberos チケット (非常に大きな BLOB になる可能性があります) を送信する必要があります。 NTLM に依存する認証方法とは対照的です。 既定では、NTLM はセッション ベースです。 これは、ブラウザーがサーバーへの TCP 接続を開いたときに、1 つの要求のみを認証することを意味します。 同じ TCP 接続での後続の各要求では、要求を受け入れるために認証が必要ではなくなります。 新しいバージョンの IIS では、Windows 2012 R2 以降では、Kerberos もセッション ベースです。 サーバーによって認証される必要があるのは、新しい TCP 接続の最初の要求のみです。 後続の要求には Kerberos チケットを含める必要はありません。

IIS 7 以降のバージョンで実行している場合は、 authPersistNonNTLM プロパティを使用して、この動作を変更できます。 プロパティが true に設定されている場合、Kerberos はセッション ベースになります。 それ以外の場合は、要求ベースになります。 毎回サーバーに送信する大量のデータを含める必要があるため、パフォーマンスが低下します。 詳細については、「 Request ベースとセッション ベースの Kerberos 認証 (または AuthPersistNonNTLM パラメーター)」を参照してください。

Note

すべてのオブジェクトで Kerberos 認証を盲目的に使用することはお勧めしません。 Kerberos 認証を使用して、 304 が変更されない可能性が高い条件付き GET 要求を使用して何百ものイメージをフェッチします 応答は、ハンマーを使用してフライを強制終了しようとするようなものです。 このような方法では、明らかなセキュリティの向上も提供されません。

2 つのフォレストの間で Kerberos の委任が失敗するのはなぜですか

以下のシナリオについて考えてみます。

  • アプリケーションのユーザーは、フォレスト A 内のドメインに配置されます。
  • アプリケーションはフォレスト B 内のドメインにあります。
  • フォレスト間に信頼関係があります。

このシナリオでは、Kerberos 委任は以前は機能していたものの、フォレストまたはドメインに変更を加えていない場合でも、動作を停止する可能性があります。 Kerberos 認証は、このシナリオでは引き続き機能します。 委任のみが失敗します。

この問題は、2019 年 3 月と 2019 年 7 月に Microsoft によってリリースされた Windows Server のセキュリティ更新プログラムが原因で発生する可能性があります。 これらの更新では、すべての新規および既存の信頼について、フォレスト境界を越えて制約のない Kerberos 委任 (アプリケーションからバックエンド サービスに Kerberos トークンを委任する機能) が無効になりました。 詳細については、「 Updates to TGT delegation across incoming trusts in Windows Server」を参照してください。

Internet Explorer の機能キー

これらのキーは、ブラウザーの一部の機能をオンまたはオフにするレジストリ キーです。 キーは、次のレジストリの場所にあります。

  • HKEY_USERS\<UserSID>\Software\Microsoft\Internet Explorer\Main\FeatureControl – ユーザー レベルで定義されている場合
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\ - マシン レベルで定義されている場合

機能キーは、機能をオンまたはオフにするかどうかに応じて、次のいずれかの場所に作成する必要があります。

  • コンピューター上のすべてのユーザーに対して
  • 特定のアカウントに対してのみ

これらのキーは、それぞれのパスの下に作成する必要があります。 キー内では、 iexplorer.exe という名前の DWORD 値を宣言する必要があります。 各キーの既定値は、機能の目的の設定に応じて、 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 統合認証のトラブルシューティングの診断ページ