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

[アーティクル]
11/16/2023

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

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

サービスの概要

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 Browser - 危険なサインインをシミュレートします。

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

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

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

前提条件

「Active Directory B2C でのカスタムポリシーの概要」にある手順を完了する。
まだ行っていない場合は、Web アプリケーションを登録します。

Pricing tier

危険なサインインのポリシーを作成するには、Azure AD B2C Premium 2 が必要です。 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 です。

Conditional access assignments 条件付きポリシーを追加するには:

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

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

包含	ライセンス	Notes
すべてのユーザー	P1、P2	このポリシーは、すべてのユーザーに影響します。自分自身をロックしないようにするには、 [除外] を選択し、 [ディレクトリロール] を選択してから、一覧で [全体管理者] を選択して、自分の管理者アカウントを除外します。 [ユーザーとグループ] を選択し、 [対象外とするユーザーの選択] の一覧で自分のアカウントを選択することもできます。

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

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

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

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

オプション	ライセンス	Notes
アクセスをブロックする	P1、P2	この条件付きアクセスポリシーに指定されている条件に基づいて、アクセスできないようにします。
[アクセス権の付与] ( [多要素認証を要求する] を指定)	P1、P2	この条件付きアクセスポリシーに指定されている条件に基づいて、ユーザーは Azure AD B2C の多要素認証を行うように要求されます。

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

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

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

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

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

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

[Include](含める) で、 [すべてのユーザー] を選択します。
[除外] で、 [ユーザーとグループ] を選択し、組織の緊急アクセス用または非常用アカウントを選択します。
[完了] を選択します。
[Cloud apps or actions](クラウドアプリまたはアクション)>[Include](含める) で、 [すべてのクラウドアプリ] を選択します。
[条件]>[サインインリスク] で、 [構成] を [はい] に設定します。 [このポリシーを適用するサインインリスクレベルを選択します] で、以下の操作を実行します。
1. [高] と [中] を選択します。
2. [Done] を選択します。
[アクセス制御]>[許可] で、 [アクセス権の付与] 、 [Require multi-factor authentication](多要素認証を要求する) の順に選択し、 [Select](選択する) を選択します。
設定を確認し、 [Enable policy](ポリシーの有効化) を [オン] に設定します。
[作成] を選択して、ポリシーを作成および有効化します。

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

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

{
    "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]>[セキュリティ]>[条件付きアクセス] を参照します。
[新しいポリシー] を選択します。
ポリシーに名前を付けます。ポリシーの名前に対する意味のある標準を組織で作成することをお勧めします。
[割り当て] で、 [ユーザーとグループ] を選択します。
1. [Include](含める) で、 [すべてのユーザー] を選択します。
2. [除外] で、 [ユーザーとグループ] を選択し、組織の緊急アクセス用または非常用アカウントを選択します。
3. [完了] を選択します。
[Cloud apps or actions](クラウドアプリまたはアクション)>[Include](含める) で、 [すべてのクラウドアプリ] を選択します。
[条件]>[ユーザーリスク] で、 [構成] を [はい] に設定します。 [ポリシーを適用するために必要なユーザーリスクのレベルを構成します] で
1. [高] と [中] を選択します。
2. [Done] を選択します。
[アクセス制御]>[付与] で、 [アクセスを許可] 、 [パスワードの変更を必須とする] の順に選択し、 [選択] を選択します。 [多要素認証を要求する] も既定で必要になります。
設定を確認し、 [Enable policy](ポリシーの有効化) を [オン] に設定します。
[作成] を選択して、ポリシーを作成および有効化します。

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

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

次のテンプレートを使用すると、レポート専用モードで、表示名が "Template 2: Require secure password change for medium+ user risk" の条件付きアクセスポリシーを作成できます。

{
    "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]>[セキュリティ]>[条件付きアクセス]>[ネームドロケーション] に移動します。
[国の場所] または [IP 範囲の場所] を選択します。
場所に名前を付けます。
指定しようとしている場所の [IP 範囲] を指定するか、 [国/地域] を選択します。国/地域を選択する場合、必要に応じて不明な領域を含めることもできます。
[保存] を選択します。

条件アクセスポリシーを使用して有効にするには:

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

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

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

次のテンプレートを使用すると、レポート専用モードで、表示名が "Template 3: Block unallowed locations" の条件付きアクセスポリシーを作成できます。

{
    "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 条件付きアクセスポリシーを追加した後、ユーザーフローまたはカスタムポリシーで条件付きアクセスを有効にします。条件付きアクセスを有効にするときに、ポリシー名を指定する必要はありません。複数の条件付きアクセスポリシーは、いつでも個々のユーザーに適用される可能性があります。この場合、最も厳格なアクセス制御ポリシーが優先されます。たとえば、あるポリシーでは MFA を要求し、別のポリシーではアクセスをブロックする場合、ユーザーはブロックされます。

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

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

[オフ] - サインイン時に MFA が適用されることはありません。ユーザーは、サインアップ時またはサインイン時に MFA への登録を求められません。
[常にオン] - 条件付きアクセスの設定に関係なく、MFA が常に必須になります。サインアップ時に、ユーザーは MFA に登録するよう求められます。サインインの間に、ユーザーが MFA にまだ登録されていない場合は、登録するよう求められます。
[Conditional](条件付き) - サインアップとサインインの間に、ユーザーは 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 enforcement](MFA の適用) で [Conditional](条件付き) を選択します。
[条件付きアクセス] セクションで、 [Enforce conditional access policies](条件付きアクセスポリシーを適用する) チェックボックスをオンにします。
[保存] を選択します。

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

条件付きアクセスポリシーの例については、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 Browser を開き、前の手順でコピーした URL を使用して登録済みのアプリにサインインします。
サインインページに要求された情報を入力し、サインインを試みます。トークンが https://jwt.ms に返され、表示されます。 jwt.ms のデコードされたトークンで、サインインがブロックされたことがわかります。

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

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

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

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

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

次のステップ

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

次の方法で共有

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

サービスの概要

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

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

前提条件

Pricing tier

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

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

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

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

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

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

場所を定義する

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

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

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

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

MFA で使用する電話番号以外の要求を構成する

カスタムポリシーのテスト

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

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

次のステップ

フィードバック

その他のリソース

次の方法で共有

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

サービスの概要

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

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

前提条件

Pricing tier

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

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

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

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

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

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

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

場所を定義する

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

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

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

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

MFA で使用する電話番号以外の要求を構成する

カスタム ポリシーのテスト

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

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

次のステップ

フィードバック

その他のリソース

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

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

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

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

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

カスタムポリシーのテスト

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