ユーザー証明書認証の 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 証明書認証を使用している場合、クライアント証明書には、Exchange Online のユーザーのルーティング可能な電子メール アドレスが、プリンシパル名の 値か、サブジェクトの別名 フィールドの RFC822 Name 値である必要があります。 Microsoft Entra ID は、RFC822 値をディレクトリ内のプロキシ アドレス属性にマップします。
手記
AD FS では、スマート カードまたは証明書ベースの認証を使用したユーザー名ヒントはサポートされていません。
ユーザー証明書認証を有効にする
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 (AD FS など) 以外の ID プロバイダーを使用してデバイス認証を実行するお客様は、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 サーバーで正しく構成されているかどうかを確認する
証明書の信頼された発行者が正しく構成されていない場合、一般的な症状の1つは HTTP 204 エラーです：「No content from https://certauth.adfs.contoso.com."」。
AD FS は、基になる Windows オペレーティング システムを使用して、ユーザー証明書の所有を証明し、証明書信頼チェーンを検証して信頼された発行者と一致することを確認します。 信頼された発行者と一致するには、すべてのルート証明機関と中間機関が、コンピューター証明機関のローカル ストアで信頼された発行者として構成されていることを確認する必要があります。
これを自動的に検証するには、AD FS Diagnostics Analyzer ツールを使用します。 このツールは、すべてのサーバーに対してクエリを実行し、適切な証明書が正しくプロビジョニングされていることを確認します。
- ツールをダウンロードして実行します。
- 結果をアップロードし、エラーを確認します。
AD FS 認証ポリシーで証明書認証が有効になっているかどうかを確認する
AD FS は、AD FS と同じホスト名を持つポート 49443 で既定でユーザー証明書認証を実行します (例: adfs.contoso.com)。 代替 SSL バインディングを使用して、ポート 443 (既定の HTTPS ポート) を使用するように AD FS を構成することもできます。 ただし、この構成で使用される URL は certauth.<adfs-farm-name> です (例: certauth.contoso.com)。 詳細については、証明書認証の代替ホスト名バインドに対する AD FS のサポート
手記
Windows Server 2016 の AD FS では、2 つのモードがサポートされるようになりました。 最初のモードでは、ポート 443 とポート 49443 のホスト adfs.contoso.com が使用されます。 2 番目のモードでは、ポート 443 でホスト adfs.contoso.com と certauth.adfs.contoso.com が使用されます。 代替サブジェクト名として certauth.\<adfs-service-name> をサポートするには、SSL 証明書が必要です。 これは、ファームの作成時以降に PowerShell を使用して行うことができます。
ネットワーク接続の問題の最も一般的なケースは、ファイアウォールが正しく構成されておらず、ユーザー証明書認証のトラフィックがブロックされていることです。 通常、この問題が発生すると、空白の画面または 500 サーバー エラーが表示されます。 これを修正するには:
- AD FS で構成したホスト名とポートをメモします。
- AD FS ファームの
hostname:portの組み合わせを許可するように、AD FS または WAP の前面にあるファイアウォールが構成されていることを確認します。 ネットワーク エンジニアがこの手順を実行する必要があります。
CRL 接続を確認する
証明書失効リスト (CRL) は、ランタイム失効チェックを実行するためにユーザー証明書にエンコードされるエンドポイントです。 たとえば、証明書を含むデバイスが盗まれた場合、管理者は失効した証明書の一覧に証明書を追加できます。 以前にこの証明書を受け入れたエンドポイントは、認証に失敗するようになりました。
提示された証明書がまだ有効であり、取り消されていないかどうかを検証するには、すべての AD FS および WAP サーバーが CRL エンドポイントに到達する必要があります。 CRL 検証は、HTTPS、HTTP、LDAP、または OCSP を介して行うことができます。 AD FS および WAP サーバーがエンドポイントに到達できない場合、認証は失敗します。 トラブルシューティングを行うには、次の手順に従います。
- PKI システムからユーザー証明書を取り消すために使用される CRL エンドポイントを決定するには、公開キー 基盤 (PKI) エンジニアに問い合わせてください。
- 各 AD FS および WAP サーバーで、使用されているプロトコル (通常は HTTPS または HTTP) を介して CRL エンドポイントに到達できることを確認します。
- 高度な検証を行うには、各 AD FS および WAP サーバーで、CAPI2 イベント ログを有効にします。
- CAPI2 操作ログでイベント ID 41 (失効の確認) を確認します。
<Result value="80092013">The revocation function was unable to check revocation because the revocation server was offline.</Result>を確認します。
ヒント
特定のサーバーを指す DNS 解決 (Windows 上のホスト ファイル) を構成することで、トラブルシューティングを容易にするために、単一の AD FS または WAP サーバーをターゲットにすることができます。 この手法を使用すると、サーバーをターゲットにしてトレースを有効にすることができます。
SNI の問題を確認する
AD FS では、クライアント デバイス (またはブラウザー) と、サーバー名表示 (SNI) をサポートするロード バランサーが必要です。 一部のクライアント デバイス (たとえば、古いバージョンの Android) では、SNI がサポートされていない場合があります。 さらに、ロード バランサーが SNI をサポートしていないか、SNI 用に構成されていない可能性があります。 このような場合、ユーザー認定エラーが発生する可能性があります。
この問題を解決するには、ネットワーク エンジニアと協力して、AD FS と WAP のロード バランサーが SNI をサポートしていることを確認してください。 SNI をサポートできない場合は、AD FS で次の回避策を使用します。
- プライマリ AD FS サーバーで管理者特権のコマンド プロンプト ウィンドウを開きます。
- 「
Netsh http show sslcert」と入力します。 - フェデレーション サービスのアプリケーション GUID と証明書ハッシュをコピーします。
- 「
netsh http add sslcert ipport=0.0.0.0:{your_certauth_port} certhash={your_certhash} appid={your_applicationGUID}」と入力します。
クライアント デバイスが証明書で正しくプロビジョニングされているかどうかを確認する
一部のデバイスは正常に動作しているが、他のデバイスは正しく動作していないことがわかります。 ほとんどの場合、一部のクライアント デバイスでユーザー証明書が正しくプロビジョニングされなかったことを意味します。 次の手順に従います。
問題が Android デバイスに固有の場合、最も一般的な原因は、証明書チェーンがデバイスで完全に信頼されていないことです。 MDM ベンダーに問い合わせて、証明書が正しくプロビジョニングされ、チェーン全体が Android デバイスで完全に信頼されていることを確認してください。
問題が Windows デバイスに固有の場合は、ログインしているユーザー (システムまたはコンピューターではなく) の Windows 証明書ストアを確認して、証明書が正しくプロビジョニングされているかどうかを確認します。
クライアント ユーザー証明書を.cer ファイルにエクスポートし、コマンド
certutil -f -urlfetch -verify certificatefilename.cerを実行します。
AD FS/WAP サーバーとクライアント デバイスの間で TLS バージョンに互換性があるかどうかを確認する
まれに、より高いバージョンの TLS (1.3 など) のみをサポートするようにクライアント デバイスが更新されます。 または、逆の問題が発生する可能性があります。AD FS サーバーと WAP サーバーは、クライアント デバイスがサポートしていないより高い TLS バージョンのみを使用するように更新されました。
オンライン 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 で証明書認証を構成した場合でも、ユーザーにはパスワード ログインのみが表示されます。 この問題を解決するには:
Get-MgDomainFederationConfigurationコマンドレットを使用して、フェデレーション ドメインの設定を取得します。PromptLoginBehaviorパラメーターがDisabledまたはNativeSupportに設定されていることを確認します。
詳細については、AD FS prompt=login パラメーターのサポートを参照してください。
その他のトラブルシューティング
まれに、CRL リストが非常に長い場合、ダウンロードしようとするとタイムアウトになる可能性があります。 この場合、Windowsのレジストリ設定の説明に従って、
リファレンス: ユーザー証明書要求の種類と値の例の完全な一覧
| 要求の種類 | 値の例 |
|---|---|
http://schemas.microsoft.com/2012/12/certificatecontext/field/x509version |
3 |
http://schemas.microsoft.com/2012/12/certificatecontext/field/signaturealgorithm |
sha256RSA |
http://schemas.microsoft.com/2012/12/certificatecontext/field/issuer |
CN=entca, DC=domain, DC=contoso, DC=com |
http://schemas.microsoft.com/2012/12/certificatecontext/field/issuername |
CN=entca, DC=domain, DC=contoso, DC=com |
http://schemas.microsoft.com/2012/12/certificatecontext/field/notbefore |
12/05/2016 20:50:18 |
http://schemas.microsoft.com/2012/12/certificatecontext/field/notafter |
12/05/2017 20:50:18 |
http://schemas.microsoft.com/2012/12/certificatecontext/field/subject |
E=user@contoso.com, CN=user, CN=Users, DC=domain, DC=contoso, DC=com |
http://schemas.microsoft.com/2012/12/certificatecontext/field/subjectname |
E=user@contoso.com, CN=user, CN=Users, DC=domain, DC=contoso, DC=com |
http://schemas.microsoft.com/2012/12/certificatecontext/field/rawdata |
{Base64 encoded digital certificate data} |
http://schemas.microsoft.com/2012/12/certificatecontext/extension/keyusage |
DigitalSignature |
http://schemas.microsoft.com/2012/12/certificatecontext/extension/keyusage |
KeyEncipherment |
http://schemas.microsoft.com/2012/12/certificatecontext/extension/subjectkeyidentifier |
9D11941EC06FACCCCB1B116B56AA97F3987D620A |
http://schemas.microsoft.com/2012/12/certificatecontext/extension/authoritykeyidentifier |
KeyID=d6 13 e3 6b bc e5 d8 15 52 0a fd 36 6a d5 0b 51 f3 0b 25 7f |
http://schemas.microsoft.com/2012/12/certificatecontext/extension/certificatetemplatename |
User |
http://schemas.microsoft.com/2012/12/certificatecontext/extension/san |
Other Name:Principal Name=user@contoso.com, RFC822 Name=user@contoso.com |
http://schemas.microsoft.com/2012/12/certificatecontext/extension/eku |
1.3.6.1.4.1.311.10.3.4 |
関連リンク
- AD FS 証明書認証 の代替ホスト名バインドを構成する
- Microsoft Entra ID で証明機関を構成する