次の方法で共有

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

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

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

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

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

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

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

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

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

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

この 2 つのページは、 ASP.NET Web フォームでコーディングされています。 これらは、コンパイルやデプロイを必要とせずに、トラブルシューティングを行おうとしている 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 アプリケーションにアクセスするために使用される認証方法を決定することです。 この場合、以前にサイトに展開した WhoAmI.aspx ページに要求を行うことができます。

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

  • Negotiate が Windows 統合認証のプロバイダーとして使用されるシナリオでの後続の要求では、認証の種類の横に Session Based ラベルのみが表示されます。 詳細については、「 Request ベースとセッション ベースの 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 ページにアクセスするために使用される場合)。

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

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

詳細

Kerberos を使用した Windows 統合認証のセットアップの詳細については、次を参照してください。