Microsoft Entra 証明書ベースの認証を構成する方法
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.mcirosoftonline.us で使用される Entra ID エンドポイントが含まれます。 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 を構成する必要があります。 次の図に示すとおり、ロールベースのアクセス制御を使用して、最小特権の管理者だけが変更を加える必要があるようにしています。 CA を構成できるのは、グローバル管理者ロールのみです。
必要に応じて、証明書を単一要素または多要素認証にマップする認証バインドを構成し、証明書フィールドをユーザー オブジェクトの属性にマップするユーザー名バインドを構成することもできます。 認証ポリシー管理者は、ユーザー関連の設定を構成できます。 すべての構成が完了したら、テナントで Microsoft Entra CBA を有効にします。
手順 1: 証明機関を構成する
Microsoft Entra 管理センターまたは Microsoft Graph REST API とサポートされている SDK (Microsoft Graph PowerShell など) を使って、証明機関 (CA) を構成できます。 PKI インフラストラクチャまたは PKI 管理者は、発行元 CA の一覧を提供できる必要があります。 すべての CA の構成が済んだことを確認するには、ユーザー証明書を開き、[証明のパス] タブをクリックして、ルートが Entra 信頼ストアにアップロードされるまですべての CA を確認します。 足りない CA がある場合、CBA 認証は失敗します。
Microsoft Entra 管理センターを使用して証明機関を構成する
Microsoft Entra 管理センターで証明書ベースの認証を有効にし、ユーザー バインドを構成するには、次の手順を実行します。
Microsoft Entra 管理センターにグローバル管理者としてサインインします。
[保護]>[更に表示]>[Security Center] (または[ID セキュリティ スコア]) >[証明機関] の順に移動します。
CA をアップロードするには、[アップロード] を選択します。
CA ファイルを選択します。
CA がルート証明書の場合は [はい] を選択し、それ以外の場合は [いいえ] を選択します。
[証明書失効リスト URL] には、失効したすべての証明書を含む CA ベース CRL のインターネットに接続する URL を設定します。 URL が設定されていない場合、失効した証明書を使用した認証が失敗しません。
[デルタ証明書失効リストの URL] には、最後のベース CRL が発行されて以降に失効したすべての証明書を含む CRL のインターネットに接続する URL を設定します。
[追加] を選択します。
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) |
ヒント
前の例の crlDistributionPoint の値は、CA の証明書失効リスト (CRL) がある場所の http です。 この値は複数の場所で確認できます。
- CA から発行された証明書の CRL 配布ポイント (CDP) 属性。
発行元 CA が Windows Server を実行している場合:
詳細については、「証明書の失効プロセスについて」を参照してください。
証明機関の構成を検証する
上記の構成手順の結果が、証明機関信頼チェーンを検証し、構成された証明機関 CRL 配布ポイント (CDP) から証明書失効リスト (CRL) を正常に取得する Entra ID 機能であることを確認することが重要です。 このタスクの支援として、MSIdentity Tools PowerShell モジュールをインストールし、Test-MsIdCBATrustStoreConfiguration を実行することをお勧めします。 この PowerShell コマンドレットは、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 管理センターにサインインします。
[保護]、[認証方法]、[ポリシー] の順に進みます。
[管理] で、[認証方法]>[証明書ベースの認証] を選択します。
[構成] を選択して、認証バインドとユーザー名バインドを設定します。
保護レベル属性の既定値は、単一要素認証です。 [多要素認証] を選択して既定値を多要素認証に変更します。
Note
カスタム ルールを追加しない場合は、既定の保護レベル値が有効になります。 カスタム ルールを追加した場合は、代わりにルール レベルで定義された保護レベルが適用されます。
また、カスタム認証バインド規則を設定して、クライアント証明書の保護レベルの決定に役立てることもできます。 これは、証明書の発行者のサブジェクトまたはポリシー OID フィールドを使用して構成できます。
認証バインド規則によって、証明書属性 (発行者またはポリシー OID) が値にマップされ、その規則に対して既定の保護レベルが選択されます。 複数のルールを作成できます。
カスタム ルールを追加するには、[ルールの追加] をクリックします。
証明書の発行者別のルールを作成するには、[証明書の発行者] を選択します。
リスト ボックスから [証明書の発行者識別子] を選択します。
[多要素認証]、[低] アフィニティ バインドを選択し、次に [追加] をクリックします。 メッセージが表示されたら、[確認しました] をクリックしてルールの追加を完了します。
ポリシー OID でルールを作成するには、[ポリシー OID] を選択します。
[ポリシー OID] の値を入力します。
[多要素認証]、[低] アフィニティ バインドを選択し、次に [追加] をクリックします。 メッセージが表示されたら、[確認しました] をクリックしてルールの追加を完了します。 .
発行者とポリシー OID でルールを作成するには:
[証明書の発行者] と [ポリシー OID] を選択します。
発行者を選択し、ポリシー OID を入力します。
[認証の強度] で、[単一要素認証] または [多要素認証] を選択します。
アフィニティ バインドの場合は、[低] を選択します。
[追加] を選択します。
ポリシー OID が 3.4.5.6 で CN=CBATestRootProd によって発行された証明書で認証します。 認証をパスして多要素クレームを取得します。
重要
Entra テナント管理者が発行元 OID とポリシー OID の両方を使用して CBA 認証ポリシー ルールを構成すると、次のような一部のデバイス登録シナリオに影響する既知の問題があります。
- Windows Hello for Business の加入契約
- Fido2 セキュリティ キーの登録
- Windows パスワードレス電話サインイン
"ワークプレースに参加させる"、Entra ID、ハイブリッド Entra ID のデバイス参加シナリオによるデバイスの登録は影響を受けません。 発行元 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 の管理特権を持つアカウント (ユーザー オブジェクトに対する委任された権限や Entra Connect Server の管理権限を持つアカウントなど) が、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 を有効にし、ユーザー名バインドを構成するには、次の手順を実行します。
Note
次の手順では、米国政府クラウドでは使用できない Graph エクスプローラーを使用します。 米国政府のクラウド テナントでは、Postman を使用して Microsoft Graph のクエリをテストできます。
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 要求を再実行して、ポリシーが正しく更新されていることを確認します。ポリシーを満たす証明書でサインインして、構成をテストします。