Windows 統合認証のトラブルシューティングの診断ページ

  • [アーティクル]

特に Kerberos 資格情報の委任を処理する場合、Windows 統合認証の失敗シナリオのトラブルシューティングは困難な場合があります。 インターネット インフォメーション サービス (IIS) が Windows 統合認証と連携し、必要に応じて資格情報の委任を使用するための正しい構成があることを確認する方法の詳細な チェックリスト がありますが、この記事では、具体的には次のシナリオを対象としています。

  • クライアント コンピューターからターゲット Web サイトにサインインできますが、認証メカニズムとして NTLM と Kerberos のどちらを使用しているかは不明です。
  • 対象の Web サイトにサインインできますが、ユーザー名とパスワードの組み合わせを入力した後にのみサインインするように求められます。
  • フロントエンド サーバーでターゲット Web サイトにアクセスできますが、フロントエンド サーバーが認証されたユーザーの資格情報を使用してバックエンド HTTP エンドポイントを呼び出す必要があるアクションを開始すると失敗します。

この記事では、次のレイアウトを検討してください。

  • クライアント 1 は、仮想ユーザーがすべての接続試行を開始するドメイン参加ワークステーションまたはノート PC です。

  • Web-serv1 は、Windows 統合認証を使用し、サービス アカウント domain\serviceaccount の ID を使用して実行される ASP.NET (.NET Framework) Web サイトをホストするフロントエンド IIS サーバーです。

  • Web-serv2 は、フロントエンド アプリケーションの API エンドポイントを公開する ASP.NET (.NET Framework) サイトもホストするバックエンド Web サーバーです。 また、Windows 統合認証を使用し、 domain\serviceapiaccount をアプリケーション プール ID として使用するアプリケーション プールで実行する要求を許可するように構成されています。

ワークステーション、Web-serv1、および Web-serv2 のレイアウトを示すスクリーンショット。

これらのシナリオのデータ収集を容易にし、Fiddler や WireShark などの外部データ収集ツールに依存しないようにするには (3 台のコンピューター間の接続では HTTPS が使用され、そのため、それらの間のすべての交換が暗号化されるため)、 IIS の Windows 統合認証の問題をトラブルシューティングするための自己完結型ページ ASP.NET の 2 つの自己完結型診断ページを使用します。

ページのトラブルシューティング

2 つのページは、ASP.NET Web Formsでコード化されます。 これらは、コンパイルや展開を必要とせずに、トラブルシューティングしようとしている Web アプリケーションのルートにコピーできる 1 つのファイルに、ページのコードとマークアップをバンドルすることを目的としています。 ページは次のとおりです。

  • WhoAmI.aspx - このページでは、次のような認証関連情報をダンプできます。

    • ターゲット サイトへのアクセスに使用される認証方法。 メソッドが Windows 統合認証のネゴシエート プロバイダーに基づいている場合は、Kerberos または NTLM を使用してユーザーを認証するかどうかを示すページが表示されます。

    • サイトをホストするアプリケーション プールを実行するアカウントの ID。

    • 認証されたユーザーの 偽装 レベル。 認証に Kerberos が使用され、制約のない資格情報の委任が許可されている場合、偽装レベルはデリゲートとしてマークされます。 存在しない場合は、制約付き委任または単純な偽装の場合、偽装としてマークされます。

    • 認証されたユーザーとユーザーが属するグループの ID。

    • ページのコードを実行しているアカウントの ID ( 偽装 設定に応じて、認証されたユーザーまたはアプリケーション プール ユーザーを指定できます)。

    • IIS サーバー変数から回復されたWhoAmI.aspx ページに入ってくる要求の要求ヘッダーのすべての値。

      認証情報と ID を含む Who Am I ページを示すスクリーンショット。

  • ScrapperTest.aspx - このページは WhoAmI.aspx ページで動作するように作成され、フロントエンド サーバーからの要求をバックエンド サーバー上の任意の URL に送信できます。 ページには、ユーザーが次の操作を可能にする UI インターフェイスが表示されます。

    • ページが読み込もうとするバックエンド サーバー リソースの目的の URL を入力します。

    • ScrapperTest.aspx ページの読み込み時に認証されているかどうかを確認し、認証された場合は、認証対象のユーザーを決定します。

    • ユーザーが実際に認証されるシナリオでは、URL テキスト ボックスに示されているバックエンド リソースを読み込もうとするときに、チェック ボックスをオンにしてユーザーの資格情報を再利用できます。

      [ScrapperTest] ページを示すスクリーンショット。

デプロイ方法

どちらのページも自己完結型であるため、必要なのは次のとおりです。

  1. GitHub リポジトリからページをダウンロードします。
  2. WhoAmI.aspx ページまたは両方のページを、IIS 内で実行されているターゲット Web アプリケーションのルートにコピーします。
  3. アクセスするページに応じて、 /WhoAmI.aspx または /ScrapperTest.aspx を追加するサイトの URL に要求を行います。

使用方法

最初の使用シナリオは、IIS でホストされている特定の Web サイトまたは Web アプリケーションにアクセスするために使用される認証方法を決定することです。 この 1 つでは、以前にサイトに展開した WhoAmI.aspx ページに要求を行うことができます。

  • 最初の要求では、ページに認証情報が表示されます。 Windows 統合認証のネゴシエート プロバイダーが使用されている場合は、使用される認証プロトコル (Kerberos または NTLM) も一覧表示されます。

  • Windows 統合認証のプロバイダーとしてネゴシエートが使用されるシナリオでの後続の要求では、認証の種類の横に [セッション ベース ] ラベルのみが表示されます。 詳細については、「 要求ベースとセッション ベースの Kerberos 認証 (または AuthPersistNonNTLM パラメーター)」を参照してください。

  • アプリケーション プール ユーザー、認証済みユーザー、実行ユーザーの詳細、受信要求のヘッダーなど、他のすべての認証情報が各要求に表示されます。

WhoAmI.aspx ページの下部には小さなフォームも表示されます。 このフォームを使用すると、サーバーに要求を発行 POST して、これらの種類の要求を発行するときのブラウザーの動作をテストできます。 ページが 60 秒を超えてアイドル状態の場合、ページをブラウザーにダウンロードするために使用され、サーバーによって認証された伝送制御プロトコル (TCP) 接続は、非アクティブのため切断されます。 そのため、要求を行 POST うと、新しい TCP 接続が開き、再認証が必要になります。 要求には微妙な要素 POST があります。

  1. ブラウザーは最初に HTTP POST 要求ヘッダーを送信します。
  2. 次に、ページに表示される HTTP フォームのさまざまな入力フィールドからキャプチャされた情報を含む要求の本文 POST を発行します。

要求のヘッダーを送信 POST した後にブラウザーが待機せず、代わりに認証されていない接続で本文を直接送信する場合は、次の問題が発生する可能性があります。

  • サーバーは要求ヘッダーを POST 受け取り、接続が認証されていないため (Windows 統合認証または別のチャレンジ ベースの認証が使用されていると仮定)、適切な認証応答 HTTP ヘッダー (WWW-Authenticate) で 401 応答を発行します。
  • この間、ブラウザーは、サーバーから 401 応答を受信する前に、要求本文を既に送信 POST しています。
  • その後、サーバーは、認証が POST 必要であることをクライアントに以前に示した接続で、認証されていない要求本文を受け取ります。
  • これにより、サーバーによって基になる TCP 接続が切断され、ブラウザーで "Web ページが使用できません" というメッセージが表示される可能性があります。

ScrapperTest.aspx ページは、フロントエンド サーバーからバックエンド サーバー エンドポイントへの資格情報シナリオの委任をテストするために使用されます。 クライアント ブラウザーからページが要求されると、次のことが可能な UI が提供されます。

  • フロントエンド サーバーが接続するバックエンド エンドポイント URL を入力します。
  • ユーザーがフロントエンドで認証されていることと、フロントエンド サーバーへの接続に使用されるユーザー名を確認する。
  • 認証されたユーザーの資格情報をバックエンド サーバーに渡す必要があるかどうか (認証が ScrapperTest.aspx ページにアクセスするために使用される場合) の決定 (偽装と委任が可能な場合)。

[ スクラップ ページ ] ボタンを選択すると、 ScrapperTest.aspx ページのコードによって、指定されたターゲット URL に対する要求が発行 GET されます。 [ 資格情報の使用 ] チェック ボックスをオンにし、指定されたバックエンド エンドポイントにアクセスするために認証が必要な場合は、認証されたユーザーの資格情報も使用して要求を行います。 要求が成功した場合、結果は、受信した応答の生の HTTP 出力としてページのテキスト領域コントロールに表示されます。

想定される使用シナリオは、バックエンド サーバーで接続される ASP.NET アプリケーション内に ScrapperTest.aspx ページと WhoAmI.aspx ページを配置することです。 したがって、 ScrapperTest.aspx ページによって回復された HTTP 応答は、バックエンドで実行されたときに 、WhoAmI.aspx ページの HTML 出力になります。 その後、この出力を評価して、バックエンドで要求がどのように認証され、どのアカウントが使用されたかを理解できます。

詳細

Kerberos を使用した Windows 統合認証のセットアップについて詳しくは、以下をご覧ください。