This post is part of the overall MS-500 Exam Study Guide. Links to each topic as they are posted can be found here.
This post will cover the following exam topics listed under the “Implement Azure AD Identity Protection” section:
- Implement user risk policy
- Implement sign-in risk policy
- Configure Identity Protection alerts
- Review and respond to risk events
Azure AD Identity Protection allows us to layer a level of intelligence over our authentication process. It enhances our Conditional Access policies by assigning risk levels to user credentials and sign-in attempts. For instance, we can assess a particular sign-in request and evaluate the risk associated based on factors such as frequency, client device or geographical location. This risk assignment can then trigger different behaviour during the sign-in process. Microsoft define the criteria for risk detection as:
|Risk detection type||Description|
|Atypical travel||Sign in from an atypical location based on the user’s recent sign-ins.|
|Anonymous IP address||Sign in from an anonymous IP address (for example: Tor browser, anonymizer VPNs).|
|Unfamiliar sign-in properties||Sign in with properties we’ve not seen recently for the given user.|
|Malware linked IP address||Sign in from a malware linked IP address.|
|Leaked Credentials||Indicates that the user’s valid credentials have been leaked.|
|Password spray||Indicates that multiple usernames are being attacked using common passwords in a unified, brute-force manner.|
|Azure AD threat intelligence||Microsoft’s internal and external threat intelligence sources have identified a known attack pattern.|
Azure AD Identity Protection can be accessed from the Azure AD “Security” section. Below is a quick run down of the options available on the Identity Protection page:
- Overview – On this page you will see a breakdown of current risk detections along with some other information about your Identity Protection configuration
- User risk policy – On this page you can configure your User risk policy
- Sign-in risk policy – On this page you can configure your Sign-in risk policy
- MFA registration policy – On this page you can configure your MFA registration policy to ensure users have MFA registered in your environment
- Risky users – This report lists detected risky users
- Risky sign-ins – This report lists detected risky sign-ins
- Risk detections – This report contains all risk events
- Users at risk detected alerts – This section can be used to specify who receive notifications when a user account is detected as at risk
- Weekly digest – This section can be used to specify who receives a weekly summary report from Identity Protection
- Troubleshooting + Support options
We can implement global User and Sign-in risk policies to define behaviour at different risk levels, the risk associated can be used as a factor in our Conditional Access policies, where they are listed under conditions:
Implement User Risk Policy
We configure a User Risk Policy from the Identity Protection section of the Azure AD portal. Here, we select the users to include in our policy (this should be limited to licensed users at a minimum), the risk level and the control. In the below example, we have specified that is user risk is medium or above, we will let them sign-in but enforce a password change. This will not bypass regular controls such as Conditional Access, MFA etc. but when a user account credentials are expected to be compromised, we are triggering the user to change their password.
This policy can also be recreated in Conditional Access however the “Require Password Change” control is currently in preview.
Implement Sign-in Risk Policy
Similar to User Risk Policies, Sign-in Risk Policies can be configured from the Identity Protection page. The configuration is the exact same where we select our users, risk levels and controls. Below we are blocking any sign-ins detected as high risk:
Note that with Sign-in Risk Policies, we have the option for MFA instead of changing password. This is because during a risky sign-in attempt, it wouldn’t make sense to reset the users password as the sign-in itself may be malicious. As before, this functionality can also be recreated in Conditional Access to add further flexibility.
Review and Respond to Risk Events
When a risk event is picked up by Identity Protection, it get’s logged into the reports section of the portal. These events can then be managed by an admin to ensure they are appropriately remediated. Let’s look at some risk events now.
First, we’ll look at the Risky Users report. These events are linked to potential compromised credentials and the associated risk score is tracked against each entry.
We can look at each entry and use the information provided to track exactly when and why the user account was marked as at risk. For example, in the below entry we can see that our users risk score was increased to low due to “unfamiliar sign-in properties”. This tracks against unfamiliar IP Addresses, client devices etc. and differences in how the user is signing in. The risk score of low signalled that the user account has a small chance of being compromised.
We can see then that the risk was upgraded to high, this was due to a sign-in attempt from an anonymous IP address. I simulated this sign-in from a VPN so it would look suspicious and my sign-in was blocked by the sign-in risk policy but the user risk was still logged. This is great as we are not only protected, but we are also given the information to follow up.
Once we confirm with the user, we have a few options:
- Reset Password – If we’re not sure, it’s always a safe option to reset the users password
- Confirm User Compromised – This will manually set the user account to high risk, triggering our Identity Protection policies
- Dismiss User Risk – If the user confirms the actions were legitimate, we can dismiss the risk
- Block User – If we can’t get hold of the use or are unsure if the account was compromised, we can block the account until we have the right information
- Investigate with ATP – This will link us to Microsoft Cloud App Security where we can perform a deep dive into the users actions (We will be looking at MCAS in a future post)
Once we have mitigated the risk, we can dismiss the entry. We saw above that the user risk was increased due to a sign-in from an anonymous address. Checking the Risky Sign-ins report shows us the details of this sign in:
Looking at the details of the sign-in, we can see that the attempt was blocked. We can then go ahead and confirm it was a bad sign-in or dismiss the risk entry by confirming safe once we verify with the user.
Users who are travelling (particularly by plane) or who are using VPNs to access services can sometimes trigger false positives, the more consistent their behaviour is, the more identity protection will learn and reduce false positives.
If you are licensed for Identity Protection, there isn’t much of a reason not to use it. It provides some really cool functionality to protect our users and sign-ins. With the exception of the “reset password” option being in preview, we can also replicate the Identity Protection policies in Conditional Access which may be a good solution when we need that extra layer of flexibility around our policies.
For more information on Identity Protection, check out the below Microsoft articles: