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

  • [アーティクル]

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

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

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

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

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

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

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

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

    MyApps ポータルの [サインイン] のスクリーンショット。

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

    Note

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

    [Use a certificate or smartcard] (証明書またはスマートカードを使用する) のスクリーンショット。

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

    [FIDO2] も有効な場合の [サインイン] のスクリーンショット。

  5. ユーザーが証明書ベースの認証を選ぶと、クライアントはパブリック Entra ID の https://certauth.login.microsoftonline.com である certauth エンドポイントにリダイレクトされます。 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 を使用します。

    アクセスが許可されていない限り、今後予定されている 信頼された CA ヒント機能を有効にすると、証明書ベースの認証は失敗します。

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

    Note

    信頼できる CA のヒントはサポートされていないため、証明書の一覧をさらにスコープすることはできません。 今後、この機能を追加する予定です。

    証明書ピッカーのスクリーンショット。

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

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

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

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

証明書ベースの認証は MFA 対応です

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

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

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

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

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

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

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

単一要素証明書ベース認証を使用する MFA（プレビュー）

Microsoft Entra CBA は、単一要素の証明書で MFA の要件を満たすための第 2 要素として使用できます。 サポートされている組み合わせの一部は次のとおりです。

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

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

重要

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

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

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

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

  2. 「パスワードレスの電話によるサインイン認証を有効にする」方法に関する記事の手順に従ってください。

    重要

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

  3. [保護]>[多要素認証]>[追加のクラウドベースの多要素認証設定] の順に選択します。

    多要素認証設定を構成する方法のスクリーンショット。

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

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

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

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

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

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

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

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

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

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

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

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

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

    第 2 要素要求のスクリーンショット。

  5. 携帯電話に通知が届きます。 [サインインを承認しますか?] を選択します。 承認要求のスクリーンショット。

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

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

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

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

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

証明書の強度

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

多要素証明書認証

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

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

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

  1. 発行元 + ポリシー OID ルールは、ポリシー OID ルールよりも優先されます。 ポリシー OID ルールは、証明書発行者ルールよりも優先されます。
  2. 発行元 + ポリシー OID ルールが最初に評価されます。 発行元 CA1 とポリシー OID 1.2.3.4.5 を持つ MFA が有効なカスタム ルールがある場合は、証明書 A のみが両方の発行元値を満たし、ポリシー OID に MFA が付与されます。
  3. 次に、ポリシー 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 要素を要求されます。
  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 の両方にバインディングすることはできません)。

重要

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

問題を修正中です。

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

ユーザー名のバインド ポリシーは、ユーザーの証明書を検証するために役立ちます。 既定では、証明書のサブジェクト代替名 (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>123456789abcdef certificateUserIds 高アフィニティ
SHA1PublicKey X509:<SHA1-PUKEY>123456789abcdef certificateUserIds 高アフィニティ
IssuerAndSerialNumber（プレビュー） X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
シリアル番号の正しい値を取得するには、このコマンドを実行し、CertificateUserIds に示されている値を格納します。
構文：
Certutil –dump –v [~certificate path~] >> [~dumpFile path~]
例:
certutil -dump -v firstusercert.cer >> firstCertDump.txt		 certificateUserIds 高アフィニティ

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

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

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

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

  1. ユーザー名またはユーザー プリンシパル名を使ってユーザー オブジェクトを検索します。
  2. CBA 認証方法構成内のテナント管理者によってセットアップされた全てのユーザー名バインディングの一覧を、'priority' 属性で並び替えて取得します。 現在、優先順位の概念はポータル UX では公開されていません。 グラフでは、各バインディングの優先度属性が返され、評価プロセスで使用されます。
  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 つの証明書が 1 つの Microsoft Entra ユーザー アカウントにのみ一致する必要があるという一意の制約があります。 ただし、Microsoft Entra CBA では、ユーザー名バインディング ポリシーで複数のバインディング方法がサポートされています。これにより、管理者は 1 つの証明書で複数の Entra ユーザー アカウント構成に対応できます。

重要

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

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

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

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

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

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

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>c11154138u089b48767212a86cd0ef76

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

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

X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>c11154138u089b48767212a86cd0ef76

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

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

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

重要

同じ資格情報を使用して異なる Entra ID アカウントで認証することは非常に安全な構成とは言えず、複数の Entra ユーザー アカウントに対して 1 つの証明書を許可することは避けることをお勧めします。

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

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

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

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

ユーザー アカウントの certificateUserIds 値:
X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>b24134139f069b49997212a86ba0ef48
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523

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

Note

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

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

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

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

フォレスト 1 - Account1 (bob@woodgrove.com):
X509:<SKI>82b287a25c48af0918ea088d5293712324dfd523
X509:<SHA1-PUKEY>123456789abcdef
X509:<PN>bob@woodgrove.com

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

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

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

certificateUserIds に同期する手順

  1. AlternativeSecurityIds フィールドをメタバースに追加するように Azure AD 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 に設定します。 それ以外の場合、アカウントは既定のケースに該当し、この例では 発行元 + SerialNumber マッピングのみにフィルター処理を行います。 キー属性が設定されている場合、値がチェックされ、定義されたユーザー型のいずれかに等しいかどうかを確認します。 この例では、その値が詳細ユーザーの場合、altSecurityIdentities から SHA1PublicKey 値にフィルター処理します。 値が開発者の場合は、altSecurityIdentities から SubjectKeyIssuer 値にフィルター処理します。 特定の種類の証明書値が複数存在する場合があります。 たとえば、複数の PrincipalName 値、複数の SKI 値、SHA1-PUKEY 値などです。 フィルターは、見つかった最初の値だけでなく、すべての値を取得し、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 を設定する前または後続のルールが無視され、結果が Entra ID で空になります。

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

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

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

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

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

管理者は、Microsoft Entra テナントの信頼できる発行者のセットアップ プロセスにおいて、CRL の配布ポイントを設定することができます。 信頼できる各発行者には、インターネット上の URL を使って参照できる CRL が必要です。

重要

対話型サインインでダウンロードとキャッシュに成功する Microsoft Entra ID の CRL の最大サイズは、パブリック 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 のダウンロード試行は、サービス側の制限 (パブリック Entra ID の場合は 45 MB、Azure US Government クラウドの場合は 150 MB) の影響を受けます。

重要

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

現時点では、パフォーマンスと信頼性の理由から、オンライン証明書状態プロトコル (OCSP) はサポートされていません。 Microsoft Entra ID は、OCSP 用にクライアント ブラウザーで接続のたびに CRL をダウンロードするのではなく、最初のサインイン時に一度ダウンロードしてキャッシュすることで、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 の失効したユーザー証明書のスクリーンショット。

    • キャッシュされた 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 フィールドを設定することで認証トークンを更新し、無効にするプロセスを簡単に示したものです。

  1. PowerShell に接続する:

    Connect-MgGraph

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

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

  3. 現在のタイムスタンプと等しいユーザーの新しい StsRefreshTokensValidFrom 値を構成します。

            Set-MsolUser -UserPrincipalName test@yourdomain.com -StsRefreshTokensValidFrom ("03/05/2021")

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

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 証明書を要求します。 中断の状態は、テナントで CBA が有効であることが Microsoft Entra ID によって検証済みであり、認証のために証明書が要求されていることを意味します。

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

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

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

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

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

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

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

多要素認証のテスト

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

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

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

  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 では、Microsoft Entra CBA を使うリソース テナントに対して多要素認証を実行できません。 代わりに、ユーザーがホーム テナントで CBA を使って MFA を実行するように指定し、リソース テナントがホーム テナントからの MFA を信頼するようにクロス テナント設定を行います。

[Microsoft Entra テナントからの多要素認証を信頼する] を有効にする方法の詳細については、「B2B コラボレーションのためにテナント間アクセス設定を構成する」を参照してください。

次のステップ