Kerberos の制約付き委任のトラブルシューティング

2025-05-03

シングルサインオン (SSO) の方法は、アプリケーションによって異なります。 Microsoft Entra アプリケーションプロキシは、既定で Kerberos の制約付き委任 (KCD) を提供します。アプリケーションプロキシでは、ユーザーは Kerberos を使用してプライベートアプリケーションに対して認証を行います。

この記事では、KCD 構成で最も一般的な問題をトラブルシューティングする方法について説明します。これには、より複雑な実装に対して実行できる診断手順が含まれています。

この記事は以下を前提としています。

Microsoft Entra アプリケーションプロキシがデプロイされ、KCD 以外のアプリケーションに一般的にアクセスできます。

詳細については、「アプリケーションプロキシの概要」を参照してください。
発行されたアプリケーションは、インターネットインフォメーションサービス (IIS) と Kerberos の Microsoft 実装に基づいています。
サーバーホストとアプリケーションホストは、単一の Microsoft Entra ドメイン内にあります。

ドメイン間およびフォレスト間のシナリオの詳細については、ホワイトペーパー「アプリケーションプロキシを使用した Kerberos の制約付き委任について」を参照してください。
アプリケーションは、事前認証が有効になっている Microsoft Entra テナントで発行されます。ユーザーは、フォームベースの認証を使用して認証する必要があります。

リッチクライアント認証のシナリオについては、この記事では説明しません。

考慮事項

次の一覧では、KCD の構成と Microsoft Entra アプリケーションプロキシでの使用に関する基本的な考慮事項について説明します。

基本的な構成ミスや一般的な間違いは、ほとんどの問題を引き起こします。トラブルシューティングを開始する前に、「アプリケーションプロキシで KCD SSO を使用する」のすべての前提条件を確認してください。
コネクタホストは、特定のローカルサイトドメインコントローラー (DC) とのみ通信するように制限されません。変更される可能性があるため、使用する DC を確認します。
クロスドメインシナリオは、コネクタホストをローカルネットワーク境界の外部にある可能性のある DC に誘導する紹介に依存します。このような場合は、他の各ドメインを表す DC にトラフィックを送信することが同様に重要です。そうしないと、委任は失敗します。
コアリモートプロシージャコール (RPC) トラフィックとの干渉による、コネクタホストとドメインコントローラー (DC) 間のアクティブな侵入防止システム (IPS) または侵入検出システム (IDS) デバイスの回避。
単純なシナリオで委任をテストします。シナリオで導入する変数が多いほど、より複雑な構成とトラブルシューティングが行われます。時間を節約するには、テストを 1 つのコネクタに制限します。問題が解決したら、コネクタを追加します。
環境要因は、問題の原因に寄与する可能性があります。これらの要因を回避するには、テスト中に可能な限りアーキテクチャを最小限に抑えます。たとえば、内部ファイアウォールアクセス制御リスト (ACL) が正しく構成されていないのが一般的です。可能であれば、コネクタからすべてのトラフィックを DC およびバックエンドアプリケーションに直接送信します。
コネクタを配置する最適な場所は、ターゲットにできるだけ近い場所です。コネクタをテストするときにインラインに配置されるファイアウォールは、不要な複雑さを増し、調査を長引く可能性があります。
KCD の問題を示す内容いくつかの一般的なエラーは、KCD SSO が失敗していることを示しています。問題の最初の兆候がブラウザーに表示されます。

次の両方のスクリーンショットは、SSO エラーの同じ現象を示しています。アプリケーションへのユーザーアクセスが拒否されています。

トラブルシューティング

KCD の問題のトラブルシューティングは、3 つの段階で行うことができます。 KCD プロセスのこれらの部分を次の順序で確認します。

クライアントの事前認証
委任サービス
ターゲットアプリケーション

クライアントの事前認証

クライアント事前認証 とは、ブラウザーを介してアプリケーションで認証を行う外部ユーザーのことです。 KCD SSO を機能させるには、Microsoft Entra ID に対する事前認証を行う機能が必要です。

最初にクライアントの事前認証をテストし、問題を解決します。事前認証ステージは、KCD または公開されたアプリケーションには関係ありません。 Microsoft Entra ID にサブジェクトアカウントが存在することを確認することで、不一致を簡単に修正できます。アプリケーションが使用できないかブロックされていないことを確認します。通常、ブラウザーでのエラー応答は、原因を説明するのに十分な説明です。

委任サービス

Kerberos 委任サービスは、Kerberos キー配布センター (KDC) から Kerberos サービスチケットを取得するプライベートネットワークコネクタです。アプリユーザーは、チケットを使用してアプリケーションで認証を行います。

クライアントと Azure フロントエンド間の外部通信は、制約付き委任には影響しません。これらの通信により、KCD が動作することだけが保証されます。アプリケーションプロキシサービスには、Kerberos チケットを取得する有効なユーザー ID が与えられます。この ID がないと、KCD は発生できず、SSO は失敗します。

ブラウザーのエラーメッセージは、サインインが失敗する理由に関する有用な情報を提供します。アプリケーションのサインインへの応答で、 TransactionID と Timestamp の値を記録します。この情報は、動作をアプリケーションプロキシイベントログに表示されるイベントに関連付けるのに役立ちます。

Kerberos の制約付き委任構成エラーメッセージを示すスクリーンショット。

イベントログ内の対応するエントリは、イベント ID 13019 または 12027 です。コネクタイベントログを表示するには、 Applications and Services Logs>Microsoft>Microsoft Entra private network>Connector>Admin に移動します。

制約付き委任の問題をトラブルシューティングするには:

アプリケーションアドレスの内部ドメインネームシステム (DNS) で、CNAME レコードではなく A レコードを使用します。
コネクタホストが、ターゲットアカウントのサービスプリンシパル名 (SPN) に委任するアクセス許可で構成されていることを確認します。 [ 任意の認証プロトコルを使用する ] が選択されていることを確認します。詳細については、 SSO の構成に関するページを参照してください。
Microsoft Entra ID に SPN のインスタンスが 1 つだけ存在することを確認します。 1 つの SPN を確認するには、任意のドメインメンバーホストのコマンドプロンプトで、 setspn -xを実行します。
発行された Kerberos トークンの最大サイズを制限するドメインポリシーが適用されていることを確認します。トークンサイズが設定された最大値を超えると、ポリシーによってコネクタがトークンを取得できなくなります。
コネクタホストとドメイン KCD の間の交換をキャプチャするネットワークトレースを実行することは、問題の詳細を取得するための次の最適な手順です。詳細については、 Microsoft Entra アプリケーションプロキシのトラブルシューティングに関するホワイトペーパーを参照してください。

チケットが正常に動作している場合、アプリケーションが 401 エラーを返したために認証に失敗したことを示すイベントがログに表示される可能性があります。このイベントは、ターゲットアプリケーションがチケットを拒否したことを示します。トラブルシューティングの次の段階に進みます。

アプリケーション

ターゲットアプリケーションは、コネクタによって提供される Kerberos チケットを処理します。この段階では、コネクタは、バックエンドへの最初のアプリケーション要求のヘッダーとして Kerberos サービスチケットを含めます。

アプリケーションの問題をトラブルシューティングするには:

アプリケーションにアクセスできることを確認します。 Azure portal で定義されている内部 URL を使用して、コネクタホスト上のブラウザーから直接サインインします。サインインが成功すると、アプリケーションにアクセスできます。
ブラウザーとアプリケーションが認証に Kerberos を使用しているかどうかを確認します。コネクタホストから、Internet Explorer の DevTools ( F12 キーを押す) または Fiddler を使用して、内部 URL を介してアプリケーションにアクセスします。アプリケーションの応答で、Web 承認ヘッダーで "Negotiate" または "Kerberos" を探します。

アプリケーションに対するブラウザーの応答には、 YIIで始まる Kerberos BLOB が含まれています。Kerberos が実行されていることを確認します。これに対し、Microsoft NT LAN Manager (NTLM) からの応答は常に TlRMTVNTUAABで始まります。 Base64 からデコードされると、この応答は NTLM セキュリティサポートプロバイダー (NTLMSSP) を読み取ります。 BLOB が TlRMTVNTUAAB で始まる場合、Kerberos は使用できません。そうでない場合は、Kerberos を使用できる可能性があります。

注

Fiddler を使用する場合は、IIS のアプリケーション構成で拡張保護を一時的に無効にする必要があります。

このスクリーンショットの BLOB は、 TIRMTVNTUAABで始まらない。そのため、この例では Kerberos を使用でき、Kerberos BLOB は YII で始まらないのです。
IIS サイトで、プロバイダーの一覧から NTLM を一時的に削除します。コネクタホスト上の Internet Explorer から直接アプリにアクセスします。 NTLM はプロバイダーの一覧に表示されなくなったため、Kerberos を使用してのみアプリケーションにアクセスできます。アクセスに失敗した場合は、アプリケーションの構成に関する問題が示されます。アプリケーションが Kerberos 認証を処理していません。
Kerberos を使用できない場合は、IIS でアプリケーションの認証設定を確認します。 ネゴシエートが一番上に表示され、NTLM がそのすぐ下にあることを確認します。 Not Negotiate、Kerberos、Negotiate、または PKU2U が表示される場合は、Kerberos が機能している場合にのみ続行します。
Kerberos と NTLM が設定された状態で、ポータルでアプリケーションの事前認証を一時的に無効にします。外部 URL を使用して、ブラウザーでアプリケーションにアクセスしてみてください。認証を求められます。前の手順で使用したのと同じアカウントを使用します。認証とサインインができない場合は、KCD ではなくバックエンドアプリケーションに問題があります。
ポータルで事前認証を再度有効にします。外部 URL を介してアプリケーションに接続を試みることで、Azure 経由で認証します。 SSO が失敗すると、ブラウザーに "禁止" というエラーメッセージが表示され、ログにイベント ID 13022 が表示されます。

Microsoft Entra private network connector can't authenticate the user because the backend server responds to Kerberos authentication attempts with an HTTP 401 error.
IIS アプリケーションを確認します。構成されているアプリケーションプールと SPN が、Microsoft Entra ID で同じアカウントを使用するように構成されていることを確認します。 IIS で、次のスクリーンショットに示すようにフォルダーに移動します。

ID を確認し、このアカウントが SPN で構成されていることを確認します。たとえば、コマンドプロンプトで setspn –q http/spn.contoso.com を実行します。
ポータルで、定義されている SPN をアプリケーション設定と照合します。アプリケーションのアプリプールで、ターゲットの Microsoft Entra アカウントに設定されているのと同じ SPN が使用されていることを確認します。
IIS で、アプリケーションの [構成エディター] オプションを選択します。 system.webServer/security/authentication/windowsAuthentication に移動します。 UseAppPoolCredentials の値が True であることを確認します。

必要に応じて、値を True に変更します。次のコマンドを実行して、キャッシュされたすべての Kerberos チケットをバックエンドサーバーから削除します。
```
Get-WmiObject Win32_LogonSession | Where-Object {$_.AuthenticationPackage -ne 'NTLM'} | ForEach-Object {klist.exe purge -li ([Convert]::ToString($_.LogonId, 16))}
```
カーネルモードが有効になっている場合、Kerberos 操作が向上します。ただし、要求されたサービスのチケットも、マシンアカウントを使用して復号化する必要があります。このアカウントは 、ローカルシステムとも呼ばれます。アプリケーションがファーム内の複数のサーバーでホストされている場合に KCD を中断するには、この値を True に設定します。
もう 1 つのチェックとして、拡張保護を無効にします。一部のテストシナリオでは、特定の構成で KCD が有効になっていると、拡張保護が KCD を壊しました。このような場合、アプリケーションは既定の Web サイトのサブフォルダーとして発行されました。このアプリケーションは、匿名認証専用に構成されています。すべてのダイアログは非アクティブであり、使用可能な選択は行われません。これは、子オブジェクトがアクティブな設定を継承しないことを示唆しています。テストすることをお勧めしますが、可能であれば、この値を 必ず有効 に復元してください。

この追加のチェックにより、発行されたアプリケーションを使用する体制が整います。委任するように構成されたコネクタをさらに生成できます。詳細については、 Microsoft Entra アプリケーションプロキシのトラブルシューティングに関する詳細な技術チュートリアルを参照してください。

それでもアプリケーション認証の問題を解決できない場合は、ポータルで直接サポートチケットを作成します。

その他のシナリオ

Microsoft Entra アプリケーションプロキシは、アプリケーションに要求を送信する前に Kerberos チケットを要求します。一部のアプリケーションでは、この認証方法がサポートされていません。これらのアプリケーションは、より従来の認証手順に対応するように設定されています。最初の要求は匿名です。これにより、アプリケーションは 401 エラーによってサポートされる認証の種類で応答できます。 SSO の Kerberos 制約付き委任に関するページで説明されている手順を完了することで、この種類の Kerberos ネゴシエーションを設定できます。

マルチホップ認証は、アプリケーションが階層化されている場合に一般的に使用されます。レベルには、バックエンドとフロントエンドが含まれます。どちらの層でも認証が必要です。たとえば、SQL Server Reporting Services を使用して階層化されたアプリケーションを作成できます。詳細については、「 Web 登録プロキシページの Kerberos の制約付き委任を構成する方法」を参照してください。

マネージドドメインで KCD を設定する

次の方法で共有