ユーザー証明書認証用に AD FS のサポートを構成する

この記事では、Active Directory フェデレーション サービス (AD FS) でユーザー証明書認証を有効にする方法について説明します。 また、この種類の認証に関する一般的な問題のトラブルシューティング情報も提供します。

ユーザー証明書認証には、主に 2 つの使用例があります。

• ユーザーはスマート カードを使用して AD FS システムにサインインしています。
• ユーザーはモバイル デバイスに対してプロビジョニングされた証明書を使用しています。

前提条件

• 「証明書認証のための代替ホスト名バインディングの AD FS サポート」で説明されているモードのいずれかを使用して、有効にする AD FS ユーザー証明書認証のモードを決定します。
• ユーザー証明書の信頼チェーンがインストールされ、中間認証局を含むすべての AD FS および Web アプリケーション プロキシ (WAP) サーバーによって信頼されていることを確認します。 通常、これは AD FS サーバーおよび WAP サーバー上のグループ ポリシー オブジェクト (GPO) を介して行います。
• ユーザー証明書の信頼チェーンのルート証明書が、Active Directory の NTAuth ストア内にあることを確認します。
• AD FS を代替証明書認証モードで使用している場合は、AD FS サーバーと WAP サーバーに、"certauth" というプレフィックスが付いた AD FS ホスト名を含む Secure Sockets Layer (SSL) 証明書があることを確認してください。例としては、certauth.fs.contoso.com があります。 また、このホスト名へのトラフィックがファイアウォールを通過できることを確認します。
• エクストラネットからの証明書認証を使用している場合は、証明書で指定されたリストにある少なくとも 1 つの機関情報アクセス (AIA) と少なくとも 1 つの CRL 配布ポイント (CDP) またはオンライン証明書ステータス プロトコル (OCSP) の場所がインターネットからアクセスできることを確認してください。
• Microsoft Entra 証明書認証用に AD FS を構成する場合は、証明書の発行者とシリアル番号に必要な Microsoft Entra 設定と AD FS 要求ルールが構成済みであることを確認します。
• Exchange ActiveSync クライアントで Microsoft Entra 証明書認証を使用している場合、クライアント証明書には、[サブジェクトの別名] フィールドの [プリンシパル名] の値または [RFC822 名] の値のいずれかに、Exchange Online でルーティング可能なユーザーのメール アドレスが含まれている必要があります。 Microsoft Entra ID は、ディレクトリ内のプロキシ アドレス属性に RFC822 の値をマップします。

ユーザー証明書認証を有効にする

AD FS 管理コンソールまたは PowerShell コマンドレット Set-AdfsGlobalAuthenticationPolicy を使用して、イントラネットまたはエクストラネットの認証方法としてのユーザー証明書認証を、AD FS で有効にします。

オプションの考慮事項には次のようなものがあります。

• EKU 要求の種類 https://schemas.microsoft.com/2012/12/certificatecontext/extension/eku に加えて、証明書フィールドと拡張子に基づくクレームを使用する場合は、Active Directory 要求プロバイダーの信頼でさらに多くの要求パススルー ルールを構成します。 使用可能な証明書要求の完全な一覧については、この記事で後ほど説明します。

• 証明書の種類に基づいてアクセスを制限する必要がある場合は、アプリケーションの AD FS 発行承認規則で、証明書の追加のプロパティを使用できます。 一般的なシナリオでは、モバイル デバイス管理 (MDM) プロバイダーによってプロビジョニングされた証明書のみを許可するか、スマート カード証明書のみを許可します。

  重要

  認証にデバイス コード フローを使用し、Microsoft Entra ID 以外の ID プロバイダー (AD FS など) を使用してデバイス認証を実行するお客様は、Microsoft Entra リソースに対してデバイスベースのアクセスを実施できません。 たとえば、サードパーティの MDM サービスを使用してマネージド デバイスのみを許可することはできません。

  Microsoft Entra ID の企業リソースへのアクセスを保護し、データ漏洩を防止することができるようにするには、Microsoft Entra のデバイス ベース条件付きアクセスを構成します。 たとえば、Microsoft Entra 条件付きアクセスで制御を許可するには、[デバイスに苦情のマークを付けるように要求する] を使用します。

  Schannel SSP の技術概要の「クライアント認証のための信頼できる発行者の管理」のガイダンスを使用して、クライアント証明書の発行を許可する認証局を構成します。

• ユーザーが証明書認証を行う際のニーズに合わせてサインイン ページを変更することを検討してください。 一般的なケースは、X509 証明書を使用したサインインをよりユーザーフレンドリーなものに変更することです。

Windows デスクトップ上の Chrome ブラウザーに対してシームレスな証明書認証を構成する

マシンにクライアント認証の目的を満たす複数のユーザー証明書 (Wi-Fi 証明書など) がある場合、Windows デスクトップ上の Chrome ブラウザーは、ユーザーに適切な証明書を選択するように求めるメッセージを表示します。 このプロンプトはユーザーを混乱させる可能性があります。 このエクスペリエンスを最適化するために、適切な証明書を自動的に選択するように Chrome のポリシーを設定できます。

このポリシーは、レジストリを変更して手動で設定することも、GPO 経由で自動的に構成することもできます (レジストリ キーを設定するため)。 このためユーザーには、AD FS に対する認証のために、他のユース ケースとは別の発行者が指定されているクライアント証明書が要求されます。

Chrome の証明書認証の構成の詳細については、「Chrome Enterprise ポリシーの一覧」を参照してください。

証明書認証のトラブルシューティング

ユーザーの証明書認証用に AD FS を構成した場合の一般的な問題のトラブルシューティングには、次の情報を使用します。

すべての AD FS サーバーと WAP サーバーで証明書の信頼された発行者が正しく構成されているかどうかを確認する

証明書の信頼できる発行者が適切に構成されていない場合、一般的な症状は HTTP 204 エラーです: "https://certauth.adfs.contoso.com." からのコンテンツがありません。

AD FS では、基盤となる Windows オペレーティング システムを使用してユーザー証明書の所有を証明し、証明書の信頼チェーンを検証することで証明書が信頼できる発行者と一致することを確認します。 信頼できる発行者と一致させるには、すべてのルートおよび中間認証局が、コンピューターの証明機関のローカル ストアで信頼できる発行者として構成されていることを確認する必要があります。

これを自動的に検証するには、AD FS 診断アナライザー ツールを使用してください。 このツールでは、すべてのサーバーに対してクエリを実行し、適切な証明書が正しくプロビジョニングされていることを確認します。

1. ツールをダウンロードして実行します。
2. 結果をアップロードしてエラーがないか確認します。

AD FS 認証ポリシーで証明書認証が有効になっているかどうかを調べる

AD FS は、既定で、AD FS と同じホスト名 (例: adfs.contoso.com) を使用してポート 49443 でユーザー証明書認証を実行します。 代替 SSL バインディングを使用して、ポート 443 (既定の HTTPS ポート) を使用するように AD FS を構成することもできます。 ただし、この構成で使用される URL は certauth.<adfs-farm-name> です (例: certauth.contoso.com)。 詳細については、「証明書認証のための代替ホスト名バインドに対する AD FS サポート」を参照してください。

ネットワーク接続の問題で最も一般的なケースは、ファイアウォールが正しく構成されておらず、ユーザー証明書認証のトラフィックをブロックしていることです。 通常、この問題が発生すると、空白の画面が表示されるか、500 サーバー エラーが表示されます。 これを修正するには:

1. AD FS で構成したホスト名とポートをメモします。
2. AD FS または WAP の前にあるすべてのファイアウォールが、AD FS ファームを表わす hostname:port の組み合わせを許可するように構成されていることを確認します。 ネットワーク エンジニアはこの手順を実行する必要があります。

CRL 接続を確認する

証明書失効リスト (CRL) は、実行時の失効確認を実行するためにユーザー証明書にエンコードされているエンドポイントです。 たとえば、証明書を含むデバイスが盗まれた場合、管理者は、失効した証明書の一覧にその証明書を追加できます。 以前はこの証明書を受け入れたすべてのエンドポイントが、認証に失敗するようになります。

すべての AD FS および WAP サーバーは、提示された証明書がまだ有効であり、失効していないかどうかを検証するために、CRL エンドポイントに到達する必要があります。 CRL 検証は、HTTPS、HTTP、LDAP、または OCSP 経由で実行できます。 AD FS および WAP サーバーがエンドポイントに接続できない場合、認証は失敗します。 次の手順を使用してトラブルシューティングを行います。

1. 公開キー基盤 (PKI) エンジニアに問い合わせて、PKI システムからユーザー証明書を失効させるために使用する CRL エンドポイントを決定します。
2. それぞれの AD FS および WAP サーバーで、使用されているプロトコル (通常は HTTPS または HTTP) を介して CRL エンドポイントに到達できることを確認します。
3. 高度な検証を行うには、各 AD FS および WAP サーバーで、CAPI2 イベント ログを有効にします。
4. CAPI2 運用ログで、イベント ID 41 (失効の確認) がないか確認します。
5. <Result value="80092013">The revocation function was unable to check revocation because the revocation server was offline.</Result> がないか確認します。

SNI の問題を確認する

AD FS では、クライアント デバイス (またはブラウザー) とロード バランサーが Server Name Indication (SNI) をサポートする必要があります。 一部のクライアント デバイス (古いバージョンの Android など) は SNI をサポートしていない場合があります。 さらに、ロード バランサーが SNI をサポートしていないか、SNI 用に構成されていない可能性があります。 このような場合、ユーザー認証に失敗する可能性があります。

この問題を解決するには、ネットワーク エンジニアと協力して、AD FS および WAP のロード バランサーが SNI をサポートしていることを確認します。 SNI をサポートできない場合は、AD FS で次の回避策を使用してください。

1. プライマリ AD FS サーバーで、管理者特権でのコマンド プロンプト ウィンドウを開きます。
2. 「Netsh http show sslcert」と入力します。
3. フェデレーション サービスの "アプリケーション GUID" と "証明書ハッシュ" をコピーします。
4. 「netsh http add sslcert ipport=0.0.0.0:{your_certauth_port} certhash={your_certhash} appid={your_applicaitonGUID}」と入力します。

クライアント デバイスに証明書が正しくプロビジョニングされているかどうかを調べる

一部のデバイスは正常に機能しているのに、他のデバイスはそうでないことに気付くことがあります。 ほとんどの場合、これはユーザー証明書が一部のクライアント デバイスで正しくプロビジョニングされていないことを意味します。 次の手順のようにします。

1. 問題が Android デバイスに固有の場合、最も一般的な原因は、証明書チェーンがデバイス上で完全に信頼されていないことです。 お使いの MDM ベンダーに問い合わせて、証明書が正しくプロビジョニングされており、Android デバイスでチェーン全体が完全に信頼されていることを確認します。

   問題が Windows デバイスに固有の場合は、(システムまたはコンピューターではなく) ログイン ユーザーの Windows 証明書ストアを確認して、証明書が正しくプロビジョニングされているかどうかを確認します。

2. クライアント ユーザー証明書を .cer ファイルにエクスポートし、コマンド certutil -f -urlfetch -verify certificatefilename.cer を実行します。

TLS バージョンが AD FS または WAP サーバーとクライアント デバイスとの間で互換性があるかどうかを調べる

まれに、クライアント デバイスが更新されて、上位バージョンの TLS (たとえば、1.3) のみをサポートすることがあります。 または、クライアント デバイスがサポートしていない上位の TLS バージョンのみを使用するように AD FS サーバーと WAP サーバーが更新された、逆の問題が発生する可能性があります。

オンライン SSL ツールを使用して、AD FS サーバーと WAP サーバーをチェックし、デバイスと互換性があるかどうかを確認できます。 TLS バージョンを制御する方法の詳細については、「AD FS の SSL/TLS プロトコルと暗号スイートの管理」を参照してください。

フェデレーション ドメインの設定で Microsoft Entra の PromptLoginBehavior が正しく構成されているかどうかを調べる

多くの Office 365 アプリケーションは prompt=login を Microsoft Entra ID に送信します。 Microsoft Entra ID では既定で、これを AD FS に対する新しいパスワード ログインに変換します。 その結果、AD FS で証明書認証を構成したとしても、ユーザーにはパスワード ログインのみが表示されます。 この問題の解決方法

1. Get-MgDomainFederationConfiguration コマンドレットを使用して、フェデレーション ドメイン設定を取得します。
2. PromptLoginBehavior パラメーターが Disabled または NativeSupport に設定されていることを確認します。

詳細については、「AD FS prompt=login パラメーターのサポート」を参照してください。

その他のトラブルシューティング

まれに、CRL リストが非常に長い場合、ダウンロードしようとするとタイムアウトが発生することがあります。 この場合、「Windows の Http.sys レジストリ設定」の説明に従って MaxFieldLength と MaxRequestByte を更新する必要があります。

参考情報: ユーザー証明書の要求の種類と値の例の完全な一覧

関連リンク

• AD FS 証明書認証のための代替ホスト名バインドを構成する
• Microsoft Entra ID で証明機関を構成する