Identity Protection is a tool that allows organizations to accomplish three key tasks:
- Automate the detection and remediation of identity-based risks.
- Investigate risks using data in the portal.
- Export risk detection data to third-party utilities for further analysis.
- Breach replay:
- Password spray:
- Phishing:
Identity Protection identifies risks in the following classifications:
Investigate
Risky users
With the information provided by the risky users report, administrators can find:
- Which users are at risk, have had risk remediated, or have had risk dismissed?
- Details about detections
- History of all risky sign-ins
- Risk history
Administrators can then choose to take action on these events. Administrators can choose to:
- Reset the user password (Not Security Administrator)
- Confirm user compromise
- Dismiss user risk
- Block user from signing in (Not Security Administrator)
- Investigate further using Azure ATP
Risky sign-ins
The risky sign-ins report contains filterable data for up to the past 30 days (1 month).
With the information provided by the risky sign-ins report, administrators can find:
- Which sign-ins are classified as at risk, confirmed compromised, confirmed safe, dismissed, or remediated.
- Real-time and aggregate risk levels associated with sign-in attempts.
- Detection types triggered
- Conditional Access policies applied
- MFA details
- Device information
- Application information
- Location information
Administrators can then choose to take action on these events. Administrators can choose to:
- Confirm sign-in compromise
- Confirm sign-in safe
Best Practice – Self-Remediation with Risk Policy
By allowing users to self-remediate, with Azure Multi-Factor Authentication (MFA) and self-service password reset (SSPR) in the risk policies, they can unblock themselves when risk is detected. These detections are then considered closed. Users must have previously registered for Azure MFA and SSPR in order to use when risk is detected.
How to manually remediate risks and unblock users
There is an option to enable automated remediation using risk policies, such as MFA or Change password (SSPR – Self-Service Password Reset) to remediate risks. For some reasons, if MFA and Require Change Password options are not available for your organization, but Risk policy has been enabled to block user’s access. Here are some manual process :
1. User blocked by User Risk Policy
Unblocking user due to user risk can be done by either Admin reset password OR dismissing user OR exclude user from policy OR disabling policy (if causing issues for all users
step 1. Since user wont be able to log in o365 related system using blocked AD account , user has to call into helpdesk to request unblock. After unblock, helpdesk will execute a manually password reset and pass password to user by phone.
-When a user gets blocked for high risk (block being the control) they are blocked from that authentication flow. Access to all resources that are integrated with Azure AD will be affected.
Step 2. Security admin contacted by helpdesk will need to investigate and take further action, such as dismiss user risk, which confirms to Azure AD that the user is not compromised. User Risk will be reset to none. All risk on this user and past sign-in will be closed.
Step 3. User should be able to sign in now.
Step 3 option: Exclude user from policy or disable policy.
2. user blocked by Sign-in Risk Policy
Step1. User will not be able to sign in certain o365 apps.
-When a user gets blocked for high risk (block being the control) they are blocked from that authentication flow. Access to all resources that are intergrated with Azure AD will be affected.
Step2. User contact helpdesk by phone or email to report issue and get support
-Only if signing in from a trusted location/device does not allow the user to unblock themselves. Then help would be needed to investigate and exclude user from policy if needed. Investigate then either confirm sign in safe or confirm sign in compromised action should be taken which will feed back to Azure AD.
Step3 Security admin confirm sign-in safe, which will set Risk level to none and reverse its impact on the user risk.
Step4. User should be able to sign -in again .
Optional step 3, exclude user from sign-in policy or disable sign-in policy. How long should we wait once add user into exclusion policy or disabled policy?
Other recommendations: When you enable Identity Protection you should start with users in report only mode which allows the machine learning to learn the user behavior like sign in location. Report only mode does not actually enforce the user to perform MFA or block the user if that is the action you have set.
When you set policies, you can set a policy to block a user with High risk but if you have low or above selected or medium or above selected this is best to allow user the option to perform and pass MFA to show Azure AD the user is not risky then learn that behavior. If you have both policies enabled, one to block high risk and the other to challenge the user with MFA (or password change) for low and above (or med and above) then the block will be the one that enforces the user.