Microsoft Edge (Chromium) を使用した Kerberos の制約のないダブルホップ認証

適用対象: インターネット インフォメーション サービス

はじめに

Kerberos 認証プロトコルに基づく Windows 認証の設定は、特に、IIS と ASP.NET のコンテキストでフロントエンド サイトからバックエンド サービスへの ID の委任などのシナリオに対処する場合に、複雑な作業になる可能性があります。 この記事の手順に従って、認証チケットの委任を設定し、Microsoft Edge バージョン 87 以上などの最新のブラウザーでサービスを使用します。

この記事では、次の図に示すようなアーキテクチャを設定していることを前提としています。

• Workstation-Client1 コンピューターは、プライマリ Web サーバーと同じ Active Directory (Primary-IIS-SRV およびバックエンド Web サーバー (Backend-Web-SRV と呼ばれます) の一部です。
• コンピューター Workstation-Client1 のユーザーは、Windows Active Directory アカウントを使用してコンピューターにログオンします。
• 次に、ブラウザー (Microsoft Edge) を起動し、Web サーバー上にある Web サイト (Primary-IIS-SRV に使用されるエイリアス名) に移動し、Kerberos を使用して統合Windows 認証を使用して認証します。
• Web サーバー上の Web サイトは、認証されたユーザーの資格情報を使用して API-Server ( Backend-Web-SRV のエイリアス) を使用して HTTP 呼び出しを行い、Kerberos 資格情報の委任を使用してユーザーに代わってアプリケーション データを取得します。

次の手順は、このシナリオのトラブルシューティングに役立ちます。セットアップは Internet Explorer で動作しますが、ユーザーが Microsoft Edge を採用すると、資格情報委任機能を使用できなくなります。 Kerberos 資格情報の委任を使用するには、最初に「 Internet Explorer での Kerberos エラーのトラブルシューティング を参照してください。

制約付き委任または制約なし委任

上記のシナリオでは、両方の構成を使用すると、ユーザーは、フロントエンド Web サーバー経由で接続するときに、コンピューター Workstation-Client1 上のユーザー セッションからバックエンド API サーバーに資格情報を委任できます。

制約のない Kerberos 委任構成では、アプリケーション プール ID は Web サーバー上で実行され、Active Directory で任意のサービスへの委任に対して信頼されるように構成されます。 Web サーバー上で実行されているアプリケーション プールのアカウントは、そのサーバーでホストされている Web サイトの認証済みユーザーの資格情報を、Active Directory 内の他のサービスに委任できます。 たとえば、SMTP サーバー、ファイル サーバー、データベース サーバー、別の Web サーバーなどです。これは制約のない委任と呼ばれます。アプリケーション プール アカウントには、接続するサービスに資格情報を委任するアクセス許可 (制約なし) があるためです。

制約付き委任構成では、アプリケーション プール ID として使用される Active Directory アカウントは、委任が承認されたサービスの一覧にのみ、認証済みユーザーの資格情報を委任できます。 Web サーバーと呼ばれるサーバー上に存在する Web アプリケーションもデータベースに接続し、ユーザーに代わって認証する必要がある場合は、このサービス プリンシパル名 (SPN) を承認されたサービスの一覧に追加する必要があります。

制約付き委任は、最小限の特権の原則に基づく制約のない委任よりも安全です。 アプリケーションには、機能するために必要な権限とそれ以上の権限が付与されますが、制約のない委任により、アプリケーションはユーザーに代わって連絡すべきでないリソースに接続できます。

Web サーバーに送信するためにクライアントで取得した Kerberos チケットが制約付き委任または制約なし委任を使用しているかどうかを確認する方法

Windows に存在する klist コマンド ツールを使用して、クライアント コンピューターからの Kerberos チケットのキャッシュを一覧表示します (上の図の Workstation-Client1 )。 Web-Server > の HTTP/<Name という名前のチケットを探します。 注: <Name of Web-Server> は、Kerberos 経由で連絡して認証するサービスの SPN です。 チケットには、いくつかのフラグも含まれています。 そのうちの 2 つ( forwardable と ok_as_delegate)が関心を持っています。

• 最初のフラグ forwardableは、KDC (キー配布センター) が必要に応じて新しいネットワーク マスクを使用して新しいチケットを発行できることを示します。 これにより、ユーザーがリモート システムにログインし、リモート システムがユーザーに代わって新しいチケットを取得して、ユーザーがリモート システムにローカルでログインしたかのように別のバックエンド システムにログインできるようになります。

• 2 番目のフラグ ok_as_delegate は、ユーザーが認証しようとしているサービスのサービス アカウント (上の図の場合、Web アプリケーションをホストしている IIS アプリケーション プールのアプリケーション プール アカウント) が、制約のない委任に対して信頼されていることを示します。

これらのサービスが制約のない委任を使用している場合、クライアント コンピューター上のチケットには ok_as_delegate フラグと forwardable フラグが含まれます。 ほとんどの場合、制約付き委任が構成されている場合、チケットには ok_as_delegate フラグは含まれず、 forwardable フラグが含まれます。

制約のない委任が Internet Explorer で機能し、Microsoft Edge では機能しないのはなぜですか?

Kerberos ベースの認証を使用して Web サイトに対する認証が試行されると、ブラウザーは Windows API を呼び出して認証コンテキストを設定します。 問題の API は InitializeSecurityContext。 この API は、ブラウザーがユーザーが受け取った delegatable チケットを許可するかどうかを示す一連のフラグを受け取る場合があります。 ユーザーが認証しようとしているサービスに制約のない方法で資格情報を委任する権限があるため、チケットは delegatable としてマークされます。 ただし、これは、アプリケーションが認証しようとしている (この場合はブラウザー) がこの容量を使用する必要があることを意味するわけではありません。

既定では、Internet Explorer はフラグを InitializeSecurityContextに渡し、チケットを委任できる場合はそのフラグを渡す必要があることを示します。 バージョン 87 以降の Microsoft Edge では、チケットが ok_as_delegate フラグでマークされているため、フラグはInitializeSecurityContextに渡されません。 アプリケーションで制約のない委任を使用することは、アプリケーションに必要以上の特権を与えるため、お勧めしません。 アプリケーションは、ドメイン上の他のサービスにユーザーの ID を委任し、ユーザーとして認証することができます。これは、資格情報の委任を使用するほとんどのアプリケーションでは必要ありません。 アプリケーションは、制約付き委任を設定するときに指定された一覧のサービスにのみ接続する必要があります。

既定では、Microsoft Edge は制約付き委任で動作します。Web サーバー上で実行されている IIS Web サイトは、次に示す Active Directory のアプリケーション プール ID アカウント構成に示すように、API-Server でホストされているバックエンド API サイトにのみ接続する権限を持ちます。

Edge-Chromium が Active Directory で制約のない委任を操作できるようにする

互換性のために、Kerberos による制約のない委任を使用してアプリケーションを維持する必要がある場合は、Microsoft Edge でチケットの委任を許可します。 以下の手順については、この記事の以下のセクションで詳しく説明します。

1. グループ ポリシーの中央ストアの管理用テンプレートを Active Directory にインストールします (まだ存在しない場合)。。
2. Microsoft Edge 管理用テンプレートをインストールします。
3. 新しいグループ ポリシー オブジェクトを作成します。
4. グループ ポリシーの構成を編集して、サーバーへの認証時に制約のない委任を許可します。
5. (省略可能)Microsoft Edge で正しい委任フラグが使用されているかどうかを確認します。

手順 1: Active Directory 用の管理用テンプレートをインストールする

1. Administrative Templates (.admx) (Windows Server 2019 の場合) からテンプレートをダウンロードします。

2. インストーラーをダウンロードし、選択したフォルダーに内容を抽出します。 パッケージの既定の指定された場所 ( C:\Program Files (x86)\Microsoft Group Policy\Windows 10 October 2018 Update (1809) v2\PolicyDefinitions に展開するだけです。

3. パッケージが解凍されたら、ドメイン コントローラーの Sysvol フォルダーを見つけます。 フォルダーへのパスは C:\Windows\SYSVOL\sysvol\です。 Sysvol フォルダー内には、Active Directory 名と同じ名前のフォルダーがあります (このサンプルでは、Oddessy.local)。 そこから、 Policies フォルダーに移動します。 存在しない場合は、次に示すように、 Policy Definitions という名前のフォルダーを作成します。

   

4. ドメイン コントローラーの sysvol フォルダー内のドメイン内で作成した PolicyDefinitions フォルダー (インストーラーから抽出されたPolicyDefinitions フォルダー) の内容をコピーします。

   Note

   インストーラーによって抽出されたファイルには、ローカライズされたコンテンツも含まれています。 領域を節約するには、目的の言語に対してのみローカライズされたファイルを転送します。 たとえば、fr-FR という名前のフォルダーには、フランス語でローカライズされたすべてのコンテンツが含まれています。

5. 転送が完了したら、テンプレートが Active Directory で使用可能であることを確認します。 これを行うには、Microsoft 管理コンソールの Group Policy Management スナップインを開きます (Windows キーを押しながら R キーを押し、「 gpmc.msc 」と入力して起動します)。 グループ ポリシー管理内で、グループ ポリシー オブジェクトを見つけて編集します。

   

   上のスクリーンショットに示すように、 Computer Configuration ノードの下には、 Policies ノードと Administrative テンプレート ノードがあります。

手順 2: Microsoft Edge 管理用テンプレートをインストールする

ドメイン コントローラーに Policy 管理用テンプレート を使用できますが、このブラウザーを使用して制約のない二重ホップ委任を有効にするためのポリシーにアクセスするには、Microsoft Edge ポリシー ファイルをインストールする必要があります。 Microsoft Edge Policy ファイルをインストールするには、次の手順に従います。

1. Microsoft Edge for ビジネスのダウンロード サイトに移動します。

2. channel/version ドロップダウンからダウンロードするバージョンを選択します。 最新の安定バージョンをお勧めします。

3. build ドロップダウンから目的のビルドを選択し、最後に platform ドロップダウンからターゲット オペレーティング システムを選択します。 選択が完了すると、さらに 2 つのボタン (ボタンとリンク) が表示されます。

   

4. [ポリシー ファイル GET] をクリックし 使用許諾契約書に同意して、 MicrosoftEdgePolicyTemplates.cabというファイルをダウンロードします。 このファイルには、Microsoft Edge のポリシー定義ファイルが含まれています。

5. ファイルをダブルクリックしてコンテンツ (同じ名前の zip アーカイブ) を探索します。

6. zip アーカイブの内容をローカル ディスク上のフォルダーに抽出します。 抽出されたコンテンツには、 Windows という名前のフォルダー Admxという名前のサブフォルダーが含まれます。 これには、管理用テンプレートとローカライズされたバージョンが含まれます (英語以外の言語で必要です)。

   

7. .admxファイルを、前の例の Administrative Templates が転送された Sysvol ディレクトリの下の同じフォルダー内に転送します (上の例: C:\Windows\SYSVOL\sysvol\sysvol\sysvol\proxyy.local\Policies\PolicyDefinitions)。

8. Active Directory グループ ポリシー エディターを開き、編集用の既存のグループ ポリシー オブジェクトを選択して、新しく転送された Microsoft Edge テンプレートの存在を確認します。 これらは、ツリー ビューの Administrative Templates フォルダーの下にある Microsoft Edge という名前のフォルダーにあります。

   

手順 3: 新しいグループ ポリシー オブジェクトを作成する

Active Directory グループ ポリシー マネージャー MMC スナップインを使用して新しいグループ ポリシー オブジェクトを作成する方法を次に示します。

1. Windows + R キーを押して、ドメイン コントローラーの Run メニューを開きます。
2. 「 Gpmc.msc を入力して Microsoft 管理コンソールを開き、Active Directory グループ ポリシー マネージャー スナップインを読み込みます。
3. コンソールのツリー ビューで Group ポリシー オブジェクト ノードを見つけ、ノードを右クリックしてコンテキスト メニューを開きます。
4. [New メニュー項目を選択し、作成するグループ ポリシーの名前を入力して、[OK] をクリック。

手順 4: サーバーへの認証時に制約のない委任を許可するようにグループ ポリシーの構成を編集する

最後の手順では、Windows 統合対応 Web サイトに対して Kerberos を使用して認証を実行するときに、Microsoft Edge ブラウザーが ok_as_delegate フラグを InitializeSecurityContext api 呼び出しに渡せるようにするポリシーを有効にします。 Microsoft Edge ブラウザーが Kerberos を使用して認証を行っている (NTLM ではない) かどうかがわからない場合は、「Internet Explorer で Kerberos のエラーを解決するを参照してください。

Active Directory グループ ポリシー エディターで、Active Directory 内のコンピューターに適用されるグループ ポリシー オブジェクトを選択します。このオブジェクトから、エンド ユーザーが Kerberos 認証を使用して認証を行い、制約のない委任によってバックエンド サービスに資格情報が委任されます。 Microsoft Edge からの制約のない委任を有効にするポリシーは、次に示すように、Microsoft Edge テンプレートの Http authentication フォルダーにあります。

Kerberos チケットの委任を許可するサーバーの一覧を構成するには、この設定を使用します。

新しく編集したグループ ポリシー オブジェクトがドメイン内のクライアント コンピューターに適用されたら、Windows 統合認証のトラブルシューティング用の Diagnostic ページのテスト認証ページに移動し GitHub の ASP.net Samples Repository から whoami.aspx ページをダウンロードします。 これにより、資格情報の委任が許可されたことを通知する Impersonate の代わりに、ImpersonationLevel の Delegate の設定が生成されます。

クライアント ワークステーションでポリシーが正しく適用されたかどうかをテストするには、新しい Microsoft Edge タブを開き、「 edge://policy」と入力します。

AuthNegotiateDelegateAllowlist ポリシーは、Microsoft Edge が Kerberos チケットの委任を実行できるサーバー名の値を示すように設定する必要があります。 ポリシーが一覧に表示されない場合、ポリシーは展開されていないか、間違ったコンピューターに展開されています。

手順 5 (省略可能): Microsoft Edge が正しい委任フラグを使用しているかどうかを確認する

トラブルシューティング/オプションのチェック手順を次に示します。

ポリシーを構成して展開したら、次の手順を実行して、Microsoft Edge が正しい委任フラグを IntializeSecurityContextに渡しているかどうかを確認する必要があります。 この手順では、Microsoft Edge に既に組み込まれているツール、またはオンライン サービスとして使用できるツールを使用します。

1. Web サイトを要求するときにブラウザーが実行している操作をログに記録するには、Microsoft Edge で使用できるログ機能を使用します。 ログを有効にするには、次の手順を行います。

   1. 新しい Microsoft Edge ウィンドウを開き、「 edge://net-export/」と入力します。

   2. トレースする場合は、 Cookie と資格情報 オプションを使用します。 このオプションがないと、認証トレース レベルのデータは省略されます。

      

   3. [ディスクへのログ記録の開始] ボタンをクリックし、トレースを保存するファイル名を指定します。

   4. 別の [Microsoft Edge] タブを開き、Microsoft Edge を使用して統合Windows 認証を実行する Web サイトに移動します。

   5. 認証を試みた後、トレースが有効になっている前のタブに戻り、 [ログ記録 ] ボタンをクリックします。 トレース インターフェイスは、トレースを含むファイルの書き込み先を示します。

2. トレースを含む JSON ファイルを使用して、認証を試みるときにブラウザーが InitializeSecurityContext 関数に渡したパラメーターを確認します。 トレースを分析するには、 netlog_viewerを使用します。

3. 解析されたトレース内には、次のようなイベント ログがあります。

   t=3076 [st=12]       +AUTH_LIBRARY_INIT_SEC_CTX  [dt=3]
                         --> flags = {"delegated":false,"mutual":false,"value":"0x00000000"}
                         --> spn = "HTTP/web-server.odessy.local"
   

   このログには、次のことが示されています。

   • AUTH_LIBRARY_INIT_SEC_CTX は、ブラウザーで InitializeSecurityContext 関数が呼び出されていることを意味します。
   • "delegated":false は、チケットが delegatableとしてマークされている場合でも、チケットを委任してはならないことを意味します。
   • "mutual":false は、クライアント (ブラウザー) は、サーバーがクライアントに対しても認証を行い、その ID を証明する必要はないことを意味します。 クライアントのみが、その ID を証明するためにサーバーに対して認証する必要があります。
   • HTTP/web-server.odessy.local は、認証呼び出しを行うときにブラウザーによって使用される SPN です。

詳細

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