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
For example, as shown in the diagram below, if you have a sign-in risk policy that requires multifactor authentication when the sign-in risk level is medium or high, then the user must pass that access control if their sign-in session is detected to be at high risk.
26
+
For example, as shown in the diagram below, if organizations have a sign-in risk policy that requires multifactor authentication when the sign-in risk level is medium or high, their users must complete multifactor authentication when their sign-in risk is medium or high.
27
27
28
-
28
+
29
29
30
-
The example above also demonstrates a main benefit of risk-based policy: **automatic risk remediation**. When a user successfully completes the required access control that verified their identity, their risk will be automatically remediated. That sign-in session and their user account won't be at risk, and no action is needed from the administrator.
30
+
The example above also demonstrates a main benefit of a risk-based policy: **automatic risk remediation**. When a user successfully completes the required access control, like a secure password change, their risk is remediated. That sign-in session and user account won't be at risk, and no action is needed from the administrator.
31
31
32
-
Automatic risk remediation will significantly reduce the risk investigation and remediation burden on the administrators while protecting your organizations from security compromises.
33
-
More information about risk as a condition in a Conditional Access policy can be found in the article, [Conditional Access: Conditions](../conditional-access/concept-conditional-access-conditions.md#sign-in-risk)
32
+
Allowing users to self-remediate using this process, will significantly reduce the risk investigation and remediation burden on the administrators while protecting your organizations from security compromises. More information about risk remediation can be found in the article, [Remediate risks and unblock users](howto-identity-protection-remediate-unblock.md).
34
33
35
34
## Sign-in risk-based Conditional Access policy
36
35
37
-
Identity Protection analyzes signals in real-time during each sign-in, calculates a real-time sign-in risk level based on the probability that the sign-in wasn't really the user, and sends the risk level to Conditional Access. Administrators can create a Sign-in risk-based Conditional Access policy to specify what access control to apply based on this risk level to enforce organizational requirements like:
36
+
During each sign-in, Identity Protection analyzes hundreds of signals in real-time and calculates a sign-in risk level that represents the probability that the given authentication request isn't authorized. This risk level then gets sent to Conditional Access, where the organization's configured policies are evaluated. Administrators can configure sign-in risk-based Conditional Access policies to enforce access controls based on sign-in risk, including requirements such as:
38
37
39
38
- Block access
40
39
- Allow access
41
40
- Require multifactor authentication
42
41
43
42
If risks are detected on a sign-in, users can perform the required access control such as multifactor authentication to self-remediate and close the risky sign-in event to prevent unnecessary noise for administrators.
> Users must have previously registered for Azure AD Multifactor Authentication before triggering the sign-in risk policy.
49
48
50
49
## User risk-based Conditional Access policy
51
50
52
-
Identity Protection can calculate what it believes is normal for a user's behavior and use that to base decisions for their risk. User risk level is a calculation of probability that an identity has been compromised. If a user has risky sign-ins or there are risks such as leaked credentials detected on their account, then the user account is at risk with a user risk level calculated by Identity Protection. Administrators can create a User risk-based Conditional Access policy to specify what access control to apply based when the user is at risk to enforce organizational requirements: block access, allow access, or allow access but require a secure password change using [Azure AD self-service password reset](../authentication/howto-sspr-deployment.md).
51
+
Identity Protection analyzes signals about user accounts and calculates a risk score based on the probability that the user has been compromised. If a user has risky sign-in behavior, or their credentials have been leaked, Identity Protection will use these signals to calculate the user risk level. Administrators can configure user risk-based Conditional Access policies to enforce access controls based on user risk, including requirements such as:
52
+
53
+
- Block access
54
+
- Allow access but require a secure password change using [Azure AD self-service password reset](../authentication/howto-sspr-deployment.md).
53
55
54
56
A secure password change will remediate the user risk and close the risky user event to prevent unnecessary noise for administrators.
55
57
@@ -58,14 +60,14 @@ A secure password change will remediate the user risk and close the risky user e
58
60
59
61
## Identity Protection policies
60
62
61
-
While Identity Protection also offers a user interface for creating user risk policy and sign-in risk policy, we highly recommend that you use Azure AD Conditional Access to create risk-based access policies for the following benefits:
63
+
While Identity Protection also offers a user interface for creating user risk policy and sign-in risk policy, we highly recommend that you [use Azure AD Conditional Access to create risk-based policies](howto-identity-protection-configure-risk-policies.md) for the following benefits:
62
64
63
65
- Rich set of conditions to control access: Conditional Access offers a rich set of conditions such as applications and locations for configuration. The risk conditions can be used in combination with other conditions to create policies that best enforce your organizational requirements.
64
66
- Multiple risk-based policies can be put in place to target different user groups or apply different access control for different risk levels.
65
67
- Conditional Access policies can be created through Microsoft Graph API and can be tested first in report-only mode.
66
68
- Manage all access policies in one place in Conditional Access.
67
69
68
-
If you already have Identity Protection risk policies set up, we encourage you to migrate them to Conditional Access.
70
+
If you already have Identity Protection risk policies set up, we encourage you to [migrate them to Conditional Access](howto-identity-protection-configure-risk-policies.md#migrate-risk-policies-from-identity-protection-to-conditional-access).
Copy file name to clipboardExpand all lines: articles/active-directory/identity-protection/howto-identity-protection-configure-risk-policies.md
+4-4Lines changed: 4 additions & 4 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: identity-protection
8
8
ms.topic: how-to
9
-
ms.date: 10/03/2022
9
+
ms.date: 10/04/2022
10
10
11
11
ms.author: joflore
12
12
author: MicrosoftGuyJFlo
@@ -22,7 +22,7 @@ As we learned in the previous article, [Identity Protection policies](concept-id
22
22
- Sign-in risk policy
23
23
- User risk policy
24
24
25
-
25
+
26
26
27
27
## Choosing acceptable risk levels
28
28
@@ -125,11 +125,11 @@ While Identity Protection also provides two risk policies with limited condition
125
125
126
126
If you already have risk policies enabled in Identity Protection, we highly recommend that you migrate them to Conditional Access:
127
127
128
-
128
+
129
129
130
130
### Migrating to Conditional Access
131
131
132
-
1. **Create**[a risk-basedpolicy](#enable-policies)in Conditional Access in report-only mode. You can do this with the steps above or using [Conditional Access templates](../conditional-access/concept-conditional-access-policy-common.md#common-conditional-access-policies).
132
+
1. **Create an equivalent**[user risk-based](#user-risk-policy-in-conditional-access) and [sign-in risk-based ](#sign-in-risk-policy-in-conditional-access) policy in Conditional Access in report-only mode. You can do this with the steps above or using [Conditional Access templates](../conditional-access/concept-conditional-access-policy-common.md#common-conditional-access-policies) based on Microsoft's recommendations.
133
133
1. Ensure that the new Conditional Access risk policy works as expected by testing it in [report-only mode](../conditional-access/howto-conditional-access-insights-reporting.md).
134
134
1. **Enable** the new Conditional Access risk policy. You can choose to have both policies running side-by-side to confirm the new policies are working as expected before turning off the Identity Protection risk policies.
135
135
1. Browse back to **Azure Active Directory** > **Security** > **Conditional Access**.
0 commit comments