Microsoft Entra の証明書ベースの認証に関する技術的な詳細情報

[アーティクル]
08/30/2024

この記事では、Microsoft Entra の証明書ベースの認証 (CBA) のしくみについて説明し、Microsoft Entra の CBA 構成に関する技術の詳細について掘り下げます。

Microsoft Entra の証明書ベースの認証のしくみ

次の画像は、Microsoft Entra CBA が有効なテナント内のアプリケーションにユーザーがサインインしようとするとどうなるかを示しています。

Microsoft Entra の証明書ベースの認証がどのように機能するかの手順を示す図。

次に、各手順について説明します。

ユーザーが Myapps ポータルなどのアプリケーションにアクセスしようとしています。
ユーザーがまだサインインしていない場合、ユーザーは https://login.microsoftonline.com/ の Microsoft Entra ID の [ユーザーサインイン] ページにリダイレクトされます。
ユーザーが Microsoft Entra のサインインページにユーザー名を入力し、[次へ] を選択します。 Microsoft Entra ID が、テナント名を使ってホーム領域の検出を行い、ユーザー名を使ってそのテナントでユーザーが検索されます。
Microsoft Entra ID により、テナントで CBA が有効になっているかどうかが確認されます。 CBA が有効な場合、ユーザーにはパスワードページに [Use a certificate or smartcard] (証明書またはスマートカードを使用する) のリンクが表示されます。ユーザーにサインインリンクが表示されない場合は、テナントで CBA が有効になっていることを確認してください。詳細については、Microsoft Entra CBA を有効にする方法に関する説明を参照してください。

Note

テナントで CBA が有効になっている場合は、[パスワード] ページで [証明書またはスマートカードを使用する] へのリンクがすべてのユーザーに表示されます。ただし、CBA の対象になるユーザーのみが、Microsoft Entra ID を ID プロバイダー (IdP) として使用するアプリケーションに対して正常に認証できます。

電話によるサインインやセキュリティキーなどの他の認証方法を有効にしている場合、ユーザーには別のサインイン画面が表示される場合があります。
ユーザーが証明書ベースの認証を選ぶと、クライアントは certauth エンドポイント (パブリック Microsoft Entra ID の場合は https://certauth.login.microsoftonline.com) にリダイレクトされます。 Azure Government の場合、certauth エンドポイントは https://certauth.login.microsoftonline.us です。

エンドポイントは TLS 相互認証を実行し、TLS ハンドシェイクの一部としてクライアント証明書を要求します。この要求のエントリがサインインログに表示されます。

Note

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

TLS 検査の無効化が、発行者ヒントを含む新しい URL に対しても機能することを確認してください。 tenantId に url をハードコーディングしないでください。B2B ユーザーの場合に変更される可能性があるためです。正規表現を使用して、古い URL と新しい URL の両方で TLS 検査の無効化が使用できるようにしてください。たとえば、プロキシに応じて、*.certauth.login.microsoftonline.com または *certauth.login.microsoftonline.com を使用します。 Azure Government では、*.certauth.login.microsoftonline.us または *certauth.login.microsoftonline.us を使用します。

アクセスが許可されていない場合、発行者ヒントを有効にすると証明書ベースの認証は失敗します。
Microsoft Entra ID がクライアント証明書を要求します。クライアント証明書を選択し、[OK] を選択します。
Microsoft Entra ID が証明書失効リストを検証して、証明書が失効しておらず、有効であることを確認します。 Microsoft Entra ID が、証明書フィールドの値をユーザー属性値にマッピングすることで、テナントで構成されたユーザー名のバインドを使ってユーザーが識別されます。
多要素認証を必須とする条件付きアクセスポリシーを使って一意のユーザーが見つかり、証明書認証のバインド規則が MFA を満たす場合、Microsoft Entra ID によってそのユーザーはすぐにサインインできるようになります。 MFA が必要であるが、証明書が満たしているのが 1 つの要素のみの場合、パスワードレスサインインまたは FIDO2 のいずれかが既に登録されていれば、第 2 要素として提供されます。
Microsoft Entra ID が、サインインが成功したことを示すプライマリ更新トークンを送信することによって、サインインプロセスを完了させます。
ユーザーはサインインが成功すると、アプリケーションにアクセスできます。

発行者ヒントについて (プレビュー)

発行者ヒントは、TLS ハンドシェイクの一部として信頼された CA を示す情報を送り返します。信頼された CA 一覧は、テナントによって Entra 信頼ストアにアップロードされた証明機関 (CA) のサブジェクトに設定されます。ブラウザークライアントまたはネイティブアプリケーションクライアントは、サーバーから返されたヒントを使用して、証明書ピッカーに表示される証明書をフィルター処理します。クライアントには、信頼ストア内の CA によって発行された認証証明書のみが表示されます。

発行者ヒントを有効にする

有効にするには、[発行者ヒント] チェックボックスをクリックします。認証ポリシー管理者は、TLS 検査が有効になっているプロキシが正しく更新されていることを確認した後、[確認しました] をクリックして保存する必要があります。

Note

組織に TLS 検査が適用されたファイアウォールまたはプロキシがある場合は、使用中の特定のプロキシに応じてカスタマイズされた、[*.]certauth.login.microsoftonline.com の任意の名前と一致することが可能な certauth エンドポイントの TLS 検査を無効にしていることを確認します。

発行者ヒントを有効にする方法のスクリーンショット。

Note

発行者ヒントが有効になった後の証明機関 URL の形式は t{tenantId}.certauth.login.microsoftonline.com になります。

発行者ヒントが有効になった後の証明書ピッカーのスクリーンショット。

CA 信頼ストアの更新の伝達

発行者ヒントを有効にして信頼状態から CA を追加、更新、または削除した後、発行者ヒントがクライアントに反映されるまでに最大 10 分の遅延が発生します。ヒントが伝達されるまで、ユーザーは新しい CA によって発行された証明書で認証できません。

認証ポリシー管理者は、発行者ヒントを有効にして伝達を開始した後、証明書でサインインする必要があります。 CA 信頼ストアの更新が伝達されると、ユーザーには以下のエラーメッセージが表示されます。

更新が処理中の場合にユーザーに表示されるエラーのスクリーンショット。

証明書ベースの認証の MFA 機能

Microsoft Entra CBA は、多要素認証 (MFA) に対応しています。 Microsoft Entra CBA は、テナントの構成に応じて、単一要素 (SF) または多要素 (MF) のいずれかになります。 CBA を有効にすると、ユーザーが潜在的に MFA を完了できるようになります。ユーザーが CBA の対象になっているときに、他の認証方法を登録するために MFA を取得し、プルーフアップするには追加の構成が必要になる場合があります。

CBA が有効になっているユーザーに単一要素 (SF) 証明書のみがあり、MFA を完了する必要がある場合:

パスワードと SF 証明書を使用します。
一時アクセスパスを発行します。
認証ポリシー管理者が電話番号を追加し、音声/テキストメッセージ認証をユーザーアカウントに許可します。

CBA 対応ユーザーがまだ証明書を発行していなくて、MFA を完了する必要がある場合:

一時アクセスパスを発行します。
認証ポリシー管理者が電話番号を追加し、音声/テキストメッセージ認証をユーザーアカウントに許可します。

CBA 対応ユーザーが MF 証明書を使用できず (スマートカードのサポートがないモバイルデバイスを使用しているなど)、MFA を完了する必要がある場合:

一時アクセスパスを発行します。
ユーザーが別の MFA メソッドを登録する必要があります (ユーザーが MF 証明書を使用できるとき)。
パスワードと MF 証明書を使用します (ユーザーが MF 証明書を使用できるとき)。
認証ポリシー管理者が電話番号を追加し、音声/テキストメッセージ認証をユーザーアカウントに許可します。

単一要素証明書ベース認証を使用する MFA

Microsoft Entra CBA は、認証の第 1 要素と第 2 要素の両方としてサポートされています。サポートされている組み合わせの一部は次のとおりです。

CBA (第 1 要素) とパスキー (第 2 要素)
CBA (第 1 要素) とパスワードレス電話サインイン (第 2 要素)
CBA (第 1 要素) と FIDO2 セキュリティキー (第 2 要素)
パスワード (第 1 要素) + CBA (第 2 要素) (プレビュー)

Note

iOS の第 2 要素としての CBA には既知の問題があり、iOS ではブロックされます。現在この問題の解決に取り組んでおり、iOS でサポートされるはずです。

ユーザーには、MFA を受ける方法が必要であり、Microsoft Entra CBA を使用してサインインするには事前にパスワードレスサインインまたは FIDO2 を登録しておく必要があります。

重要

CBA 方法の設定に含まれているとき、ユーザーは MFA を実行できるとみなされます。つまり、このユーザーは、他の利用可能な方法を登録するために、認証の一部としてプルーフアップを使用できません。有効な証明書を持たないユーザーが CBA 方法の設定に含められないようにしてください。認証のしくみの詳細については、「Microsoft Entra多要素認証」を参照してください。

CBA でパスワードレスの電話によるサインイン (PSI) を設定する手順

パスワードレスサインインを機能させるには、ユーザーはモバイルアプリを使用してレガシ通知を無効にする必要があります。

少なくとも認証ポリシー管理者として Microsoft Entra 管理センターにサインインします。
「パスワードレスの電話によるサインイン認証を有効にする」方法に関する記事の手順に従ってください。

重要

前述の構成で、[パスワードレス] オプションを選択していることを確認します。 PSI 用に追加されたグループの認証モードを [パスワードレス] に変更する必要があります。 [任意] を選択した場合、CBA と PSI は機能しません。
[保護]>[多要素認証]>[追加のクラウドベースの多要素認証設定] の順に選択します。
[検証オプション] で、[モバイルアプリによる通知] をオフにして [保存] を選択します。

単一要素証明書を持つ、パスワードレスサインインを構成したユーザーの例を見てみましょう。

ユーザープリンシパル名 (UPN) を入力し、[次へ] を選択します。
[証明書を使用してサインイン] を選択します。

電話によるサインインや FIDO2 セキュリティキーなどの他の認証方法を有効にしている場合、ユーザーには別のサインイン画面が表示される場合があります。
クライアント証明書ピッカーで正しいユーザー証明書を選択し、[OK] を選択します。
証明書は単一要素認証強度として構成されているため、ユーザーは MFA 要件を満たすための第 2 要素が必要になります。使用可能な第 2 要素 (このケースではパスワードレスサインイン) がユーザーに表示されます。 [Microsoft Authenticator アプリで要求を承認する] を選択します。
携帯電話に通知が届きます。 [サインインを承認しますか?] を選択します。
ブラウザーまたはアプリ画面に表示される数値を Microsoft Authenticator に入力します。
[はい] を選択すると、ユーザーが認証とサインインを行うことができます。

認証バインドポリシーについて

認証バインドポリシーは、認証の強度を単一要素か多要素のいずれかに決定するのに役立ちます。認証ポリシー管理者は、既定値を単一要素から多要素に変更することや、証明書の発行者のサブジェクト、ポリシー OID または発行者およびポリシー OID フィールドを使用してカスタムポリシー構成を設定することができます。

証明書の強度

認証ポリシー管理者は、証明書の強度が単一要素であるか多要素であるかを決定できます。詳細については、Microsoft Entra の認証方式に対する NIST 認証の保証レベルに関するドキュメントを参照してください。これは、NIST 800-63B SP 800-63B の「デジタル ID ガイドライン: 認証とライフサイクル管理」に基づいています。

多要素証明書認証

ユーザーが多要素証明書を持っている場合、証明書を使った多要素認証のみを実行できます。ただし、認証ポリシー管理者は、多要素と見なされるように証明書を PIN または生体認証で保護する必要があります。

Microsoft Entra ID の複数の認証ポリシーバインド規則の解決方法

複数のカスタム認証バインディングポリシールールは、発行元 + ポリシー OID の使用、またはポリシー OID か発行元のみの使用など、異なる証明書フィールドを使用して作成できるためです。以下は、カスタムルールが重複する場合の認証保護レベルを決定するために使用される手順です。手順は次のとおりです:

発行元 + ポリシー OID ルールは、ポリシー OID ルールよりも優先されます。ポリシー OID ルールは、証明書発行者ルールよりも優先されます。
発行元 + ポリシー OID ルールが最初に評価されます。発行元 CA1 とポリシー OID 1.2.3.4.5 を持つ MFA が有効なカスタムルールがある場合は、証明書 A のみが両方の発行元値を満たし、ポリシー OID に MFA が付与されます。
次に、ポリシー OID を使用するカスタムルールが評価されます。証明書 A のポリシー OID が 1.2.3.4.5 で、その証明書に基づく派生資格情報 B のポリシー OID が 1.2.3.4.5.6 で、カスタムルールのポリシーOID の値が MFA に 1.2.3.4.5 と定義されている場合、MFA を満たすのは証明書 A のみで、資格情報 B が満たすのは単一要素認証のみです。ユーザーがサインイン時に派生した資格情報を使用し、MFA を使用するように構成されている場合、ユーザーは認証を成功させるために第 2 要素を要求されます。
複数のポリシー OID 間に競合がある場合 (たとえば、証明書に 2 つのポリシー OID が設定されており、一方が単一要素認証にバインドされ、他方が MFA にバインドされている場合)、その証明書を単一要素認証として扱います。
次に、発行元 CA を使用するカスタムルールが評価されます。
証明書にポリシー OID と発行元の両方が設定されている場合、常にポリシー OID が最初にチェックされ、ポリシールールが見つからない場合は、発行元のバインディングがチェックされます。ポリシー OID は、認証バインドが強力で発行者よりも優先度が高いです。
1 つの CA が MFA にバインドされている場合、この CA によって発行されるすべてのユーザー証明書は MFA として適格となります。単一要素認証にも同じロジックが適用されます。
1つのポリシー OID が MFA にバインドしている場合、このポリシー OID を OID の1つとして含むすべてのユーザー証明書 (ユーザー証明書は複数のポリシー OID を持つことができます) が MFA として適格となります。
1 つの証明書発行元は、有効な強力な認証バインディングを 1 つだけ設定できます (つまり、証明書は単一要素と MFA の両方にバインディングすることはできません)。

重要

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 のみを使用してルールを作成します

問題を修正中です。

ユーザー名のバインドポリシーについて

ユーザー名のバインドポリシーは、ユーザーの証明書を検証するために役立ちます。既定では、証明書のサブジェクト代替名 (SAN) のプリンシパル名は、ユーザーを特定するユーザーオブジェクトの UserPrincipalName 属性にマップされます。

証明書バインドを使ってセキュリティを強化する

証明書バインドには、7 つの方法がサポートされています。一般に、マッピングの種類が再利用できない識別子 (サブジェクトキー識別子、SHA1 公開キーなど) に基づいている場合は、高アフィニティとみなされます。これらの識別子は、個々のユーザーを認証するために使用できる証明書が 1 つのみであることをより確実に保証するものです。

ユーザー名とメールアドレスに基づくマッピングの種類は、低アフィニティとみなされます。 Microsoft Entra ID は、再利用可能な識別子に基づいて、低アフィニティとみなされる 3 つのマッピングを実装します。その他のバインドは、高アフィニティバインドとみなされます。詳細については、certificateUserIds に関する記事を参照してください。

証明書マッピングフィールド	certificateUserIds の値の例	ユーザーオブジェクト属性	種類
プリンシパル名	`X509:<PN>bob@woodgrove.com`	userPrincipalName onPremisesUserPrincipalName certificateUserIds	低アフィニティ
RFC822Name	`X509:<RFC822>user@woodgrove.com`	userPrincipalName onPremisesUserPrincipalName certificateUserIds	低アフィニティ
IssuerAndSubject (プレビュー)	`X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest`	certificateUserIds	低アフィニティ
件名 (プレビュー)	`X509:<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest`	certificateUserIds	低アフィニティ
SKI	`X509:<SKI>aB1cD2eF3gH4iJ5kL6-mN7oP8qR=`	certificateUserIds	高アフィニティ
SHA1PublicKey	`X509:<SHA1-PUKEY>aB1cD2eF3gH4iJ5kL6-mN7oP8qR`	certificateUserIds	高アフィニティ
IssuerAndSerialNumber（プレビュー）	`X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT` シリアル番号の正しい値を取得するには、このコマンドを実行し、CertificateUserIds に示されている値を格納します。構文： `Certutil –dump –v [~certificate path~] >> [~dumpFile path~]` 例: `certutil -dump -v firstusercert.cer >> firstCertDump.txt`	certificateUserIds	高アフィニティ

テナントレベルでアフィニティバインドを定義し、カスタムルールでオーバーライドする（プレビュー）

この機能を使用すると、認証ポリシー管理者は、低アフィニティまたは高アフィニティのユーザー名バインドマッピングのどちらかを使用してユーザーを認証できるかどうかを構成できます。すべてのユーザーに適用される、テナントに必要なアフィニティバインドを設定できます。また、発行者とポリシー OID、ポリシー OID、または発行者に基づいてカスタム規則を作成することで、テナント全体の既定値をオーバーライドすることもできます。

Microsoft Entra ID の複数のユーザー名ポリシーバインド規則の解決方法

優先順位 (最小数) が最も高いバインドを使用します。

ユーザー名またはユーザープリンシパル名を使ってユーザーオブジェクトを検索します。
CBA 認証方法の構成で、認証ポリシー管理者によって設定されたすべてのユーザー名バインドの一覧を "priority" 属性で並べ替えて取得します。現在、優先順位の概念はポータル UX では公開されていません。グラフでは、各バインディングの優先度属性が返され、評価プロセスで使用されます。
テナントで高アフィニティバインディングが有効になっている場合、または証明書の値が高アフィニティバインディングを必要とするカスタムルールと一致する場合は、一覧から低アフィニティバインディングをすべて削除します。
認証が成功するまで、リスト内の各バインディングを評価します。
提示された証明書に X.509 証明書フィールドがある場合、Microsoft Entra ID は、証明書フィールドの値をユーザーオブジェクトの属性値と照合します。
1. 一致するものが見つかった場合、ユーザー認証は成功します。
2. 一致するものが見つからない場合は、次の優先順位のバインドに移ります。
提示された証明書に X.509 証明書フィールドが存在しない場合は、次の優先順位のバインドに移ります。
構成されているすべてのユーザー名バインディングのうち、1 つでも一致するものが見つかり、ユーザー認証が成功するまで検証します。
構成されているユーザー名バインディングのいずれにも一致するものが見つからない場合、ユーザー認証は失敗します。

ユーザー名バインディングが複数ある Microsoft Entra 構成のセキュリティ保護

Microsoft Entra ユーザーアカウントに証明書をバインディングするために使用できる各 Microsoft Entra ユーザーオブジェクト属性 (userPrincipalName、onPremiseUserPrincipalName、certificateUserIds) には、1 つの証明書が 1 つの Microsoft Entra ユーザーアカウントにのみ一致する必要があるという一意の制約があります。ただし、Microsoft Entra CBA では、ユーザー名バインドポリシーで複数のバインド方法がサポートされているため、認証ポリシー管理者は 1 つの証明書で複数の Microsoft Entra ユーザーアカウント構成に対応できます。

重要

複数のバインドを構成する場合、CBA は各バインドを検証してユーザーを認証するため、Microsoft Entra CBA 認証は、最も低いアフィニティバインドと同じくらい安全です。 1 つの証明書が複数の Microsoft Entra アカウントと一致するシナリオを防ぐために、認証ポリシー管理者は次のことができます。

ユーザー名バインドポリシーで 1 つのバインド方法を構成します。
テナントに複数のバインド方法が構成されており、1 つの証明書を複数のアカウントにマップすることを許可しない場合、認証ポリシー管理者は、ポリシーに構成されているすべての許可された方法が同じ Microsoft Entra アカウントにマップされるようにする必要があります。すべてのユーザーアカウントには、すべてのバインドに一致する値が必要です。
テナントに複数のバインディング方法が構成されている場合、認証ポリシー管理者は、複数の低アフィニティバインディングがないことを確認する必要があります。

たとえば、PrincipalName を UPN に、SubjectKeyIdentifier (SKI) を certificateUserIds にマッピングした2つのユーザー名バインドがあるとします。証明書を 1 つのアカウントにのみ使用する場合、認証ポリシー管理者は、そのアカウントに証明書に存在する UPN があることを確認し、同じアカウントの certificateUserId 属性に SKI マッピングを実装する必要があります。

1 つの Microsoft Entra ユーザーアカウントでの複数の証明書のサポート (M:1)

組織が 1 つの ID に対して複数の証明書を発行するシナリオがあります。最も一般的な方法は、モバイルデバイスの派生認証情報、またはセカンダリスマートカード、Yubikey などの x509 認証情報ホルダー対応デバイスの場合です。

クラウド専用アカウント クラウド専用アカウントの場合は、certificateUserIds フィールド (ユーザーポータルの承認情報) に各証明書を識別する一意の値を設定することで、使用する複数の証明書 (最大 5 つ) をマップできます。組織で高アフィニティバインディング (発行元 + SerialNumber) を使用している場合、CertificateUserIds 内の値は次のようになります。

X509:DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
X509:DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>eF3gH4iJ5kL6mN7oP8-qR9sT0uV

この例では、最初の値は X509Certificate1 を表し、2 番目の値は X509Certificate2 を表します。ユーザーは、サインイン時にいずれかの証明書を提示できます。また、CBA ユーザー名バインドが certificateUserIds フィールドを指すように設定されている限り、特定のバインディングの種類 (この例では Issuer + SerialNumber) を検索すると、ユーザーは正常にサインインします。

ハイブリッド同期アカウント 同期されたアカウントの場合、AD の altSecurityIdentities フィールドに各証明書を識別する値を入力することで、複数の証明書をマップして使用できます。組織が高いアフィニティ (つまり、強力な認証) バインディングを使用している場合、たとえば Issuer + SerialNumber であれば次のようになります。

X509:DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
X509:DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>eF3gH4iJ5kL6mN7oP8-qR9sT0uV

この例では、最初の値は X509Certificate1 を表し、2 番目の値は X509Certificate2 を表します。これらの値は、Microsoft Entra ID の certificateUserIds フィールドに同期する必要があります。

複数の Microsoft Entra ユーザーアカウントを持つ 1 つの証明書のサポート (1:M)

一部のシナリオでは、組織のユーザーが同じ証明書を使用して複数の ID に対して認証を行う必要があります。最も一般的なのは、管理アカウントの場合です。また、開発者アカウントまたは一時的な職務アカウントの場合もあります。従来の AD では、altSecurityIdentities フィールドを使用して証明書の値を設定し、ログイン時にヒントを使用して、ログインにチェックする目的のアカウントに AD を転送します。 Microsoft Entra CBA ではこのようになっておらず、ヒントはありません。代わりに、ホーム領域検出は、証明書の値をチェックする目的のアカウントを識別します。もう 1 つの主な違いは、Microsoft Entra CBA が certificateUserIds フィールドに一意性を要求することです。これは、2 つのアカウントが両方とも同じ証明書値を設定することはできないことを意味します。

重要

異なる Microsoft Entra アカウントに対して同じ資格情報を使用して認証することは安全性の高い構成ではなく、1 つの証明書を複数の Microsoft Entra ユーザーアカウントに対して許可しないことをお勧めします。

クラウド専用アカウント クラウド専用アカウントの場合、複数のユーザー名バインディングを作成する必要があり、証明書を使用する各ユーザーアカウントに一意の値をマップする必要があります。各アカウントは、異なるユーザー名バインディングを使用して認証されます。これは、1 つのディレクトリ/テナントの境界内に適用されます (つまり、認証ポリシー管理者は、アカウントごとに値が一意である限り、別のディレクトリ/テナントで使用するために証明書をマップすることもできます)。

certificateUserIds フィールド (ユーザーポータルの承認情報) に、目的の証明書を識別する一意の値を設定します。組織で高いアフィニティバインディング (つまり、強力な認証) バインドを使用している場合、たとえば Issuer + SerialNumber と SKI は次のようになります。

ユーザー名のバインディング:

発行元 + シリアル番号 -> CertificateUserIds
SKI -> CertificateUserIds

ユーザーアカウントの certificateUserIds 値:
X509:DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>aB1cD2eF3gH4iJ5kL6-mN7oP8qR
X509:<SKI>cD2eF3gH4iJ5kL6mN7-oP8qR9sT

いずれかのユーザーがサインイン時に同じ証明書を提示すると、アカウントがその証明書の一意の値と一致するため、ユーザーは正常にサインインできます。 1 つのアカウントは、発行元 + SerialNumber を使用し、もう 1 つは SKI バインディングを使用して認証されます。

Note

この方法で使用できるアカウントの数は、テナントで構成されたユーザー名バインディングの数によって制限されます。組織で高アフィニティバインディングのみを使用している場合、サポートされるアカウントの数は 3 に制限されます。組織が低アフィニティバインディングも使用している場合、この数は 7 アカウント (1 PrincipalName、1 RFC822Name、1 SubjectKeyIdentifier、1 SHA1PublicKey、1 Issuer+Subject、1 Issuer+SerialNumber、1 Subject) に増加します。

ハイブリッド同期アカウント 同期されたアカウントの場合、アプローチは異なります。認証ポリシー管理者は、証明書を使用する各ユーザーアカウントに一意の値をマップできますが、Microsoft Entra ID の各アカウントにすべての値を設定する一般的な方法では、これが困難になります。代わりに、Microsoft Entra Connect では、アカウントごとの目的の値を、Microsoft Entra ID のアカウントに設定された一意の値にフィルター処理する必要があります。この一意のルールは、1 つのディレクトリ/テナントの境界内に適用されます (つまり、認証ポリシー管理者は、アカウントごとに値が一意である限り、別のディレクトリ/テナントで使用するために証明書をマップすることもできます)。さらに、組織には、1 つの Microsoft Entra テナントにユーザーを提供する複数の AD フォレストが存在する場合があります。この場合、Microsoft Entra Connect は、必要な一意の値のみをクラウドアカウントに設定するという同じ目的を持つこれらの各 AD フォレストにフィルターを適用します。

AD の altSecurityIdentities フィールドに、目的の証明書を識別する値を設定し、そのユーザーアカウントの種類 (詳細、管理者、開発者など) に必要な証明書の値を含めます。 AD で、ユーザーが評価しているユーザーアカウントの種類 (msDS-cloudExtensionAttribute1 など) を同期に指示するキー属性を選択します。この属性には、詳細ユーザー、管理者、開発者など、目的のユーザータイプの値を設定します。これがユーザーのプライマリアカウントの場合、値は空または null のままにすることができます。

アカウントは次のようになります。

フォレスト 1 - Account1 (bob@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

フォレスト 1 - Account2 (bob-admin@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

フォレスト 2 - ADAccount1 (bob-tdy@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

これらの値は、Microsoft Entra ID の certificateUserIds フィールドに同期する必要があります。

certificateUserIds に同期する手順

Metaverse に alternativeSecurityIds フィールドを追加するように Microsoft Entra Connect を構成する
AD フォレストごとに、優先順位が高い (100 未満の低い数値) 新しいカスタム受信ルールを構成します。 altSecurityIdentities フィールドをソースとして使用して式変換を追加します。ターゲット式では、選択して設定したキー属性と、定義したユーザー型へのマッピングが使用されます。
次に例を示します。

IIF((IsPresent([msDS-cloudExtensionAttribute1]) && IsPresent([altSecurityIdentities])), 
    IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("detailee"))>0), 
    Where($item,[altSecurityIdentities],(InStr($item, "X509:<SHA1-PUKEY>")>0)), 
        IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("developer"))>0), 
        Where($item,[altSecurityIdentities],(InStr($item, "X509:<SKI>")>0)), NULL) ), 
    IIF(IsPresent([altSecurityIdentities]), 
    Where($item,[altSecurityIdentities],(BitAnd(InStr($item, "X509:<I>"),InStrRev($item, "<SR>"))>0)), NULL) 
)

上記の例では、altSecurityIdentities とキー属性 msDS-cloudExtensionAttribute1is が最初にチェックされ、それらが設定されているかどうかを確認します。そうでない場合は、altSecurityIdentities がチェックされ、設定されているかどうかを確認します。空の場合は、NULL に設定します。それ以外の場合、アカウントは既定のケースに該当し、この例では発行元 + SerialNumber マッピングのみにフィルター処理を行います。キー属性が設定されている場合、値がチェックされ、定義されたユーザー型のいずれかに等しいかどうかを確認します。この例では、その値が詳細ユーザーの場合、altSecurityIdentities から SHA1PublicKey 値にフィルター処理します。値が開発者の場合は、altSecurityIdentities から SubjectKeyIssuer 値にフィルター処理します。特定の種類の証明書値が複数存在する場合があります。たとえば、複数の PrincipalName 値、複数の SKI 値、SHA1-PUKEY 値などです。フィルターによって、最初に見つかった値だけでなくすべての値が取得され、Microsoft Entra ID に同期されます。

コントロール属性が空の場合に空の値をプッシュする方法を示す 2 番目の例を次に示します。

IIF((IsPresent([msDS-cloudExtensionAttribute1]) && IsPresent([altSecurityIdentities])), 
    IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("detailee"))>0), 
    Where($item,[altSecurityIdentities],(InStr($item, "X509:<SHA1-PUKEY>")>0)), 
        IIF((InStr(LCase([msDS-cloudExtensionAttribute1]),LCase("developer")>0), 
        Where($item,[altSecurityIdentities],(InStr($item, "X509:<SKI>")>0)), NULL) ), 
    IIF(IsPresent([altSecurityIdentities]), 
    AuthoritativeNull, NULL) 
)

altSecurityIdentities の値がコントロール属性の検索値と一致しない場合は、AuthoritativeNull が渡されます。これにより、alternativeSecurityId を設定する前またはそれ以降の規則が無視され、結果が Microsoft Entra ID で空になります。

優先順位が低い新しいカスタム送信ルールを構成します (160 よりも大きな数で、リストの最下位に)。
alternativeSecurityIds フィールドをソース、certificateUserIds フィールドをターゲットとして直接変換を追加します。
同期サイクルを実行して、Microsoft Entra ID のデータの作成を完了します。

各テナントの CBA が、証明書からマップしたフィールド型の certificateUserIds フィールドを指すユーザー名バインディングで構成されていることを確認します。これらのユーザーは、サインイン時に証明書を提示できるようになり、証明書の一意の値が certificateUserIds フィールドに対して検証された後、そのユーザーは正常にサインインされます。

証明書の失効プロセスについて

証明書の失効プロセスにより、認証ポリシー管理者は、以前に発行された証明書を取り消して、今後の認証に使用されないようにすることができます。証明書が失効しても、ユーザーに既に発行されているトークンは失効しません。「失効の構成」の手順に従って、トークンを手動で失効させます。

Microsoft Entra ID は、ユーザーの認証時に証明書が失効しているかどうかを確認するために、顧客の証明書失効リスト (CRL) を証明機関からダウンロードしてキャッシュします。

認証ポリシー管理者は、Microsoft Entra テナントの信頼された発行者のセットアッププロセス中に CRL の配布ポイントを構成することができます。信頼できる各発行者には、インターネット上の URL を使って参照できる CRL が必要です。

重要

対話型サインインでダウンロードとキャッシュに成功する Microsoft Entra ID の CRL の最大サイズは、パブリック Microsoft Entra ID では 20 MB、Azure US Government クラウドでは 45 MB です。また、CRL は 10 秒以内でダウンロードできる必要があります。 Microsoft Entra ID が CRL をダウンロードできない場合、対応する CA によって発行された証明書を使用する証明書ベースの認証は失敗します。ベストプラクティスは、CRL ファイルをサイズの制限内に収め、証明書の有効期間を妥当な制限内に保ち、期限切れの証明書をクリーンアップすることです。詳細については、CRL サイズに制限はありますかに関する記事を参照してください。

ユーザーが証明書を使用して対話型サインインを行い、CRL がクラウドに対する対話型の制限を超えたとき、初回サインインは次のエラーで失敗します。

"{uri} からダウンロードした証明書失効リスト (CRL) が、Microsoft Entra ID の CRL の最大許容サイズ ({size} バイト) を超過しています。 Try again in few minutes. If the issue persists, contact your tenant administrators. ({size} bytes) for CRLs in Azure Active Directory." ({uri} からダウンロードした証明書失効リスト (CRL) が、Azure Active Directory の CRL の最大許容サイズ ({size} バイト) を超えました。数分してからもう一度お試しください。問題が解決しない場合は、テナント管理者に問い合わせてください。)

このエラーの後、Microsoft Entra ID による CRL のダウンロード試行は、サービス側の制限 (パブリック Microsoft Entra ID の場合は 45 MB、Azure US Government クラウドの場合は 150 MB) の影響を受けます。

重要

認証ポリシー管理者が CRL の構成をスキップした場合、Microsoft Entra ID はユーザーの証明書ベースの認証時に CRL チェックを実行しません。これは初期のトラブルシューティングに役立ちますが、運用環境での使用は考えない方が良いでしょう。

現時点では、パフォーマンスと信頼性の理由から、オンライン証明書状態プロトコル (OCSP) はサポートされていません。 Microsoft Entra ID は、OCSP 用にクライアントブラウザーで接続のたびに CRL をダウンロードするのではなく、最初のサインイン時に一度ダウンロードしてキャッシュすることで、CRL 検証のパフォーマンスと信頼性を向上させています。また、キャッシュにインデックスを付けるので、検索は毎回ずっと速くなります。顧客は、証明書の失効のために CRL を発行する必要があります。

次の手順は、CRL チェックの一般的なフローです。

Microsoft Entra ID は、対応する信頼された発行者または証明機関の証明書を持つユーザーの最初のサインインイベントで、CRL のダウンロードを試行します。
Microsoft Entra ID は、後で使用するために CRL をキャッシュして再利用します。 CRL ドキュメントにある次の更新日と、利用可能な場合は次の CRL 発行日 （Windows Server CA で使用）が採用されます。
次の場合、ユーザー証明書ベースの認証は失敗します:
- 信頼できる発行者に対して CRL が構成されており、可用性、サイズ、または待機時間の制約により Microsoft Entra ID が CRL をダウンロードできません。
- ユーザーの証明書が CRL に失効済みとして表示されます。
- キャッシュされた CRL ドキュメントの有効期限が切れている場合、Microsoft Entra ID は配布ポイントから新しい CRL のダウンロードを試行します。

Note

Microsoft Entra ID が、発行元の CA と、ルート CA までの PKI 信頼チェーン内にある他の CA の CRL を確認します。 PKI チェーン内の CRL 検証には、リーフクライアント証明書から最大 10 個の CA という制限があります。この制限は、悪意のあるアクターが CRL サイズが大きく、膨大な数の CA を含む PKI チェーンをアップロードしてサービスを停止しないようにするためのものです。テナントの PKI チェーンに 5 つを超える CA があり、CA が侵害された場合、認証ポリシー管理者は、侵害を受けた信頼された発行者を Microsoft Entra テナント構成から削除する必要があります。

重要

CRL のキャッシュと公開サイクルの性質上、証明書が失効した場合は、Microsoft Entra ID の影響を受けたユーザーのすべてのセッションも失効させることをお勧めします。

現時点では、CRL のダウンロードを手動で強制または再トリガーする方法はありません。

失効を構成する方法

クライアント証明書を失効させるために、Microsoft Entra ID は、証明機関の情報の一部としてアップロードされた URL から証明書失効リスト (CRL) をフェッチし、キャッシュします。 CRL の最後の発行タイムスタンプ (発効日 プロパティ) を使用し、CRL がまだ有効であることを確認します。 CRL は定期的に参照されて、リストに含まれる証明書へのアクセスは無効になります。

即時の失効が必要な場合 (たとえば、ユーザーがデバイスを紛失した場合) は、ユーザーの認証トークンを無効にできます。認証トークンを無効にするには、Windows PowerShell を使用してこの特定のユーザーの StsRefreshTokenValidFrom フィールドを設定します。アクセスを無効にする各ユーザーの StsRefreshTokenValidFrom フィールドを更新する必要があります。

失効状態が継続していることを確認するには、CRL の発効日を StsRefreshTokenValidFrom で設定した値より後の日付に設定し、対象の証明書が CRL にあることを確認する必要があります。

Note

Azure AD および MSOnline PowerShell モジュールは、2024 年 3 月 30 日の時点で非推奨となります。詳細については、非推奨の最新情報を参照してください。この日以降、これらのモジュールのサポートは、Microsoft Graph PowerShell SDK への移行支援とセキュリティ修正プログラムに限定されます。非推奨になるモジュールは、2025 年 3 月 30 日まで引き続き機能します。

Microsoft Entra ID (旧称 Azure AD) を使用するには、Microsoft Graph PowerShell に移行することをお勧めします。移行に関する一般的な質問については、「移行に関する FAQ」を参照してください。注: バージョン 1.0.x の MSOnline では、2024 年 6 月 30 日以降に中断が発生する可能性があります。

次の手順は、 StsRefreshTokenValidFrom フィールドを設定することで認証トークンを更新し、無効にするプロセスを簡単に示したものです。

PowerShell に接続する:
```
Connect-MgGraph
```

ユーザーの現在の StsRefreshTokensValidFrom 値を取得します。

        $user = Get-MsolUser -UserPrincipalName test@yourdomain.com`
        $user.StsRefreshTokensValidFrom

現在のタイムスタンプと等しいユーザーの新しい StsRefreshTokensValidFrom 値を構成します。
```
        Set-MsolUser -UserPrincipalName test@yourdomain.com -StsRefreshTokensValidFrom ("03/05/2021")
```

設定する日付は、現在より後の日付にする必要があります。日付を現在より後の日付にしないと、 StsRefreshTokensValidFrom プロパティは設定されません。日付を現在より後の日付にすると、 StsRefreshTokensValidFrom は、現在の時刻に設定されます (Set-MsolUser コマンドで指定した日付ではありません)。

CRL 検証について (プレビュー)

CRL は、証明機関 (CA) によって有効期間が終了する前に取り消されたデジタル証明書の記録です。 CA を Microsoft Entra 信頼ストアにアップロードする場合、CRL、またはより具体的には CrlDistributionPoint 属性は必要ありません。 CRL エンドポイントなしで CA をアップロードできます。発行元 CA に CRL が指定されていない場合、証明書ベースの認証は失敗しません。

セキュリティを強化し、構成ミスを回避するために、認証ポリシー管理者は、エンドユーザー証明書を発行する CA に対して CRL が構成されていない場合、CBA 認証の失敗を要求できます。

CRL 検証を有効にする

CRL 検証を有効にするには、[CRL 検証を要求する (推奨)]をクリックします。

CRL 検証を要求する方法のスクリーンショット。

有効にすると、CRL が構成されていない CA によってエンドユーザー証明書が発行された場合、これらの CBA は失敗します。

認証ポリシー管理者は、CRL に修正が必要な問題がある場合、CA を除外できます。 [除外対象の追加] をクリックし、除外する必要がある CA を選択します。

CRL 検証から CA を除外する方法のスクリーンショット。

除外リスト内の CA は CRL を構成する必要がなく、CA が発行するエンドユーザー証明書は認証に失敗しません。

Note

オブジェクトピッカーで、選択した項目が正しく表示されないという既知の問題があります。 CA を選択または削除するには、[証明機関] タブを使用します。

CRL 検証から除外される CA のスクリーンショット。

CBA と条件付きアクセスの認証強度ポリシーの連携

お客様は条件付きアクセス認証の強度ポリシーを作成して、リソースへのアクセスに CBA を使用するように指定できます。

ユーザーは、組み込みの フィッシング耐性 MFA 認証強度を使用できます。このポリシーでは、CBA、FIDO2 セキュリティキー、Windows Hello for Business などのフィッシングに強い認証方法のみが許可されています。

また、カスタム認証強度を作成して、機密性の高いリソースに CBA のみがアクセスできるようにすることもできます。 CBAを、単一要素、多要素、またはその両方として許可できます。詳細については、条件付きアクセスの認証強度に関する記事を参照してください。

高度なオプションによる CBA 認証強度

CBA 認証方法ポリシーでは、認証ポリシー管理者は、CBA 方法の認証バインドポリシーを使用して証明書の強度を決定できます。ユーザーは、ユーザーがCBAを実行して特定の機密性の高いリソースにアクセスするときに、発行者とポリシーの OID に基づいて特定の証明書の使用を要求するカスタム認証強度を作成する場合、詳細オプションを構成できるようになりました。この機能により、リソースにアクセスできる証明書とユーザーを特定するための、より正確な構成が提供されるようになっています。詳細については、条件付きアクセスの認証強度の詳細オプションに関する記事を参照してください。

サインインログは、サインインと、ユーザーのリソース使用状況に関する情報を提供します。サインインログの詳細については、Microsoft Entra ID のサインインログに関する説明を参照してください。

ここでは、証明書が単一要素認証を満たす場合と、MFA を満たす場合の 2 つのシナリオを見てみましょう。

テストシナリオでは、MFA を必要とする条件付きアクセスポリシーを持つユーザーを選択します。 SAN プリンシパル名を UserPrincipalName にマップして、ユーザーバインディングポリシーを構成します。

ユーザー証明書は次のスクリーンショットのように構成する必要があります。

ユーザー証明書のスクリーンショット。

サインインログでは、ユーザーのサインインの問題をデバッグするための情報がすべて提供されますが、特定の値が必要な場合があり、サインインログは動的変数をサポートしていないため、サインインログに情報が不足している可能性があります。例: サインインログのエラー理由は、次のように表示されます。「証明書失効リスト (CRL) が署名の検証に失敗しました。予想されるサブジェクトキー識別子 {expectedSKI} が CRL 機関キー {crlAK} と一致しません。テナント管理者に CRL 構成をチェックするよう要求してください。」ここでは、{expectedSKI} と {crlAKI} に正しい値が設定されていません。

ユーザーが CBA でサインインできない場合は、エラーページの [詳細] リンクからログの詳細をコピーしてください。詳細については、「CBA エラーのページについて」を参照してください。

単一要素認証のテスト

最初のテストシナリオでは、発行者のサブジェクト規則が単一要素認証を満たす認証ポリシーを構成します。

CBA を使用してテストユーザーとして Microsoft Entra 管理センターにサインインします。発行者サブジェクト規則が単一要素認証を満たす認証ポリシーが設定されています。
[サインインログ] を検索して選択します。

サインインログに表示されるエントリの一部を詳しく見てみましょう。

最初のエントリは、ユーザーに X.509 証明書を要求します。中断の状態は、テナントで CBA が有効であることが Microsoft Entra ID によって検証済みであり、認証のために証明書が要求されていることを意味します。

[アクティビティの詳細] を見ると、これがユーザーが証明書を選ぶときに想定されるログインフローの一部に過ぎないことがわかります。

[追加の詳細] には、証明書の情報が表示されます。

これらの追加エントリは、認証が完了し、プライマリ更新トークンがブラウザーに送り返され、ユーザーにリソースへのアクセスが与えられたことを示します。

多要素認証のテスト

次のテストシナリオでは、policyOID ルールが多要素認証を満たす認証ポリシーを構成します。

CBA を使用して Microsoft Entra 管理センターにサインインします。ポリシーは多要素認証を満たすように設定されているので、ユーザーのサインインは 2 つ目の認証要素なしで成功します。

[サインイン] を検索して選択します。

サインインログに "中断" 状態のエントリを含むいくつかのエントリが表示されます。

[アクティビティの詳細] を見ると、これがユーザーが証明書を選ぶときに想定されるログインフローの一部に過ぎないことがわかります。

サインインログの第 2 要素サインインの詳細のスクリーンショット。

[中断] 状態のエントリには、[追加の詳細] タブに追加の診断情報があります。

サインインログの中断された試行の詳細のスクリーンショット。

次の表に、各フィールドの説明を示します。

フィールド	説明
ユーザー証明書のサブジェクト名	証明書のサブジェクト名フィールドを指します。
ユーザー証明書バインディング	証明書: プリンシパル名; ユーザー属性: userPrincipalName; ランク: 1 これは、どの SAN プリンシパル名の証明書フィールドが userPrincipalName ユーザ属性にマップされ、優先度 1 であったかを示しています。
ユーザー証明書の認証レベル	multiFactorAuthentication
ユーザー証明書の認証レベルの種類	PolicyId これは、認証の強度を決定するためにポリシー OID が使用されたことを示しています。
ユーザー証明書の認証レベル識別子	1.2.3.4 これは、証明書の識別子ポリシー OID の値を示しています。

証明書ベースの認証のエラーページの概要

証明書ベースの認証が失敗する理由は、証明書が無効である、ユーザーが間違った証明書や期限切れの証明書を選んだ、証明書失効リスト (CRL) の問題などです。証明書の検証に失敗すると、ユーザーにはこのようなエラーが表示されます。

証明書の検証エラーのスクリーンショット。

ブラウザー上で CBA が失敗した場合、その失敗の原因がユーザーが証明書ピッカーを取り消したためであっても、ブラウザーセッションを閉じて、新しいセッションを開いて CBA を再試行する必要があります。ブラウザーにはその証明書がキャッシュされているので、新しいセッションが必要です。 CBA を再試行すると、TLS チャレンジ中にブラウザーからキャッシュ済みの証明書が送信されます。その結果としてサインインが失敗し、検証エラーが発生します。

[詳細] を選択してログ情報を取得します。これを認証ポリシー管理者に送信することで、サインインログから詳細情報が取得されます。

エラーの詳細のスクリーンショット。

ユーザーがサインインに使用できる他の方法を試すには、[その他のサインイン方法] を選択します。

Note

ブラウザーで CBA を再試行すると、ブラウザーのキャッシュの問題が原因で失敗し続けます。ユーザーは新しいブラウザーセッションを開いて、再度サインインする必要があります。

新しいサインイン試行のスクリーンショット。

MostRecentlyUsed (MRU) 方法での証明書ベースの認証

ユーザーが CBA を使用して認証に成功すると、そのユーザーの MostRecentlyUsed (MRU) 認証方法が CBA に設定されます。次回、ユーザーが UPN を入力して [次へ] を選択すると、その CBA 方法に直接移動します。[証明書またはスマートカードを使用する] を選択する必要はありません。

MRU 方法をリセットするには、ユーザーが証明書ピッカーを取り消し、[その他のサインイン方法] を選択し、ユーザーが使用できる別の方法を選んで認証に成功する必要があります。

外部 ID のサポート

外部 ID B2B ゲストユーザーは、ホームテナントで CBA を使用でき、リソーステナントのクロステナント設定がホームテナントから MFA を信頼するように設定されている場合、ホームテナントでのユーザーの CBA 認証は受け入れられます。 [Microsoft Entra テナントからの多要素認証を信頼する] を有効にする方法の詳細については、「B2B コラボレーションのためにテナント間アクセス設定を構成する」を参照してください。リソーステナントでの CBA はまだサポートされていません。

次の方法で共有

Microsoft Entra の証明書ベースの認証に関する技術的な詳細情報

Microsoft Entra の証明書ベースの認証のしくみ

発行者ヒントについて (プレビュー)

発行者ヒントを有効にする

CA 信頼ストアの更新の伝達

証明書ベースの認証の MFA 機能

単一要素証明書ベース認証を使用する MFA

認証バインドポリシーについて

証明書の強度

多要素証明書認証

Microsoft Entra ID の複数の認証ポリシーバインド規則の解決方法

ユーザー名のバインドポリシーについて

証明書バインドを使ってセキュリティを強化する

テナントレベルでアフィニティバインドを定義し、カスタムルールでオーバーライドする（プレビュー）

Microsoft Entra ID の複数のユーザー名ポリシーバインド規則の解決方法

ユーザー名バインディングが複数ある Microsoft Entra 構成のセキュリティ保護

1 つの Microsoft Entra ユーザーアカウントでの複数の証明書のサポート (M:1)

複数の Microsoft Entra ユーザーアカウントを持つ 1 つの証明書のサポート (1:M)

証明書の失効プロセスについて

失効を構成する方法

CRL 検証について (プレビュー)

CRL 検証を有効にする

CBA と条件付きアクセスの認証強度ポリシーの連携

高度なオプションによる CBA 認証強度

単一要素認証のテスト

多要素認証のテスト

証明書ベースの認証のエラーページの概要

MostRecentlyUsed (MRU) 方法での証明書ベースの認証

外部 ID のサポート

次のステップ

フィードバック

その他のリソース

次の方法で共有

Microsoft Entra の証明書ベースの認証に関する技術的な詳細情報

Microsoft Entra の証明書ベースの認証のしくみ

発行者ヒントについて (プレビュー)

発行者ヒントを有効にする

CA 信頼ストアの更新の伝達

証明書ベースの認証の MFA 機能

単一要素証明書ベース認証を使用する MFA

単一要素証明書とパスワードレス サインインを使用した MFA 認証フロー

認証バインドポリシーについて

証明書の強度

多要素証明書認証

Microsoft Entra ID の複数の認証ポリシー バインド規則の解決方法

ユーザー名のバインド ポリシーについて

証明書バインドを使ってセキュリティを強化する

テナント レベルでアフィニティ バインドを定義し、カスタム ルールでオーバーライドする（プレビュー）

Microsoft Entra ID の複数のユーザー名ポリシー バインド規則の解決方法

ユーザー名バインディングが複数ある Microsoft Entra 構成のセキュリティ保護

1 つの Microsoft Entra ユーザー アカウントでの複数の証明書のサポート (M:1)

複数の Microsoft Entra ユーザー アカウントを持つ 1 つの証明書のサポート (1:M)

証明書の失効プロセスについて

失効を構成する方法

CRL 検証について (プレビュー)

CRL 検証を有効にする

CBA と条件付きアクセスの認証強度ポリシーの連携

高度なオプションによる CBA 認証強度

サインイン ログの概要

サインイン ログの動的変数に関するサインインの問題のトラブルシューティング

単一要素認証のテスト

多要素認証のテスト

証明書ベースの認証のエラー ページの概要

MostRecentlyUsed (MRU) 方法での証明書ベースの認証

外部 ID のサポート

次のステップ

フィードバック

その他のリソース

単一要素証明書とパスワードレスサインインを使用した MFA 認証フロー

Microsoft Entra ID の複数の認証ポリシーバインド規則の解決方法

ユーザー名のバインドポリシーについて

テナントレベルでアフィニティバインドを定義し、カスタムルールでオーバーライドする（プレビュー）

Microsoft Entra ID の複数のユーザー名ポリシーバインド規則の解決方法

1 つの Microsoft Entra ユーザーアカウントでの複数の証明書のサポート (M:1)

複数の Microsoft Entra ユーザーアカウントを持つ 1 つの証明書のサポート (1:M)

サインインログの概要

サインインログの動的変数に関するサインインの問題のトラブルシューティング

証明書ベースの認証のエラーページの概要