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

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

Azure AD の証明書ベースの認証のしくみ

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

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

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

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

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

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

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

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

    Note

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

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

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

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

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

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

    Azure AD のサインイン ログのスクリーンショット。

    Note

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

    ログ エントリをクリックして アクティビティの詳細 を表示し、[認証の詳細] をクリックします。 X.509 証明書のエントリが表示されます。

    X.509 証明書のエントリのスクリーンショット。

  6. Azure AD からクライアント証明書が要求され、ユーザーはクライアント証明書を選んで [OK] をクリックします。

    Note

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

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

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

  8. 多要素認証 (MFA) を必須とする条件付きアクセス ポリシーを使って一意のユーザーが見つかり、証明書認証のバインド規則が MFA を満たす場合、Azure AD によるそのユーザーのサインインはすぐに完了します。 多要素認証が必要だが、証明書が 1 つの要素しか満たしていない場合、認証は失敗します。

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

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

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

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

証明書の強度

管理者は、証明書の強度が単一要素か多要素かを決定できます。 詳細については、NIST Authentication Assurance Levels の Azure AD 認証メソッドへのマップに関するドキュメントを参照してください。これは、NIST 800-63B SP 800-63B の「Digital Identity Guidelines: Authentication and Lifecycle Mgmt (デジタル ID ガイドライン: 認証とライフサイクルの管理)」に基づいています。

単一要素証明書認証

ユーザーが単一要素証明書を持っている場合、多要素認証は実行できません。 1 番目の要素が単一要素証明書の場合、2 番目の要素はサポートされません。 2 番目の要素のサポートを追加する作業が行われています。

単一要素証明書に許可されていない MFA のスクリーンショット。

多要素証明書認証

ユーザーが多要素証明書を持っている場合、証明書を使った多要素認証のみを実行できます。 ただし、テナント管理者は、多要素と見なされるように証明書を PIN またはハードウェア モジュールで保護する必要があります。

複数ある認証ポリシー バインド規則の Azure AD による解決方法

複数の認証バインドポリシー規則を異なる証明書フィールドで作成できるため、認証保護レベルを決定する規則がいくつかあります。 制限事項は次のとおりです。

  1. 完全一致は、ポリシー 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 つ目の要素を要求されます。
  2. ポリシー OID ルールは、証明書発行者ルールよりも優先されます。 証明書にポリシー OID と発行者の両方が設定されている場合、常にポリシー OID が最初にチェックされ、ポリシー規則が見つからない場合は、発行者のサブジェクトのバインドがチェックされます。 ポリシー OID は、認証バインドが強力で発行者よりも優先度が高いです。
  3. 1 つの CA が MFA にバインドされている場合、この CA によって発行されるすべてのユーザー証明書は MFA として適格となります。 単一要素認証にも同じロジックが適用されます。
  4. 1つのポリシー OID が MFA にバインドしている場合、このポリシー OID を OID の1つとして含むすべてのユーザー証明書 (ユーザー証明書は複数のポリシー OID を持つことができます) が MFA として適格となります。
  5. 複数のポリシー OID 間に競合がある場合 (たとえば、証明書に 2 つのポリシー OID が設定されており、一方が単一要素認証にバインドされ、他方が MFA にバインドされている場合)、その証明書を単一要素認証として扱います。
  6. 1 つの証明書には、有効な強力な認証バインドを 1 つだけ含めることができます (つまり、証明書は単一要素と MFA の両方にバインドすることはできません)。

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

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

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

サポートされている 4 つの方法があります。 一般に、マッピングの種類は、再利用できない識別子 (サブジェクト キー識別子や SHA1 公開キーなど) に基づいている場合、高アフィニティと見なされます。 これらの識別子は、個々のユーザーを認証するために使用できる証明書が 1 つのみであることをより確実に保証するものです。 そのため、ユーザー名とメール アドレスに基づくすべてのマッピングの種類は低アフィニティと見なされます。 そのため、Azure AD は (再利用できる識別子に基づく) 低アフィニティと見なされる 2 つのマッピングを実装しています。他の 2 つは高アフィニティ バインディングと見なされます。 詳細については、certificateUserIds に関する記事を参照してください。

証明書マッピング フィールド certificateUserIds の値の例 ユーザー オブジェクト属性 種類
プリンシパル名 "X509:<PN>bob@woodgrove.com" userPrincipalName
onPremisesUserPrincipalName
certificateUserIds
低アフィニティ
RFC822Name "X509:<RFC822>user@woodgrove.com" userPrincipalName
onPremisesUserPrincipalName
certificateUserIds
低アフィニティ
X509SKI "X509:<SKI>123456789abcdef" certificateUserIds 高アフィニティ
X509SHA1PublicKey "X509:<SHA1-PUKEY>123456789abcdef" certificateUserIds 高アフィニティ

複数あるユーザー名ポリシー バインド規則の Azure AD による解決方法

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

  1. ユーザー名またはユーザー プリンシパル名を使ってユーザー オブジェクトを検索します。
  2. 提示された証明書に X.509 証明書フィールドがある場合、Azure AD により、証明書フィールドの値がユーザー オブジェクトの属性値と照合されます。
    1. 一致するものが見つかった場合、ユーザー認証は成功します。
    2. 一致するものが見つからない場合は、次の優先順位のバインドに移ります。
  3. 提示された証明書に X.509 証明書フィールドが存在しない場合は、次の優先順位のバインドに移ります。
  4. 構成されているすべてのユーザー名バインディングのうち、1 つでも一致するものが見つかり、ユーザー認証が成功するまで検証します。
  5. 構成されているユーザー名バインディングのいずれにも一致するものが見つからない場合、ユーザー認証は失敗します。

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

Azure AD ユーザー アカウントに証明書をバインドするために使用できる各 Azure AD 属性 (userPrincipalName、onPremiseUserPrincipalName、certificateUserIds) には、証明書が 1 つの Azure AD ユーザー アカウントにのみ一致するように確保する一意の制約があります。 ただし、Azure AD CBA は、ユーザー名バインド ポリシーで複数のバインド方法を構成することをサポートしています。 これにより、管理者は複数の証明書構成に対応できます。 ただし、複数の方法を組み合わせることで、1 つの証明書が複数の Azure AD ユーザー アカウントと一致することを許可する可能性もあります。

重要

複数のバインディングを使う場合、Azure AD CBA 認証の安全性は低アフィニティのバインディングと同程度にしかなりません。これは、Azure AD CBA では、ユーザーを認証する際に各バインディングを検証するからです。 1 つの証明書が複数の Azure AD アカウントに一致するシナリオを排除するために、テナント管理者は次のことを行う必要があります。

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

たとえば、テナント管理者が、Azure AD UPN にマップされる PrincipalName と、certificateUserIds にマップされる SubjectKeyIdentifier (SKI) という 2 つのユーザー名バインディングを持ち、証明書を 1 つの Azure AD アカウントにのみ使う場合、管理者は、そのアカウントが証明書に存在する UPN を持ち、同じアカウントの certificateUserId 属性で SKI マッピングを実装していることを確認する必要があります。

UPN と certificateUserID の考えられる値の例を次に示します。

Azure AD ユーザー プリンシパル名 = Bob.Smith@Contoso.com
certificateUserIDs = [x509:<SKI>89b0f468c1abea65ec22f0a882b8fda6fdd6750p]

PrincipalName と SKI の両方の値をユーザーの証明書から同じアカウントにマップすると、テナント ポリシーで PrincipalName を Azure AD UPN と certificateUserIds の SKI 値にマップすることを許可する一方で、その証明書が 1 つの Azure AD アカウントのみに一致するようにすることができます。 UserPrincipalName と certificateUserIds の両方に一意の制約があるので、他のユーザー アカウントは同じ値を持つことはできず、同じ証明書を使って認証できません。

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

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

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

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

重要

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

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

"The Certificate Revocation List (CRL) downloaded from {uri} has exceeded the maximum allowed size ({size} bytes) for CRLs in Azure Active Directory. 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} バイト) を超えました。数分してからもう一度お試しください。問題が解決しない場合は、テナント管理者に問い合わせてください。)

このエラーの後、Azure AD は、サービス側の制限 (Azure グローバルの場合は 45 MB、Azure US Government クラウドの場合は 150 MB) に従って CRL のダウンロードを試みます。

重要

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

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

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

  1. Azure AD は、対応する信頼された発行者または証明機関の証明書を持つユーザーの最初のサインイン イベントで、CRL のダウンロードを試行します。
  2. Azure AD は、後で使用するために CRL をキャッシュして再利用します。 CRL 文書に記載されている次の更新日と、利用可能な場合は次の CRL 発行日(Windows Server CA で使用)が適用されます。
  3. 次の場合、ユーザー証明書ベースの認証は失敗します。
    • 信頼できる発行者に対して CRL が構成されており、可用性、サイズ、または待機時間の制約により、Azure AD が CRL をダウンロードできません。

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

      CRL の失効したユーザー証明書のスクリーンショット。

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

Note

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

重要

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

現在のところ、管理者が CRL のダウンロードを手動で強制または再トリガーする方法はありません。

失効を構成する方法

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

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

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

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

  1. 管理者の資格情報で MSOL サービスに接続します。

            $msolcred = get-credential
             connect-msolservice -credential $msolcred
    
  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 コマンドで指定した日付ではありません)。

サインイン ログの概要

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

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

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

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

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

単一要素認証のテスト

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

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

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

  2. サインインが成功したら、[Azure Active Directory>のサインイン ログ] をクリックします。

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

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

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

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

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

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

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

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

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

多要素認証のテスト

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

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

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

  2. [Azure Active Directory]>[サインイン] をクリックします。

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

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

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

    サインイン ログの第 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 方法に直接移動します。[Use the certificate or smart card] (証明書またはスマート カードを使用する) を選ぶ必要はありません。

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

外部 ID のサポート

外部 ID では、Azure AD CBA を使うリソース テナントに対して多要素認証 (MFA) を実行できません。 代わりに、ユーザーがホーム テナントで CBA を使って MFA を実行するように指定し、リソース テナントがホーム テナントからの MFA を信頼するようにクロス テナント設定を行います。

[Trust multi-factor authentication from Azure AD tenants] (Azure AD テナントからの多要素認証を信頼する) を有効にする方法の詳細については、B2B コラボレーション クロステナント アクセスの構成に関する記事を参照してください。

既知の問題

  • iOS クライアントでは、Azure AD CBA フローの一部として、ユーザーが [Use the certificate or smart card] (証明書またはスマート カードを使用する) を 2 回クリックする必要があるという、二重のプロンプトの問題があります。 Microsoft はこの UX エクスペリエンスの問題を認識しており、シームレスな UX エクスペリエンスのためにこの問題の修正に取り組んでいます。

次のステップ