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-user-flow.md
+41-18Lines changed: 41 additions & 18 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,7 @@ services: active-directory
6
6
ms.service: active-directory
7
7
ms.subservice: conditional-access
8
8
ms.topic: overview
9
-
ms.date: 04/22/2021
9
+
ms.date: 05/06/2021
10
10
ms.custom: project-no-code
11
11
ms.author: mimart
12
12
author: msmimart
@@ -44,9 +44,18 @@ The following example shows a Conditional Access technical profile that is used
44
44
</TechnicalProfile>
45
45
```
46
46
47
+
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.
48
+
47
49
::: zone-end
48
50
49
-
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 multi-factor authentication challenge.
51
+
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 multi-factor authentication challenge.
52
+
53
+
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 the user *Risk state* in the [risky users report](identity-protection-investigate-risk.md#navigating-the-risky-users-report).
54
+
55
+
> [!IMPORTANT]
56
+
> 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*.
57
+
58
+
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*.
50
59
51
60
::: zone pivot="b2c-custom-policy"
52
61
@@ -147,25 +156,19 @@ To add a Conditional Access policy:
147
156
|---------|---------|---------|
148
157
|**Report-only**|P1, P2| Report-only allows administrators to evaluate the impact of Conditional Access policies before enabling them in their environment. We recommend you check policy with this state, and determine the impact to end users without requiring multi-factor authentication or blocking users. For more information, see [Review Conditional Access outcomes in the audit report](#review-conditional-access-outcomes-in-the-audit-report)|
149
158
|**On**| P1, P2| The access policy is evaluated and not enforced. |
150
-
|**Off**| P1, P2| The access policy is not activated and has no affect on the users. |
159
+
|**Off**| P1, P2| The access policy is not activated and has no effect on the users. |
151
160
152
161
1. Enable your test Conditional Access policy by selecting **Create**.
153
162
154
-
## Add Conditional Access to a user flow
155
-
156
-
After you've added the Azure AD 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.
157
-
158
-
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 multi-factor authentication (MFA), while the other blocks access, the user will be blocked.
Most users have a normal behavior that can be tracked, when they fall outside of this norm it could be risky to allow them to just sign in. You may want to block that user or maybe just ask them to perform multi-factor authentication to prove that they are really who they say they are.
163
166
164
-
A sign-in risk represents the probability that a given authentication request isn't authorized by the identity owner. Organizations with P2 licenses can create Conditional Access policies incorporating [Azure AD Identity Protection sign-in risk detections](../active-directory/identity-protection/concept-identity-protection-risks.md#sign-in-risk). Please note the [limitations on Identity Protection detections for B2C](./identity-protection-investigate-risk.md?pivots=b2c-user-flow#service-limitations-and-considerations).
167
+
A sign-in risk represents the probability that a given authentication request isn't authorized by the identity owner. Azure AD B2C tenants with P2 licenses can create Conditional Access policies incorporating [Azure AD Identity Protection sign-in risk detections](../active-directory/identity-protection/concept-identity-protection-risks.md#sign-in-risk). Please note the [limitations on Identity Protection detections for B2C](./identity-protection-investigate-risk.md?pivots=b2c-user-flow#service-limitations-and-considerations).
165
168
166
169
If risk is detected, users can perform multi-factor authentication to self-remediate and close the risky sign-in event to prevent unnecessary noise for administrators.
167
170
168
-
Organizations should choose one of the following options to enable a sign-in risk-based Conditional Access policy requiring multi-factor authentication (MFA) when sign-in risk is medium OR high.
171
+
Configure Conditional Access through the Azure portal or Microsoft Graph APIs to enable a sign-in risk-based Conditional Access policy requiring MFA when the sign-in risk is *medium* or *high*.
169
172
170
173
### Enable with Conditional Access policy
171
174
@@ -185,11 +188,11 @@ Organizations should choose one of the following options to enable a sign-in ris
185
188
9. Confirm your settings and set **Enable policy** to **On**.
186
189
10. Select **Create** to create to enable your policy.
187
190
188
-
### Enable with Conditional Access APIs
191
+
### Enable with Conditional Access APIs (optional)
189
192
190
-
To create a Sign-in risk-based Conditional Access policy with Conditional Access APIs, please refer to the documentation for[Conditional Access APIs](../active-directory/conditional-access/howto-conditional-access-apis.md#graph-api).
193
+
Create a sign-in risk-based Conditional Access policy with MS Graph APIs. For more information, see[Conditional Access APIs](../active-directory/conditional-access/howto-conditional-access-apis.md#graph-api).
191
194
192
-
The following template can be used to create a Conditional Access policy with display name "CA002: Require MFA for medium+ sign-in risk" in report-only mode.
195
+
The following template can be used to create a Conditional Access policy with display name "Template 1: Require MFA for medium+ sign-in risk" in report-only mode.
193
196
194
197
```json
195
198
{
@@ -222,6 +225,12 @@ The following template can be used to create a Conditional Access policy with di
222
225
}
223
226
```
224
227
228
+
## Add Conditional Access to a user flow
229
+
230
+
After you've added the Azure AD 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.
231
+
232
+
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.
233
+
225
234
## Enable multi-factor authentication (optional)
226
235
227
236
When adding Conditional Access to a user flow, consider the use of **Multi-factor authentication (MFA)**. Users can use a one-time code via SMS or voice, or a one-time password via email for multi-factor authentication. MFA settings are independent from Conditional Access settings. You can choose from these MFA options:
@@ -230,9 +239,6 @@ When adding Conditional Access to a user flow, consider the use of **Multi-facto
230
239
-**Always on** - MFA is always required regardless of your Conditional Access setup. If users aren't already enrolled in MFA, they're prompted to enroll during sign-in. During sign-up, users are prompted to enroll in MFA.
231
240
-**Conditional (Preview)** - MFA is required only when an active Conditional Access Policy requires it. If the result of the Conditional Access evaluation is an MFA challenge with no risk, MFA is enforced during sign-in. If the result is an MFA challenge due to risk *and* the user is not enrolled in MFA, sign-in is blocked. During sign-up, users aren't prompted to enroll in MFA.
232
241
233
-
> [!IMPORTANT]
234
-
> If your Conditional Access policy grants access with MFA but the user hasn't enrolled a phone number, the user may be blocked.
235
-
236
242
::: zone pivot="b2c-user-flow"
237
243
238
244
To enable Conditional Access for a user flow, make sure the version supports Conditional Access. These user flow versions are labeled **Recommended**.
@@ -265,6 +271,23 @@ To enable Conditional Access for a user flow, make sure the version supports Con
265
271
1. Get the example of a conditional access policy on [GitHub](https://github.com/azure-ad-b2c/samples/tree/master/policies/conditional-access).
266
272
1. In each file, replace the string `yourtenant` with the name of your Azure AD B2C tenant. For example, if the name of your B2C tenant is *contosob2c*, all instances of `yourtenant.onmicrosoft.com` become `contosob2c.onmicrosoft.com`.
267
273
1. Upload the policy files.
274
+
275
+
### Configure claim other than phone number to be used for MFA
276
+
277
+
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.
278
+
279
+
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.
Copy file name to clipboardExpand all lines: articles/active-directory-b2c/contentdefinitions.md
+46-20Lines changed: 46 additions & 20 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,7 +9,7 @@ manager: celestedg
9
9
ms.service: active-directory
10
10
ms.workload: identity
11
11
ms.topic: reference
12
-
ms.date: 02/15/2021
12
+
ms.date: 05/10/2021
13
13
ms.author: mimart
14
14
ms.subservice: B2C
15
15
---
@@ -71,6 +71,26 @@ The **ContentDefinition** element contains the following elements:
71
71
| Metadata | 0:1 | A collection of key/value pairs that contains the metadata utilized by the content definition. |
72
72
| LocalizedResourcesReferences | 0:1 | A collection of localized resources references. Use this element to customize the localization of a user interface and claims attribute. |
73
73
74
+
### LoadUri
75
+
76
+
The **LoadUri** element is used to specify the URL of the HTML5 page for the content definition. The Azure AD B2C [custom policy starter-packs](https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack) come with content definitions that use Azure AD B2C HTML pages. The **LoadUri** starts with `~`, which is a relative path to your Azure AD B2C tenant.
You can [customize the user interface with HTML templates](customize-ui-with-html.md). When using HTML templates, provide an absolute URL. The following example illustrates a content definition with HTML template:
The **DataUri** element is used to specify the page identifier. Azure AD B2C uses the page identifier to load and initiate UI elements and client side JavaScript. The format of the value is `urn:com:microsoft:aad:b2c:elements:page-name:version`. The following table lists the page identifiers you can use.
@@ -95,30 +115,36 @@ The [version](page-layout.md) part of the `DataUri` specifies the package of con
95
115
The following example shows the **DataUri** of `selfasserted` version `1.2.0`:
The format of the value must contain the word `contract`: _urn:com:microsoft:aad:b2c:elements:**contract**:page-name:version_. To specify a page layout in your custom policies that use an old **DataUri** value, use following table to migrate to the new format.
136
+
To migrate from the old **DataUri**value (without page contract) to page layout version, add the word `contract` follow by a page version. Use following table to migrate from the old **DataUri** valueto page layout version.
0 commit comments