In this ever-dangerous and hard-to-navigate cyber security landscape, it falls to IT pros to use every tool at their disposal to protect the data he or she is tasked with protecting. Using conditional access policies in Azure Active Directory can be one of those tools. Since these policies are super flexible, we have to make sure we are configuring this tool correctly or else one can end up getting blocked from the Azure portal altogether!
In this article, I will be taking you through one way to use conditional access policies to allow traffic only from countries specified in the policy. This sort of geo-blocking is IP-based, and IP’s can be spoofed to get around these policies, but it still behooves us to create these policies to add to a defense-in-depth strategy to protecting your users and your data. Let’s dig in!
Create Named Locations
First thing we need to do is set up the countries we want to allow in the “Named locations” section of the conditional access policy blade in Azure AD. Since we will be making exclusions to this blocking policy based on geo-location, we’ll need to set the countries we want to allow over here first so they will be available to ad to any policies later. Follow these two steps:
- In the “Named locations” section of the Conditional Access blade in Azure AD, click “+New location”:
- In the Named locations blade, choose “Countries/Regions” and start searching for United States, for example, and then select it. Repeat this step for any other countries you want to be made available to your policies. Again, these will be the countries that you will be allowing access to. Don’t worry – adding these countries here has no effect until you choose them as a condition in a policy:
Create Your Policy… Safely
It’s always good to have an escape plan. This way of thinking is no different when it comes to conditional access policies. I believe that it’s good practice when creating any conditional access policies that you add two security groups (they can be cloud-based groups, but synced groups from on-prem are even better since you can add users to the group outside of Azure AD in case you really get stuck), even if they are empty, to the “exclude” tab of the “Users and groups” assignments (see image below). One group should be a group that is added to ALL conditional access policies and the other group should be one specific to the policy being configured. This gives you the flexibility you need to add a user to that group to exclude them from the policy for troubleshooting or to get yourself out of a bind. I’ve seen unsuspecting admins lock themselves out from Azure completely because of a conditional access policy that targeted all users and groups and all apps – not good!
Now that you’ve given yourself a safety net, switch over to the Include tab on this same blade and target All users since you want to make this an all-encompassing policy targeting everyone (except the groups we specified above).
Now that you have the “who” part of your policy done, let’s move over to the “Cloud apps or actions” section of the policy to target all of our apps (see image below). This is the “what” part of your policy. You have the same flexibility here you do with targeting users, so set this to whatever might be appropriate for your environment.
Next, we’ll be setting up the location piece of this particular policy puzzle. Click over to the “Conditions” section of your policy. Then choose the condition based on “Locations” and choose “Any location” under the Include tab on this blade (see image below). Note you may have to toggle the Configure button:
Then choose the “Exclude” tab and pick the countries you’d like to allow access from, like below for example. Use the selections that are appropriate for your environment. In this example, I’m only allowing traffic from the US and Canada. Once you’re all set, click Done and Done.:
Finally, let’s choose our access controls. Head over to the “Access controls” section of your policy. In this blade, we are going to choose to “Block”.
Once you verify your settings by double checking your work, you can enable the policy and enjoy a more locked down tenant.
Overview of the Policy
Here is a high level overview of what’s happening with this policy:
- Who – You’re targeting everyone except people in the exclusion safety groups you created.
- What – You’re targeting ALL apps in your tenant. This will include any and all Office 365 apps like Exchange Online, SharePoint Online, etc…
- Where – You’re targeting all locations and excluding the countries you wish to allow access from.
- Based on all of the above criteria, you are blocking access.
Things To Note
There are a few important things to be aware of when it comes to conditional access policies (CAP). This list is not exhaustive, but is a good general reference. Please see this excellent reference article for a deeper understanding of how these policies work.
- CAP’s that conflict (same conditions, same users\groups, etc..), a Block action will ALWAYS win.
- CAP’s are cumulative meaning their settings merge when a user is targeted for multiple policies that satisfy multiple conditions. So if one Grant policy requires MFA and another requires a compliant device, that user\condition targeted for both policies will need BOTH a compliant device AND MFA. In effect, the policies merge.
- Expounding on the above, CAP’s don’t have priorities like mail flow rules or anti-spam policies in Exchange Online, for example.
- Make use of the what-if tool in the CAP blade to see which policy or policies could effect which users,
It’s important to have a defense-in-depth approach to your security plan. Using Azure AD Conditional Access Policies is a great way to help augment and control access to your resources in Azure. As with everything you do, it’s important to TEST TEST TEST (did I mention TEST?) all of this in a non-production lab environment!
Happy blocking!<div class='sharedaddy sd-block sd-like jetpack-likes-widget-wrapper jetpack-likes-widget-unloaded' id='like-post-wrapper-127276047-71-5dab96dbdc14c' data-src='https://widgets.wp.com/likes/#blog_id=127276047&post_id=71&origin=pragmaticadmin.com&obj_id=127276047-71-5dab96dbdc14c' data-name='like-post-frame-127276047-71-5dab96dbdc14c'><h3 class="sd-title">Like this:</h3><div class='likes-widget-placeholder post-likes-widget-placeholder' style='height: 55px;'><span class='button'><span>Like</span></span> <span class="loading">Loading...</span></div><span class='sd-text-color'></span><a class='sd-link-color'></a></div>