Microsoft Entra アプリケーションプロキシを使う Kerberos の制約付き委任 (KCD) 構成のトラブルシューティング

[アーティクル]
03/05/2024

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

この記事では、最も一般的な問題をトラブルシューティングするための 1 つの参照ポイントを提供します。より複雑な実装の問題の診断についても説明します。

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

Microsoft Entra アプリケーションプロキシのデプロイと、KCD 以外のアプリケーションへの一般的なアクセス。詳細については、アプリケーションプロキシの概要に関する記事を参照してください。
公開されたアプリケーションがインターネットインフォメーションサービス (IIS) と Microsoft による Kerberos の実装に基づいている。
サーバーとアプリケーションのホストが単一の Microsoft Entra ドメインに存在する。クロスドメインとフォレストのシナリオの詳細については、KCD のホワイトペーパーを参照してください。
アプリケーションは、事前認証が有効な Microsoft Entra ID テナントで公開されている。ユーザーは、フォームベースの認証を使って認証をうけることが想定されています。リッチクライアントの認証シナリオは、この記事で説明していません。

前提条件

単純な構成の不備や一般的なミスが、ほとんどの問題を発生させます。トラブルシューティングの前に、アプリケーションプロキシでの KCD シングルサインオンの使用のページですべての前提条件を確認してください。

コネクタのホストは、特定のローカルサイトドメインコントローラー (DC) と通信を持つことに制限はありません。これは変更される可能性があるので、お使いの DC を確認してください。

上記の点と同様、クロスドメインのシナリオでは、参照によってローカルネットワークの境界外に存在する DC にコネクタホストが　誘導される場合があります。これらの場合、他のそれぞれのドメインを代表する DC に、トラフィックを送信させることが、同じように重要です。そうでないと、委任が失敗となります。

コネクタホストと DC の間にはアクティブな侵入防止システム (IPS) または侵入検出システム (IDS) デバイスを使わないでください。このようなデバイスは侵入的すぎるため、コアリモートプロシージャコール (RPC) トラフィックに干渉します。

単純なシナリオにおける委任をテスト。一般に、不確定要素が多いほど、取り組むべき問題も多くなります。時間を節約するには、テストを 1 つのコネクタに制限します。問題が解決してからコネクタを追加してください。

いくつかの環境的要因が、問題の原因となる可能性もあります。これらの要因を回避するのには、テスト中に、できるだけアーキテクチャを最小限に抑えます。たとえば、内部ファイアウォールのアクセス制御リスト (ACL) が正しく構成されていないことがよくあります。可能であれば、すべてのトラフィックを、,コネクタから、直接的に、 DC とバックエンドアプリケーションに送信します。

実際、コネクタは、そのターゲットにできるだけ近づけて配置するのが鉄則です。テストするときに、インラインに存在するファイアウォールは、不必要に複雑を追加し、調査を長引かせることがあります。

何が、KCD 問題を示していますか？ KCD シングルサインオンが失敗していることを示す一般的な兆候がいくつかあります。ブラウザーに、問題が発生した最初の兆候が表示されます。

$正しくない K C D 構成エラーの例を示すスクリーンショット。[Incorrect Kerberos constrained delegation]$Kerberos の制約付き委任が正しくありません$ というエラーが強調表示されています。$

例:権限がないために承認に失敗

どちらの画像も、シングルサインオンの失敗という同じ症状を示しています。アプリケーションへのユーザーアクセスが拒否されました。

トラブルシューティング

トラブルシューティングを 3 つの段階に分けます。

クライアントの事前認証

外部ユーザーはブラウザー経由で認証を行います。 KCD シングルサインオン (SSO) が機能するには、Microsoft Entra ID に対する事前認証機能が必要です。問題がある場合は、テストしてこの問題に対処する必要があります。事前認証段階は、KCD や公開されたアプリケーションとは無関係です。対象のアカウントが Microsoft Entra ID に存在することを確認することで、不具合を簡単に修正できます。アプリケーションが無効化またはブロックされていないことを確認します。通常、ブラウザーに返されたエラー応答を見れば、原因を把握することができます。

委任サービス

ユーザーから、Kerberos キー配布センター (KCD) からユーザーのために、Kerberos サービスチケットを取得するプライベートネットワークコネクタです。

クライアントと Azure フロントエンドとの間の外部通信は、KCD の働きに負荷をかけるものではありません。これらの通信は、KCD が動作することのみを確認します。アプリケーションプロキシサービスには有効なユーザー ID が提供され、それが Kerberos チケットの取得に使われます。この ID を持たないと、 KCD は不可能であり、失敗します。

ブラウザーのエラーメッセージは、失敗する理由についての良い手掛かりになります。応答の activity ID と timestamp の各フィールドをメモしてください。この情報は、動作をアプリケーションプロキシイベントログ内の実際のイベントと関連付けるために役立ちます。

例:KCD の正しくない構成によるエラー

また、イベントログ内に見られる、該当するエントリが、イベント 13019 またはイベント 12027 として記録されます。 [アプリケーションとサービスログ]>[Microsoft]>[Microsoft Entra プライベートネットワーク]>[Connector]>[Admin] でコネクタのイベントログを見つけます。

アプリケーションのアドレスには、CName ではなく、内部ドメインネームシステム (DNS) の A レコードを使います。
指定されたターゲットアカウントのサービスプリンシパル名 (SPN) に委任する権限がコネクタホストにあることをもう一度確認します。再確認任意の認証プロトコルを使用するが選択されていることを確認します。このトピックの詳細については、SSO 構成に関する記事を参照してください。
Microsoft Entra ID で、SPN の 1 つだけのインスタンスがあることを確認します。 setspn -x任意のドメインのメンバーホストのコマンドプロンプトからの発行です。
発行済みの Kerberos トークンの最大サイズを制限するようにドメインポリシーが強化されていることを確認します。コネクタによるトークンの取得が過剰になると、このポリシーによって停止されます。

問題についてさらに詳しい情報を得る手順として次にお勧めするのは、コネクタホストとドメイン Kerberos の制約付き委任 (KDC) 間のやり取りを取り込むネットワークトレースです。詳細については、トラブルシューティングについて詳しく解説したホワイトペーパーを参照してください。

チケットの発行に問題がなさそうなら、アプリケーションから 401 が返されたために認証に失敗した、という内容のイベントをログで確認します。このイベントは、対象のアプリケーションに、チケットが拒否されたことを示します。次の段階へ移動します。

ターゲットアプリケーション

コネクタから提供された Kerberos チケットのコンシューマーです。この段階で、コネクタからバックエンドに Kerberos サービスチケットが送信されることが予想されます。このチケットは、最初のアプリケーション要求のヘッダーです。

ポータルで定義されたアプリケーション内の URL を使用して、コネクタホストのブラウザからアプリケーションに直接アクセスできることを認証します。その後、首尾良くサインインできます。詳細は、コネクタのトラブルシューティングのページをご覧ください。
ブラウザーとアプリケーション間の認証に Kerberos が使われていることを確認します。
Internet Explorer で DevTools を働かせるか (F12)、またはコネクタホストから、 Fiddler を使用します。内部 URL を使用して、アプリケーションに移動します。ネゴシエートまたは Kerberos が存在することを確認するには、アプリケーションからの応答で返された、提供された Web 認可ヘッダーを調べます。
- ブラウザからアプリケーションへの応答で返される、次の Kerberos blobは、YIIで開始します。これらの文字は、Kerberos が実行されていることを確認します。一方、Micrisod NT LAN Manager（NTLM）は、いつもTlRMTVNTUAAB で始まります。これは、Base64 からデコードされるときにNTLM Security Support Provider (NTLMSSP) を読みます。 BLOB の先頭に TlRMTVNTUAAB がある場合、Kerberos は使用できません。 TlRMTVNTUAAB を見なければ、Kerberos は利用できる可能性があります。
  
  注意
  
  Fiddler を使用する場合、この方法を利用するには、IIS のアプリケーション構成で拡張保護を一時的に無効化する必要があります。
- この図では、blob の先頭が TIRMTVNTUAAB で始まっていません。この例では Kerberos が使用可能であり、および Kerberos blob はYII で始まりません。
IIS サイトのプロバイダーリストから、NTLM を一時的に削除します。コネクタのホスト上で Internet Explorer から直接アプリにアクセスします。 NTLM は、プロバイダーの一覧上から、なくなりました。 Kerberos をのみを使用してアプリケーションにアクセスすることができます。アクセスに失敗した場合、アプリケーションの構成の問題である可能性があります。 Kerberos 認証が機能していません。
- Kerberos を使用できない場合は、IIS でアプリケーションの認証設定を確認します。 Negotiate がリストの最上部にあり、そのすぐ下に NTLM があることを確認します。 Not Negotiateが表示される場合、 Kerberos またはネゴシエート、または PKU2U は、 Kerberos が機能するときのみ、存続します。
- Kerberos と NTLM を導入したら、ポータルでアプリケーションの事前認証を一時的に無効にします。インターネットから外部 URL を使って、アプリケーションにアクセスできるかどうかを確認します。認証情報が求められます。前の手順で使用されるのと同じアカウントで、これを行うことができます。それ以外の場合は、KCD はなく、バックエンドアプリケーションに問題があります。
- ポータルで事前認証を再度有効にします。その外部 URL を介して、アプリケーションに接続を試みることで、Azure による認証を行います。 SSO が失敗した場合、アクセス不可のエラーメッセージがブラウザーに表示され、ログにはイベント 13022 が記録されます：
  
  "バックエンドサーバーが Kerberos 認証試行に対して HTTP 401 エラーを返すため、Microsoft Entra プライベートネットワークコネクタはユーザーを認証できません。"
- IIS アプリケーションをチェックします。構成済みのアプリケーションプールと SPN が、Microsoft Entra ID で同じアカウントを使用するように構成されていることを確認します。次の図に示すように、IIS に移動します。
  
  Id を確認した後は、このアカウントが、問題のSPN と構成されていることを確認します。たとえば setspn –q http/spn.wacketywack.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 を中断します。こような場合、アプリケーションは、既定の web サイトのサブフォルダーとして発行されました。このアプリケーションは、匿名認証のためのみに、構成されます。すべてのダイアログボックスは淡色表示され、子オブジェクは、アクティブな設定を継承しないことを提案します。テストするが、可能な限り、この値が有効になっているように復元することを忘れないように推奨いたします。

この追加のチェックにより、公開されたアプリケーションを使用できるようになります。委任するように構成されたコネクタをさらに増やすことができます。詳細については、より詳細な技術ウォークスルーか、Microsoft Entra アプリケーションプロキシのトラブルシューティングをご覧ください。

より進化させることはできませんが、Microsoft がサポート致します。ポータル内で直接サポートチケットを作成します。

その他のシナリオ

Microsoft Entra アプリケーションプロキシは、Kerberos チケットを要求したうえで、その要求をアプリケーションに送信します。この認証方法を受け付けないアプリケーションもあります。これらのアプリケーションは、より従来のネゴシエーションを実行することが予想されます。最初の要求は、匿名です。401 を介して、サポートするタイプの認証で応答することを、アプリケーションに許可します。この種類の Kerberos ネゴシエーションは、このドキュメントに記載されている手順に従って有効にすることができます。シングルサインオンでの Kerberos の制約付き委任.

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

次のステップ

管理されたドメインで OU を作成する。

Microsoft Entra アプリケーション プロキシを使う Kerberos の制約付き委任 (KCD) 構成のトラブルシューティング