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

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

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

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

実行する手順を次に示します。

1. ユーザーは、 MyApps ポータルなどのアプリケーションへのアクセスを試みます。

2. まだサインインしていない場合、ユーザーは https://login.microsoftonline.com/ の Microsoft Entra ID の [ユーザー サインイン] ページにリダイレクトされます。

3. ユーザーが Microsoft Entra サインイン ページにユーザー名を入力し、[ 次へ] を選択します。 Microsoft Entra ID により、テナント名を使ってホーム領域の検出が行われます。ユーザー名は、テナントでユーザーを検索するために使われます。

   

4. Microsoft Entra ID は、テナントに対して CBA が有効になっているかどうかを確認します。 CBA が有効になっている場合、パスワード ページに [証明書またはスマートカードを使用 する] へのリンクがユーザーに表示されます。 ユーザーにサインイン リンクが表示されない場合は、テナントで CBA が有効になっていることを確認してください。 詳細については、「 Microsoft Entra CBA を有効にする方法」を参照してください。

   注

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

   

   電話によるサインインやセキュリティ キーなどの他の認証方法を有効にした場合、ユーザーに別のサインイン画面が表示されることがあります。

   

5. ユーザーが証明書ベースの認証を選ぶと、クライアントは公開 Microsoft Entra ID の https://certauth.login.microsoftonline.com である certauth エンドポイントにリダイレクトされます。 Azure Government の場合、証明書認証エンドポイントはhttps://certauth.login.microsoftonline.us。

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

   注

   ネットワーク管理者は、お客様のクラウド環境の [ユーザー サインイン] ページと 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 を使用します。

   アクセスが許可されない限り、 発行者ヒントを有効にした場合、証明書ベースの認証は失敗します。

6. Microsoft Entra ID がクライアント証明書を要求します。 ユーザーがクライアント証明書を選択し、[ OK] を選択します。

   

7. Microsoft Entra ID は、証明書失効リストを検証して、証明書が失効しておらず、有効であることを確認します。 Microsoft Entra ID は、証明書フィールドの値をユーザー属性値にマップするようにテナントで 構成されたユーザー名バインド を使用して、ユーザーを識別します。

8. 多要素認証を必要とする条件付きアクセス ポリシーを使用して一意のユーザーが見つかり、 証明書認証バインド規則 が MFA を満たしている場合、Microsoft Entra ID はユーザーを直ちにサインインさせます。 MFA が必要であるにもかかわらず、証明書が単一要素しか満たしていない場合、パスワードレス サインインまたは FIDO2 のいずれかが既に登録されていれば、第 2 要素として提供されます。

9. Microsoft Entra ID は、サインインが成功したことを示すプライマリ更新トークンを送信してサインイン プロセスを完了します。

10. ユーザーはサインインが成功すると、アプリケーションにアクセスできます。

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

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

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

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

注

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

注

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

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

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

認証ポリシー管理者は、発行者ヒントを有効にして伝達を開始した後、証明書を使用してサインインする必要があります。 CA 信頼ストアの更新プログラムが反映されている場合、ユーザーには次のエラー メッセージが表示されます。

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

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

1. CBA (第 1 要素) とパスキー (第 2 要素)
2. CBA (第 1 要素) と パスワードなしの電話によるサインイン (2 番目の要素)
3. CBA (第 1 要素) および FIDO2 セキュリティ キー (第 2 要素)
4. パスワード (第 1 要素) + CBA (2 番目の要素) (プレビュー)

注

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

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

重要

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

単一要素証明書で MFA 機能を取得するオプション

Microsoft Entra CBA は多要素認証 (MFA) に対応しています。 Microsoft Entra CBA は、テナントの構成に応じて単一要素 (SF) または多要素 (MF) のいずれかになります。 CBA を有効にすると、ユーザーが潜在的に MFA を完了可能になります。 単一要素証明書を持つユーザーは、MFA を完了するためにもう 1 つの要素を必要とするため、MFA を満たさずに他の方法の登録を許可しません。 ユーザーに他の MFA 認証方法が登録されておらず、CBA 認証方法のスコープに追加されている場合、ユーザーは他の認証方法を登録して MFA を取得するための証明を行うことはできません。

CBA 対応ユーザーが単一要素 (SF) 証明書のみを所有しており、MFA を完了する必要がある場合:

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

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

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

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

1. 認証ポリシー管理者が一時アクセス パス (OR) を発行できる
2. ユーザーは別の MFA 方法を登録する必要があります (ユーザーが一部のデバイスで MF 証明書を使用できる場合) (OR)
3. 認証ポリシー管理者が電話番号を追加し、音声/テキスト メッセージ認証をユーザー アカウントに許可します。

CBA を使用してパスワードレス電話サインイン (PSI) を設定する手順

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

1. 少なくとも認証ポリシー管理者として Microsoft Entra 管理センターにサインインします。

2. 「パスワードレス電話によるサインイン認証を有効にする」の手順に従います。

   重要

   前の構成で、[ パスワードなし ] オプションを選択していることを確認します。 PSI 用に追加されたグループの 認証モード を パスワードレスに変更する必要があります。 [Any] を選択した場合、CBA と PSI は機能しません。

3. Entra ID>多要素認証>追加のクラウドベースの多要素認証設定を選択します。

   

4. [ 確認オプション] で、[ モバイル アプリによる通知] をオフにして、[保存] を選択 します。

   

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

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

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

   

2. [ 証明書でサインイン] を選択します。

   

   電話によるサインインや FIDO2 セキュリティ キーなどの他の認証方法を有効にしている場合、ユーザーには別のサインイン画面が表示される場合があります。

   

3. クライアント証明書ピッカーで適切なユーザー証明書を選択し、[ OK] を選択します。

   

4. 証明書は単一要素認証強度として構成されているため、ユーザーは MFA 要件を満たすための第 2 要素が必要になります。 ユーザーに使用可能な第 2 要素 (このケースではパスワードレス サインイン) が表示されます。 [Microsoft Authenticator アプリで要求を承認する] を選択します。

   

5. 携帯電話に通知が届きます。 [ サインインの承認] を選択します。

6. ブラウザーまたはアプリ画面に表示される数値を Microsoft Authenticator に入力します。

   

7. [ はい ] を選択すると、ユーザーは認証とサインインを行うことができます。

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

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

証明書の強度

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

多要素証明書認証

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

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

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

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

重要

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

• Windows Hello For Business の登録
• Fido2 セキュリティ キーの登録
• Windows のパスワードレスの電話によるサインイン

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

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

現在、問題の解決に取り組んでいます。

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

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

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

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

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

証明書マッピング フィールド	certificateUserIds の値の例	ユーザー オブジェクト属性	Type
PrincipalName	X509:<PN>bob@woodgrove.com	userPrincipalName onPremisesUserPrincipalName（オンプレミスユーザープリンシパル名） 証明書ユーザーID	低アフィニティ
RFC822Name	X509:<RFC822>user@woodgrove.com	userPrincipalName onPremisesUserPrincipalName（オンプレミスユーザープリンシパル名） 証明書ユーザーID	低アフィニティ
発行者と対象	X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	証明書ユーザーID	低アフィニティ
サブジェクト	X509:<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest	証明書ユーザーID	低アフィニティ
スキー	X509:<SKI>aB1cD2eF3gH4iJ5kL6-mN7oP8qR=	証明書ユーザーID	高アフィニティ
SHA1PublicKey	X509:<SHA1-PUKEY>aB1cD2eF3gH4iJ5kL6-mN7oP8qR SHA1PublicKey 値 (公開キーを含む証明書コンテンツ全体の SHA1 ハッシュ) は、証明書の拇印プロパティにあります。	証明書ユーザーID	高アフィニティ
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	証明書ユーザーID	高アフィニティ

重要

CertificateBasedAuthentication PowerShell モジュールを使用して、エンド ユーザー証明書からユーザーの正しい CertificateUserIds 値を見つけることができます。

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

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

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

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

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

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

証明書を Microsoft Entra ユーザー アカウントにバインドするために使用できる各 Microsoft Entra ユーザー オブジェクト属性 (userPrincipalName、onPremiseUserPrincipalName、certificateUserIds) には、証明書が 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:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>eF3gH4iJ5kL6mN7oP8-qR9sT0uV

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

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

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>cD2eF3gH4iJ5kL6mN7-oP8qR9sT
X509:<I>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 アカウントで認証することは非常に安全な構成ではなく、複数の Microsoft Entra ユーザー アカウントに対して 1 つの証明書を許可しないことをお勧めします。

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

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

ユーザー名バインド:

• Issuer + Serial Number -> CertificateUserIds
• SKI -> 証明書ユーザーID

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

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

注

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

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

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

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

Forest 1 - Account1 (bob@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Forest 1 - Account2 (bob-admin@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

Forest 2 – ADAccount1 (bob-tdy@woodgrove.com):
X509:<SKI>aB1cD2eF3gH4iJ5kL6mN7oP8qR
X509:<SHA1-PUKEY>>cD2eF3gH4iJ5kL6mN7oP8qR9sT
X509:<PN>bob@woodgrove.com

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

certificateUserIds に同期する手順

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

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 に設定します。 それ以外の場合、アカウントは既定のケースに該当し、この例では Issuer+SerialNumber マッピングのみに絞り込みます。 キー属性が設定されている場合、値は、定義されているユーザー型のいずれかと等しいかどうかを確認するためにチェックされます。 この例では、その値が detailee の場合、altSecurityIdentities からの SHA1PublicKey 値に絞り込みます。 値が developer の場合、altSecurityIdentities から SubjectKeyIssuer 値に絞り込みます。 特定の種類の証明書値が複数存在する場合があります。 たとえば、複数の PrincipalName 値、複数の SKI 値、SHA1-PUKEY 値などです。 フィルターはすべての値を取得し、最初に見つけた値だけでなく、Microsoft Entra ID に同期します。

1. コントロール属性が空の場合に空の値をプッシュする方法を示す 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 で結果が空になります。

1. 優先順位が低い新しいカスタム アウトバウンド規則を構成します (160 よりも大きな数値。リストの一番下)。
2. alternativeSecurityIds フィールドをソースとし、certificateUserIds フィールドをターゲットとして直接変換を追加します。
3. 同期サイクルを実行し、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. 問題が解決しない場合は、テナント管理者に問い合わせてください。"

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

重要

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

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

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

1. Microsoft Entra ID は、対応する信頼された発行者または証明機関の証明書を持つユーザーの最初のサインイン イベントで、CRL のダウンロードを試行します。
2. Microsoft Entra ID は、後で使用するために CRL をキャッシュして再利用します。 次の更新日および、使用可能な場合は CRL ドキュメント内の次の CRL 発行日（Windows Server CA によって使用されます）を遵守します。
3. 次の場合、ユーザー証明書ベースの認証は失敗します。

   • 信頼された発行者に対して CRL が構成されており、可用性、サイズ、または待機時間の制約により、Microsoft Entra ID は CRL をダウンロードできません。

   • ユーザーの証明書が CRL に失効済みとして表示されます。

     

   • キャッシュされた CRL ドキュメントの有効期限が切れている場合、Microsoft Entra ID は配布ポイントから新しい CRL のダウンロードを試行します。

注

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 を使用して、この特定のユーザーの StsRefreshTokensValidFrom フィールドを設定します。 アクセスを取り消す各ユーザーの StsRefreshTokensValidFrom フィールドを更新する必要があります。

失効が維持されるようにするには、CRL の 有効日 を StsRefreshTokensValidFrom によって設定された値の後の日付に設定し、問題の証明書が CRL にあることを確認する必要があります。

次の手順では、 StsRefreshTokensValidFrom フィールドを設定して承認トークンを更新および無効化するプロセスについて説明します。

# Authenticate to Microsoft Graph
Connect-MgGraph -Scopes "User.Read.All"

# Get the user
$user = Get-MgUser -UserPrincipalName "test@yourdomain.com"

# Get the StsRefreshTokensValidFrom property
$user.StsRefreshTokensValidFrom

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

CRL 検証について

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

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

CRL 検証の有効化

CRL 検証を有効にするには、[ CRL 検証が必要です (推奨)] を選択します。

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

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

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

CA を選択し、[ 追加] を選択します。 [ 検索 ] テキスト ボックスを使用すると、CA リストをフィルター処理して特定の CA を選択できます。

証明機関 (CA) スコープ (プレビュー)

Microsoft Entra の証明機関 (CA) スコープを使用すると、テナント管理者は、特定の証明機関 (CA) の使用を定義されたユーザー グループに制限できます。 この機能は、承認されたユーザーのみが特定の CA によって発行された証明書を使用して認証できるようにすることで、証明書ベースの認証 (CBA) のセキュリティと管理性を強化します。

CA スコープは、複数の CA が異なるユーザー集団間で使用されるマルチ PKI または B2B シナリオで特に役立ちます。 意図しないアクセスを防ぎ、組織のポリシーへの準拠をサポートします。

主な利点

• 証明書の使用を特定のユーザー グループに制限する
• 複数の CA を含む複雑な PKI 環境のサポート
• 証明書の誤用や侵害に対する保護の強化
• サインイン ログと監視ツールを使用して CA の使用状況を可視化する

CA スコープを使用すると、管理者は CA (サブジェクト キー識別子または SKI で識別) を特定の Microsoft Entra グループに関連付ける規則を定義できます。 ユーザーが証明書を使用して認証を試みると、証明書の発行元 CA のスコープがユーザーを含むグループに設定されているかどうかをシステムがチェックします。 Entra は CA チェーンをウォークアップし、すべてのスコープ ルールのグループの 1 つにユーザーが見つかるまで、すべてのスコープ ルールを適用します。 ユーザーがスコープ 付きグループに属していない場合、証明書が有効な場合でも認証は失敗します。

CA スコープ機能を有効にする手順

1. 少なくとも認証ポリシー管理者として Microsoft Entra 管理センターにサインインします。
2. Entra ID> の認証方法、>証明書ベースの認証を参照します。
3. [構成] で、証明書発行者のスコープ ポリシーに移動します

1. [ ルールの追加] を選択する

1. [PKI による CA のフィルター処理] を選択します。 クラシック CA には、クラシック CA ストアのすべての CA が表示され、特定の PKI を選択すると、選択した PKI のすべての CA が表示されます。 PKI を選択します。

1. [証明書発行者 ] ドロップダウンには、選択した PKI のすべての CA が表示されます。 スコープ ルールを作成する CA を選択します。

1. [ グループの追加] を選択する

1. グループを選択する

1. [ 追加] を選択してルールを保存する

1. [ 確認する] を選択し、[ 保存] を選択して CBA 構成を保存する

1. CA スコープ ポリシーを編集または削除するには、ルール行の「...」を選択します。 [ 編集] を 選択してルールを編集し、[ 削除] を選択してルールを削除します。

既知の制限

• CA ごとに割り当てることができるグループは 1 つだけです。
• 最大 30 個のスコープ規則がサポートされています。
• スコープは中間 CA レベルで適用されます。
• 有効なスコープ規則が存在しない場合、不適切な構成によりユーザーロックアウトが発生する可能性があります。

サインイン ログ エントリ

• サインイン ログには成功が表示され、[追加の詳細] タブにはスコープ ポリシー規則の CA の SKI が表示されます。

• CA スコープ規則のために CBA 認証が失敗した場合、サインイン ログの [基本情報] タブにエラー コード500189が表示されます。

• エンド ユーザーには、次のエラー メッセージが表示されます。

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 エラー ページの理解を参照してください

単一要素認証のテスト

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

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

2. サインイン ログを検索して選択します。

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

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

   

   アクティビティの詳細では、これは、ユーザーが証明書を選択する想定されるサインイン フローの一部にすぎません。

   

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

   

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

   

多要素認証のテスト

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

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

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

   サインイン ログには、いくつかのエントリがあり、その中には中断 状態のエントリも表示されます。

   

   アクティビティの詳細では、これは、ユーザーが証明書を選択する想定されるサインイン フローの一部にすぎません。

   

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

   

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

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

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

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

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

注

ただし、Edge ブラウザーでは、ブラウザーを 再起動せずに証明書の選択をリセットする新しい機能が追加されました。

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

サインイン するその他の方法を 選択して、ユーザーがサインインできる他の方法を試します。

エッジ ブラウザーで証明書の選択をリセットする

CBA がブラウザーで失敗した場合、たとえ証明書ピッカーをキャンセルしたことが原因でも、ブラウザーが証明書をキャッシュするため、一度ブラウザーセッションを閉じてから新しいセッションを開き、もう一度 CBA を試す必要があります。 ただし、Edge ブラウザーでは、ブラウザーで証明書の選択をリセットするための新しい機能強化が追加されました。

• CBA が失敗すると、ユーザーはエラー ページに送信されます

• アドレス URL の左側にあるロック アイコンを選択し、[ 証明書の選択] を選択します。

• [証明書の選択項目のリセット] を選択する

• ダイアログで [リセット] の選択肢 を選択する

• [ その他の方法 ] をクリックして、エラー ページにサインインします

• ピッカー で [証明書またはスマート カードを使用 する] を選択し、CBA 認証を続行します。

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

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

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

MRU 認証方法はユーザー レベルで設定されるため、ユーザーが別の認証方法を使用して別のデバイスに正常にサインインした場合、MRU はユーザーで現在ログインしている方法にリセットされます。

外部 ID のサポート

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

次のステップ

• Microsoft Entra CBA の概要
• Microsoft Entra CBA を構成する方法
• iOS デバイス上の Microsoft Entra CBA
• Android デバイス上の Microsoft Entra CBA
• Microsoft Entra CBA を使用した Windows スマート カード ログオン
• 証明書ユーザー ID
• フェデレーション ユーザーを移行する方法
• よくある質問
• Microsoft Entra CBA のトラブルシューティング