Microsoft Entra 証明書ベースの認証を設定する

組織では、Microsoft Entra 証明書ベースの認証 (CBA) を使用して、ユーザー X.509 証明書を使用して、フィッシングに対する耐性、最新、パスワードレスの認証を実装できます。

この記事では、X.509 証明書を使用してテナントユーザーの認証を許可または要求するように Microsoft Entra テナントを設定する方法について説明します。ユーザーは、アプリケーションとブラウザーのサインインにエンタープライズ公開キー基盤 (PKI) を使用して X.509 証明書を作成します。

Microsoft Entra CBA を設定すると、サインイン中に、ユーザーはパスワードを入力するのではなく、証明書を使用して認証するオプションを表示します。デバイスに複数の一致する証明書がある場合、ユーザーは関連する証明書を選択し、ユーザーアカウントに対して証明書が検証されます。検証に成功すると、ユーザーはサインインします。

Office 365 Enterprise および US Government プランのテナントに Microsoft Entra CBA を構成して使用するには、この記事で説明されている手順を完了します。 PKI が既に構成されている必要があります。

前提条件

次の前提条件が満たされていることを確認します。

Microsoft Entra ID では、少なくとも 1 つの証明機関 (CA) と中間 CA が構成されています。
ユーザーは、Microsoft Entra ID でのクライアント認証を目的としてテナントで構成された信頼された PKI から発行されたユーザー証明書にアクセスできます。
各 CA には、インターネットに接続する URL から参照できる証明書失効リスト (CRL) があります。信頼された CA に CRL が構成されていない場合、Microsoft Entra ID で CRL チェックは実行されず、ユーザー証明書の失効は機能せず、認証はブロックされません。

考慮事項

PKI がセキュリティで保護されており、簡単に侵害できないことを確認します。侵害が発生した場合、攻撃者はクライアント証明書を作成して署名し、テナント内のすべてのユーザー (オンプレミスから同期されたユーザーを含む) を侵害することができます。強力なキー保護戦略やその他の物理的および論理的な制御により、外部の攻撃者や内部関係者の脅威によって PKI の整合性が損なわれないように、多層防御を実現できます。詳細については、PKI の保護に関する記事をご覧ください。
アルゴリズム、キーの長さ、データ保護の選択など、Microsoft Cryptography のベストプラクティスについては、 Microsoft の推奨事項を参照してください。推奨されるアルゴリズムの 1 つ、推奨されるキーの長さ、および NIST で承認された曲線を必ず使用してください。
継続的なセキュリティ強化の一環として、Azure と Microsoft 365 エンドポイントでは TLS 1.3 のサポートが追加されました。このプロセスは、Azure と Microsoft 365 全体の何千ものサービスエンドポイントをカバーするのに数か月かかると予想されます。 Microsoft Entra CBA が使用する Microsoft Entra エンドポイントは、 *.certauth.login.microsoftonline.com と *.certauth.login.microsoftonline.usの更新プログラムに含まれています。

TLS 1.3 は、インターネットで最も一般的にデプロイされるセキュリティプロトコルの最新バージョンです。 TLS 1.3 は、データを暗号化して、2 つのエンドポイント間のセキュリティで保護された通信チャネルを提供します。古い暗号アルゴリズムを排除し、以前のバージョンよりもセキュリティを強化し、できるだけ多くのハンドシェイクを暗号化します。アプリケーションとサービスで TLS 1.3 のテストを開始することを強くお勧めします。
PKI を評価するときは、証明書の発行ポリシーと適用を確認することが重要です。前述のように、Ca を Microsoft Entra 構成に追加すると、それらの CA によって発行された証明書は、Microsoft Entra ID で任意のユーザーを認証できます。

CA が証明書の発行を許可される方法とタイミング、およびそれらが再利用可能な識別子を実装する方法を考慮することが重要です。管理者は、特定の証明書を使用してユーザーを認証できるようにする必要がありますが、特定の証明書のみがユーザーを認証できるより高いレベルの保証を実現するには、アフィニティの高いバインドのみを使用する必要があります。詳細については、「高アフィニティバインディング」を参照してください。

Microsoft Entra CBA の構成とテスト

Microsoft Entra CBA を有効にする前に、いくつかの構成手順を完了する必要があります。

管理者は、ユーザー証明書を発行する信頼された CA を構成する必要があります。次の図に示すように、Azure ではロールベースのアクセス制御 (RBAC) を使用して、最小限の特権を持つ管理者のみが変更を行う必要があることを確認します。

重要

Microsoft は、アクセス許可が最も少ないロールを使用することを推奨しています。この方法は、組織のセキュリティ向上に役立ちます。グローバル管理者は、既存のロールを使用できないときの緊急シナリオに限定する必要がある、高い特権を持つロールでます。

必要に応じて、証明書を単一要素認証または多要素認証 (MFA) にマップするように認証バインドを構成できます。証明書フィールドをユーザーオブジェクトの属性にマップするようにユーザー名バインドを構成します。認証ポリシー管理者は、ユーザー関連の設定を構成できます。

すべての構成が完了したら、テナントで Microsoft Entra CBA を有効にします。

Microsoft Entra 証明書ベースの認証を有効にするために必要な手順の概要を示す図。

手順 1: PKI ベースの信頼ストアを使用して CA を構成する

Microsoft Entra には、新しい PKI ベースの CA 信頼ストアがあります。信頼ストアは、PKI ごとにコンテナーオブジェクト内に CA を保持します。管理者は、PKI に基づいてコンテナー内の CA を簡単に管理できます。これは、CA のフラットリストを管理するよりも簡単です。

PKI ベースの信頼ストアには、CA の数と各 CA ファイルのサイズに関する従来の信頼ストアよりも高い制限があります。 PKI ベースの信頼ストアは、CA オブジェクトごとに最大 250 CA と 8 KB をサポートします。

従来の信頼ストアを使用して CA を構成する場合は、PKI ベースの信頼ストアを設定することを強くお勧めします。 PKI ベースの信頼ストアはスケーラブルであり、発行者ヒントなどの新機能をサポートしています。

管理者は、ユーザー証明書を発行する信頼された CA を構成する必要があります。変更を加える必要があるのは、最小限の特権を持つ管理者だけです。 PKI ベースの信頼ストアには、特権認証管理者ロールが割り当てられます。

PKI ベースの信頼ストアの PKI アップロード機能は、Microsoft Entra ID P1 または P2 ライセンスでのみ使用できます。ただし、Microsoft Entra の無料ライセンスでは、管理者は PKI ファイルをアップロードするのではなく、すべての CA を個別にアップロードできます。その後、PKI ベースの信頼ストアを構成し、アップロードした CA ファイルを追加できます。

Microsoft Entra 管理センターを使用して CA を構成する

PKI コンテナーオブジェクトを作成する (Microsoft Entra 管理センター)

PKI コンテナーオブジェクトを作成するには:

特権認証管理者ロールが割り当てられているアカウントで Microsoft Entra 管理センターにサインインします。
Entra ID>Identity Secure Score>Public キーインフラストラクチャに移動します。
[ PKI の作成] を選択します。
[表示名] に名前を入力します。
を選択してを作成します。
列を追加または削除するには、[列の 編集] を選択します。
PKI の一覧を更新するには、[ 最新の情報に更新] を選択します。

PKI コンテナーオブジェクトを削除する

PKI を削除するには、PKI を選択し、[削除] を選択します。 PKI に CA が含まれている場合は、PKI の名前を入力して、PKI 内のすべての CA の削除を確認します。次に、[削除] を選択 します。

個々の CA を PKI コンテナーオブジェクトにアップロードする

PKI コンテナーに CA をアップロードするには:

[ 証明機関の追加] を選択します。
CA ファイルを選択します。
CA がルート証明書の場合は、[ はい] を選択します。それ以外の場合 は、[いいえ] を選択します。
[証明書失効リストの URL] に、失効したすべての証明書を含む CA ベース CRL のインターネットに接続する URL を入力します。 URL が設定されていない場合、失効した証明書を使用した認証の試行は失敗しません。
[Delta Certificate Revocation List URL] には、最後のベース CRL が発行されてからのすべての失効した証明書を含む CRL のインターネットに接続する URL を入力します。
CA を発行者ヒントに含めてはいけない場合は、発行者ヒントをオフにします。 発行者ヒント フラグは、既定ではオフになっています。
[保存] を選択します。
CA を削除するには、CA を選択し、[ 削除] を選択します。
列を追加または削除するには、[列の 編集] を選択します。
PKI の一覧を更新するには、[ 最新の情報に更新] を選択します。

最初に、100 個の CA 証明書が表示されます。ウィンドウを下にスクロールすると、さらに表示されます。

PKI コンテナーオブジェクトにすべての CA をアップロードする

すべての CA を PKI コンテナーに一括アップロードするには:

PKI コンテナーオブジェクトを作成するか、既存のコンテナーを開きます。
[Upload PKI]$PKI のアップロード$ を選択します。
.p7b ファイルの HTTP インターネットに接続する URL を入力します。
ファイルの SHA-256 チェックサムを入力します。
アップロードを選択します。

PKI アップロードプロセスは非同期です。各 CA がアップロードされると、PKI で使用できるようになります。 PKI のアップロード全体には、最大で 30 分かかることがあります。
[最新の情報に更新] を選択して、CA の一覧を更新します。
アップロードされた各 CA CRL エンドポイント 属性は、CRL 配布ポイント 属性としてリストされている CA 証明書の最初の使用可能な HTTP URL で更新されます。リーフ証明書は手動で更新する必要があります。

PKI .p7b ファイルの SHA-256 チェックサムを生成するには、次のコマンドを実行します。

Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256

PKI を編集する

PKI 行で、[ ... ] を選択し、[ 編集] を選択します。
新しい PKI 名を入力します。
[保存] を選択します。

CA を編集する

CA 行で、[ ... ] を選択し、[ 編集] を選択します。
要件に従って、CA の種類 (ルートまたは中間)、CRL URL、デルタ CRL URL、または発行者ヒントが有効なフラグの新しい値を入力します。
[保存] を選択します。

発行者ヒント属性を一括編集する

複数の CA を編集し、 発行者ヒントが有効 になっている属性をオンまたはオフにするには、複数の CA を選択します。
[ 編集] を選択し、[ 発行者ヒントの編集] を選択します。
選択したすべての CA に対して [ 発行者ヒントが有効] チェックボックスをオンにするか、選択をオフにして、選択したすべての CA に対して 発行者ヒントが有効な フラグをオフにします。既定値は 不確定です。
[保存] を選択します。

PKI を復元する

[Deleted PKIs]$削除された PKI$ タブを選択します。
PKI を選択し、[Restore PKI]$PKI の復元$ を選択します。

CA を復元する

[Deleted CA]$削除された CA$ タブを選択します。
CA ファイルを選択し、[証明機関の復元] を選択します。

CA の isIssuerHintEnabled 属性を構成する

発行者のヒントは、トランスポート層セキュリティ (TLS) ハンドシェイクの一部として 信頼された CA インジケーターを返します。信頼された CA リストは、テナントが Microsoft Entra 信頼ストアにアップロードする CA のサブジェクトに設定されます。詳細については、「発行者のヒントについて」を参照してください。

既定では、Microsoft Entra 信頼ストア内のすべての CA のサブジェクト名が、ヒントとして送信されます。特定の CA に対してのみヒントを返送する場合は、発行者ヒント属性 isIssuerHintEnabled を true に設定します。

サーバーは、発行者ヒント (CA のサブジェクト名) に対して最大 16 KB の応答を TLS クライアントに送り返すことができます。 isIssuerHintEnabled属性は、ユーザー証明書を発行する CA に対してのみtrueに設定することをお勧めします。

同じルート証明書の複数の中間 CA がユーザー証明書を発行する場合、既定では、すべての証明書が証明書ピッカーに表示されます。 isIssuerHintEnabledを特定の CA に対してtrueに設定すると、証明書ピッカーに関連するユーザー証明書のみが表示されます。

Microsoft Graph API を使用して CA を構成する

次の例では、Microsoft Graph を使用して、PKI または CA の HTTP メソッドを使用して作成、読み取り、更新、および削除 (CRUD) 操作を実行する方法を示します。

PKI コンテナーオブジェクトを作成する (Microsoft Graph)

PATCH https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/
Content-Type: application/json
{
   "displayName": "ContosoPKI"
}

すべての PKI オブジェクトを取得する

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations
ConsistencyLevel: eventual

PKI ID で PKI オブジェクトを取得する

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/<PKI-ID>/
ConsistencyLevel: eventual

.p7b ファイルを使用して CA をアップロードする

PATCH https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/<PKI-id>/certificateAuthorities/<CA-ID>
Content-Type: application/json
{
     "uploadUrl":"https://CBA/demo/CBARootPKI.p7b,
     "sha256FileHash": "AAAAAAD7F909EC2688567DE4B4B0C404443140D128FE14C577C5E0873F68C0FE861E6F"
}

PKI 内のすべての CA を取得する

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/<PKI-ID>/certificateAuthorities
ConsistencyLevel: eventual

PKI 内の特定の CA を CA ID で取得する

GET https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/<PKI-ID>/certificateAuthorities/<CA-ID>
ConsistencyLevel: eventual

特定の CA 発行者ヒントフラグを更新する

PATCH https://graph.microsoft.com/beta/directory/publicKeyInfrastructure/certificateBasedAuthConfigurations/<PKI-ID>/certificateAuthorities/<CA-ID>
Content-Type: application/json
{
   "isIssuerHintEnabled": true
}

PowerShell を使用して CA を構成する

これらの手順では、 Microsoft Graph PowerShell を使用します。

[管理者として実行] オプションを使用して PowerShell を起動します。

Microsoft Graph PowerShell SDK をインストールしてインポートします。

Install-Module Microsoft.Graph -Scope AllUsers
Import-Module Microsoft.Graph.Authentication
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

テナントに接続し、 すべて受け入れます。

   Connect-MGGraph -Scopes "Directory.ReadWrite.All", "User.ReadWrite.All" -TenantId <tenantId>

PKI ベースの信頼ストアと従来の CA ストアの間の優先順位付け

PKI ベースの CA ストアと従来の CA ストアの両方に CA が存在する場合、PKI ベースの信頼ストアが優先されます。

クラシック CA ストアは、次のシナリオで優先されます。

CA は両方のストアに存在し、PKI ベースのストアには CRL はありませんが、クラシックストア CA には有効な CRL があります。
CA は両方のストアに存在し、PKI ベースのストア CA CRL は従来のストア CA CRL とは異なります。

Microsoft Entra サインインログの中断されたエントリには 、[追加の詳細] の下に 2 つの属性があり、認証時にクラシック信頼ストアとレガシ信頼ストアのどちらがまったく使用されたかを示します。

使用されているレガシストア の値は 0 で、PKI ベースのストアが使用されていることを示します。値 1 は、クラシックストアまたはレガシストアが使用されることを示します。
従来のストアの使用情報 には、クラシックストアまたはレガシストアが使用されている理由が表示されます。

PKI ベースのストアまたは従来の CA ストアを使用するためのサインインログエントリを示すスクリーンショット

監査ログ

信頼ストア内の PKI または CA で実行する CRUD 操作は、Microsoft Entra 監査ログに表示されます。

従来の CA ストアから PKI ベースのストアに移行する

テナント管理者は、PKI ベースのストアにすべての CA をアップロードできます。その後、PKI CA ストアはクラシックストアよりも優先され、すべての CBA 認証は PKI ベースのストアを介して行われます。テナント管理者は、サインインログにクラシックストアまたはレガシストアが使用されたことの兆候がないことを確認した後、クラシックストアまたはレガシストアから CA を削除できます。

よく寄せられる質問

PKI のアップロードが失敗する理由

PKI ファイルが有効であり、問題なくアクセスできることを確認します。 PKI ファイルの最大サイズは 2 MB (CA オブジェクトごとに 250 CA と 8 KB) です。

PKI アップロードのサービスレベルアグリーメントとは

PKI アップロードは非同期操作であり、完了するまでに最大 30 分かかる場合があります。

PKI ファイルの SHA-256 チェックサムを生成するにはどうすればよいですか?

PKI .p7b ファイルの SHA-256 チェックサムを生成するには、次のコマンドを実行します。

Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256

手順 2: テナントの CBA を有効にする

重要

ユーザーが認証方法ポリシーで CBA のスコープとして指定されている場合、ユーザーは MFA を完了できると見なされます。このポリシー要件は、ユーザーが認証の一部として ID 証明を使用して他の使用可能な方法を登録できないことを意味します。ユーザーが証明書にアクセスできない場合、ユーザーはロックアウトされ、MFA の他の方法を登録できません。認証ポリシー管理者ロールが割り当てられている管理者は、有効な証明書を持つユーザーに対してのみ CBA を有効にする必要があります。 CBA に [すべてのユーザー] を含めないでください。有効な証明書を使用できるユーザーのグループのみを使用します。詳細については、「Microsoft Entra MFA 多要素認証」を参照してください。

Microsoft Entra 管理センターを使用して CBA を有効にするには:

少なくとも認証ポリシー管理者ロールが割り当てられているアカウントを使用して、Microsoft Entra 管理センターにサインインします。
グループ>すべてのグループに移動します。
[ 新しいグループ ] を選択し、CBA ユーザー用のグループを作成します。
Entra ID>Authentication メソッド>Certificate ベースの認証に移動します。
[ 有効] と [ターゲット] で [ 有効] を選択し、[ 確認する ] チェックボックスをオンにします。
[グループの選択] を選択>グループを追加します。
作成したグループなど、特定のグループを選択し、[選択] を選択します。 [すべてのユーザー] ではなく、特定のグループを使用します。
[保存] を選択します。

テナントに対して CBA を有効にすると、テナント内のすべてのユーザーに、証明書を使用してサインインするオプションが表示されます。 X.509 証明書を使用して認証できるのは、CBA を使用できるユーザーだけです。

注

ネットワーク管理者は、 login.microsoftonline.com エンドポイントに加えて、組織のクラウド環境の証明書認証エンドポイントへのアクセスを許可する必要があります。証明書認証エンドポイントで TLS 検査をオフにして、クライアント証明書要求が TLS ハンドシェイクの一部として成功することを確認します。

手順 3: 認証バインドポリシーを構成する

認証バインディングポリシーは、認証の強度を単一要素または MFA に設定するのに役立ちます。テナント上のすべての証明書の既定の保護レベルは、単一要素認証です。

テナントレベルでの既定のアフィニティバインドは低 アフィニティです。認証ポリシー管理者は、既定値を単一要素認証から MFA に変更できます。保護レベルが変更されると、テナント上のすべての証明書が MFA に設定されます。同様に、テナントレベルのアフィニティバインドは 、高いアフィニティに設定できます。すべての証明書は、高アフィニティ属性のみを使用して検証されます。

重要

管理者は、テナントの既定値を、ほとんどの証明書に適用できる値に設定する必要があります。テナントの既定値とは異なる保護レベルまたはアフィニティバインディングを必要とする特定の証明書に対してのみ、カスタム規則を作成します。すべての認証方法の構成は、同じポリシーファイル内にあります。複数の冗長ルールを作成すると、ポリシーファイルのサイズ制限を超える可能性があります。

認証バインディング規則は、 発行者、 ポリシーオブジェクト ID (OID)、 発行者、ポリシー OID などの証明書属性を指定した値にマップします。規則は、その規則の既定の保護レベルとアフィニティバインディングを設定します。

Microsoft Entra 管理センターを使用して既定のテナント設定を変更し、カスタムルールを作成するには:

少なくとも認証ポリシー管理者ロールが割り当てられているアカウントを使用して、Microsoft Entra 管理センターにサインインします。
Entra ID>Authentication メソッド>Policies に移動します。
[ 移行の管理] で、 認証方法>Certificate ベースの認証を選択します。
認証バインドとユーザー名バインドを設定するには、[ 構成] を選択します。
既定値を MFA に変更するには、[ 多要素認証] を選択します。保護レベル属性の既定値は、単一要素認証です。

注

カスタム規則が追加されない場合、既定の保護レベルが有効になります。カスタム規則を追加すると、既定の保護レベルではなく、規則レベルで定義された保護レベルが適用されます。
また、カスタム認証バインド規則を設定して、保護レベルまたはアフィニティバインドにテナントの既定値とは異なる値を必要とするクライアント証明書の保護レベルを決定することもできます。証明書の発行者のサブジェクトまたはポリシー OID、または両方のフィールドを使用して、規則を構成できます。

認証バインディング規則は、証明書属性 (発行者またはポリシー OID) を値にマップします。この値は、その規則の既定の保護レベルを設定します。複数のルールを作成できます。次の例では、テナントの既定値が 多要素認証 で、アフィニティバインドの 場合は Low であるとします。

カスタムルールを追加するには、[ルールの追加] をクリックします。

証明書発行者別にルールを作成するには:
1. [ 証明書の発行者] を選択します。
2. [ 証明書発行者識別子] で、関連する値を選択します。
3. [認証の強度] で、[多要素認証] を選択します。
4. アフィニティバインドの場合は、[低] を選択します。
5. [追加] を選択します。
6. メッセージが表示されたら、[ 確認] チェックボックスをオンにしてルールを追加します。
ポリシー OID でルールを作成するには:
1. [ポリシー OID] を選択します。
2. [ポリシー OID] に値を入力します。
3. [認証の強度] で、[単一要素認証] を選択します。
4. アフィニティバインドの場合は、[低] を選択してアフィニティバインドを選択します。
5. [追加] を選択します。
6. メッセージが表示されたら、[ 確認] チェックボックスをオンにしてルールを追加します。
発行者とポリシー OID でルールを作成するには:
1. [ 証明書の発行者 ] と [ ポリシー OID] を選択します。
2. 発行者を選択し、ポリシー OID を入力します。
3. [認証の強度] で、[多要素認証] を選択します。
4. アフィニティバインドの場合は、[低] を選択します。
5. [追加] を選択します。
6. 3.4.5.6のポリシー OID を持ち、CN=CBATestRootProdによって発行される証明書で認証します。多要素要求に対して認証が成功することを確認します。
発行者とシリアル番号でルールを作成するには:
1. 認証バインドポリシーを追加します。このポリシーでは、ポリシー OID が 1.2.3.4.6 のCN=CBATestRootProdによって発行された証明書には、高アフィニティバインドのみが必要です。発行者とシリアル番号が使用されます。
2. 証明書フィールドを選択します。この例では、 発行者とシリアル番号を選択します。
3. サポートされている唯一のユーザー属性は certificateUserIdsです。 certificateUserIdsを選択し、[追加] を選択します。
4. [保存] を選択します。
  
  サインインログには、サインインに使用されたバインドと証明書の詳細が表示されます。
[ OK] を 選択してカスタムルールを保存します。

重要

オブジェクト識別子の形式を使用して、ポリシー OID を入力します。たとえば、証明書ポリシーに [すべての発行ポリシー] と表示されている場合は、規則を追加するときに 2.5.29.32.0 としてポリシー OID を入力します。 すべての発行ポリシーという文字列はルールエディターに対して無効であり、有効になりません。

手順 4: ユーザー名バインドポリシーを構成する

ユーザー名バインドポリシーは、ユーザーの証明書を検証するのに役立ちます。既定では、ユーザーを特定するために、証明書の プリンシパル名 をユーザーオブジェクトの userPrincipalName にマップします。

認証ポリシー管理者は、既定値をオーバーライドし、カスタムマッピングを作成できます。詳細については、「ユーザー名のバインドのしくみ」を参照してください。

certificateUserIds属性を使用するその他のシナリオについては、「証明書ユーザー ID」を参照してください。

重要

ユーザー名バインドポリシーでユーザーオブジェクトの certificateUserIds、 onPremisesUserPrincipalName、 userPrincipalName 属性などの同期属性が使用されている場合、オンプレミスの Windows Server Active Directory の管理アクセス許可を持つアカウントは、Microsoft Entra ID のこれらの属性に影響する変更を加えることができます。たとえば、ユーザーオブジェクトに対する委任された権限を持つアカウントや、Microsoft Entra Connect Server の管理者ロールを持つアカウントでは、これらの種類の変更を行うことができます。

X.509 証明書フィールドのいずれかを選択してユーザー属性の 1 つとバインドし、ユーザー名バインドを作成します。ユーザー名のバインド順序は、バインドの優先順位を表します。最初のユーザー名バインドの優先度が最も高いなどです。

指定した X.509 証明書フィールドが証明書で見つかったが、Microsoft Entra ID で対応する値を持つユーザーオブジェクトが見つからない場合、認証は失敗します。次に、Microsoft Entra ID は、リスト内の次のバインディングを試みます。
[保存] を選択します。

最終的な構成は、次の例のようになります。

手順 5: 構成をテストする

このセクションでは、証明書とカスタム認証バインド規則をテストする方法について説明します。

証明書をテストする

最初の構成テストで、デバイスブラウザーを使用して MyApps ポータルへのサインインを試みます。

ユーザープリンシパル名 (UPN) を入力します。
[次へ] を選択します。

電話によるサインインや FIDO2 など、他の認証方法を使用できるようにすると、ユーザーに別のサインインダイアログが表示されることがあります。
[証明書を使用してサインイン] を選択します。
クライアント証明書ピッカー UI で適切なユーザー証明書を選択し、[ OK] を選択します。
MyApps ポータルにサインインしていることを確認します。

サインインが成功した場合、次のことがわかります。

ユーザー証明書はテストデバイスにプロビジョニングされます。
Microsoft Entra ID は、信頼できる CA を使用するように正しく構成されています。
ユーザー名のバインドが正しく構成されています。ユーザーが見つかり、認証されます。

カスタム認証バインドルールをテストする

次に、強力な認証を検証するシナリオを完了します。 2 つの認証ポリシー規則を作成します。1 つは単一要素認証を満たす発行者のサブジェクトを使用し、もう 1 つは多要素認証を満たすためにポリシー OID を使用します。

単一要素認証の保護レベルで発行者のサブジェクトルールを作成します。 CA サブジェクト値に値を設定します。

次に例を示します。

CN=WoodgroveCA
多要素認証の保護レベルを持つポリシー OID ルールを作成します。証明書のポリシー OID のいずれかに値を設定します。たとえば 1.2.3.4 です。
ユーザーが MFA を要求するための Microsoft Entra 条件付きアクセスポリシーを作成します。「条件付きアクセス - MFA を要求する」で説明されている手順を完了します。
MyApps ポータルに移動します。 UPN を入力し、[次へ] を選択します。
[ 証明書またはスマートカードを使用する] を選択します。

電話によるサインインやセキュリティキーなど、他の認証方法を使用できるようにした場合、ユーザーに別のサインインダイアログが表示されることがあります。
クライアント証明書を選択し、[ 証明書情報] を選択します。

証明書が表示され、発行者とポリシー OID の値を確認できます。
ポリシー OID 値を表示するには、[ 詳細] を選択します。
クライアント証明書を選択し、[OK] を選択します。

証明書のポリシー OID は、 1.2.3.4 の構成された値と一致し、MFA を満たします。証明書の発行者は、 CN=WoodgroveCA の構成された値と一致し、単一要素認証を満たします。

ポリシー OID ルールは発行者ルールよりも優先されるため、証明書は MFA を満たします。

ユーザーの条件付きアクセスポリシーには MFA が必要であり、証明書は MFA を満たすので、ユーザーはアプリケーションにサインインできます。

ユーザー名バインドポリシーをテストする

ユーザー名のバインドポリシーは、ユーザーの証明書を検証するために役立ちます。ユーザー名バインドポリシーでは、次の 3 つのバインドがサポートされています。

IssuerAndSerialNumber > certificateUserIds
IssuerAndSubject > certificateUserIds
Subject > certificateUserIds

既定では、Microsoft Entra ID は、証明書の プリンシパル名 をユーザーオブジェクトの userPrincipalName にマップして、ユーザーを特定します。認証ポリシー管理者は、前に説明したように、既定値をオーバーライドし、カスタムマッピングを作成できます。

認証ポリシー管理者は、新しいバインディングを設定する必要があります。準備するには、ユーザーオブジェクトの certificateUserIds 属性で、対応するユーザー名バインドの正しい値が更新されていることを確認する必要があります。

クラウドのみのユーザーの場合は、 Microsoft Entra 管理センターまたは Microsoft Graph API を使用して、 certificateUserIdsの値を更新します。
オンプレミスの同期されたユーザーの場合は、Microsoft Entra Connect を使用して、 Microsoft Entra Connect ルールに従うか、 AltSecId 値を同期することで、オンプレミスの値を同期します。

重要

発行者、サブジェクト、シリアル番号の値の形式は、証明書の形式の逆の順序にする必要があります。 発行者またはサブジェクトの値にスペースを追加しないでください。

発行者とシリアル番号の手動マッピング

次の例では、発行者とシリアル番号の手動マッピングを示します。

追加する 発行者 の値は次のとおりです。

C=US,O=U.SGovernment,OU=DoD,OU=PKI,OU=CONTRACTOR,CN=CRL.BALA.SelfSignedCertificate

発行者の値の手動マッピングを示すスクリーンショット。

シリアル番号の正しい値を取得するには、次のコマンドを実行します。 certificateUserIdsに表示される値を格納します。

コマンド構文は次のとおりです。

certutil –dump –v [~certificate path~] >> [~dumpFile path~]

次に例を示します。

certutil -dump -v firstusercert.cer >> firstCertDump.txt

certutil コマンドの例を次に示します。

certutil -dump -v C:\save\CBA\certs\CBATestRootProd\mfausercer.cer 

X509 Certificate: 
Version: 3 
Serial Number: 48efa06ba8127299499b069f133441b2 

   b2 41 34 13 9f 06 9b 49 99 72 12 a8 6b a0 ef 48

certificateUserIdに追加するシリアル番号の値は次のとおりです。

b24134139f069b49997212a86ba0ef48

certificateUserIds値は次のとおりです。

X509:<I>C=US,O=U.SGovernment,OU=DoD,OU=PKI,OU=CONTRACTOR,CN=CRL.BALA.SelfSignedCertificate<SR> b24134139f069b49997212a86ba0ef48

発行者とサブジェクトの手動マッピング

次の例では、発行者とサブジェクトの手動マッピングを示します。

発行者の値は次のとおりです。

複数のバインドで使用した場合の発行者の値を示すスクリーンショット。

Subject 値は次のとおりです。

[件名] の値を示すスクリーンショット。

certificateUserId値は次のとおりです。

X509:<I>C=US,O=U.SGovernment,OU=DoD,OU=PKI,OU=CONTRACTOR,CN=CRL.BALA.SelfSignedCertificate<S> DC=com,DC=contoso,DC=corp,OU=UserAccounts,CN=FirstUserATCSession

サブジェクトの手動マッピング

次の例では、サブジェクトの手動マッピングを示します。

Subject 値は次のとおりです。

別の [件名] 値を示すスクリーンショット。

certificateUserIds値は次のとおりです。

X509:<S>DC=com,DC=contoso,DC=corp,OU=UserAccounts,CN=FirstUserATCSession

アフィニティバインドをテストする

少なくとも認証ポリシー管理者ロールが割り当てられているアカウントを使用して、Microsoft Entra 管理センターにサインインします。
Entra ID>Authentication メソッド>Policies に移動します。
[ 管理] で、 認証方法>Certificate ベースの認証を選択します。
[構成] をクリックします。
テナントレベルで必要なアフィニティバインドを設定します。

重要

テナント全体のアフィニティ設定は、慎重に行って下さい。テナントの 必須アフィニティバインド の値を変更し、ユーザーオブジェクトに正しい値がない場合は、テナント全体をロックアウトすることがあります。同様に、すべてのユーザーに適用され、アフィニティの高いバインドが必要なカスタムルールを作成すると、テナント内のユーザーがロックアウトされる可能性があります。
テストするには、[ 必要なアフィニティバインド] で [ 低] を選択します。
サブジェクトキー識別子 (SKI) などの高アフィニティバインディングを追加します。 [ ユーザー名のバインド] で、[ ルールの追加] を選択します。
[SKI] を選択し、[追加] を選択します。

完了すると、ルールは次の例のようになります。
すべてのユーザーオブジェクトについて、 certificateUserIds 属性をユーザー証明書の正しい SKI 値で更新します。

詳細については、「CertificateUserID のサポートされるパターン」を参照してください。
認証バインディング用のカスタム規則を作成します。
[追加] を選択します。

完成したルールが次の例のようになります。
9.8.7.5の証明書とポリシー OID の適切な SKI 値を使用して、ユーザーのcertificateUserIds値を更新します。
ポリシー OID が 9.8.7.5の証明書を使用してテストします。ユーザーが SKI バインディングで認証されていること、および MFA と証明書のみでサインインするように求められることを確認します。

Microsoft Graph API を使用して CBA を設定する

Microsoft Graph API を使用して CBA を設定し、ユーザー名バインドを構成するには:

Microsoft Graph エクスプローラーに移動します。
[ Graph Explorer にサインイン] を選択し、テナントにサインインします。
Policy.ReadWrite.AuthenticationMethodの委任されたアクセス許可に同意するには、手順に従います。

すべての認証方法を取得します。

GET  https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy

X.509 証明書認証方法の構成を取得します。

GET https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy/authenticationMethodConfigurations/X509Certificate

既定では、X.509 証明書の認証方法はオフになっています。ユーザーが証明書を使用してサインインできるようにするには、認証方法を有効にし、更新操作を通じて認証ポリシーとユーザー名バインドポリシーを構成する必要があります。ポリシーを更新するには、 PATCH 要求を実行します。

リクエストの本文

PATCH https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/x509Certificate
Content-Type: application/json

{
    "@odata.type": "#microsoft.graph.x509CertificateAuthenticationMethodConfiguration",
    "id": "X509Certificate",
    "state": "enabled",
    "certificateUserBindings": [
        {
            "x509CertificateField": "PrincipalName",
            "userProperty": "onPremisesUserPrincipalName",
            "priority": 1
        },
        {
            "x509CertificateField": "RFC822Name",
            "userProperty": "userPrincipalName",
            "priority": 2
        }, 
        {
            "x509CertificateField": "PrincipalName",
            "userProperty": "certificateUserIds",
            "priority": 3
        }
    ],
    "authenticationModeConfiguration": {
        "x509CertificateAuthenticationDefaultMode": "x509CertificateSingleFactor",
        "rules": [
            {
                "x509CertificateRuleType": "issuerSubject",
                "identifier": "CN=WoodgroveCA ",
                "x509CertificateAuthenticationMode": "x509CertificateMultiFactor"
            },
            {
                "x509CertificateRuleType": "policyOID",
                "identifier": "1.2.3.4",
                "x509CertificateAuthenticationMode": "x509CertificateMultiFactor"
            }
        ]
    },
    "includeTargets": [
        {
            "targetType": "group",
            "id": "all_users",
            "isRegistrationRequired": false
        }
    ]
}

204 No content応答コードが返されることを確認します。 GET要求を再実行して、ポリシーが正しく更新されていることを確認します。
ポリシーを満たす証明書でサインインして、構成をテストします。

Microsoft PowerShell を使用して CBA を設定する

PowerShell を開きます。

Microsoft Graph に接続します。

Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"

CBA ユーザーのグループを定義するために使用する変数を作成します。
```
$group = Get-MgGroup -Filter "displayName eq 'CBATestGroup'"
```

要求本文を定義します。

$body = @{
"@odata.type" = "#microsoft.graph.x509CertificateAuthenticationMethodConfiguration"
"id" = "X509Certificate"
"state" = "enabled"
"certificateUserBindings" = @(
    @{
        "@odata.type" = "#microsoft.graph.x509CertificateUserBinding"
        "x509CertificateField" = "SubjectKeyIdentifier"
        "userProperty" = "certificateUserIds"
        "priority" = 1
    },
    @{
        "@odata.type" = "#microsoft.graph.x509CertificateUserBinding"
        "x509CertificateField" = "PrincipalName"
        "userProperty" = "UserPrincipalName"
        "priority" = 2
    },
    @{
        "@odata.type" = "#microsoft.graph.x509CertificateUserBinding"
        "x509CertificateField" = "RFC822Name"
        "userProperty" = "userPrincipalName"
        "priority" = 3
    }
)
"authenticationModeConfiguration" = @{
    "@odata.type" = "#microsoft.graph.x509CertificateAuthenticationModeConfiguration"
    "x509CertificateAuthenticationDefaultMode" = "x509CertificateMultiFactor"
    "rules" = @(
        @{
            "@odata.type" = "#microsoft.graph.x509CertificateRule"
            "x509CertificateRuleType" = "policyOID"
            "identifier" = "1.3.6.1.4.1.311.21.1"
            "x509CertificateAuthenticationMode" = "x509CertificateMultiFactor"
        }
    )
}
"includeTargets" = @(
    @{
        "targetType" = "group"
        "id" = $group.Id
        "isRegistrationRequired" = $false
    }
) } | ConvertTo-Json -Depth 5

PATCH要求を実行します。

Invoke-MgGraphRequest -Method PATCH -Uri "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/x509Certificate" -Body $body -ContentType "application/json"

フィードバック

このページはお役に立ちましたか?

Last updated on 2025-08-16