インターネット エクスプローラーでの Kerberos エラーのトラブルシューティング

この記事は、インターネット エクスプローラーで 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 を使用すると、ヘッダーに Kerberos チケットが含まれているため HTTP_AUTHORIZATION 、クライアントから送信される要求は大きくなります (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 認証設定のスクリーンショット。

インターネット エクスプローラーで統合認証が有効になっている

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

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

次のサイトに対して常にこのチェックを実行します。

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

ブラウザーがサイトを含めることにしたゾーンをチェックできます。 これを行うには、インターネット エクスプローラーの [ファイル] メニューを開き、[プロパティ] を選択します。 [ プロパティ ] ウィンドウには、ブラウザーが閲覧先のサイトを含めるゾーンが表示されます。

[インターネットのプロパティ] エクスプローラーのゾーンを確認します。

サイトが含まれているゾーンで自動ログオンが許可されているかどうかをチェックできます。 これを行うには、インターネット エクスプローラーの [インターネット オプション] メニューを開き、[セキュリティ] タブを選択します。目的のゾーンを選択した後、[カスタム レベル] ボタンを選択して設定を表示し、[自動ログオン] が選択されていることを確認します。 (通常、この機能はイントラネットゾーンと信頼済みサイトゾーンに対して既定でオンになっています)。

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

注:

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

WWW 認証: ネゴシエート ヘッダーを送信するように IIS サーバーが構成されているか

WWW 認証: ネゴシエート ヘッダーを送信するように IIS サーバーが構成されているかどうかを確認します。

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

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

注:

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

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

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

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

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

注:

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

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

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

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

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

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

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

インターネットエクスプローラー予想される SPN を使用します。

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

ネットワーク モニター トレースは、次の例のように、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 チケットがインターネット エクスプローラーから IIS サーバーに送信されると、秘密キーを使用してチケットが暗号化されます。 秘密キーは、SPN に関連付けられているユーザー アカウントに使用されるパスワードのハッシュです。 そのため、このアカウントで実行されているアプリケーションのみがチケットをデコードできます。

次の手順は、Kerberos 認証アルゴリズムの概要です。

  1. インターネット エクスプローラーは、アドレス バーに入力された URL を使用して SPN を決定します。

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

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

  4. インターネット エクスプローラーは、LSASS によって提供される Kerberos チケットをAuthorization: Negotiateヘッダーにカプセル化し、IIS サーバーにチケットを送信します。

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

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

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

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

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

  • ネットワーク サービス
  • ApplicationPoolIdentity
  • LOCALSYSTEM や LOCALSERVICE などの別のシステム アカウント

ただし、これらの ID はセキュリティ リスクであるため、推奨されません。 この場合、Kerberos チケットは、コンピューター (この場合は IIS が実行されているサーバー) がドメインに追加されたときに Active Directory で作成される既定の SPN を使用して構築されます。 この既定の SPN は、コンピューター アカウントに関連付けられています。 IIS では、コンピューター アカウントは Network Service または 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 を宣言するときにコマンドを使用して重複する SPN を検出できるようにする、Windows 用の SETSPN の更新バージョンを使用 setspn –X することもできます。 詳細については、「 Setspn」を参照してください。

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

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

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

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

警告

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

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

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

このシナリオでは、次の項目をチェックします。

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

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

委任がそれでも失敗する場合は、IIS 用の Kerberos Configuration Managerの使用を検討してください。 このツールを使用すると、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 はセッション ベースになります。 それ以外の場合は、要求ベースになります。 サーバーに送信するデータを毎回大量に含める必要があるため、パフォーマンスが低下します。 詳細については、「 要求ベースとセッション ベースの Kerberos 認証 (または AuthPersistNonNTLM パラメーター)」を参照してください。

注:

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

2 つのフォレスト間で Kerberos 委任が失敗する理由

次のような状況で問題が発生します。

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

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

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

インターネット エクスプローラー機能キー

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

  • 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 統合認証のトラブルシューティングの診断ページ