Conditional Access and Compliance Policies

1. Introduction to Conditional Access Policies

So what are conditional access policies? Well, Conditional Access Policies is a feature that Microsoft has put into their Microsoft 365 and Azure environments to allow us to detect the different ways that users are logging on. Not just different ways they're logging on, but where they're logging on from, when they're logging on, what apps they're using to log on, and things that they're trying to get access to. So one of the things that Microsoft has put together here is something called signals. Signals are going to help us detect the different ways that people are going about accessing their applications and accessing their data—where, when, and how they're doing this. And then, of course, from there, Microsoft365 has got to make a decision. The decision is going to be whether or not to allow somebody to gain access to require some more assurance, allow limited access, or flat out just block them. There's also what's known as remediation, which is a way for them to prove a little bit more information and then get access to what it is that they need.

From there we have enforcement, which of course plays upon the concept of blocking whether or not we're going to stop the user from accessing what it is they're trying to access or send an alert to an administrator or warn the user or require more authentication information. So the dilemma of modern administrators, the issue that we have as admins today, is something that's very different than it was 2030 years ago. Well, definitely years ago, but even 20 years ago we mostly had laptops to deal with and desktops in the mobile world. Was I correct about laptops? We didn't have any smartphones or tablets or any of these things that we had to worry about. We had desktop computers, we had laptops, and a lot of times, even then, laptops were issued out to our employees. They were company-issued laptops. They weren't personal laptops that were allowed in the environment. Well, here's that acronym that you've been hearing probably now if you've been in the industry for a while: BYOD, or bring your own device.

So now we have a big scenario where companies want employees to be able to bring their own devices to the office and access resources and all of that. And then the other scary thing is that the device users are bringing to the office is theirs, then leaves the office and goes anywhere to any network, and there's no telling what network that device could be accessing. It could be one minute at their house, the next at a Starbucks, the next at a hotel, the next at an airport, and there's all kinds of stuff going on in those networks that we have no control over. We also have no control over what the user is looking at doing on their devices when they're in that environment. And of course, then the scary thing is that we have to allow that device to come to our office and access our resources, or even worse, they could be on one of those networks trying to access resources in our environment that could be osprey. It can also, of course, be out in the cloud, which is sort of what this is focused on.

But we have to have a way for administrators to control all of that. Users are basically expecting to be able to work from anywhere. This is one of the big new generational things that has sort of changed over the last 20 years: users want to be able to work anytime they want, anywhere they want, using any application they want. So you've got location to worry about, you've got the type of device to worry about, you’ve got applications to worry about. Then there's the possibility that whatever network they're connecting to is putting their device in grave danger. So there's got to be a system that can quickly detect it. Obviously, we can't have a person that sits as a gatekeeper that just approves every connection coming in, at least not normally. That's something that's not going to be doable in most environments. So would it be great if we had a system that could do that for us? Well, that's exactly where this is going. We have that.

That is exactly what conditional access policies are going to do for us. It's going to make sure that a set of requirements are met and then make a decision based upon that. So you log on from a location, from a device, from an application, whatever it may be. If the device is not at risk, or if it is at risk, decisions have to be made. It's going to verify every access attempt and then from there it can make a decision to allow somebody to access block them, or if it is going to allow them, it can also add an additional restriction in there, such as MFA multi-factor Authentication. Only then does the user actually get access to the data that they're trying to get access to. So exactly how does all this work? Well, signals and outcome essentially are where this is going. And the signals and the outcome being a decision that has to be made. What are the different signals? So a signal involves a rule that gets put in place that it's being looked at when somebody logs on.

One of those being user or group membership. Depending upon the user or the group that the user is a member of, it can signal this conditional access to make a decision. Another option for signaling is IP location. This could be an IP address, which is an approved IPad dress based on an IP address range that we've set up. This could be a restricted address or an array of restricted addresses that we've configured. So we can do this based upon IP location. Another option is devices. The type of device they're using, whether it's an iPhone or an Android phone or a Microsoft Surface tablet or even just a regular Windows desktop computer, falls into this category, and we can require things like a certain version of the operating system to be in place. The device can't be at risk at this time. Microsoft has this insanely large team of security personnel that are monitoring risk for different devices. So, today, the iPhone 7 may be considered a risk; we could flag it as a high risk, and it could then be blocked until a patch or whatever is released.

Cloud app security is another option for Signaling. So that involves different cloud apps that users are using in the cloud. This gets into things like Dropbox and things like that that users might be using to want to access data. We can have it make a decision to either block it or allow it. And then just plain old applications. You can have rules for applications that users are using. Perhaps. Maybe I want to allow my employees to check their email, but I want them to use the official Outlook app. I don't want them to use an app like Easy Mail or something like that. I could have a restriction in place, a signal in place that's going to look for that, and then a decision that's going to block it. OK, and then you have real time and calculated risk detection. And so with that, that gets into based upon the different things we saw there earlier with signals, IP location, and the type of device the user is using. If Microsoft has flagged a certain location as risk that an IP address is coming from another location, it would be like an anonymous IP address. If somebody's using something like Tor or something along those lines to mask IP addressing, then real-time calculated risk detection can throw a signal and a decision can be made to, of course, either allow it or block it based upon that. Now the decisions, as you can see, are two decisions: block or grant. But with grants, you're going to notice that a decision can be made to further some checking. One being requires MFA, or multi-factor authentication.

Okay, so I could throw that up there. Maybe somebody's logging on in an IP location that's outside one of our ranges. Maybe they could be in a different country. I could be on business in Australia and the company could call me and say, hey, we need you to do something in the cloud. So, at that point, I could remote, I could connect to the cloud, and an IPad dress signal would be thrown, right? And so it may require me to use MFA. Then a compliant device that plays upon the device signal Perhaps a certain type of device, a certain phone, certain tablet, certain desktop, it's going to require a compliance check and then a hybrid Azure Ad Join.

To get access to certain resources, you might have to have a hybrid environment with Azure Ad Connect. I've talked about that before, where we setup a server on premise in Ad DS Active Directory Domain Services and we are synchronizing things between the on premise world and the cloud. We might require the account to be an Azure Ad joint account. And then lastly, you might have to just flat out have an approved app. So as I was saying earlier about wanting to check your email, maybe you have to have the official Outlook app. You can't have like, easy mail or something that would require an approved app. So those are your signals and your decisions. And this is all part of setting up conditional access policies to control who gets access when, where, and how they get access.

2. Demonstration of controlling access using Conditional Access Policies

We're now going to take a look at conditional access policies in the Azure Portal. So here we are on Portal Azure.com. I'm going to click on the menu option here. And then we're going to go to Azure Active Directory. From there, scroll down and click on Security Blade, and you'll see conditional access right here. So I'm going to go ahead and click on that. And right out of the gate, you're going to see that there are some baseline policies. But you're also going to see that there's a note saying that the baseline protection policies are considered legacy now. So this is something they sort of discarded. They built a few policies that can be turned on.

But what they're saying now is that you should go through the process of enabling something called security defaults, or you can configure your access policies directly, which is what we're going to do here. all right? So I'm going to go ahead and click on New Policy. Then you would give it a name. So, for example, if I'm going to block Android devices for cloud apps, I'll give it a name, all right? And then from there we would do an assignment. So you have users and groups here. So we would select the users and groups that we would want to turn this on for. Maybe I want to turn it on for all users. Or I could do both. I can choose guest external users. I can have specific directory roles that I want to allow block, as you can see here. And then users and groups directly. If I want specific users and groups, all right, click that and I can get my list of users and groups that I usually see whenever I want to add my users to an access control of some sort.

So I'm going to go all users. But I also wanted to point out that you can have exclusions as well. Now, remember that when it comes to inclusions and exclusions, inclusions are groups that you want to add to something. An exclusion is something you want to take away. Right now, exclusions will always override inclusion. So, for example, if I had a group called, let’s say, receptionists, OK, and then I had another group called Temps, and maybe we've got a group called Receptionist, that's a large group of people. Maybe there's a user named Jane Doe who's a member of the receptionist group, but Jane Doe is also a member of Temps. So if I added Receptionist here and then under inclusions or include and then I added Temps under exclude, then Jane Doe, if she was a member of both groups, would not be allowed access to whatever it is or would not be included in this. In other words, again, excluding groups will override include groups if you go the route of using groups. So I just wanted to point that out. I'm going to click on "all users here" and "Done." All right. And then we've got our cloud app, Action. So I'd said Android cloud apps. So at that point, I've chosen cloud apps. I'm going to say all cloud apps. But you could click select and you could choose what services. Microsoft has a lot of services here you could choose from, including Office 365,that would be a part of that. But I'm going to choose all the cloud apps. In my example here, we're going to click Done.

Okay, then you've got conditions. So here are some of these different signals that I was talking about, the different conditions that are looked at. We have a sign-in risk, so we could say yes. And if the sign-in risk is high, meaning it is considered a high risk based upon Microsoft's findings, it could be a device, it could be location. This is what is going to be defined as high, medium, low, or no risk at all. We haven't really gone over risk thoroughly yet, but again, as I said previously, Microsoft has a very large, massive team of people that are monitoring different types of risk involving devices and user locations. All of that stuff. And another thing that can flag something as high risk is based on travel, meaning somebody's logged on in Atlanta, Georgia, and then five minutes later they've logged on over in China. Okay, so that flags the system as a high risk. So maybe I don't want to take a high risk, maybe a medium risk, whatever. I'm going to choose "high" in this case. And then I'm going to hit select. Then we have device platforms.

This is where I would choose the platform that I want. So I'm going to go with Android. Since I did name this block Android Devices for Cloud apps, we're going to hit Done. And then I can choose a location. Now you have to create some locations. You can create some locations back over on the previous screen before you get here. There's a location area that you can define what your locations are. So I could say yes to that and I could use any location, trusted locations or selected locations that I've created locations for. Again, I haven't done any trusted locations other than this default one here, MFA trusted IPS. I'm not going to put a location in this policy. So I'm going to click "done." Then I've got client apps. So these are some of the different apps. Notice it's in preview. Anytime you see that word "preview," that means Microsoft has not completely finalized it yet. The feature hasn't been finalized yet. So at that point, I can click yes, and I can configure browser apps, mobile apps,and desktop modern authentication clients, and exchange Active Sync.

If I want, it gets back into good old Exchange synchronizing email and all that if I want. I’m not going to do client apps in this case. And then you have the device state. Okay, so the state of the device. You have to define what is considered a device in another area of this. So depending on the state of the device that gets into conditional access policies or compliance policies, sorry, and what your device state is currently, we haven't gone over compliance policies. But I'm going to go ahead now. I've defined the things that I want. I'm going to click done, and then from there I can choose the access control. So access control if I want, I can say block. Of course, that's exactly what I want this policy to do. However, as I've said previously, you can also, if you were to grant access, you could require some of these dependencies here. So we talked about multi-factor authentication. You can require a certain device to be compliant. Again, that gets into compliance policies like which version of the phone operating system or tablet operating system or desktop operating system you have. Or the required hybrid, Azure adjoin. You can require an approved app to be on a list here. Require app protection policies, which is another thing that's actually set in Intune. We're going to be talking about it in a later video. So we'll clarify some of this stuff. But I'm going to click on Block because that's what I want to do in this case. I'm going to hit select and then I'm going to go to session. I'm not going to do anything here, but I'll explain the idea here. So, with concession or session, you are going to be configuring conditional access app control. If you want, you can turn that on. If you turn that on, it's going to do monitor only, which means it's just going to create an alert, create a logged event for you that you can view when somebody's connecting in. You can say "block downloads." As you can see, these two are previews, but Block Downloads is going to make it so the user can use the app but they can't download anything through the app.

OK, if you want. And then, of course, you've also got an adaptable policy here that you can click on. It will give you a few other small options there that you can use. You've got a sign-in frequency. Now sign in frequency is going to default to 90, which means 90 every time somebody signs in 90 times. It's going to require things like MFA. You can set the frequency here though, based on hours or days. The default is days. So every 90 days it's going to try to force conditional access policies whether you set this or not. By default, it's going to force them to use MFA if you've got MFA enabled. So you can customize that here by setting this to whatever you want. and then a persistent browser session. This is just going to require them to stay persistent. If this is a web-based thing they're accessing through a web-based app, it's going to mean that you have to have persistent packet traffic basically flowing back and forth between the client side and the cloud side.

Okay, so those are your different options under session. I'm not going to set anything under session, so I'm going to go ahead and go down here and we're going to go with enforce policy. I can say "report only," which means it's not actually going to enforce anything. It's just essentially going to report and log what's going on. I can turn this on, which means it will do that. Notice you get this little warning message that says, "Don't lock yourself out." We recommend applying the policy to a small set of users. In other words, not everybody. Okay, now in my case, it isn't everybody. I said just Android users, right? Plus you can also add exclusions if you want, and then you can also say, okay, well, I understand, and all of that if I want.

So let's see, select and then at that point, I'm going to click to create. So, in a lab scenario, possibly on the test, they would tell me which options they want me to choose, and I would simply go through and choose those. In this case, I just wanted to block Android devices for cloud apps. Right. By the way, second, I was talking about locations. This is where you can go through the process of creating locations that will be available when you create these policies. This is one of many places (actually wherever Microsoft lets you create what are called "named locations," which will involve things like Prangs and all that good stuff. So that's how you go through and configure a conditional access policy. Obviously, there are a lot of features there to play around with, a lot of things that you can look at.

3. Stepping through the hands on tutorial for Conditional Access Policies

Click the menu button here. Azure active directory I'm going to scroll down. And then we're going to click on the security blade. From there, we're going to go to Conditional Access, and then we're going to create a new policy, the policy and name, okay? And then from there, we will select our users and groups. In this case, we're choosing all users. Remember that if you were doing this on the exam, the exam would tell you if it wanted you to choose a specific user or group or whatever. In this case, we're choosing all. So we're going to go with all users clicking Done. We're going to set up our cloud apps. We're going to say all cloud apps, click Done. We're going to set our conditions. Our conditions are going to be signed in. The risk is going to be high.

That would be one of the criteria they might require you to put on the exam. We're going to click Select Device Platform. So we're going to make sure that's turned on and we're going to configure just Android. That was the only thing that was needed in this policy. We're going to click Done. Those are the only two conditions, or signals, as they're called, that need to be selected. So we're going to click Done on that. We're going to go to this Grant Access option, but we're going to be blocking. That was what the policy was calling for, to block it. We'll click select from there. Make sure the policy is enabled, because we do want this turned on. We don't want it just for monitoring. So then we're going to click Create and we're done. We've now created our conditional access policy to block Android for the cloud apps. So now this is something that you get a chance to practice.

4. Understanding Device Compliance Policies

So what exactly are compliance policies? So compliance policies in Intune, this is going to allow you to define some rules that are essentially going to check certain settings on a person's device to make sure that they meet a certain criteria, okay? And of course, if they don't meet certain criteria, then a couple of things can happen. You can have reports being generated, auditing can occur, or if you're working with conditional access, you can actually have the device blocked, you can force it to meet certain rules, all of that. So a couple of nice things, a couple of great features. It's sort of like, I always use the analogy that it's like when you go to a store, okay, here in the United States we have the no shirt, no shoes, no service rule, right? And so imagine that you get into the store with clothes on, then all of a sudden, for whatever weird reason, somebody decides to take their shirt off when they're in the store. And I'm not just talking about like a changing room, I’m talking about they take their shirt off at that point, they are no longer compliant inside that store, okay? Now one of two things can happen.

They can get kicked out or they can get picked up on video surveillance and maybe nothing happens to them. I don't know. But this is sort of how conditional access policies and compliance policies are going to work together to do this. all right? If you have conditional access policies in place with compliance policies, okay, so the two are working together, the compliance policy can detect whether the device is compliant. And if it's not compliant, then at that point we can make it so the user has no access to their organization's resources. So we're talking about things like OneDrive and SharePoint exchange their files that they want to use. They don't get any access. Of course, if you don't have any conditional access policies in place, then at that point, the device is not going to get restricted. However, it will do reporting. It will allow an administrator to audit their users and audit the devices and to determine maybe who are our troublemakers here, who are our troublemaking devices.

Okay? So again, with conditional access policies, the device can be blocked. The device can be restricted without conditional access policies. Well, the device does not get restricted, but it does generate reports and allows me to determine exactly which devices are causing problems. Okay? So another thing we have is that I want to talk about what devices aren't compliant. So, here are the main criteria to consider when determining whether or not a device is compliant. We have a pin number password, so we can require the device to have a certain size of password or if it's a pin number, it's got to be a certain number of characters, okay? Take it all in. So we've talked about password policies in the past. It's along those lines. And of course, if their password isn't strong enough, then they are not compliant. We have device encryption. Most devices nowadays do require device encryption, especially if you have Apple devices and all that. But for Windows devices and Android devices, device encryption is something that's got to be turned on, although a lot of those devices it's turned on by default. Of course, somebody could turn it off if they wanted to. For example, if you buy a Surface Pro tablet, it's going to have BitLocker, but you could turn that off. If you get an Android device, it's going to encrypt the device through full disc encryption. However, you could turn that off. Another thing is gel broken or rooted devices. In the Apple world, they use gel breaking, and in the Android world, they call it rooting. But that's basically somebody who has taken over and gotten admin rights over the operating system.

The downside of that, the reason why it's considered a security risk, is that the device is no longer protected by the operating systems, digital signing, and all of that. So they could get malware on the device. Another thing would be an email profile. You could require that email be set up in a certain way that an email application is being used. Maybe I want to require that they have to use the official Outlook app to get access to email. I could put that in place. minimum operating system and maximum operating system version.

That's pretty straightforward. Whatever the operating system is, iOS, Android, or Windows, you could require it to be a certain version. Then you get a health certificate. This is going to involve making sure that the device is healthy and not reporting malware or viruses on the device right now. What is the outcome of non compliance?First off, it's going to happen one of two ways. The device can be remediated so the device operating system can enforce compliance. So, for example, maybe you have a user who doesn't have a PIN number that's long enough. They could force them to reset their password or PIN number and make it longer.

Or maybe they're missing an operating system update that can force them to get that update. Secondly, the device can be quarantined. So if it doesn't, this is what would happen. For example, if you're not enforcing compliance, OK, maybe you're not using conditional access policies with it. Then at that point, it's not going to enforce anything. If the user gets a message, they'll get notified using the portal app that's being used there, and it'll let them know, hey, you're not compliant. You need to get compliant, okay? But it's not going to enforce it. So that's the difference between remediated and quarantined. OK? Hopefully that gives you guys a good understanding of dealing with the concepts of compliance policies and why they're important. And in this next little section, we'll also be looking at actually implementing compliance policies.

Study with ExamSnap to prepare for Microsoft 365 Certified: Security Administrator Associate Practice Test Questions and Answers, Study Guide, and a comprehensive Video Training Course. Powered by the popular VCE format, Microsoft 365 Certified: Security Administrator Associate Certification Exam Dumps compiled by the industry experts to make sure that you get verified answers. Our Product team ensures that our exams provide Microsoft 365 Certified: Security Administrator Associate Practice Test Questions & Exam Dumps that are up-to-date.