Microsoft Entra 証明書ベースの認証を構成する方法

[アーティクル]
12/03/2024

Microsoft Entra 証明書ベースの認証 (CBA) を使用すると、組織はアプリやブラウザーのサインイン時に Enterprise 公開キー基盤 (PKI) によって作成された X.509 証明書を使用して認証を許可または要求するように Microsoft Entra テナントを構成できます。この機能により、組織は x.509 証明書を使用したフィッシングに強い最新のパスワードレス認証を採用することができます。

サインイン時に、パスワードを入力する代わりに、証明書で認証するオプションもユーザーに表示されます。一致する証明書がデバイスに複数存在する場合、ユーザーは使用するものを選択できます。証明書がユーザーアカウントに対して検証され、成功すればサインインとなります。

Office 365 Enterprise および US Government プランのテナントに Microsoft Entra CBA を構成して使用するには、次の手順に従います。公開キー基盤 (PKI) が構成済みである必要があります。

前提条件

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

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

重要

PKI がセキュリティで保護され、容易に侵害されないことを確認します。侵害が発生した場合、攻撃者はクライアント証明書を作成して署名し、テナント内のすべてのユーザー (オンプレミスから同期されたユーザーとクラウド専用ユーザーの両方) を侵害する可能性があります。しかし、強力なキー保護戦略に加え、HSM アクティブ化カードや成果物を安全に保管するためのトークンなど、その他の物理的および論理的コントロールにより、外部攻撃者や内部脅威による PKI 整合性の侵害を防ぐための多重防御を実現できます。詳細については、PKI の保護に関する記事をご覧ください。

重要

アルゴリズムの選択、キーの長さ、データ保護を含む Microsoft 暗号化のベストプラクティスについては、Microsoft の推奨事項にアクセスしてください。推奨されるアルゴリズムの 1 つ、キーの長さ、NIST で承認された曲線を必ず使用してください。

重要

継続的なセキュリティ強化の一環として、Azure/M365 エンドポイントは TLS 1.3 のサポートを追加しています。このプロセスは、Azure/M365 全体の何千ものサービスエンドポイントをカバーするのに数か月かかることが予想されます。これには、Microsoft Entra 証明書ベース認証 (CBA) *.certauth.login.microsoftonline.com および *.certauth.login.microsoftonline.us で使用される Microsoft Entra エンドポイントが含まれます。 TLS 1.3 は、2 つのエンドポイント間のセキュリティで保護された通信チャネルを提供するためにデータを暗号化する、インターネットで最もデプロイされているセキュリティプロトコルの最新バージョンです。 TLS 1.3 は、古い暗号アルゴリズムを排除し、古いバージョンよりもセキュリティを強化し、できるだけ多くのハンドシェイクを暗号化することを目的としています。開発者には、アプリケーションとサービスで TLS 1.3 のテストを開始することを強くお勧めします。

Note

PKI を評価するときは、証明書の発行ポリシーと適用を確認することが重要です。前述のように、Microsoft Entra 構成に証明機関 (CA) を追加すると、それらの CA によって発行された証明書で Microsoft Entra ID のすべてのユーザーを認証できます。このため、CA が証明書の発行をいつどのように許可されるか、また、再利用可能な識別子をどのように実装するかを検討することが重要です。管理者が、ユーザーの認証に特定の証明書のみを使用できるようにする必要がある場合、管理者は高アフィニティバインドのみを使用して、特定の証明書でのみユーザーを認証できるという、より高いレベルの保証を実現する必要があります。詳細については、高アフィニティバインドに関するページを参照してください。

Microsoft Entra CBA を構成およびテストする手順

Microsoft Entra CBA を有効にする前に、いくつかの構成手順を完了する必要があります。まず、管理者は、ユーザー証明書を発行する信頼された CA を構成する必要があります。次の図に示すとおり、ロールベースのアクセス制御を使用して、最小特権の管理者だけが変更を加える必要があるようにしています。

この機能を管理するには、全体管理者が必要です。

必要に応じて、証明書を単一要素または多要素認証にマップする認証バインドを構成し、証明書フィールドをユーザーオブジェクトの属性にマップするユーザー名バインドを構成することもできます。認証ポリシー管理者は、ユーザー関連の設定を構成できます。すべての構成が完了したら、テナントで Microsoft Entra CBA を有効にします。

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

手順 1: PKI ベースの信頼ストアを使用して認証局を構成する (プレビュー)

Entra には、新しい公開キー基盤 (PKI) ベースの認証局 (CA) 信頼ストアがあります。 PKI ベースの CA 信頼ストアは、異なる PKI ごとにコンテナーオブジェクト内に CA を保持します。管理者は、1 つのフラットな CA リストを管理するよりも簡単に、PKI に基づいてコンテナー内に CA を管理できます。

PKI ベースの信頼ストアでは、CA の数と各 CA ファイルのサイズに対する制限が高くなります。 PKI ベースの信頼ストアでは、最大 250 個の CA と、CA オブジェクトごとに 8 KB のサイズがサポートされます。 CA を格納するために、新しい PKI ベースの信頼ストアを使用することを強くお勧めします。このストアはスケーラブルであり、発行者のヒントなどの新機能をサポートします。

Note

CA を構成するために以前の信頼ストアを使用している場合、PKI ベースの信頼ストアを構成することをお勧めします。

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

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

重要

新しいストアに関する既知の問題のため、古いストア内のすべての CA を削除せず、古いストアに少なくとも 1 つの CA を使用しないことをお勧めします。制限を取り除くために、問題の修正に取り組んでいます。

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

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

PKI コンテナーオブジェクトを作成します。
認証ポリシー管理者として、Microsoft Entra 管理センターにサインインします。
[保護]>[表示数を増やす ]>[Security Center] (または[ID セキュリティスコア]) >[公開キー基盤] (プレビュー) の順に移動します。
[+ Create PKI]$+ PKI の作成$ を選択します。
[表示名] を入力します。
Create をクリックしてください。
[列] を選択して列を追加または削除します。
[最新の情報に更新] を選択して、PKI の一覧を更新します。

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

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

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

PKI コンテナーに CA をアップロードするには、次の手順を実行します。
1. [+ Add certificate authority]$+ 認証局の追加$ を選択します。
2. CA ファイルを選択します。
3. CA がルート証明書の場合は [はい] を選択し、それ以外の場合は [いいえ] を選択します。
4. [証明書失効リスト URL] には、失効したすべての証明書を含む CA ベース CRL のインターネットに接続する URL を設定します。 URL が設定されていない場合、失効した証明書を使用した認証は失敗しません。
5. [デルタ証明書失効リストの URL] には、最後のベース CRL が発行されて以降に失効したすべての証明書を含む CRL のインターネットに接続する URL を設定します。
6. [Issuer hints]$発行者のヒント$ フラグは、既定で有効になっています。 CA が発行者ヒントに含まれないようにする場合、[Issuer hints]$発行者のヒント$ をオフにします。
7. [保存] を選択します。
8. CA 証明書を削除するには、証明書を選択し、[削除] を選択します。
9. [列] を選択して列を追加または削除します。
10. [最新の情報に更新] を選択して、CA の一覧を更新します。

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

すべての CA を PKI コンテナーに一度にアップロードするには、次の手順を実行します。
1. PKI コンテナーオブジェクトを作成するか、開きます。
2. [Upload PKI]$PKI のアップロード$ を選択します。
3. .p7b ファイルが使用可能な HTTP インターネット接続 URL を入力します。
4. ファイルの SHA256 チェックサムを入力します。
5. アップロードを選択します。
6. PKI のアップロードは、非同期プロセスです。各 CA がアップロードされると、PKI で使用できるようになります。 PKI のアップロードが完了するには、最大で 30 分かかることがあります。
7. [最新の情報に更新] を選択して、CA を更新します。
PKI .p7b ファイルの SHA256 チェックサムを生成するには、次のコマンドを実行します。
```
Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256
```

PKI を編集する

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

CA を編集する

CA を編集するには、CA 行で [...] を選択し、[編集] を選択します。
認証局の種類 (ルートまたは中間)、CRL URL、Delta CRL URL、発行者ヒントが有効なフラグの新しい値を必要に応じて入力し、[保存] を選択します。

PKI を復元する

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

CA を復元する

[Deleted CA]$削除された CA$ タブを選択します。
CA ファイルを選択し、[Restore certificate authority]$認証局の復元$ を選択します。

CA の isIssuerHintEnabled 属性について

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

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

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

同じルート証明書から複数の中間 CA がエンドユーザー証明書を発行する場合、既定では、すべての証明書が証明書ピッカーに表示されます。ただし、isIssuerHintEnabled を特定の CA に対して true に設定すると、証明書ピッカーに適切なユーザー証明書のみが表れます。 isIssuerHintEnabled を有効にするには、CA を編集し、値を true に更新します。

Microsoft Graph API を使用して認証局を構成する

Microsoft Graph API を使用して CA を構成できます。次の例は、Microsoft Graph を使用して PKI または CA の作成、読み取り、更新、削除 (CRUD) の各操作を実行する方法を示しています。

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

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/microsoftgraph/installation) を使用できます。

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 に対する CRUD 操作は、Microsoft Entra 監査ログに記録されます。

監査ログのダイアグラム。

よく寄せられる質問

質問: PKI のアップロードが失敗するのはなぜですか?

回答: PKI ファイルが有効であり、問題なくアクセスできるかどうかを確認してください。 PKI ファイルの最大サイズ以下である必要があります

質問: PKI のアップロードのサービスレベルアグリーメント (SLA) は何ですか?

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

質問: PKI ファイルの SHA256 チェックサムは、どのような方法で生成しますか?

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

Get-FileHash .\CBARootPKI.p7b -Algorithm SHA256

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

重要

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

Microsoft Entra 管理センターで CBA を有効にするには、次の手順を実行します。

少なくとも認証ポリシー管理者として Microsoft Entra 管理センターにサインインします。
[グループ]>[すべてのグループ]> を参照し、[新しいグループ] を選んで CBA ユーザー用のグループを作成します。
[保護]>[認証方法]>[証明書ベースの認証] の順に移動します。
[有効とターゲット] で [有効] を選択します。
[グループの追加] を選択して、作成したグループのような特定のグループを選択します。 [すべてのユーザー] でなく、特定のグループを使用します。

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

Note

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

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

認証バインドポリシーは、認証の強度を単一要素か多要素のいずれかに決定するのに役立ちます。テナントでの証明書の既定の保護レベルは、単一要素認証です。

認証ポリシー管理者は、既定値を単一要素から多要素に変更したり、カスタムポリシールールを構成したりできます。認証バインドルールは、発行者、ポリシー OID、発行者とポリシーオブジェクト ID (OID) などの証明書属性を値にマップされ、そのルールの既定の保護レベルを選択します。複数のルールを作成できます。

Microsoft Entra 管理センターでテナントの既定の設定を変更するには、次の手順のようにします。

少なくとも認証ポリシー管理者として Microsoft Entra 管理センターにサインインします。
[保護]、>、[ポリシー] の順に進みます。
[管理] で、[認証方法]>[証明書ベースの認証] を選択します。
[構成] を選択して、認証バインドとユーザー名バインドを設定します。
保護レベル属性の既定値は、単一要素認証です。 [多要素認証] を選択して既定値を MFA に変更します。

Note

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

認証バインドルールによって、証明書属性 (発行者またはポリシー OID) が値にマップされ、そのルールに対して既定の保護レベルが選択されます。複数のルールを作成できます。

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

証明書の発行者別のルールを作成するには、[証明書の発行者] を選択します。
1. リストボックスから [証明書の発行者識別子] を選択します。
2. [多要素認証]、[低] アフィニティバインドを選択し、次に [追加] をクリックします。メッセージが表示されたら、[確認しました] をクリックしてルールの追加を完了します。
ポリシー OID でルールを作成するには、[ポリシー OID] を選択します。
1. [ポリシー OID] の値を入力します。
2. [多要素認証]、[低] アフィニティバインドを選択し、次に [追加] をクリックします。メッセージが表示されたら、[確認しました] をクリックしてルールの追加を完了します。
発行者とポリシー OID でルールを作成するには:
1. [証明書の発行者] と [ポリシー OID] を選択します。
2. 発行者を選択し、ポリシー OID を入力します。
3. [認証の強度] で、[単一要素認証] または [多要素認証] を選択します。
4. アフィニティバインドの場合は、[低] を選択します。
5. [追加] を選択します。
6. ポリシー OID が 3.4.5.6 で CN=CBATestRootProd によって発行された証明書で認証します。認証をパスして多要素クレームを取得します。

重要

Microsoft Entra テナント認証ポリシー管理者が発行者とポリシー OID の両方を使用して CBA 認証ポリシールールを構成した場合の既知の問題があります。この問題は、次のような一部のデバイス登録シナリオに影響します。

Windows Hello for Business の加入契約
FIDO2 セキュリティキーの登録
Windows パスワードレス電話サインイン

Workplace Join、Microsoft Entra ID、Hybrid Microsoft Entra デバイス参加シナリオを使用したデバイスの登録は影響を受けません。発行元 OID またはポリシー OID を使用する CBA 認証ポリシールールは影響を受けません。軽減するには、管理者は次を実行する必要があります。

発行者とポリシー OID の両方のオプションを使用する証明書ベースの認証ポリシールールを編集します。発行者またはポリシー OID の要件を削除し、保存します。 -または-
発行者とポリシー OID の両方を使用する認証ポリシールールを削除します。発行者またはポリシー OID のみを使用するルールを作成します。

現在、この問題の修正に向けて取り組んでいます。

発行者とシリアル番号でルールを作成するには:

認証バインドポリシーを追加します。このポリシーでは、CN=CBATestRootProd によって発行され、policyOID 1.2.3.4.6 を持つすべての証明書に、高いアフィニティバインドのみが必要であることが求められます。発行者とシリアル番号が使用されます。
証明書フィールドを選択します。この例では、発行者とシリアル番号を選択します。
サポートされている唯一のユーザー属性は CertificateUserIds です。 [追加] を選択します。
[保存] を選択します。

サインインログには、サインインに使用されたバインドと、証明書の詳細が表示されます。
[OK] を選択して、任意のカスタムルールを保存します。

重要

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

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

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

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

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

重要

ユーザー名バインドポリシーで同期された属性 (ユーザーオブジェクトの certificateUserIds、onPremisesUserPrincipalName、userPrincipalName 属性など) を使用する場合、Active Directory で管理特権を持つアカウント (たとえば、ユーザーオブジェクトに対する委任された権限または Microsoft Entra Connect サーバーに対する管理権限を持つもの) では、Microsoft Entra ID のこれらの属性に影響する変更を行うことができます。

X.509 証明書フィールドのいずれかを選択してユーザー属性の 1 つとバインドし、ユーザー名バインドを作成します。ユーザー名のバインド順序は、バインドの優先順位を表します。 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 の要求に関する記事の手順に従って、ユーザーに多要素認証を要求するための条件付きアクセスポリシーを作成します。
MyApps ポータルに移動します。 UPN を入力し、[次へ] を選択します。
[証明書を使用してサインイン] を選択します。

電話によるサインインやセキュリティキーなどの他の認証方法を有効にしている場合、ユーザーには別のサインイン画面が表示される場合があります。
クライアント証明書を選択し、[証明書情報] を選択します。
証明書が表示され、発行者とポリシー OID の値を確認できます。
ポリシー OID の値を表示するには、[詳細] を選択します。
クライアント証明書を選択し、[OK] を選択します。
証明書のポリシー OID は、構成された値 1.2.3.4 と一致しており、多要素認証を満たすことになります。同様に、証明書の発行者は、構成された値 CN=WoodgroveCA と一致しており、単一要素認証を満たすことになります。
ポリシー OID ルールは発行者ルールよりも優先されるので、証明書は多要素認証を満たすことになります。
ユーザーの条件付きアクセスポリシーは 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 値を同期することでオンプレミスから値を同期します。

重要

Issuer、Subject、SerialNumber の値の形式は、証明書内の書式と逆の順序にする必要があります。発行者またはサブジェクトにスペースを入れないでください。

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

発行者とシリアル番号の手動マッピングの例を次に示します。追加する発行者の値は次のとおりです。

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 に追加する SerialNumber 値は次のとおりです。

b24134139f069b49997212a86ba0ef48

CertificateUserId:

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

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

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

複数のバインドで使われる場合の発行者の値のスクリーンショット。

サブジェクトの値は次のとおりです。

サブジェクト値のスクリーンショット。

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

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

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

別のサブジェクト値のスクリーンショット。

CertificateUserId:

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

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

少なくとも認証ポリシー管理者として Microsoft Entra 管理センターにサインインします。
[保護]、>、[ポリシー] の順に進みます。
[管理] で、[認証方法]>[証明書ベースの認証] を選択します。
[構成] をクリックします。
テナントレベルで必要なアフィニティバインドを設定します。

重要

テナント全体のアフィニティ設定には注意が必要です。テナントで必要なアフィニティバインドを変更して、ユーザーオブジェクトに適切な値がない場合は、テナント全体をロックアウトできます。同様に、すべてのユーザーに適用され、高いアフィニティバインドが必要なカスタムルールを作成すると、テナント内のユーザーがロックアウトされる可能性があります。
テストするには、必要なアフィニティバインドに対して [低] を選択します。
SKI などの高いアフィニティバインドを追加します。 [ユーザー名のバインド] で [ルールの追加] を選択します。
[SKI] を選択し、[追加] を選択します。

完了すると、ルールは次のスクリーンショットのようになります。
すべてのユーザーオブジェクトの CertificateUserIds 属性を更新して、ユーザー証明書から SKI の正しい値を取得します。詳細については、「CertificateUserID のサポートされるパターン」を参照してください。
認証バインドのカスタム規則を作成します。
[追加] を選択します。

完了すると、ルールは次のスクリーンショットのようになります。
ポリシー OID 9.8.7.5 の証明書から適切な SKI 値でユーザーの CertificateUserIds を更新します。
ポリシー OID 9.8.7.5 の証明書を使用してテストすると、ユーザーは SKI バインドで認証され、証明書のみで MFA を取得できるはずです。

Microsoft Graph API を使用して CBA を有効にする

Graph API を使用して CBA を有効にし、ユーザー名バインドを構成するには、次の手順を実行します。

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

次のように、すべての認証方法を取得します。

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

次のように、x509 証明書の認証方法の構成を取得します。

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

既定では、x509 証明書の認証方法は無効になっています。ユーザーが証明書を使用してサインインできるようにするには、更新操作によって認証方法を有効にし、認証とユーザー名バインドのポリシーを構成する必要があります。ポリシーを更新するには、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"

次の方法で共有

Microsoft Entra 証明書ベースの認証を構成する方法

前提条件

Microsoft Entra CBA を構成およびテストする手順

手順 1: PKI ベースの信頼ストアを使用して認証局を構成する (プレビュー)

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

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

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

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

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

PKI を編集する

CA を編集する

PKI を復元する

CA を復元する

CA の isIssuerHintEnabled 属性について

Microsoft Graph API を使用して認証局を構成する

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

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

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

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

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

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

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

監査ログ

よく寄せられる質問

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

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

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

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

証明書をテストする

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

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

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

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

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

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

Microsoft Graph API を使用して CBA を有効にする

要求本文:

Microsoft PowerShell を使用して CBA を有効にする

次のステップ

フィードバック

その他のリソース

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

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

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

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

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

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

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

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

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

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

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