You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/active-directory-b2c/conditional-access-identity-protection-overview.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@
2
2
title: Identity Protection and Conditional Access in Azure AD B2C
3
3
description: Learn how Identity Protection gives you visibility into risky sign-ins and risk detections. Find out how and Conditional Access lets you enforce organizational policies based on risk events in your Azure AD B2C tenants.
4
4
ms.service: active-directory
5
-
ms.subservice: conditional-access
5
+
ms.subservice: B2C
6
6
ms.topic: overview
7
7
ms.date: 01/11/2024
8
8
ms.author: kengaderdus
@@ -29,7 +29,7 @@ If you're already familiar with [Identity Protection](../active-directory/identi
29
29
30
30
By pairing Conditional Access policies with Identity Protection risk detection, you can respond to risky authentications with the appropriate policy action.
31
31
32
-
-**Gain a new level of visibility into the authentication risks for your apps and your customer base**. With signals from billions of monthly authentications across Microsoft Entra ID and Microsoft Account, the risk detection algorithms will now flag authentications as low, medium, or high risk for your local consumer or citizen authentications.
32
+
-**Gain a new level of visibility into the authentication risks for your apps and your customer base**. With signals from billions of monthly authentications across Microsoft Entra ID and Microsoft Account, the risk detection algorithms flag authentications as low, medium, or high risk for your local consumer or citizen authentications.
33
33
-**Automatically address risks by configuring your own adaptive authentication**. For specified applications, you can require a specific set of users to provide a second authentication factor, as in multi-factor authentication (MFA). Or you can block access based on the risk level detected. As with other Azure AD B2C experiences, you can customize resulting end-user experience with your organization’s voice, style, and brand. You can also display mitigation alternatives if the user isn't able to gain access.
34
34
-**Control access based on location, groups, and apps**. Conditional Access can also be used to control non-risk based situations. For example, you can require MFA for customers accessing a specific app, or block access from specified geographies.
35
35
-**Integrate with Azure AD B2C user flows and Identity Experience Framework custom policies**. Use your existing customized experiences and add the controls you need to interface with Conditional Access. You can also implement advanced scenarios for granting access, such as knowledge-based access or your own preferred MFA provider.
Copy file name to clipboardExpand all lines: articles/active-directory-b2c/conditional-access-user-flow.md
+7-7Lines changed: 7 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,7 +3,7 @@ title: Add Conditional Access to a user flow in Azure AD B2C
3
3
description: Learn how to add Conditional Access to your Azure AD B2C user flows. Configure multifactor authentication (MFA) settings and Conditional Access policies in your user flows to enforce policies and remediate risky sign-ins.
4
4
5
5
ms.service: active-directory
6
-
ms.subservice: conditional-access
6
+
ms.subservice: B2C
7
7
ms.topic: overview
8
8
ms.date: 01/11/2024
9
9
ms.author: kengaderdus
@@ -40,13 +40,13 @@ The following example shows a Conditional Access technical profile that is used
40
40
</TechnicalProfile>
41
41
```
42
42
43
-
To ensure that Identity Protection signals are evaluated properly, you'll want to call the `ConditionalAccessEvaluation` technical profile for all users, including both [local and social accounts](technical-overview.md#consumer-accounts). Otherwise, Identity Protection will indicate an incorrect degree of risk associated with users.
43
+
To ensure that Identity Protection signals are evaluated properly, you'll want to call the `ConditionalAccessEvaluation` technical profile for all users, including both [local and social accounts](technical-overview.md#consumer-accounts). Otherwise, Identity Protection indicates an incorrect degree of risk associated with users.
44
44
::: zone-end
45
45
In the *Remediation* phase that follows, the user is challenged with MFA. Once complete, Azure AD B2C informs Identity Protection that the identified sign-in threat has been remediated and by which method. In this example, Azure AD B2C signals that the user has successfully completed the multifactor authentication challenge.
46
46
The remediation may also happen through other channels. For example, when the account's password is reset, either by the administrator or by the user. You can check the user *Risk state* in the [risky users report](identity-protection-investigate-risk.md#navigating-the-risky-users-report).
47
47
::: zone pivot="b2c-custom-policy"
48
48
> [!IMPORTANT]
49
-
> To remediate the risk successfully within the journey, make sure the *Remediation* technical profile is called after the *Evaluation* technical profile is executed. If *Evaluation* is invoked without *Remediation*, the risk state will be*At risk*.
49
+
> To remediate the risk successfully within the journey, make sure the *Remediation* technical profile is called after the *Evaluation* technical profile is executed. If *Evaluation* is invoked without *Remediation*, the risk state indicates as*At risk*.
50
50
When the *Evaluation* technical profile recommendation returns `Block`, the call to the *Evaluation* technical profile is not required. The risk state is set to *At risk*.
51
51
The following example shows a Conditional Access technical profile used to remediate the identified threat:
52
52
@@ -122,7 +122,7 @@ To add a Conditional Access policy:
122
122
123
123
| Include |License | Notes|
124
124
|---|---|---|
125
-
|**All users**| P1, P2 | This policy will affect all of your users. To be sure not to lock yourself out, exclude your administrative account by choosing **Exclude**, selecting **Directory roles**, and then selecting **Global Administrator** in the list. You can also select **Users and Groups** and then select your account in the **Select excluded users** list. |
125
+
|**All users**| P1, P2 | This policy affects all of your users. To be sure not to lock yourself out, exclude your administrative account by choosing **Exclude**, selecting **Directory roles**, and then selecting **Global Administrator** in the list. You can also select **Users and Groups** and then select your account in the **Select excluded users** list. |
126
126
127
127
1. Select **Cloud apps or actions**, and then **Select apps**. Browse for your [relying party application](tutorial-register-applications.md).
128
128
1. Select **Conditions**, and then select from the following conditions. For example, select **Sign-in risk** and **High**, **Medium**, and **Low** risk levels.
@@ -228,7 +228,7 @@ To configure your user based conditional access:
228
228
7. Under **Conditions** > **User risk**, set **Configure** to **Yes**. Under **Configure user risk levels needed for policy to be enforced**
229
229
1. Select **High** and **Medium**.
230
230
2. Select **Done**.
231
-
8. Under **Access controls** > **Grant**, select **Grant access**, **Require password change**, and select **Select**. **Require multi-factor authentication**will also be required by default.
231
+
8. Under **Access controls** > **Grant**, select **Grant access**, **Require password change**, and select **Select**. **Require multi-factor authentication**is also be required by default.
232
232
9. Confirm your settings and set **Enable policy** to **On**.
233
233
10. Select **Create** to create to enable your policy.
234
234
@@ -345,7 +345,7 @@ The following template can be used to create a Conditional Access policy with di
345
345
## Add Conditional Access to a user flow
346
346
347
347
After you've added the Microsoft Entra Conditional Access policy, enable Conditional Access in your user flow or custom policy. When you enable Conditional Access, you don't need to specify a policy name.
348
-
Multiple Conditional Access policies may apply to an individual user at any time. In this case, the most strict access control policy takes precedence. For example, if one policy requires MFA while the other blocks access, the user will be blocked.
348
+
Multiple Conditional Access policies may apply to an individual user at any time. In this case, the most strict access control policy takes precedence. For example, if one policy requires MFA while the other blocks access, the user is blocked.
349
349
350
350
## Enable multifactor authentication (optional)
351
351
@@ -386,7 +386,7 @@ To enable Conditional Access for a user flow, make sure the version supports Con
386
386
### Configure claim other than phone number to be used for MFA
387
387
388
388
In the Conditional Access policy above, the `DoesClaimExist` claim transformation method checks if a claim contains a value, for example if the `strongAuthenticationPhoneNumber` claim contains a phone number.
389
-
The claims transformation isn't limited to the `strongAuthenticationPhoneNumber` claim. Depending on the scenario, you can use any other claim. In the following XML snippet, the `strongAuthenticationEmailAddress` claim is checked instead. The claim you choose must have a valid value, otherwise the `IsMfaRegistered` claim will be set to `False`. When set to `False`, the Conditional Access policy evaluation returns a `Block` grant type, preventing the user from completing user flow.
389
+
The claims transformation isn't limited to the `strongAuthenticationPhoneNumber` claim. Depending on the scenario, you can use any other claim. In the following XML snippet, the `strongAuthenticationEmailAddress` claim is checked instead. The claim you choose must have a valid value, otherwise the `IsMfaRegistered` claim is set to `False`. When set to `False`, the Conditional Access policy evaluation returns a `Block` grant type, preventing the user from completing user flow.
0 commit comments