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/identity-protection/concept-identity-protection-policies.md
+2-5Lines changed: 2 additions & 5 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: conceptual
9
-
ms.date: 10/04/2022
9
+
ms.date: 11/11/2022
10
10
11
11
ms.author: joflore
12
12
author: MicrosoftGuyJFlo
@@ -51,13 +51,10 @@ If risks are detected on a sign-in, users can perform the required access contro
51
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
52
53
53
- Block access
54
-
- Allow access but require a secure password change using [Azure AD self-service password reset](../authentication/howto-sspr-deployment.md).
54
+
- Allow access but require a secure password change.
55
55
56
56
A secure password change will remediate the user risk and close the risky user event to prevent unnecessary noise for administrators.
57
57
58
-
> [!NOTE]
59
-
> Users must have previously registered for self-service password reset before triggering the user risk policy.
60
-
61
58
## Identity Protection policies
62
59
63
60
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:
Copy file name to clipboardExpand all lines: articles/active-directory/identity-protection/concept-identity-protection-user-experience.md
+3-3Lines changed: 3 additions & 3 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: conceptual
9
-
ms.date: 01/21/2022
9
+
ms.date: 11/11/2022
10
10
11
11
ms.author: joflore
12
12
author: MicrosoftGuyJFlo
@@ -42,7 +42,7 @@ When an administrator has configured a policy for sign-in risks, affected users
42
42
43
43
### Risky sign-in self-remediation
44
44
45
-
1. The user is informed that something unusual was detected about their sign-in. This could be something like, such as signing in from a new location, device, or app.
45
+
1. The user is informed that something unusual was detected about their sign-in. This behavior could be something like, such as signing in from a new location, device, or app.
@@ -84,7 +84,7 @@ If your organization has users who are delegated access to another tenant and th
84
84
1. An organization has a managed service provider (MSP) or cloud solution provider (CSP) who takes care of configuring their cloud environment.
85
85
1. One of the MSPs technicians credentials are leaked and triggers high risk. That technician is blocked from signing in to other tenants.
86
86
1. The technician can self-remediate and sign in if the home tenant has enabled the appropriate policies [requiring password change for high risk users](../conditional-access/howto-conditional-access-policy-risk-user.md) or [MFA for risky users](../conditional-access/howto-conditional-access-policy-risk.md).
87
-
1. If the home tenant hasn't enabled self-remediation policies, an administrator in the technician's home tenant will have to [remediate the risk](howto-identity-protection-remediate-unblock.md#remediation).
87
+
1. If the home tenant hasn't enabled self-remediation policies, an administrator in the technician's home tenant will have to [remediate the risk](howto-identity-protection-remediate-unblock.md#risk-remediation).
Copy file name to clipboardExpand all lines: articles/active-directory/identity-protection/howto-identity-protection-investigate-risk.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
@@ -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: 01/24/2022
9
+
ms.date: 11/11/2022
10
10
11
11
ms.author: joflore
12
12
author: MicrosoftGuyJFlo
@@ -100,7 +100,7 @@ Administrators can then choose to return to the user's risk or sign-ins report t
100
100
Organizations may use the following frameworks to begin their investigation into any suspicious activity. Investigations may require having a conversation with the user in question, review of the [sign-in logs](../reports-monitoring/concept-sign-ins.md), or review of the [audit logs](../reports-monitoring/concept-audit-logs.md) to name a few.
101
101
102
102
1. Check the logs and validate whether the suspicious activity is normal for the given user.
103
-
1. Look at the user’s past activities including at least the following properties to see if they are normal for the given user.
103
+
1. Look at the user’s past activities including at least the following properties to see if they're normal for the given user.
104
104
1. Application
105
105
1. Device - Is the device registered or compliant?
106
106
1. Location - Is the user traveling to a different location or accessing devices from multiple locations?
After completing your [investigation](howto-identity-protection-investigate-risk.md), you need to take action to remediate the risk or unblock users. Organizations can enable automated remediation using their [risk policies](howto-identity-protection-configure-risk-policies.md). Organizations should try to close all risk detections that they're presented in a time period your organization is comfortable with. Microsoft recommends closing events quickly, because time matters when working with risk.
20
+
After completing your [investigation](howto-identity-protection-investigate-risk.md), you need to take action to remediate the risky users or unblock them. Organizations can enable automated remediation by setting up [risk-based policies](howto-identity-protection-configure-risk-policies.md). Organizations should try to investigate and remediate all risky users in a time period that your organization is comfortable with. Microsoft recommends acting quickly, because time matters when working with risks.
21
21
22
-
## Remediation
22
+
## Risk remediation
23
23
24
-
All active risk detections contribute to the calculation of a value called user risk level. The user risk level is an indicator (low, medium, high) for the probability that an account has been compromised. As an administrator, you want to get all risk detections closed, so that the affected users are no longer at risk.
24
+
All active risk detections contribute to the calculation of the user's risk level. The user risk level is an indicator (low, medium, high) of the probability that the user's account has been compromised. As an administrator, after thorough investigation on the risky users and the corresponding risky sign-ins and detections, you want to remediate the risky users so that they're no longer at risk and won't be blocked.
25
25
26
-
Some risks detections may be marked by Identity Protection as "Closed (system)" because the events were no longer determined to be risky.
26
+
Some risk detections and the corresponding risky sign-ins may be marked by Identity Protection as dismissed with risk state "Dismissed" and risk detail "Azure AD Identity Protection assessed sign-in safe" because those events were no longer determined to be risky.
27
27
28
28
Administrators have the following options to remediate:
29
-
30
-
- Self-remediation with risk policy
29
+
- Set up [risk-based policies](howto-identity-protection-configure-risk-policies.md) to allow users to self-remediate their risks
31
30
- Manual password reset
32
31
- Dismiss user risk
33
-
- Close individual risk detections manually
34
32
35
-
### Remediation framework
33
+
### Self-remediation with risk-based policy
36
34
37
-
1. If the account is confirmed compromised:
38
-
1. Select the event or user in the **Risky sign-ins** or **Risky users** reports and choose "Confirm compromised".
39
-
1. If a risk policy or a Conditional Access policy wasn't triggered at part of the risk detection, and the risk wasn't [self-remediated](#self-remediation-with-risk-policy), then:
40
-
1.[Request a password reset](#manual-password-reset).
41
-
1. Block the user if you suspect the attacker can reset the password or do multi-factor authentication for the user.
42
-
1. Revoke refresh tokens.
43
-
1.[Disable any devices](../devices/device-management-azure-portal.md) considered compromised.
44
-
1. If using [continuous access evaluation](../conditional-access/concept-continuous-access-evaluation.md), revoke all access tokens.
35
+
You can allow users to self-remediate their sign-in risks and user risks by setting up [risk-based policies](howto-identity-protection-configure-risk-policies.md). If users pass the required access control, such as Azure AD multifactor authentication (MFA) or secure password change, then their risks are automatically remediated. The corresponding risk detections, risky sign-ins, and risky users will be reported with the risk state "Remediated" instead of "At risk".
45
36
46
-
For more information about what happens when confirming compromise, see the section [How should I give risk feedback and what happens under the hood?](howto-identity-protection-risk-feedback.md#how-should-i-give-risk-feedback-and-what-happens-under-the-hood).
37
+
Here are the prerequisites on users before risk-based policies can be applied to them to allow self-remediation of risks:
38
+
- To perform MFA to self-remediate a sign-in risk:
39
+
- The user must have registered for Azure AD MFA.
40
+
- To perform secure password change to self-remediate a user risk:
41
+
- The user must have registered for Azure AD MFA.
42
+
- For hybrid users that are synced from on-premises to cloud, password writeback must have been enabled on them.
43
+
44
+
If a risk-based policy is applied to a user during sign-in before the above prerequisites are met, then the user will be blocked because they aren't able to perform the required access control, and admin intervention will be required to unblock the user.
47
45
48
-
### Self-remediation with risk policy
46
+
Risk-based policies are configured based on risk levels and will only apply if the risk level of the sign-in or user matches the configured level. Some detections may not raise risk to the level where the policy will apply, and administrators will need to handle those risky users manually. Administrators may determine that extra measures are necessary like [blocking access from locations](../conditional-access/howto-conditional-access-policy-location.md) or lowering the acceptable risk in their policies.
49
47
50
-
If you allow users to self-remediate, with Azure AD multifactor authentication (MFA) and self-service password reset (SSPR) in your risk policies, they can unblock themselves when risk is detected. These detections are then considered closed. Users must have previously registered for Azure AD MFA and SSPR for use when risk is detected.
48
+
### Self-remediation with self-service password reset
51
49
52
-
Some detections may not raise risk to the level where a user self-remediation would be required but administrators should still evaluate these detections. Administrators may determine that extra measures are necessary like [blocking access from locations](../conditional-access/howto-conditional-access-policy-location.md) or lowering the acceptable risk in their policies.
50
+
If a user has registered for self-service password reset (SSPR), then they can also remediate their own user risk by performing a self-service password reset.
53
51
54
52
### Manual password reset
55
53
56
-
If requiring a password reset using a user risk policy isn't an option, administrators can close all risk detections for a user with a manual password reset.
54
+
If requiring a password reset using a user risk policy isn't an option, administrators can remediate a risky user by requiring a password reset.
57
55
58
56
Administrators are given two options when resetting a password for their users:
59
57
@@ -63,24 +61,37 @@ Administrators are given two options when resetting a password for their users:
63
61
64
62
### Dismiss user risk
65
63
66
-
If a password reset isn't an option for you, you can choose to dismiss user risk detections.
64
+
If after investigation and confirming that the user account isn't at risk of being compromised, then you can choose to dismiss the risky user.
67
65
68
-
When you select **Dismiss user risk**, all events are closed and the affected user is no longer at risk. However, because this method doesn't have an impact on the existing password, it doesn't bring the related identity back into a safe state.
66
+
To **Dismiss user risk**, search for and select **Azure AD Risky users** in the Azure portal or the Entra portal, select the affected user, and select **Dismiss user(s) risk**.
69
67
70
-
To **Dismiss user risk**, search for and select **Azure AD Risky users**, select the affected user, and select **Dismiss user(s) risk**.
68
+
When you select **Dismiss user risk**, the user will no longer be at risk, and all the risky sign-ins of this user and corresponding risk detections will be dismissed as well.
71
69
72
-
### Close individual risk detections manually
70
+
Because this method doesn't have an impact on the user's existing password, it doesn't bring their identity back into a safe state.
73
71
74
-
You can close individual risk detections manually. By closing risk detections manually, you can lower the user risk level. Typically, risk detections are closed manually in response to a related investigation. For example, when talking to a user reveals that an active risk detection isn't required anymore.
75
-
76
-
When closing risk detections manually, you can choose to take any of the following actions to change the status of a risk detection:
72
+
#### Risk state and detail based on dismissal of risk
77
73
78
-
- Confirm user compromised
79
-
- Dismiss user risk
80
-
- Confirm sign-in safe
81
-
- Confirm sign-in compromised
74
+
- Risky user:
75
+
- Risk state: "At risk" -> "Dismissed"
76
+
- Risk detail (the risk remediation detail): "-" -> "Admin dismissed all risk for user"
77
+
- All the risky sign-ins of this user and the corresponding risk detections:
78
+
- Risk state: "At risk" -> "Dismissed"
79
+
- Risk detail (the risk remediation detail): "-" -> "Admin dismissed all risk for user"
82
80
83
-
#### Deleted users
81
+
### Confirm a user to be compromised
82
+
83
+
If after investigation, an account is confirmed compromised:
84
+
1. Select the event or user in the **Risky sign-ins** or **Risky users** reports and choose "Confirm compromised".
85
+
2. If a risk-based policy wasn't triggered, and the risk wasn't [self-remediated](#self-remediation-with-risk-based-policy), then do one or more of the followings:
86
+
1.[Request a password reset](#manual-password-reset).
87
+
1. Block the user if you suspect the attacker can reset the password or do multi-factor authentication for the user.
88
+
1. Revoke refresh tokens.
89
+
1.[Disable any devices](../devices/device-management-azure-portal.md) that are considered compromised.
90
+
1. If using [continuous access evaluation](../conditional-access/concept-continuous-access-evaluation.md), revoke all access tokens.
91
+
92
+
For more information about what happens when confirming compromise, see the section [How should I give risk feedback and what happens under the hood?](howto-identity-protection-risk-feedback.md#how-should-i-give-risk-feedback-and-what-happens-under-the-hood).
93
+
94
+
### Deleted users
84
95
85
96
It isn't possible for administrators to dismiss risk for users who have been deleted from the directory. To remove deleted users, open a Microsoft support case.
86
97
@@ -92,9 +103,9 @@ An administrator may choose to block a sign-in based on their risk policy or inv
92
103
93
104
To unblock an account blocked because of user risk, administrators have the following options:
94
105
95
-
1.**Reset password** - You can reset the user's password.
96
-
1.**Dismiss user risk** - The user risk policy blocks a user if the configured user risk level for blocking access has been reached. You can reduce a user's risk level by dismissing user risk or manually closing reported risk detections.
97
-
1.**Exclude the user from policy** - If you think that the current configuration of your sign-in policy is causing issues for specific users, you can exclude the users from it. For more information, see the section Exclusions in the article [How To: Configure and enable risk policies](howto-identity-protection-configure-risk-policies.md#exclusions).
106
+
1.**Reset password** - You can reset the user's password. If a user has been compromised or is at risk of being compromised, the user's password should be reset to protect their account and your organization.
107
+
1.**Dismiss user risk** - The user risk policy blocks a user if the configured user risk level for blocking access has been reached. If after investigation you're confident that the user isn't at risk of being compromised, and it's safe to allow their access, then you can reduce a user's risk level by dismissing their user risk.
108
+
1.**Exclude the user from policy** - If you think that the current configuration of your sign-in policy is causing issues for specific users, and it's safe to grant access to these users without applying this policy to them, then you can exclude them from this policy. For more information, see the section Exclusions in the article [How To: Configure and enable risk policies](howto-identity-protection-configure-risk-policies.md#exclusions).
98
109
1.**Disable policy** - If you think that your policy configuration is causing issues for all your users, you can disable the policy. For more information, see the article [How To: Configure and enable risk policies](howto-identity-protection-configure-risk-policies.md).
0 commit comments