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

[アーティクル]
10/04/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: 証明機関を構成する

Microsoft Entra 管理センターまたは Microsoft Graph REST API とサポートされている SDK (Microsoft Graph PowerShell など) を使って、証明機関 (CA) を構成できます。 PKI インフラストラクチャまたは PKI 管理者は、発行元 CA の一覧を提供できる必要があります。すべての CA の構成が済んだことを確認するには、ユーザー証明書を開き、[証明のパス] タブをクリックして、ルートが Microsoft Entra ID 信頼ストアにアップロードされるまですべての CA を確認します。足りない CA がある場合、CBA 認証は失敗します。

Microsoft Entra 管理センターを使用して証明機関を構成する

Microsoft Entra 管理センターで証明書ベースの認証を有効にし、ユーザーバインドを構成するには、次の手順を実行します。

Microsoft Entra 管理センターにグローバル管理者としてサインインします。
[保護]>[更に表示]>[Security Center] (または[ID セキュリティスコア]) >[証明機関] の順に移動します。
CA をアップロードするには、[アップロード] を選択します。
1. CA ファイルを選択します。
2. CA がルート証明書の場合は [はい] を選択し、それ以外の場合は [いいえ] を選択します。
3. [証明書失効リスト URL] には、失効したすべての証明書を含む CA ベース CRL のインターネットに接続する URL を設定します。 URL が設定されていない場合、失効した証明書を使用した認証が失敗しません。
4. [デルタ証明書失効リストの URL] には、最後のベース CRL が発行されて以降に失効したすべての証明書を含む CRL のインターネットに接続する URL を設定します。
5. [追加] を選択します。
CA 証明書を削除するには、証明書を選択し、[削除] を選択します。
[列] を選択して列を追加または削除します。

Note

既存の CA の有効期限が切れた場合、新しい CA のアップロードは失敗します。有効期限が切れたCAはすべて削除し、新しいCAのアップロードをやり直してください。

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

PowerShell を使って証明機関 (CA) を構成する

信頼された CA に対してサポートされている CRL 配布ポイント (CDP) は 1 つのみです。 CDP には HTTP URL のみを指定できます。オンライン証明書状態プロトコル (OCSP)、またはライトウェイトディレクトリアクセスプロトコル (LDAP) の URL はサポートされていません。

Microsoft Entra ID で証明機関を構成するには、証明機関ごとに次のものをアップロードします。

証明書の公開部分 ( .cer 形式)
証明書失効リスト (CRL) が存在する、インターネットに接続する URL

証明機関のスキーマは次のようになります。

    class TrustedCAsForPasswordlessAuth
    {
       CertificateAuthorityInformation[] certificateAuthorities;
    }

    class CertificateAuthorityInformation

    {
        CertAuthorityType authorityType;
        X509Certificate trustedCertificate;
        string crlDistributionPoint;
        string deltaCrlDistributionPoint;
        string trustedIssuer;
        string trustedIssuerSKI;
    }

    enum CertAuthorityType
    {
        RootAuthority = 0,
        IntermediateAuthority = 1
    }

構成には、Microsoft Graph PowerShell を使用できます。

Windows PowerShell を管理者特権で起動します。
Microsoft Graph PowerShell をインストールします。
```
    Install-Module Microsoft.Graph
```

構成の最初の手順では、テナントとの接続を確立する必要があります。テナントへの接続が確立されるとすぐに、ディレクトリに定義されている信頼された証明機関をレビュー、追加、削除、および変更できます。

のインスタンスに接続するときには、

テナントとの接続を確立するには、Connect-MgGraph を使います。

    Connect-MgGraph

Retrieve

ディレクトリで定義されている信頼された証明機関を取得するには、Get-MgOrganizationCertificateBasedAuthConfiguration を使います。

    Get-MgOrganizationCertificateBasedAuthConfiguration

追加

Note

既存の CA のいずれかが期限切れになると、新しい CA のアップロードは失敗します。テナント管理者は、期限切れの CA を削除してから、新しい CA をアップロードする必要があります。

上記の手順に従って、Microsoft Entra 管理センターに CA を追加します。

AuthorityType

ルート証明機関を示すには、0 を使用します
中間または発行元の証明機関を示すには 1 を使用します

crlDistributionPoint

CRL をダウンロードし、CA 証明書と CRL 情報を比較して、前の PowerShell 例の crlDistributionPoint 値が、追加する CA に対して有効であることを検証できます。

次の表と図は、CA 証明書の情報とダウンロードした CRL の属性との対応関係を表しています。

CA 証明書の情報	=	ダウンロードされた CRL 情報
サブジェクト	=	発行者
サブジェクトキー識別子	=	機関キー識別子 (KeyID)

CA 証明書と CRL 情報を比較します。

ヒント

前の例の crlDistributionPoint の値は、CA の証明書失効リスト (CRL) がある場所の http です。この値は複数の場所で確認できます。

CA から発行された証明書の CRL 配布ポイント (CDP) 属性。

発行元 CA が Windows Server を実行している場合:

証明機関 Microsoft 管理コンソール (MMC) の CA の [プロパティ]。
CA (certutil -cainfo cdp を実行)。詳細については、「certutil」を参照してください。

詳細については、「証明書の失効プロセスについて」を参照してください。

Microsoft Graph API を使用して証明機関を構成する

MS Graph API を使用して、証明機関を構成できます。 certificatebasedauthconfiguration MSGraph コマンドの手順に従って、Microsoft Entra 証明機関信頼ストアを更新してください。

証明機関の構成を検証する

上記の構成手順の結果として、Microsoft Entra で、証明機関信頼チェーンを検証し、構成された証明書機関 CRL 配布ポイント (CDP) から証明書失効リスト (CRL) を正常に取得できることを確認することが重要です。このタスクの支援として、MSIdentity Tools PowerShell モジュールをインストールし、Test-MsIdCBATrustStoreConfiguration を実行することをお勧めします。この PowerShell コマンドレットでは、Microsoft Entra テナント証明機関の構成を確認し、一般的な構成ミスの問題に関するエラー/警告を表示します。

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

重要

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

Microsoft Entra 管理センターで証明書ベースの認証を有効にするには、次の手順を実行します。

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

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

Note

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

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

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

認証ポリシー管理者は、既定値を単一要素から多要素に変更したり、カスタムポリシールールを構成したりできます。認証バインディング規則は、発行者、ポリシー OID、発行者とポリシー 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 の要件を削除して保存します。 OR
発行元 OID とポリシー OID の両方を現在使用している認証ポリシールールを削除し、発行元 OID またはポリシー OID のみを使用してルールを作成します

問題を修正中です。

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

ポリシー OID 1.2.3.4.6 で CN=CBATestRootProd によって発行された任意の証明書を要求する認証バインドポリシーを追加します。このポリシーでは、高いアフィニティバインドのみが必要となります（つまり、発行者とシリアル番号が使用されます）。
証明書フィールドを選択します。この例では、発行者とシリアル番号を選択します。
サポートされている唯一のユーザー属性は 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 にマップしてユーザーを特定します。認証ポリシー管理者は、手順 4 で説明したように、既定値をオーバーライドし、カスタムマッピングを作成できます。

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

クラウドのみのユーザーの場合は、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: 証明機関を構成する

Microsoft Entra 管理センターを使用して証明機関を構成する

PowerShell を使って証明機関 (CA) を構成する

のインスタンスに接続するときには、

Retrieve

追加

Microsoft Graph API を使用して証明機関を構成する

証明機関の構成を検証する

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

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

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

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

証明書をテストする

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

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

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

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

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

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

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

要求本文:

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

次のステップ

フィードバック

その他のリソース

次の方法で共有

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

前提条件

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

手順 1: 証明機関を構成する

Microsoft Entra 管理センターを使用して証明機関を構成する

PowerShell を使って証明機関 (CA) を構成する

のインスタンスに接続するときには、

Retrieve

追加

Microsoft Graph API を使用して証明機関を構成する

証明機関の構成を検証する

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

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

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

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

証明書をテストする

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

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

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

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

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

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

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

要求本文:

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

次のステップ

フィードバック

その他のリソース

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

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

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

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

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