Microsoft Entra の証明書ベース認証に関する技術的概念

この記事では、Microsoft Entra の証明書ベースの認証 (CBA) の仕組みを説明するための技術的な概念について説明します。 技術的背景を理解し、テナントで CBA Microsoft Entra設定および管理する方法について理解を深めましょう。

Microsoft Entra の証明書ベース認証はどのように機能しますか？

次の図は、Microsoft Entra の CBA が構成されているテナントのアプリケーションにユーザーがサインインしようとする際に何が起こるかを示しています。

Microsoft Entra 証明書ベースの認証手順の概要を示す図。

次の手順では、Microsoft Entra CBA プロセスの概要を示します。

  1. ユーザーは、 MyApps ポータルなどのアプリケーションにアクセスしようとします。

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

  3. Microsoft Entraサインイン ページでユーザー名を入力し、Next を選択します。 Microsoft Entra IDは、テナント名を使用してホーム領域の検出を完了します。 ユーザー名を使用してテナント内のユーザーを検索します。

    MyApps ポータルのサインイン ページを示すスクリーンショット。

  4. Microsoft Entra IDは、CBA がテナント用に設定されているかどうかを確認します。 CBA が設定されている場合、ユーザーにはパスワード ページに [証明書またはスマート カードを使用 する] へのリンクが表示されます。 ユーザーにサインイン リンクが表示されない場合は、テナントに対して CBA が設定されていることを確認します。

    詳細については、「Microsoft Entra CBA を有効にする方法」を参照。

    注

    テナントに対して CBA が設定されている場合、すべてのユーザーはパスワード サインイン ページに [証明書またはスマート カードの使用 ] リンクを表示します。 ただし、MICROSOFT ENTRA IDを ID プロバイダーとして使用するアプリケーションに対して正常に認証できるのは、CBA のスコープ内のユーザーだけです。

    証明書またはスマート カードを使用するオプションを示すスクリーンショット。

    電話によるサインインやセキュリティ キーなど、他の認証方法を使用できるようにすると、ユーザーに別のサインイン ダイアログが表示されることがあります。

    FIDO2 認証も使用できる場合のサインイン ダイアログを示すスクリーンショット。

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

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

    注

    管理者は、ユーザーのサインイン ページと、クラウド環境の *.certauth.login.microsoftonline.com 証明書認証エンドポイントへのアクセスを許可する必要があります。 証明書認証エンドポイントで TLS 検査をオフにして、クライアント証明書要求が TLS ハンドシェイクの一部として成功することを確認します。

    TLS 検査をオフにしても、新しい URL を持つ発行者ヒントに対しても機能することを確認します。 テナント ID を使用して URL をハードコーディングしないでください。 テナント ID は、企業間 (B2B) ユーザーに対して変更される可能性があります。 正規表現を使用して、TLS 検査をオフにしたときに、前の URL と新しい URL の両方が機能することを許可します。 たとえば、プロキシに応じて、*.certauth.login.microsoftonline.com または *certauth.login.microsoftonline.com を使用します。 Azure Governmentでは、*.certauth.login.microsoftonline.us または *certauth.login.microsoftonline.us を使用します。

    アクセスが許可されない限り、 発行者ヒントを有効にすると CBA は失敗します。

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

    証明書ピッカーを示すスクリーンショット。

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

  8. Microsoft Entra 条件付きアクセス ポリシーによって、多要素認証 (MFA) と 認証バインド規則が MFA を満たし、一意のユーザーが検出された場合、Microsoft Entra IDはすぐにそのユーザーをサインインさせます。 MFA が必要で、証明書が 1 つの要素のみを満たしている場合、ユーザーが既に登録されている場合は、パスワードレス サインインと FIDO2 が 2 番目の要素として提供されます。

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

ユーザーのサインインが成功した場合、ユーザーはアプリケーションにアクセスできます。

発行者のヒント

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

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

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

注

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

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

注

発行者ヒントを有効にすると、CA URL の形式は t<tenantId>.certauth.login.microsoftonline.com。

発行者ヒントを有効にした後の証明書ピッカーを示すスクリーンショット。

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

発行者ヒントを有効にし、信頼ストアから CA を追加、更新、または削除すると、発行者ヒントがクライアントに反映されるまでに最大 10 分の遅延が発生する可能性があります。 発行者ヒントが利用可能になった後に伝達を開始するために、認証ポリシー管理者は証明書でサインインする必要があります。

ヒントが伝達されるまで、新しい CA によって発行された証明書を使用してユーザーを認証することはできません。 CA 信頼ストアの更新が反映されると、次のエラー メッセージが表示されます。

更新が進行中かどうかをユーザーが確認するエラーを示すスクリーンショット。

単一要素認証であるCBAを用いたMFA

Microsoft Entra CBA は、第 1 要素認証と第 2 要素認証の両方を対象とします。

サポートされている組み合わせをいくつか次に示します。

ユーザーは、MICROSOFT ENTRA CBA を使用してサインインする前に、MFA を取得し、パスワードなしのサインインまたは FIDO2 を登録する方法が必要です。

重要

ユーザー名が CBA メソッドの設定に表示される場合、ユーザーは MFA 対応と見なされます。 このシナリオでは、ユーザーは自分の ID を認証の一部として使用して、他の使用可能な方法を登録することはできません。 有効な証明書を持たないユーザーが CBA メソッドの設定に含まれていないことを確認します。 認証のしくみの詳細については、「Microsoft Entra多要素認証」を参照してください。

CBA を有効にして MFA 機能を取得するオプション

Microsoft Entra CBA は、テナントの構成に応じて、単一要素または多要素のいずれかになります。 CBA を有効にすると、ユーザーは MFA を完了できる可能性があります。 単一要素証明書またはパスワードを持つユーザーは、MFA を完了するために別の要素を使用する必要があります。

最初に MFA を満たさなければ、他の方法の登録は許可されません。 ユーザーに他の MFA メソッドが登録されておらず、CBA のスコープ内にある場合、ユーザーは ID 証明を使用して他の認証方法を登録し、MFA を取得することはできません。

CBA 対応ユーザーが単一要素証明書のみを持っており、MFA を完了する必要がある場合は、 次のいずれかのオプション を選択してユーザーを認証します。

  • ユーザーはパスワードを入力し、単一要素証明書を使用できます。
  • 認証ポリシー管理者は、一時的なアクセス パスを発行できます。
  • 認証ポリシー管理者は、電話番号を追加し、ユーザー アカウントの音声またはテキスト メッセージ認証を許可できます。

CBA 対応ユーザーが証明書を発行されておらず、MFA を完了する必要がある場合は、次 のいずれかの オプションを選択してユーザーを認証します。

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

CBA 対応ユーザーが多要素証明書を使用できない場合 (スマート カードのサポートなしでモバイル デバイスを使用しているが、MFA を完了する必要がある場合など) は、 次のいずれかのオプション を選択してユーザーを認証します。

  • 認証ポリシー管理者は、一時的なアクセス パスを発行できます。
  • ユーザーは別の MFA 方法を登録できます (ユーザーがデバイスで多要素証明書を使用 できる 場合)。
  • 認証ポリシー管理者は、電話番号を追加し、ユーザー アカウントの音声またはテキスト メッセージ認証を許可できます。

CBA を使用してパスワードなしの電話によるサインインを設定する

パスワードなしの電話によるサインインを機能させるには、まず、ユーザーのモバイル アプリを通じてレガシ通知をオフにします。

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

  2. 「パスワードレス電話によるサインイン認証を有効にする」で説明されている手順を完了します。

    重要

    [パスワードなし] オプションを選択していることを確認します。 パスワードなしの電話によるサインインに追加するグループの場合は、 認証モード の値を パスワードレスに変更する必要があります。 [ 任意] を選択した場合、CBA とパスワードなしのサインインは機能しません。

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

    MFA 設定を構成する方法を示すスクリーンショット。

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

    モバイル アプリを使用して通知を削除する方法を示すスクリーンショット。

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

単一要素証明書を持ち、パスワードレス サインイン用に構成されているユーザーの例を考えてみましょう。 ユーザーは、次の手順を実行します。

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

    ユーザー プリンシパル名を入力する方法を示すスクリーンショット。

  2. [ 証明書またはスマート カードを使用する] を選択します。

    証明書を使用してサインインする方法を示すスクリーンショット。

    電話によるサインインやセキュリティ キーなど、他の認証方法を使用できるようにすると、ユーザーに別のサインイン ダイアログが表示されることがあります。

    証明書を使用してサインインする別の方法を示すスクリーンショット。

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

    証明書を選択する方法を示すスクリーンショット。

  4. 証明書は単一要素認証の強度として構成されているため、MFA 要件を満たすには 2 番目の要素が必要です。 使用可能な 2 つ目の要因は、サインイン ダイアログに表示されます。 この場合は、パスワードなしのサインインです。 [Microsoft Authenticator アプリで要求を承認するを選択します。

    第 2 要素要求の完了を示すスクリーンショット。

  5. 電話で通知を受け取ります。 [ サインインの承認] を選択します。 電話承認要求を示すスクリーンショット。

  6. Microsoft Authenticatorで、ブラウザーまたはアプリに表示される番号を入力します。

    数値の一致を示すスクリーンショット。

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

認証バインド ポリシー

認証バインディング ポリシーは、認証の強度を単一要素または多要素として設定するのに役立ちます。 認証ポリシー管理者は、既定の方法を単一要素から多要素に変更できます。 管理者は、 IssuerAndSubject、 PolicyOID、または証明書の Issuer と PolicyOID を使用して、カスタム ポリシー構成を設定することもできます。

証明書の強度

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

多要素証明書認証

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

複数の認証ポリシー バインドルール

異なる証明書属性を使用して、複数のカスタム認証バインディング ポリシー規則を作成できます。 たとえば、発行者とポリシー 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 と、 1.2.3.4.5.6のポリシー OID を持つ証明書に基づく派生資格情報 B があり、カスタム規則が MFA で 1.2.3.4.5 値を持つポリシー OID として定義されている場合、証明書 A のみが MFA を満たします。 資格情報 B は単一要素認証のみを満たします。 ユーザーがサインイン時に派生資格情報を使用し、MFA 用に構成されている場合、認証を成功させるために 2 番目の要素を求められます。
  4. 複数のポリシー OID の間に競合がある場合 (たとえば、1 つの証明書に 2 つのポリシー OID があり、一方が単一要素認証にバインドされ、もう一方が MFA にバインドされている場合など)、証明書を単一要素認証として扱います。
  5. 発行者 CA を使用するカスタム ルールが評価されます。 証明書にポリシー OID と発行者の規則が一致する場合、ポリシー OID は常に最初にチェックされます。 ポリシー規則が見つからない場合は、発行者のバインドがチェックされます。 ポリシー OID は、発行者よりも高い強力な認証バインディングの優先順位を持ちます。
  6. 1 つの CA が MFA にバインドされている場合、この CA によって発行されるすべてのユーザー証明書は MFA として適格となります。 同じロジックが単一要素認証に適用されます。
  7. 1 つのポリシー OID が MFA にバインドされている場合、OID の 1 つとしてこのポリシー OID を含むすべてのユーザー証明書が MFA として修飾されます。 (1 つのユーザー証明書に複数のポリシー OID を含めることができます)。
  8. 1 つの証明書発行者が有効な強力な認証バインドを 1 つだけ持つことができます (つまり、証明書を単一要素認証と MFA の両方にバインドすることはできません)。

重要

現在、対処中の既知の問題では、認証ポリシー管理者が発行者とポリシー OID の両方を使用して CBA ポリシー規則を作成した場合、一部のデバイス登録シナリオが影響を受けます。

影響を受けるシナリオは次のとおりです。

  • Windows Hello for Business登録
  • FIDO2 セキュリティ キーの登録
  • Windows を使用した電話を使ったパスワードレスのサインイン

Workplace Join、Microsoft Entra ID、Microsoft Entra ハイブリッド参加済みシナリオへのデバイス登録は影響を受けません。 発行者 または ポリシー OID を使用する CBA ポリシー規則は影響を受けません。

この問題を軽減するには、認証ポリシー管理者が次 のいずれかの オプションを完了する必要があります。

  • 発行者とポリシー OID の両方を現在使用している CBA ポリシー規則を編集して、発行者またはポリシー ID の要件を削除します。
  • 発行者とポリシー OID の両方を現在使用している認証ポリシー規則を削除し、発行者またはポリシー OID のみを使用する規則を作成します。

ユーザー名バインド ポリシー

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

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

Microsoft Entraでは、証明書バインドを使用するための 7 つの方法がサポートされています。 一般に、マッピング型は、 SubjectKeyIdentifier (SKI) や SHA1PublicKeyなど、再利用できない識別子に基づいている場合、高いアフィニティと見なされます。 これらの識別子は、1 つの証明書のみを使用してユーザーを認証できることを保証します。

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

証明書マッピング フィールド の値の例 certificateUserIds ユーザー オブジェクト属性 タイプ
PrincipalName 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 低アフィニティ
Subject X509:<S>DC=com,DC=contoso,OU=UserAccounts,CN=mfatest certificateUserIds 低アフィニティ
SKI X509:<SKI>aB1cD2eF3gH4iJ5kL6-mN7oP8qR= certificateUserIds 高い親和性
SHA1PublicKey X509:<SHA1-PUKEY>aB1cD2eF3gH4iJ5kL6-mN7oP8qR
SHA1PublicKey値 (公開キーを含む証明書コンテンツ全体の SHA1 ハッシュ) は、証明書の拇印プロパティにあります。		 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 高い親和性

重要

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

アフィニティ バインディングの定義とオーバーライド

認証ポリシー管理者は、ユーザーが低アフィニティまたは高アフィニティのユーザー名バインディング マッピングを使用して認証できるかどうかを構成できます。

テナントに 必要なアフィニティ バインディング を設定します。これはすべてのユーザーに適用されます。 テナント全体の既定値をオーバーライドするには、発行者とポリシー OID、またはポリシー OID のみに基づいて、または発行者のみに基づいてカスタム 規則を作成します。

複数のユーザー名ポリシー バインディングルール

複数のユーザー名ポリシー バインド規則を解決するために、Microsoft Entra IDは最も高い優先度 (最小数) のバインドを使用します。

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

複数のユーザー名バインドを使用してMicrosoft Entra構成をセキュリティで保護する

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

重要

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

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

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

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

一部のシナリオでは、組織は 1 つの ID に対して複数の証明書を発行します。 モバイル デバイスの派生資格情報である可能性がありますが、セカンダリ スマート カードや、YubiKey などの X.509 資格情報ホルダー対応デバイスの場合もあります。

クラウド専用アカウント (M:1)

クラウド専用アカウントの場合は、 certificateUserIds フィールドに一意の値を設定して各証明書を識別することで、使用する証明書を最大 5 つマップできます。 証明書をマップするには、管理センターで [ 承認情報 ] タブに移動します。

組織が IssuerAndSerialNumberなどの高アフィニティ バインディングを使用している場合、 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 を表します。 ユーザーは、サインイン時にいずれかの証明書を提示できます。 特定のバインディングの種類 (この例では certificateUserIds) を検索するために CBA ユーザー名バインドが IssuerAndSerialNumber フィールドを指すように設定されている場合、ユーザーは正常にサインインします。

ハイブリッド同期アカウント (M:1)

同期されたアカウントの場合は、複数の証明書をマップできます。 オンプレミスの Active Directoryで、altSecurityIdentities フィールドに、各証明書を識別する値を設定します。 組織で、 IssuerAndSerialNumberのような高アフィニティ バインディング (つまり、強力な認証) を使用している場合、値は次の例のようになります。

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 に対して認証を行う必要があります。 管理者アカウント、開発者または一時的な職務アカウントの場合があります。

オンプレミスの Active Directoryでは、altSecurityIdentities フィールドに証明書の値が設定されます。 サインイン時にヒントを使用して、サインインを確認する目的のアカウントにActive Directoryを指示します。

Microsoft Entra CBA には異なるプロセスがあり、ヒントは含まれません。 代わりに、ホーム領域検出によって目的のアカウントが識別され、証明書の値が確認されます。 Microsoft Entra CBA では、certificateUserIds フィールドにも一意性が適用されます。 2 つのアカウントで同じ証明書の値を設定することはできません。

重要

同じ資格情報を使用して異なるMicrosoft Entra アカウントで認証することは、セキュリティで保護された構成ではありません。 複数のMicrosoft Entra ユーザー アカウントに対して 1 つの証明書を使用することは許可しないことをお勧めします。

クラウド専用アカウント (1:M)

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

certificateUserIds フィールドに、証明書を識別する一意の値を設定します。 このフィールドを設定するには、管理センターで [ 承認情報 ] タブに移動します。

組織で、 IssuerAndSerialNumber や SKIなどの高アフィニティ バインディング (つまり、強力な認証) を使用している場合、値は次の例のようになります。

ユーザー名バインド:

  • IssuerAndSerialNumber > certificateUserIds
  • SKI > certificateUserIds

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

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

注

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

ハイブリッド同期アカウント (1:M)

同期されたアカウントには、別のアプローチが必要です。 認証ポリシー管理者は、証明書を使用する各ユーザー アカウントに一意の値をマップできますが、Microsoft Entra ID内の各アカウントにすべての値を設定する一般的な方法では、このアプローチが困難になります。 代わりに、Microsoft Entra Connect では、アカウントごとに値をフィルター処理して、Microsoft Entra IDのアカウントに入力された一意の値に設定する必要があります。 一意性ルールは、1 つのディレクトリまたはテナントの境界に適用されます。 認証ポリシー管理者は、アカウントごとに値が一意のままである場合に、証明書を別のディレクトリまたはテナントで使用するようにマップできます。

組織には、1 つのMicrosoft Entra テナントにユーザーを提供する複数のActive Directory フォレストがある場合もあります。 この場合、Microsoft Entra Connect は、同じ目標を持つ各Active Directory フォレストにフィルターを適用します。クラウド アカウントに特定の一意の値のみを設定します。

Active Directoryの altSecurityIdentities フィールドに、証明書を識別する値を設定します。 そのユーザー アカウントの種類 ( detailed、 admin、 developerなど) の特定の証明書の値を含めます。 Active Directoryでキー属性を選択します。 この属性は、ユーザーが評価しているユーザー アカウントの種類 ( msDS-cloudExtensionAttribute1など) を同期に通知します。 この属性には、 detailed、 admin、 developerなど、使用するユーザーの種類の値を設定します。 アカウントがユーザーのプライマリ アカウントの場合、値は空または 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に同期するには:

  1. Microsoft Entra Connect を構成して、alternativeSecurityIds フィールドをメタバースに追加します。
  2. オンプレミスの Active Directory フォレストごとに、優先順位の高い新しいカスタム受信規則 (100 未満の低い数値) を構成します。 Expression フィールドをソースとして使用して、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-cloudExtensionAttribute1 が最初にチェックされ、値が設定されているかどうかを確認します。 設定されていない場合は、altSecurityIdentities に値が設定されているかどうかのチェックが行なわれます。 空の場合は、NULL に設定します。 それ以外の場合、アカウントは既定のシナリオです。

また、この例では、 IssuerAndSerialNumber マッピングでのみフィルター処理します。 キー属性が設定されている場合、値がチェックされ、定義されているユーザーの種類の 1 つと等しいかどうかを確認します。 その例では、もしその値がdetailedの場合、SHA1PublicKeyからのaltSecurityIdentities値をフィルターします。 値がdeveloperの場合は、SubjectKeyIssuerからaltSecurityIdentities値をフィルター処理します。

特定の種類の複数の証明書値が発生する可能性があります。 たとえば、複数の 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では空です。

空の値を同期するには:

  1. 優先順位を低く (数値は高く、160 より大きく、かつ一覧の下位になるように) 設定した、新しいカスタムのアウトバウンド規則を構成します。
  2. alternativeSecurityIds フィールドをソースとして、certificateUserIds フィールドをターゲットとして直接変換を追加します。
  3. 同期サイクルを実行して、Microsoft Entra IDでのデータ入力を完了します。

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

証明機関 (CA) の範囲設定

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

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

主な利点

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

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

CA スコープ機能を設定する

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

  2. Entra ID>認証方法>証明書ベースの認証に移動します。

  3. [ 構成] で、 証明書発行者のスコープ ポリシーに移動します。

    CA スコープ ポリシーを示すスクリーンショット。

  4. [ ルールの追加] を選択します。

    CA スコープ規則を追加する方法を示すスクリーンショット。

  5. [PKI による CA のフィルター処理] を選択します。

    クラシック CA には、クラシック CA ストアのすべての CA が表示されます。 特定の PKI を選択すると、選択した PKI のすべての CA が表示されます。

  6. PKI を選択します。

    CA スコープ PKI フィルターを示すスクリーンショット。

  7. 証明書発行者の一覧には、選択した PKI のすべての CA が表示されます。 スコープ ルールを作成する CA を選択します。

    CA スコープで CA を選択する方法を示すスクリーンショット。

  8. [ グループの追加] を選択します。

    CA スコープの [グループの追加] オプションを示すスクリーンショット。

  9. グループを選択します。

    CA スコープの [グループの選択] オプションを示すスクリーンショット。

  10. [ 追加] を選択してルールを保存します。

    CA スコープの [規則の保存] オプションを示すスクリーンショット。

  11. [ 確認する ] チェック ボックスをオンにし、[保存] を選択 します。

    CA スコープの [CBA 構成の保存] オプションを示すスクリーンショット。

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

    CA スコープで編集または削除する方法を示すスクリーンショット。

既知の制限事項

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

サインイン ログ エントリ

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

    CA スコープ ルールのサインイン ログの成功を示すスクリーンショット。

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

    CA のスコープサインイン ログ エラーを示すスクリーンショット。

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

    CA スコープ ユーザー エラーを示すスクリーンショット。

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

組み込みの Microsoft Entra Phishing 耐性 MFA 認証強度を使用して、CBA を使用してリソースにアクセスすることを指定する条件付きアクセス認証ポリシーを作成できます。 このポリシーでは、CBA、FIDO2 セキュリティ キー、Windows Hello for Businessなど、フィッシングに強い認証方法のみを許可します。

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

高度なオプションで強化された CBA

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

サインイン ログ

サインイン ログには、サインインに関する情報と、組織内でのリソースの使用方法が示されます。 詳細については、「Microsoft Entra ID の Sign-in ログ」を参照してください。

次に、2 つのシナリオを検討します。 1 つのシナリオでは、証明書は単一要素認証を満たします。 2 番目のシナリオでは、証明書が MFA を満たします。

テスト シナリオでは、MFA を必要とする条件付きアクセス ポリシーを持つユーザーを選択します。

サブジェクトの別名とプリンシパル名を userPrincipalName ユーザー オブジェクトにマッピングして、ユーザー バインド ポリシーを構成します。

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

ユーザー証明書を示すスクリーンショット。

サインイン ログにおける動的変数を利用したサインインエラーのトラブルシューティング

サインイン ログは通常、サインインの問題をデバッグするために必要なすべての情報を提供しますが、特定の値が必要な場合があります。 サインイン ログでは動的変数がサポートされていないため、場合によっては、サインイン ログにデバッグに必要な情報がありません。

たとえば、サインイン ログのエラーの理由に "The Certificate Revocation List (CRL) failed signature validation. Expected Subject Key Identifier <expectedSKI> doesn't match CRL Authority Key <crlAK>. Request your tenant administrator to check the CRL configuration." このシナリオでは、<expectedSKI> と <crlAKI> に正しい値が設定されていないと表示される場合があります。

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

単一要素認証のテスト

最初のテスト シナリオでは、 IssuerAndSubject 規則が単一要素認証を満たす認証ポリシーを構成します。

認証ポリシーの構成と必要な単一要素認証を示すスクリーンショット。

  1. CBA を使用して、Microsoft Entra 管理センター にテスト ユーザーとしてサインインします。 認証ポリシーは、 IssuerAndSubject 規則が単一要素認証を満たす場所に設定されます。

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

    次の図は、サインイン ログで確認できるエントリの一部を示しています。

    最初のエントリは、ユーザーに X.509 証明書を要求します。 Interrupted 状態はMicrosoft Entra IDテナントに対して CBA が設定されていることを検証したことを意味します。 認証のために証明書が要求されます。

    サインイン ログの単一要素認証エントリを示すスクリーンショット。

    アクティビティの詳細 は、要求が、ユーザーが証明書を選択する想定されるサインイン フローの一部であることを示しています。

    サインイン ログのアクティビティの詳細を示すスクリーンショット。

    その他の詳細 には、証明書の情報が表示されます。

    サインイン ログの多要素の追加の詳細を示すスクリーンショット。

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

    サインイン ログの更新トークン エントリを示すスクリーンショット。

MFA のテスト

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

MFA が必要であることを示す認証ポリシーの構成を示すスクリーンショット。

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

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

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

    サインイン ログ内のいくつかのエントリを示すスクリーンショット。

    アクティビティの詳細 は、要求が、ユーザーが証明書を選択する想定されるサインイン フローの一部であることを示しています。

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

    [中断] 状態のエントリの詳細な診断情報は、[追加の詳細] タブに表示されます。

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

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

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

CBA エラー ページ

CBA は複数の理由で失敗する可能性があります。 たとえば、無効な証明書、ユーザーが間違った証明書を選択した、有効期限が切れた証明書、CRL の問題が発生したなどです。 証明書の検証が失敗すると、次のエラー メッセージが表示されます。

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

CBA がブラウザーで失敗した場合、証明書ピッカーを取り消したために失敗した場合でも、ブラウザー セッションを閉じます。 新しいセッションを開いて CBA をもう一度試します。 ブラウザーが証明書をキャッシュするため、新しいセッションが必要です。 CBA が再試行されると、ブラウザーは TLS チャレンジ中にキャッシュされた証明書を送信します。これにより、サインインエラーと検証エラーが発生します。

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

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

  2. サインイン するその他の方法を 選択し、他の使用可能な認証方法を試してサインインします。

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

Microsoft Edgeで証明書の選択をリセットする

Microsoft Edge ブラウザーは、ブラウザーを再起動せずに証明書の選択を<>に設定する機能を追加しました。

ユーザーは次の手順を実行します。

  1. CBA が失敗すると、エラー ページが表示されます。

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

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

    Microsoft Edge ブラウザー証明書の選択肢を示すスクリーンショット。

  3. [ 証明書の選択項目のリセット] を選択します。

    Microsoft Edge ブラウザー証明書の選択をリセットするスクリーンショットを示す

  4. 「リセットの選択肢をリセット」を選択します。

    Microsoft Edgeブラウザー証明書の選択のリセットの同意を示すスクリーンショット。

  5. [ その他のサインイン方法] を選択します。

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

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

MostRecentlyUsed メソッドにおける CBA

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

MRU メソッドをリセットするには、証明書ピッカーをキャンセルし、[ その他のサインイン方法] を選択します。 別の使用可能な方法を選択し、認証を完了します。

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

外部 ID のサポート

外部 ID B2B ゲスト ユーザーは、ホーム テナントで CBA を使用できます。 リソース テナントのクロステナント設定がホーム テナントから MFA を信頼するように設定されている場合は、ホーム テナント上のユーザーの CBA が優先されます。 詳細については、「 B2B コラボレーションのテナント間アクセスの構成」を参照してください。 現在、リソース テナントの CBA はサポートされていません。

関連コンテンツ

  • Last updated on