1. Azure AD Security Defaults
So in this section of the course, we’re going to talk about a concept called conditional access. But, before we do that, we must acknowledge that some security defaults have been enabled in brand new tenants, and we will need to disable them in order to begin playing with our tenants’ security. So, if we’re in our tenant overview screen, we can scroll down into properties, and at the bottom, it says Manage security defaults. So we can see here that security defaults are enabled by default. So any tenant that was created after October 2019 is going to have security enabled by default. and that’s okay. So this is very similar to when we had Microsoft Internet Explorer and now Edge, where when you first log into this browser for the first time, you’re given certain security defaults.
As a result, a slew of pop-up messages appeared. Every time you try to navigate to something, you’re reminded that you’re now travelling in an unsecured area. So there are some pretty strict security defaults that have been automatically enforced by default. It is far preferable to have default security settings that must be disabled than to have no security as the default posture. So let’s have a look at what Microsoft considers to be security defaults. So one of them is that all users must eventually register for two-factor authentication. We saw this, I believe, earlier in this course when we went to login using a test user, and it asked us to register for MFA and told us we had 14 days to do that. Another default is that administrators must have multifactor authentication. Some of the old authentication protocols are being blocked. When necessary, some multifactor authentications are activated.
And any kind of privileged activity like access to the portal is not given by default. You have to grant that access. We can see more details on this 14-day policy for MFA on those specific roles, having MFA required, requiring stronger account verification for everyone, legacy protocols like POP 3, and so on. turning that stuff off unless you want to reenable it. So we can see that these are the defaults. Now that we’re in here, if we want to start playing with that, and this is where we get into conditional access, we’re going to have to turn off the defaults and we’re going to have to basically say we’re going to use our own conditional access settings. So I’m going to do that just so that we can continue to learn about conditional access.
2. Azure AD Conditional Access
So now that that’s done, we can talk about Azure conditional access. Now you can get conditional access. Again, it’s right on the home screen. We continue to scroll down. Conditional access is listed in the overview here. The concept of conditional access allows you to create rules that trigger a higher level of security. So let’s say that by default, people who log in with your username and password are granted access to your accountant. But you want to come up with some additional rules that say, “Well, under these conditions, we need to take a little extra precaution.” And what are those conditions? So let’s assume somebody is logging in from an account that hasn’t been used in a long time. Let’s say this account has been sitting in your directory for a year and a half. No one’s ever logged into it, and suddenly someone goes to log into it.
Some might consider that a risky action, that the account hasn’t been used for some reason and suddenly someone has discovered the password and logged into it. And so you can set up basically different rules based on the condition of the account, the condition of the access, and the users themselves. And maybe Azure has its own assessment of the risk. So let’s create a very simple policy. It’s called a policy. And in this case, we’re going to look for accounts that are sort of risky accounts.So I’m going to call these risky accounts, and we’re going to let Microsoft Azure determine what the risk of these accounts is. and I’ll tell you that in a second. So first, we’re going to have to select who this applies to. We could include all users. That’s kind of risky, because even you, as an administrator, are going to get caught up in this particular thing. And if you’ve created a particular role that blocks you out, then that might not be a great thing.
So let’s look for particular users. And in this case, I’m going to look for students. And we have a group called students. And so I’m going to select that group. So this policy, the risky accounts policy, only applies to students. Next up, we’re going to select the cloud applications or actions that it applies to. So there are two options here. We’re not going to talk about the preview mode. One is the user action, which could be the registration of an account, the joining of a device, or the logging into an app. So I’m going to say we’re going to include all app logins in this policy.
Now there’s a warning here that says this policy, a cloud app, is included in the Azure Portal. So perhaps you’d like to select apps from a list here. But in this particular case, these are the students, and I’m not giving them access to the portal. And so it’s okay if the portal is included. So I’ll disregard this message and say all cloud apps. In terms of the conditions, we have six conditions that we can choose from. The first is the user’s risk. So this is the user as it exists in the Azure AD database. And regardless of this particular attempt to sign in, Azure is going through your user accounts and classifying them as low, medium, or high risk. Now, low-level accounts may be accounts that don’t have very many privileges and are logged in every day.
There’s just no suspicious activity. And even if this account were compromised, there wouldn’t be a very high risk. Microsoft doesn’t actually define these specifically in terms of what makes an account high-risk or low-risk. However, you can imagine that a very powerful account, such as a global administrator, that is never logged into but is suddenly logged into, will be considered high risk. And so I’m going to say “configure yes,” and I’m going to pick the medium- and high-risk categories for this particular example. Now we also have sign-in risk. So this is independent of the user, as it exists in your users. This is the condition under which they are signing in. As a result, they could be logging in from a brand new device. They’re signing in outside your organization. They’re signing in from IP addresses known to be hacker addresses on the weekend from halfway around the world. So Microsoft makes a determination in terms of the sign-in risk. And so I could optionally configure additional conditions to address both the user risk and the sign-in risk. I’m not going to do that. For that, we can choose locations.
So are they in a trusted location? Are they outside of a trusted location? Are they in specific locations? We haven’t talked about defining the locations of your organization, but you can define them within Azure: your offices, your headquarters, and your satellite offices. And are they there, or are they somewhere else? The actual apps that they’re using—Adobe Cloud being one of them, SAP, all of the different apps And there’s this preview feature that won’t be on the exam. In this case, we only have the user risk covered. So what do we want to happen? So we can just block the access. So if they are our medium or high access student, maybe we just say, “You know what, you can’t log in right now,” and that’s an okay decision. We can also grant them access, but then require an additional piece of proof. And this could be multifactor authentication. This could be because they are logging in with a specific client application in order for their devices to join the network and achieve some level of intune compliance.
I’m just going to leave multifactor authentication. You can also have multiples of these and require all of them, or this could be session level controls rather than granting them access for that specific login. We can set this to an audit status, where it’s a report only, or we can turn it on so it becomes a policy. I’m going to say “create,” so we can go ahead and create additional policies. We can get our administrators back to requiring multifactor authentication required.We can get our teachers to have a certain policy. Perhaps the risky areas outside of our premises will have different policies. This is sort of your strategy: to create policies that make sense as opposed to the defaults that Microsoft is giving you.
3. Test Conditional Access
So once you’ve set your conditional access policies, you may want to make sure that they are working the way that you intended before you get too far.
So we just created these risky accounts for students, and let’s just make sure that students can log in under normal conditions without having to do the multi-factor authentication. The way you do this is called the “what if” button. It’s basically the way to test policies. So I’m going to speculate. Now, let’s start with testing a teacher. So we don’t want a teacher to be included in this app or in this policy. So I’m going to say this teacher is medium-risk. We don’t have a policy to classify the teacher as medium-risk. So I said, “What if?” And we see that it says no policies will apply. And when we see the policy that will not apply, it’s because this teacher does not appear under the users and groups, which is correct. This policy only applies to students. That is correct. So far, this is working the way we intended.
Let’s change this to one of the students. So now the student is logging in. Instead of having a medium risk, let’s say it’s a low-risk situation for the student. The student logs in every day from the same device; everything’s normal. Again, the policy does not apply exactly as expected, and there’s no reason why it won’t apply. But it just doesn’t fall under the risk that we’ve selected. Now, let’s just say the student is no longer low-risk. They’re using a new device. They are? Well, no, this is a user risk. So they are high-privileged users. They haven’t logged in in a while. There’s something about their account that makes it suspicious. Let’s try that. Now, the required multifactor authentication policy does apply because the user risk falls within our expectations according to our policy if we switch it to the sign-in risk. We did not follow the sign-in-risk policy, and again, no policies apply. So it’s probably smart to try all the different combinations and make sure that no one gets accidentally caught up in this. But this is how you would test if your conditional access policies are behaving the way that you expect.
4. Application Controls
Another feature of conditional access is the ability to effectively restrict application use based on the user and their role. This is, to me, one of the more annoying things that I’ve encountered working in different organizations. To demonstrate this, I’ve added Dropbox to the applications alongside Creative Cloud. Switching over to conditional access, I can create a new policy and call it “Block Dropbox.” So I worked at a place once where we weren’t allowed to use Dropbox. I think the security teams thought, “Well, we don’t want them to be taking client files and uploading them to the web,” and basically made it impossible to share files through Dropbox.
But there are tonnes of other services, right? So Dropbox is not the only file-sharing service. And so the people in the organisation just adapted to—I think we used file transfer—sending files. I don’t know if it was any safer, but there was a specific block against Dropbox. Well, you can use conditional access. You can say, “Let’s choose the Dropbox app.” And what we want to happen—let’s say it’s for all users—that’s fine. And what we want to happen is under session control, we want to say, “Use conditional access, app control.” And so this is basically going to affect the ability for your users who are using the application that’s connected to your tenant to either log that access, block access, or create their own policy.
Now, like I said, this is not blocking the browser from going to Dropbox.com. But if you are setting up an environment where people have to launch their apps from that app dashboard and they’re using integrated security with Dropbox, then you can certainly implement controls on what they do with Dropbox so that they can create their own custom policy that restricts what features and functions of Dropbox they have access to. I’m not a big fan of this, but I can see how security, in this day and age, might limit what people can do based on their level, based on who they are as users — perhaps students are restricted while teachers are allowed — and other such things. You’re basically restricting access to corporate applications, which are third-party applications, through this conditional access control.
