1. AD Identity Protection
So in this section of the course, we’re going to talk about Microsoft Azure and identity protection. Now, identity protection does have a lot in common with the conditional access feature that we just saw. And we’re going to see a lot of the same terms and concepts when it comes to signin risk versus user risk and how MFA gets configured. So let’s go down into identity protection. That’s going to be found under the security settings. And on the left here, under “Protect,” we see “conditional access,” which we just talked about, and the second item is “identity protection.” Now the overview screen here is sort of a general report on the identity protection policy of your organization.
I’ve got a security score of 29.9%. We don’t discuss security score in this course, but it is a general measure of how well you’re doing in terms of security. Identity protection covers three main policies. These are your user risk policy, sign-in risk policy, and your MFA registration policy. Now, these policies then generate these reports, which we see on the overview screen, and reports that then go into the reports section. So if we look at the user risk policy as a start, we can see first of all that there’s only one user risk policy. It’s not like you’re going to do something like “conditional access,” where you create multiple policies. So in this policy, we decide who this userrisk policy is meant to monitor, what the userrisk needs to be, and then what happens. So it’s a very simplistic conditional access rule. And again, since there’s only one of them, you have to sort of make it as broad as possible so we can make this user risk policy. In this case, I’ve got it set to the teachers, as I do, and let’s set this to say all users.
So we are concerned about all users. And in terms of user risk, remember that Microsoft Azure uses its best artificial intelligence machine to identify the risk level of a user as it exists in your Azure ad. I’m going to set this as high-risk users, and what are we going to happen to a user who is identified under the user risk policy as being high-risk? So, when they try to log in, we could grant them access while also forcing them to change their password. Usually that means sending a link to their email that they have to use to change their password.
Or we can just block their access. See how simple this is in comparison to the settings and the options that we have under conditional access? I’ll leave that as a barrier. So in this policy, anyone who Microsoft has identified as being at high risk is not going to be able to log in to their account using Azure AD. Now, similarly, we have the sign-in risk. So when they sign in, they run the risk that the moment they sign in, the location they’re in, the device they’re using, or some other suspicious element of the activity of signing in has nothing to do with who they are as a specific user. So in this case, this policy affects all users. I’m just going to let that happen, and it’ll be medium or higher in this case. Let’s set that to “high.” And so we’re going to basically block access to anyone who’s trying to sign in but is in a very high-risk situation. There.
Again the Microsoft Azure artificial intelligence has determinedthat they are perhaps not the person thatthey supposed to be trying to sign in. The force policy is on the last tab. Here is the MFA registration policy. So we had the option earlier of a per-user policy saying these users must have MFA and these users must not. When we had our default security set up, all users were required to sign up for MFA within 14 days. So the MFA registration policy is currently off. However, we could essentially impose MFA on all users and require them to register for it. That’s identity protection. It’s pretty straightforward. Again, you can monitor these behaviors. We can set up alerts and say that this is the report of which users in your database are risky, which sign-ins that have happened in the last seven days have been risky sign-ins, etc. So it’s a very simplistic way of viewing the user risk, the signing risk, and how you respond to that risk versus the MFA registration policy of your whole organization.
