Azure Active Directory B2C のユーザーフローに条件付きアクセスを追加する

[アーティクル]
2025-05-06

重要

2025 年 5 月 1 日より、Azure AD B2C は新規のお客様向けに購入できなくなります。詳細については、FAQ を参照してください。

開始する前にこのページの上部にある ポリシーの種類 セレクターを使用して、設定するポリシーの種類を選択します。 Azure Active Directory B2C には、ユーザーがアプリケーションを操作する方法を定義する 2 つの方法 (定義済みのユーザーフローを使用する、または完全に構成可能なカスタムポリシーを使用する) があります。この記事で必要な手順は、方法ごとに異なります。

条件付きアクセスは、Azure Active Directory B2C (Azure AD B2C) ユーザーフローまたはカスタムポリシーに追加して、アプリケーションへの危険なサインインを管理できます。 Microsoft Entra 条件付きアクセスは、Azure AD B2C がシグナルをまとめ、意思決定を行い、組織のポリシーを適用するために使用するツールです。条件付きアクセスフローポリシー条件を使用してリスク評価を自動化すると、リスクの高いサインインがすぐに特定され、修復またはブロックされます。

サービスの概要

Azure AD B2C は、各サインインイベントを評価し、ユーザーにアクセス権を付与する前にすべてのポリシー要件が満たされていることを確認します。この評価フェーズでは、条件付きアクセスサービスによって、サインインイベント中に Identity Protection リスク検出によって収集されたシグナルが評価されます。この評価プロセスの結果は、サインインを許可するかブロックするかを示す一連の要求です。 Azure AD B2C ポリシーでは、これらの要求を使用してユーザーフロー内で機能します。たとえば、アクセスをブロックしたり、多要素認証 (MFA) などの特定の修復策でユーザーにチャレンジしたりする場合です。 [アクセスのブロック] は、他のすべての設定よりも優先されます。

次の例は、サインインの脅威を評価するために使用される条件付きアクセス技術プロファイルを示しています。

<TechnicalProfile Id="ConditionalAccessEvaluation">
  <DisplayName>Conditional Access Provider</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.ConditionalAccessProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <Metadata>
    <Item Key="OperationType">Evaluation</Item>
  </Metadata>
  ...
</TechnicalProfile>

Identity Protection シグナルが適切に評価されるようにするには、ローカルアカウントとソーシャルアカウントの両方を含むすべてのユーザーに対して ConditionalAccessEvaluation テクニカルプロファイルを呼び出す必要があります。そうしないと、Identity Protection はユーザーに関連付けられたリスクの度合いが正しくないことを示します。

次の修復フェーズでは、ユーザーに MFA がチャレンジされます。完了すると、Azure AD B2C は、特定されたサインインの脅威が修復されたことと、どの方法によって修復されたかを Identity Protection に通知します。この例では、Azure AD B2C は、ユーザーが多要素認証チャレンジを正常に完了したことを通知します。修復は、他のチャネルを通じて行われる場合もあります。たとえば、アカウントのパスワードが管理者またはユーザーによってリセットされた場合です。ユーザーの リスク状態 は、危険なユーザーレポートで確認できます。

重要

体験内でリスクを正常に修復するには、評価技術プロファイルの実行後に修復技術プロファイルが呼び出されることを確認します。修復なしで評価が呼び出された場合、リスク状態は [リスクあり] と表示されます。評価技術プロファイルの推奨事項が Block を返す場合、評価技術プロファイルの呼び出しは必要ありません。リスクの状態は [リスク] に設定されます。次の例は、特定された脅威を修復するために使用される条件付きアクセス技術プロファイルを示しています。

<TechnicalProfile Id="ConditionalAccessRemediation">
  <DisplayName>Conditional Access Remediation</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.ConditionalAccessProtocolProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
  <Metadata>
    <Item Key="OperationType">Remediation</Item>
  </Metadata>
  ...
</TechnicalProfile>

ソリューションのコンポーネント

Azure AD B2C で条件付きアクセスを有効にするコンポーネントは次のとおりです。

サインインとサインアップのプロセスをユーザーにガイドするユーザーフローまたはカスタムポリシー。
意思決定を行い、組織のポリシーを適用するためのシグナルをまとめる条件付きアクセスポリシー。ユーザーが Azure AD B2C ポリシーを使用してアプリケーションにサインインすると、条件付きアクセスポリシーでは Microsoft Entra ID Protection シグナルを使用して危険なサインインを特定し、適切な修復アクションを提示します。
ユーザーを適切な Azure AD B2C ユーザーフローまたはカスタムポリシーに誘導する登録済みアプリケーション。
危険なサインインをシミュレートするための TOR ブラウザー。

サービスの制限と考慮事項

Microsoft Entra 条件付きアクセスを使用する場合は、次の点を考慮してください。

Identity Protection は、ローカル ID と、Google や Facebook などのソーシャル ID の両方で使用できます。ソーシャル ID の場合は、条件付きアクセスを手動でアクティブ化する必要があります。ソーシャルアカウントの認証情報は外部 ID プロバイダによって管理されるため、検出は制限されます。
Azure AD B2C テナントでは、 Microsoft Entra 条件付きアクセスポリシーのサブセットのみを使用できます。

[前提条件]

「Active Directory B2C でのカスタムポリシーの概要」の手順を完了してください。このチュートリアルでは、Azure AD B2C テナント構成を使用するようにカスタムポリシーファイルを更新する方法について説明します。
Web アプリを登録していない場合は、Web アプリケーションを登録する手順を使用して Web アプリを登録します。

価格階層

危険なサインインポリシーを作成するには、Azure AD B2C Premium P2 が必要です。 Premium P1 テナントは、場所、アプリケーション、ユーザーベース、またはグループベースのポリシーに基づくポリシーを作成できます。詳細については、「Azure AD B2C の価格レベルを変更する」を参照してください。

Azure AD B2C テナントを準備する

条件付きアクセスポリシーを追加するには、セキュリティの既定値群を無効にします。

Azure portal にサインインします。
複数のテナントにアクセスできる場合、上部のメニューの [設定] アイコンを選択し、[ディレクトリとサブスクリプション] メニューからお使いの Azure AD B2C テナントに切り替えます。
Azure サービス で、Microsoft Entra ID を選択します。または、検索ボックスを使用して Microsoft Entra ID を見つけて選択します。
[プロパティ] を選択し、[セキュリティの既定値の管理] を選択します。
[セキュリティの既定値を有効にする] で、[いいえ] を選択します。

条件付きアクセスポリシーを追加する

条件付きアクセスポリシーは、割り当てとアクセス制御の if-then ステートメントです。条件付きアクセスポリシーは、シグナルをまとめて意思決定を行い、組織のポリシーを適用します。

ヒント

この手順では、条件付きアクセスポリシーを構成します。テンプレート 1: サインインリスクベースの条件付きアクセス、テンプレート 2: ユーザーリスクベースの条件付きアクセス、またはテンプレート 3: 条件付きアクセスで場所をブロックするテンプレートのいずれかを使用することをお勧めします。条件付きアクセスポリシーは、Azure portal または MS Graph API を使用して構成できます。

代入間の論理演算子は AND です。各代入の演算子は OR です。

条件付きアクセスの割り当て条件付きアクセスポリシーを追加するには:

Azure portal で、 [Azure AD B2C] を検索して選択します。
[ セキュリティ] で、[ 条件付きアクセス] を選択します。 [条件付きアクセスポリシー] ページが開きます。
[新しいポリシー] を選択します。
ポリシーの名前を入力します (例: 危険なサインインをブロックする)。

[割り当て] で [ユーザーとグループ] を選択し、次のサポートされている設定のいずれかを選択します。

包含	ライセンス	注記
すべてのユーザー	P1、P2	このポリシーは、すべてのユーザーに影響します。ロックアウトされないようにするには、[ 除外] を選択し、[ ディレクトリロール] を選択し、一覧で [ グローバル管理者 ] を選択して、管理者アカウントを除外します。 [ ユーザーとグループ ] を選択し、[ 除外されたユーザーの選択 ] リストでアカウントを選択することもできます。

[クラウドアプリまたはアクション] を選択し、[アプリの選択] を選択します。証明書利用者アプリケーションを参照します。

[条件] を選択し、次の条件から選択します。たとえば、 [ サインインリスク ] と [ 高、中、低のリスクレベル] を選択します。

条件	ライセンス	注記
ユーザーリスク	P2	ユーザーリスクは、特定の ID またはアカウントが侵害されているおそれがあることを表します。
サインインリスク	P2	サインインリスクは、特定の認証要求が ID 所有者によって承認されていない可能性を表します。
デバイスプラットフォーム	サポートされていません	デバイス上で実行されるオペレーティングシステムによって特徴付けられます。詳細については、「デバイスプラットフォーム」を参照してください。
場所	P1、P2	ネームドロケーションには、パブリック IPv4 ネットワーク情報、国や地域、特定の国や地域にマッピングされていない不明なエリアが含まれる場合があります。詳細については、「場所」を参照してください。

アクセス制御 で、許可を選択します。次に、アクセスをブロックするか許可するかを選択します。

選択肢	ライセンス	注記
[アクセスのブロック]	P1、P2	この条件付きアクセスポリシーで指定された条件に基づくアクセスを防止します。
[多要素認証が必要] でアクセスを許可する	P1、P2	この条件付きアクセスポリシーで指定された条件に基づいて、ユーザーは Azure AD B2C 多要素認証を通過する必要があります。

[ ポリシーの有効化] で、次のいずれかを選択します。

選択肢	ライセンス	注記
レポート専用	P1、P2	レポート専用では、管理者は、条件付きアクセスポリシーを環境で有効にする前に、その影響を評価できます。この状態でポリシーを確認し、多要素認証を必要とせずにエンドユーザーへの影響を判断したり、ユーザーをブロックしたりすることをお勧めします。詳細については、「監査レポートで条件付きアクセスの結果を確認する」を参照してください
オン	P1、P2	アクセスポリシーは評価され、強制されません。
オフ	P1、P2	アクセスポリシーはアクティブ化されず、ユーザーには影響しません。

テストの条件付きアクセスポリシーを有効にするには、 [作成] を選択します。

ほとんどのユーザーは、追跡できる正常な動作をしています。この規範から外れた場合は、そのユーザーにサインインを許可すると危険であることがあります。そのユーザーをブロックしたり、多要素認証を実行してユーザーが本人であることを証明するように求めたりすることが必要な場合もあります。サインインリスクは、特定の認証要求が ID 所有者によって承認されていない可能性があることを表します。 P2 ライセンスを持つ Azure AD B2C テナントは、Microsoft Entra ID Protection のサインインリスク検出を組み込んだ条件付きアクセスポリシーを作成できます。

B2C の Identity Protection 検出に関する制限事項に注意してください。リスクが検出された場合、ユーザーは多要素認証を実行して自己修復し、危険なサインインイベントを閉じて、管理者の不要なノイズを防ぐことができます。

Azure portal または Microsoft Graph API を使用して条件付きアクセスを構成し、サインインリスクが中または高い場合に MFA を必要とするサインインリスクベースの条件付きアクセスポリシーを有効にします。

[Include](含める) で、 [すべてのユーザー] を選択します。
[ 除外] で、[ ユーザーとグループ ] を選択し、組織の緊急アクセス用またはブレイクグラスアカウントを選択します。
完了を選択します。
[Cloud apps or actions](クラウドアプリまたはアクション)>[Include](含める) で、 [すべてのクラウドアプリ] を選択します。
[条件]>[ログインリスク] で、[構成] を [はい] に設定します。 [ このポリシーを適用するサインインリスクレベルを選択してください]
1. [高] と [中] を選択します。
2. 完了を選択します。
アクセス制御>許可で、アクセスの許可を選択し、多要素認証が必要を要求し、選択をクリックします。
設定を確認し、 [Enable policy](ポリシーの有効化) を [オン] に設定します。
[作成] を選択して、ポリシーを作成および有効化します。

条件付きアクセス API を使用してテンプレート 1 を有効にする (省略可能)

MS Graph API を使用して、サインインリスクベースの条件付きアクセスポリシーを作成します。詳細については、「条件付きアクセス API」を参照してください。次のテンプレートを使用すると、レポート専用モードで "Template 1: Require MFA for medium+ sign-in risk" (テンプレート 1: 中 + サインインリスクに MFA が必要)" という表示名を持つ条件付きアクセスポリシーを作成できます。

{
    "displayName": "Template 1: Require MFA for medium+ sign-in risk",
    "state": "enabledForReportingButNotEnforced",
    "conditions": {
        "signInRiskLevels": [ "high" ,
            "medium"
        ],
        "applications": {
            "includeApplications": [
                "All"
            ]
        },
        "users": {
            "includeUsers": [
                "All"
            ],
            "excludeUsers": [
                "f753047e-de31-4c74-a6fb-c38589047723"
            ]
        }
    },
    "grantControls": {
        "operator": "OR",
        "builtInControls": [
            "mfa"
        ]
    }
}

テンプレート 2: ユーザーリスクベースの条件付きアクセス

Identity Protection は、ユーザーの行動に対して正常と思われるものを計算し、それを使用してリスクの判断を下すことができます。ユーザーリスクとは、IDが侵害された確率の計算です。 P2 ライセンスを持つ B2C テナントは、ユーザーリスクを組み込んだ条件付きアクセスポリシーを作成できます。ユーザーが危険にさらされていると検出された場合、リスクを是正し、アカウントにアクセスできるように、パスワードを安全に変更するように要求できます。ユーザーが自己修復できるように、安全なパスワードの変更を要求するようにユーザーリスクポリシーを設定することを強くお勧めします。

Identity Protection のユーザーリスクの詳細については、B2C の Identity Protection 検出の制限を考慮してください。

Azure portal または Microsoft Graph API を使用して条件付きアクセスを構成し、ユーザーリスクが中または高の場合に多要素認証 (MFA) とパスワードの変更を必要とするユーザーリスクベースの条件付きアクセスポリシーを有効にします。

ユーザーベースの条件付きアクセスを構成するには:

Azure portal にサインインします。
Azure AD B2C>Security>Conditional Access を参照します。
[新しいポリシー] を選択します。
ポリシーの名前を設定してください。ポリシーの名前に対する意味のある標準を組織で作成することをお勧めします。
[割り当て] で、 [ユーザーとグループ] を選択します。
1. [Include](含める) で、 [すべてのユーザー] を選択します。
2. [ 除外] で、[ ユーザーとグループ ] を選択し、組織の緊急アクセス用またはブレイクグラスアカウントを選択します。
3. 完了を選択します。
[Cloud apps or actions](クラウドアプリまたはアクション)>[Include](含める) で、 [すべてのクラウドアプリ] を選択します。
[条件]>[ユーザーリスク] で、[構成] を [はい] に設定します。 ポリシー適用に必要なユーザーリスクレベルの設定
1. [高] と [中] を選択します。
2. 完了を選択します。
アクセス制御>許可で、アクセスの許可、パスワード変更の必要 を選択し、選択を選択します。 [多要素認証が必要 ] もデフォルトで必須です。
設定を確認し、 [Enable policy](ポリシーの有効化) を [オン] に設定します。
[作成] を選択して、ポリシーを作成および有効化します。

条件付きアクセス API を使用してテンプレート 2 を有効にする (省略可能)

条件付きアクセス API を使用してユーザーリスクベースの条件付きアクセスポリシーを作成するには、条件付きアクセス API のドキュメントを参照してください。

次のテンプレートを使用すると、レポート専用モードで "テンプレート 2: 中 + ユーザーリスクに対してセキュリティで保護されたパスワードの変更を要求する" という表示名を持つ条件付きアクセスポリシーを作成できます。

{
    "displayName": "Template 2: Require secure password change for medium+ user risk",
    "state": "enabledForReportingButNotEnforced",
    "conditions": {
        "userRiskLevels": [ "high" ,
            "medium"
        ],
        "applications": {
            "includeApplications": [
                "All"
            ]
        },
        "users": {
            "includeUsers": [
                "All"
            ],
            "excludeUsers": [
                "f753047e-de31-4c74-a6fb-c38589047723"
            ]
        }
    },
    "grantControls": {
        "operator": "AND",
        "builtInControls": [
            "mfa",
            "passwordChange"
        ]
    }
}

テンプレート 3: 条件付きアクセスで場所をブロックする

条件付きアクセスで場所の条件を使用すると、ユーザーのネットワークの場所に基づいて、クラウドアプリへのアクセスを制御できます。 Azure portal または Microsoft Graph API を使用して条件付きアクセスを構成し、特定の場所へのアクセスをブロックする条件付きアクセスポリシーを有効にします。詳細については、「条件付きアクセスポリシーでの場所条件の使用」を参照してください

場所を定義する

Azure portal にサインインします。
Azure AD B2C>Security>Conditional Access>Named Locations に移動します。
[国] の場所または [IP 範囲の場所] を選択します
場所に名前を付けます。
IP 範囲を指定するか、指定する場所の国/地域を選択します。国/地域を選択する場合、必要に応じて不明な領域を含めることもできます。
保存] を選択します。

条件付きアクセスポリシーで有効にするには:

Azure portal にサインインします。
Azure AD B2C>Security>Conditional Access を参照します。
[新しいポリシー] を選択します。
ポリシーの名前を設定してください。ポリシーの名前に対する意味のある標準を組織で作成することをお勧めします。
[割り当て] で、 [ユーザーとグループ] を選択します。
1. [Include](含める) で、 [すべてのユーザー] を選択します。
2. [ 除外] で、[ ユーザーとグループ ] を選択し、組織の緊急アクセス用またはブレイクグラスアカウントを選択します。
3. 完了を選択します。
[Cloud apps or actions](クラウドアプリまたはアクション)>[Include](含める) で、 [すべてのクラウドアプリ] を選択します。
条件>ロケーション
1. [構成] を [はい] に設定します。
2. [Include](含める) で [選択された場所] を選択します
3. 作成したネームドロケーションを選択します。
4. [選択] をクリックします
[アクセス制御] で>[アクセスのブロック] を選択し、[選択] を選択します。
設定を確認し、 [Enable policy](ポリシーの有効化) を [オン] に設定します。
[作成] を選択して、ポリシーを作成および有効化します。

条件付きアクセス API を使用してテンプレート 3 を有効にする (省略可能)

条件付きアクセス API を使用して場所ベースの条件付きアクセスポリシーを作成するには、条件付きアクセス API のドキュメントを参照してください。ネームドロケーションを設定するには、ネームドロケーションのドキュメントを参照してください。

次のテンプレートを使用すると、レポート専用モードで "テンプレート 3: 許可されていない場所をブロックする" という表示名を持つ条件付きアクセスポリシーを作成できます。

{
    "displayName": "Template 3: Block unallowed locations",
    "state": "enabledForReportingButNotEnforced",
    "conditions": {
        "applications": {
            "includeApplications": [
                "All"
            ]
        },
        "users": {
            "includeUsers": [
                "All"
            ],
            "excludeUsers": [
                "f753047e-de31-4c74-a6fb-c38589047723"
            ]
        },
        "locations": {
            "includeLocations": [
                "b5c47916-b835-4c77-bd91-807ec08bf2a3"
          ]
        }
    },
    "grantControls": {
        "operator": "OR",
        "builtInControls": [
            "block"
        ]
    }
}

ユーザーフローに条件付きアクセスを追加する

Microsoft Entra 条件付きアクセスポリシーを追加したら、ユーザーフローまたはカスタムポリシーで条件付きアクセスを有効にします。条件付きアクセスを有効にする場合、ポリシー名を指定する必要はありません。複数の条件付きアクセスポリシーは、いつでも個々のユーザーに適用できます。この場合、最も厳格なアクセス制御ポリシーが優先されます。たとえば、1 つのポリシーで MFA が必要で、もう 1 つのポリシーでアクセスがブロックされている場合、ユーザーはブロックされます。

多要素認証を有効にする (オプション)

ユーザーフローに条件付きアクセスを追加する場合は、 多要素認証 (MFA) の使用を検討してください。ユーザーは、SMSまたは音声によるワンタイムコード、電子メールによるワンタイムパスワード、または認証アプリを介した時間ベースのワンタイムパスワード(TOTP)コードを使用して多要素認証を行うことができます。 MFA 設定は、条件付きアクセス設定とは別に構成されます。次の MFA オプションから選択できます。

オフ - サインイン時に MFA が適用されることはなく、ユーザーはサインアップまたはサインイン時に MFA への登録を求められません。
Always On - 条件付きアクセスの設定に関係なく、MFA は常に必要です。サインアップ時に、ユーザーは MFA に登録するように求められます。サインイン中に、ユーザーがまだ MFA に登録されていない場合は、登録を求められます。
条件付き - サインアップとサインイン中に、ユーザーは MFA (新しいユーザーと MFA に登録されていない既存のユーザーの両方) に登録するように求められます。サインイン中、MFA は、アクティブな条件付きアクセスポリシー評価で必要な場合にのみ適用されます。
- 結果がリスクのない MFA チャレンジである場合は、MFA が適用されます。ユーザーがまだ MFA に登録されていない場合は、登録を求められます。
- 結果がリスクによる MFA チャレンジであり、ユーザーが MFA に登録されていない場合、サインインはブロックされます。
注

Azure AD B2C での条件付きアクセスの一般提供により、ユーザーはサインアップ時に MFA メソッドに登録するように求められるようになりました。一般提供前に作成したサインアップユーザーフローは、この新しい動作を自動的に反映しませんが、新しいユーザーフローを作成することで動作を含めることができます。

ユーザーフローの条件付きアクセスを有効にするには、バージョンが条件付きアクセスをサポートしていることを確認します。これらのユーザーフローバージョンには 、 [推奨] というラベルが付けられています。

Azure portal にサインインします。
複数のテナントにアクセスできる場合、上部のメニューの [設定] アイコンを選択し、[ディレクトリとサブスクリプション] メニューからお使いの Azure AD B2C テナントに切り替えます。
Azure サービスで、Azure AD B2C を選択します。または、検索ボックスを使用して Azure AD B2C を検索して選択します。
[ポリシー] で [ユーザーフロー] を選択します。次に、ユーザーフローを選択します。
[プロパティ] を選択し、ユーザーフローが条件付きアクセスをサポートしていることを確認するために、 [条件付きアクセス] というラベルの付いた設定を探します。
[ 多要素認証 ] セクションで、目的の 方法の種類を選択し、[ MFA の適用] で [条件付き] を選択します。
[条件付きアクセス] セクションで、[条件付きアクセスポリシーを適用する] チェックボックスをオンにします。
保存を選択します。

ポリシーに条件付きアクセスを追加する

条件付きアクセスポリシーの例を GitHub で入手してください。
各ファイルで、 yourtenant 文字列を Azure AD B2C テナントの名前に置き換えます。たとえば、B2C テナントの名前が contosob2c の場合、 yourtenant.onmicrosoft.com のすべてのインスタンスが contosob2c.onmicrosoft.comになります。
ポリシーファイルをアップロードします。

MFA に使用する電話番号以外のクレームを設定する

上記の条件付きアクセスポリシーでは、 DoesClaimExist 要求変換方法によって、要求に値が含まれているかどうか (たとえば、 strongAuthenticationPhoneNumber 要求に電話番号が含まれているかどうか) がチェックされます。請求の変換は、 strongAuthenticationPhoneNumber 請求に限定されません。シナリオによっては、他の任意の要求を使用できます。次の XML スニペットでは、代わりに strongAuthenticationEmailAddress クレームがチェックされます。選択する要求には有効な値が必要であり、そうでない場合は、 IsMfaRegistered 要求は False に設定されます。 Falseに設定すると、条件付きアクセスポリシーの評価では Block の許可の種類が返され、ユーザーがユーザーフローを完了できなくなります。

 <ClaimsTransformation Id="IsMfaRegisteredCT" TransformationMethod="DoesClaimExist">
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="strongAuthenticationEmailAddress" TransformationClaimType="inputClaim" />
  </InputClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="IsMfaRegistered" TransformationClaimType="outputClaim" />
  </OutputClaims>
 </ClaimsTransformation>

カスタムポリシーをテストする

B2C_1A_signup_signin_with_caポリシーまたはB2C_1A_signup_signin_with_ca_whatifポリシーを選択して、その概要ページを開きます。次に、 [ユーザーフローの実行] を選択します。 [アプリケーション] で [webapp1] を選択します。 応答 URL にhttps://jwt.msが表示されます。
[ ユーザーフローエンドポイントの実行] の下の URL をコピーします。
危険なサインインをシミュレートするには、 Tor ブラウザを開き、前の手順でコピーしたURLを使用して登録済みアプリにサインインします。
サインインページに要求された情報を入力し、サインインを試みます。トークンは https://jwt.ms に返され、表示されます。 jwt.ms デコードされたトークンでは、サインインがブロックされたことがわかります。

ユーザーフローをテストする

作成したユーザーフローを選択して概要ページを開き、 [ ユーザーフローの実行] を選択します。 [アプリケーション] で [webapp1] を選択します。 応答 URL にhttps://jwt.msが表示されます。
[ ユーザーフローエンドポイントの実行] の下の URL をコピーします。
危険なサインインをシミュレートするには、 Tor ブラウザを開き、前の手順でコピーしたURLを使用して登録済みアプリにサインインします。
サインインページに要求された情報を入力し、サインインを試みます。トークンは https://jwt.ms に返され、表示されます。 jwt.ms デコードされたトークンでは、サインインがブロックされたことがわかります。

監査レポートで条件付きアクセスの結果を確認する

条件付きアクセスイベントの結果を確認するには:

Azure portal にサインインします。
複数のテナントにアクセスできる場合、上部のメニューの [設定] アイコンを選択し、[ディレクトリとサブスクリプション] メニューからお使いの Azure AD B2C テナントに切り替えます。
Azure サービスで、Azure AD B2C を選択します。または、検索ボックスを使用して Azure AD B2C を検索して選択します。
[ アクティビティ] で、[ 監査ログ] を選択します。
監査ログをフィルター処理するには、[ カテゴリ] を [B2C ] に設定し、[ アクティビティリソースの種類 ] を [IdentityProtection] に設定します。次に、[適用] を選択します。
過去 7 日間の監査アクティビティを確認します。次のタイプのアクティビティが含まれます。
- 条件付きアクセスポリシーの評価: この監査ログエントリは、認証中に条件付きアクセス評価が実行されたことを示します。
- ユーザーの修復: このエントリは、条件付きアクセスポリシーの付与または要件がエンドユーザーによって満たされ、このアクティビティがユーザーの軽減 (リスク軽減) のためにリスクエンジンに報告されたことを示します。
一覧で [条件付きアクセスポリシーの評価 ] ログエントリを選択して [ アクティビティの詳細: 監査ログ ] ページを開きます。このページには、監査ログ識別子と、次の情報が [ 追加の詳細 ] セクションに表示されます。
- ConditionalAccessResult: 条件付きポリシーの評価に必要な付与。
- AppliedPolicies: 条件が満たされ、ポリシーが ON になっているすべての条件付きアクセスポリシーの一覧。
- ReportingPolicies: レポート専用モードに設定された条件付きアクセスポリシーと、条件が満たされた場所の一覧。

Azure AD B2C ユーザーフローのユーザーインターフェイスをカスタマイズする

次の方法で共有

Azure Active Directory B2C のユーザー フローに条件付きアクセスを追加する

サービスの概要

ソリューションのコンポーネント

サービスの制限と考慮事項

[前提条件]

価格階層

Azure AD B2C テナントを準備する

条件付きアクセス ポリシーを追加する

テンプレート 1: サインイン リスクベースの条件付きアクセス

条件付きアクセス API を使用してテンプレート 1 を有効にする (省略可能)

テンプレート 2: ユーザー リスクベースの条件付きアクセス

条件付きアクセス API を使用してテンプレート 2 を有効にする (省略可能)

テンプレート 3: 条件付きアクセスで場所をブロックする

場所を定義する

条件付きアクセス API を使用してテンプレート 3 を有効にする (省略可能)

ユーザー フローに条件付きアクセスを追加する

多要素認証を有効にする (オプション)

ポリシーに条件付きアクセスを追加する

MFA に使用する電話番号以外のクレームを設定する

カスタム ポリシーをテストする

ユーザー フローをテストする

監査レポートで条件付きアクセスの結果を確認する

関連コンテンツ

フィードバック

その他のリソース