Conditional Access is one of the most important security features in Entra ID. It ties all the security components of your modern workplace together and you can build all the rules you need to match your security requirements. But with great strength, comes…. Well, confusion. In the trainings I deliver is a MCT, I see a lot of students that are confused with all the posibilities within Conditonal Access. In this blogpost, I’ll try to help you understand all the posibilities so you can get started building your own policies.
Some basic ground rules
The most confusing part for most people is how Conditional Access policies are applied. The first instinct for IT Pro’s is to compare Conditional Access to some sort of firewall. You allow or block specific requests (connections) based on conditions (like source or destination of the traffic). I can see the comparison, but it’s not really true. There are two important differences between Conditional Access and firewall rules.
-
A firewall will apply rules top-down. If there is a match (either with a block or a deny), processing of rules will stop. Conditional Access however, will apply all rules. If there is a conflict (or multple rules are applied) the most restricvie control will win. So, if there is both a rule that will blcok access and a rule that will grant the same access, access will be blocked because that’s the most restrictive (or strongest) control.
-
A firewall usually has an ‘implicit deny’ at the very botom of the list of rules. So: if access was nog granted in one of the previous rules, access will be blocked. You have to explicitly allow something to have access. For Conditional Access, there is no such thing. If there is no rule in place to block certain access, access will be granted (as that is the default).
Just two key differences, but because of this you’ll need top approach setting up your rules differently than what you’d expect.
Planning your policies
All rules are applied and there is no implicit deny. What are the consequences in your design? Let’s think of a scenario with the following requirements:
We have an application that should be available to the users in the ‘accounting’ department, but not to other users in our company.
The solution for most users would be to create a rule to allow access to the ‘accounting’ department. However, because there is no implicit deny this would not block access to all other users. The solution would be to create an extra rule, to block access for these users, placing it below the first rule. Right? No! All rules are applied, so there would be two rules for the ‘accounting’ users: one that grants access and one that blocks access. The strongest control wins, so the extra rule will cause the ‘accounting’ users to be blocked as well.
So, what would be the solution? In this case, you could create a rule for all users to block access, and exclude the ‘accounting’ user from this rule. In this scenario, there is no block in place for the ‘accounting’ users so they will have access to the app.
As you can see, sometimes you have to approach the solution in a completely opposite way as you normally would, because of the ground rules layed out in the previous chapter.
Best practices for your design
So, are there any real best practices? I’m not sure. Of course, the ground rules mentioned before can also be seen as best practices. I think the mnost important part is to document your policies as good as you can. A perfect way to do this is in the naming of the policies: by explicitly naming the goal of you policy, you can make them ‘self documenting’. For example, you can call your policy 001 - Require strong authentication for Admin sign-ins. This explicitly mentions the goal of the policy, so you can quickly see what it does without going into the actual configuration.
Did you see the ‘001’ at the start of my policy name? As I mentioned before, policies are not ‘ordered’. All policies will be evaluated and applied. By including a number in the start of the policy name, you can at least order them based on the name and refer to specific policies in your documentation, based on the number. It makes tracking down policies that don’t work as intended much easier!
Conditional Access: Conditions
So, Conditional Access consists of two things (as the name implies): conditions, and access. The ‘conditions’-part dictates if a policy will be applied or not. If a sign-in matches the conditions, the actions in the ‘access’ section will be enforced. If there’s no match the rule will be ignored. The conditions can be built with several components.
Assignment
The ‘assignment’ section is all about…. Well, assignment. It dictates the user or groups to wich the policy will be targeted. Apart from specfic users or groups, you can also select ‘guest users’ or specific role assignments. You could use this, for example, to target a policy to all global administrators. You can also use this section to target specific actions, in stead of users. For example you could create a policy that is applied to users who do MFA registration.
Apps
The ‘apps’ section is about the apps. Is the user signing in trying to reach Exchange Online, or Microosft Teams? Or maybe a third-party application that uses Entra ID as their IDP?
One of the options here is the all apps option, that will cover each and every sign-in. So be carefull when you use this! If you whish to protect your Microsoft 365 workloads, like Teams, Exchange and Sharepoint, you can use the Microsoft 365 Apps option. This will cover all Microsoft 365 applications, even if new apps are released in the future. So you won’t need to update your rules every time Microsoft releases new functionality.
Location
Locations in Conditional Access are based on IP-address. You can include or excluded IP-addresses or entire geographical locations (countries) in you policies. This way, you can block sign-ins from specific countries, or maybe go even more secure: block all sign-ins, except from the ones coming from you home country.
You can create named locations, where you specify specific IP ranges. This can be usefull to easily recognise sign-ins from, for example, your corporate network. If check te box to mark as trusted location, you can easily in- or exclude all trusted locations in specific policies.
Devices
Another signal collected at each sign-in is the device being used. Is your user connecting from a Windows- or Mac-based laptop, or from a mobile device such as Android or iPhone? By using the devices option you can create policies that only apply to mobile devices, so you can require these devices to have password, for example.
Risks
Part of Entra ID is risk protection. At each sign-in, two types of risk are calculated. You can use these risks in your conditonal access policies. The risks can be low, medium or high and the policies can be set to apply on either of these conditions.
Sign-in Risks
Sign in risks are about the risk that a given sign-in is not authorized by the identity owner. So: is there a change that this sign-in is not the actual user signing in. There are several ways this can be detected. Sign ins from unfamilliar devices or locations, for example, can increase this risk score. ‘Impossible travel’ (signing in from Amsterdam and then signing in from New York five minutes later) can also be indication of this. There are a lot more possible indicator, but maybe that’s something for another blog post ;)
User Risks
User risk represents the possibility that the identity that is being is signed in is compromised. Maybe the credentials for an account are found in online dump of breached passwords, for example.
Client Apps
We’ve seen the ‘app’ being used as a condition (the resource that is being accessed), but we can also focus on the client app being used. Is the user trying to reach his mailbox using Microsoft Outlook, the native mail client on his mobile device, or maybe a browser to access webmail? All these options can be covered in your policy.
Conditional Access: Access
The other part of condition access: access. If we match the conditions, what should we do?
Allow, block and extra requirements
The most basic controls come first. We can choose to block the sign-in all togeter, or require multi-factor authentication. Or maybe we want to allow the sign-in with some extra requirements: require an approved app being used (‘you can only fetch your mail through Outlook, not through your native client’) or require a trusted / compliant device (‘you can only get get here through your corporate device that’s enrolled in Intune, not via a BYOD!’). Use the ‘block’ option wisely, especially if you target ‘all users’ and/or ‘all applications’. Make sure to not lock yourself out, if you do this you will need the help of Microsoft support to get back into your tenant!
Session Controls
‘Session controls’ give you some extra control of specific sessions. Do you want users to reauthenticate every couple of hours? Do you want the session to automatically end if a browser session is closed? Or do you want to use Cloud App Security to block the download of files in web-based session? This is the place to set that up.
Troubleshooting and testing
So, a lot of options to get your polcies set up. But how do you test them and see if everything works as intended? There are two places to do so.
Sign-in logs
First of all, the Entra ID sign-in logs for each sign-in shows all the conditional access policies that are evaluated, and if they are applied or not. You can also see why they are or aren’t applied, based on device information, location and all the other options from the ‘conditions’ section. This is very usefull information for troubleshooting sign-ins: why can’t a user reach his or hers email? The sign-in logs will show all information.
What-if
But what if you want to check a policy before you actually apply it? In the conditional access tab, you can find the what if option. Here, you specify some information to replicate a sign-in: the user, location, device, etc. The portal will then show you all conditional access and if they will be applied or not. This way, you can troubleshoot (or test) certain scenarios without an actual sign-in (and therefore, without any disturbance for the end-user).
Important tips for getting started
So, there are a lot of options. The best way to get started is just getting your feet wet. Create a policy, target just a test-user and see how it behaves. If your ready to apply your policy, target a set of pilot users before rolling out at scale. And: use the what-if function to test your workflow and check if the policy you built meets your functional requirements. And about that functional requirements part: think of your policy before you start building. If you have a clear picture of what you want to achieve (‘I want all end users to be able to read their email on a mobile device, but only with the Microsoft Outlook app so I can apply some extra security polciies’), building the policy from there is just a small step. See how I included all the conditions in my functiona, description? If you have that, you’re all set to build the policy.
Moving on from here
There are a lot of good blog posts on Conditional Access. Some go deep, some help you getting started. Just use your favorite search engine to find them. If you want to learn more directly from Microsoft, hop over to Microsoft Learn for some basic documentation and some tips on building your first policies.
Have fun getting your environment more secure!