Configure Azure AD Identity Protection (AAD IP)
If you looked at the how to set up Azure MFA post, you’ll have seen a step on how to require users to register for Azure MFA using Azure AD Identity Protection (AAD IP). You may be thinking – what else can I do with AAD IP? Let’s find out!
First, access the AAD IP portal by heading to portal.azure.com and searching for Identity Protection. To use this feature, you (and the users you target) will need an Azure AD P2 license.
There are basically two components of AAD IP – protect and report. In the protection section, we have the User risk policy, the Sign-in risk policy, and the MFA registration policy. Let’s start with MFA registration, since we covered it in an earlier post.
When you click on MFA registration policy, you’ll be presented with 2 options. Who to assign the policy too, and whether or not to enforce the MFA registration control:
As a recommended practice, if you haven’t required all users to enroll in Azure MFA, start by selecting a smaller subsection of your users and creating communications for your helpdesk. But other than the assignments portion, for the MFA registration policy you should leave the Require Azure MFA registration checked, and set Enforce policy to On. Then your users will be forced to sign up for Azure MFA next time they log in (which is the only way to force MFA registration without using Conditional Access to restrict resources).
Great! So what can we do next? If you select Sign-in risk policy, we can configure whether users are required to use MFA for a risky sign in:
Here we can configure who is targeted, the level of risk that enforces the policy, and whether they are blocked or can use MFA remediate the risky log in.
I can answer your first question right away – No, you can’t configure which signals will cause a certain risk level. Meaning, I can’t say “users logging into Teams from a different country every 30 seconds is a high risk.” Microsoft uses their extensive logging & understanding of user log-ins to determine the risk levels, and it’s all behind the scenes.
I’d recommend allowing users to user self-remediate by using MFA, since it would verify that the sign-in is authentic.
Next – if you select the User risk policy, we can configure whether users are required to change their password based on a user risk:
Here we can configure who is targeted, the level of risk that enforces the policy, and whether users are blocked or require a password change.
Just like before, we’re unable to define the signals for our risk levels. Here, I’d recommend allowing users to change their password to remediate a high user risk. We’ll still be able to see reporting on the risks (including the cause) and how they were remediated, but users won’t have to call a helpdesk to unblock their account.
So that is all the protection policies we have for Azure AD Identity protection! The rest of the portal is used for reporting & notifications, so we can run through those as well.
If we select Risky users, we’ll see a report from the last 90 days on our risky users and which signals caused the risk:
If I click on Bill Smith, for example, I’ll be given some basic info, and the ability to reset their password, confirm they’re compromised, block the user, or even investigate further with Azure ATP. If we click on the risk detections, that’s where we can see the signals:
For Bill, we selected Users risk detections, which shows that on April 1 2020 he had two risky sign-ins due to unfamiliar sign-in properties, that ended up reporting a Medium risk.
If we click on the Risky sign-ins report, we can see a report of all risky sign-in for up to the last month:
Unfortunately (or fortunately?) I don’t have any to report, but the portal looks much the same as the risk detections that we saw on Bills unfamiliar sign-in.
The Risk detections report shows the aggregation of all risks in the last 90 days. So here we’ll see the 2 risks we saw from Bill’s account, as well as a risk from the Admin account:
Other than those reports, the only other option left to configure is notifications. So if we don’t expect someone to be constantly reviewing the AAD IP portal, we can at least be notified of the risks that are being captured:
That’s all! Azure AD Identity Protection is a fantastic quick way to improve the security posture for your organization, as it gives you a few simple policies that can really reduce the risk of attackers infiltrating your user’s sign-ins and passwords. And if you’re looking to also move your org to passwordless, the MFA registration policy is a great way to plan out your MFA enablement without restricting certain apps to require MFA.
Happy risk detecting! 🕵️♀️
