Quietly, Microsoft has released (a preview version of the) country-based controls for Conditional Access. While this is technically a minor addition, the ability to block logins to Office 365 or other cloud applications based on the location of the user has been a common request for years. Office 365 being a public SaaS offering is by default accessible from anywhere, anytime and this can be problematic for some organizations. Previously, AD FS claims rules were the only method that allowed restrictions to be configured based on the IP of the user/client. With the advent of Azure AD Conditional Access and Multi-factor authentication, we now have more robust and easier to use alternatives. Let’s do a quick test of the new feature.
Since this feature is part of Conditional Access policies, to configure it you need to browse to the corresponding blade in the Azure AD portal. Then, select the Named locations tab or click directly on this link. You will be presented with the same old interface used to define trusted IPs/ranges for both Conditional Access and Azure MFA. However, when you press the New location button, you are now given the option to define the location via Countries/Region as shown on the below screenshot:
To create a new country-based location, all you need to do is to give it a Name, and then select one or more of the countries from the dropdown control. In the example above, I have already created a location that includes my country, Bulgaria, and another one that includes the Netherlands, which happens to be the country in which my Azure VMs are hosted. In effect, I’m preparing a list of “known” or “good” locations which I can then whitelist in any CA policies. It’s important to note that you cannot designate any country or group of countries as a “trusted location” directly in the settings, as one can do for IPs/ranges.
You can of course approach this from the opposite angle – create a list of countries that are “bad” and any potential login attempt from those should either be blocked, or be a subject to more strict CA policy. In such scenarios, you will probably also want to check the Include unknown areas option, which will apply to any IP address that cannot be mapped to a given country. Whichever approach you select, the steps to create the named location are almost identical, and very easy to follow.
Once you have described all the “good” or “bad” locations, it’s time to put them in use in your Conditional Access policies. To do so, create a new policy or edit any existing one, then navigate to the Conditions tab, and under Locations, toggle the Configure slider, then select the relevant locations to include or exclude. Adjust any additional conditions as needed and decide on which controls to use. In the following example, I have created a policy that will require MFA for any login attempt, unless it’s coming from Bulgaria, where any such attempts are designated by the exclusion of the “BG” named location:
As you can see from the above screenshot, any Named locations you defined will appear in the list and you can select one or more of them for each of your policies, either as included or excluded location. You can of course still create a policy that does not depend on the network location, or a policy that applies to any “uncategorized” locations as we discussed above. After selecting the appropriate controls for your policy, it’s strongly recommended to test it via the WhatIf tool and also via some real login attempts. Be warned that the IP-to-country mappings are not always correct and can actually change over time, so have that in mind when configuring and troubleshooting country-based policies.
On to testing then. In my case, the policy should enforce MFA on any attempt not coming from Bulgaria, so lets check that. Connecting to a VM in Azure and trying to open any Office 365 application results either an MFA prompt, or triggering the “proof up” process if the user hasn’t registered their MFA methods already, as expected:
Just to be on the safe side, it’s a good idea to perform the same test from any location that is excluded from the policy. In my case, opening the Office 365 portal from my home PC with the same account resulted in no MFA prompts, so the policy seems to be working as expected. In effect, now I have a better control over who can access my Office 365 tenant, and from which country. Take that, random Chinese guy trying to brute force my account! 🙂
29 thoughts on “How to limit access to Office 365 by country”
Is there a way to audit that access attempts from other countries have been blocked, and the details of these? Is there a log somewhere?
Did you check the Azure AD sign-in logs? https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/concept-sign-ins
Sorry, what I mean is: If I have all non-US locations blocked, does this log get populated with events of attempted accesses from other countries, or is it dismissed before it shows in logs?
If blocked by CA policy, you will find the relevant entries in the Sign-in logs.
Is there a way to do this via Powershell?
Best use the Graph API: https://docs.microsoft.com/en-us/graph/api/resources/conditionalaccesspolicy?view=graph-rest-1.0
If I put static UK IP address and try to use it from US , will my log in be successful?
Hi Vasil, is it a good practice if i add a trusted country, then block access from “Any Location” & exclude my trusted country?
Probably not the best practice, as you risk locking yourself out if the IP ever gets attributes to another country. Instead of blocking access, force MFA or similar.
Do you know of a way to block users after working hours?
No reliable solution for that within M365 afaik. Maybe the new “real-time” CA controls can help, once they enable it for real-life scenarios that is.
Guys how do I block personal laptops and desktops from login In to Microsoft Teams without using CASB
CASB or conditional access policy are your options there. Or you might be able to restrict login to just specific IPs.
And what about how policies are evaluated? I´ve noticed that there is no “order” in the policies, so polices are “cumulativie”. So, if the same user is on two policies, one blocking and another one allowing, the block takes precedence?
In my scenario, we have 6 main countries and 5% of the users traveling around the world, so wee need to create something feasable, to allow allow only the 6 main countries and allowing ocasionaly, more countries, to key people
Block always wins, it should be mentioned somewhere in the documentation.
@ Vasil – When you setup the conditional access to block selected countries, will it still show in the alerts when someone tries to login from the blocked country?
Which alerts are you referring to? It will show up in the Azure AD sign-in logs.
Can this block OneDrive downloads, too? For example, if I want to share a file, but prevent some country IPs from every being able to access that file. (because my company is required)
You can use the Limited access functionality for that: https://docs.microsoft.com/en-us/sharepoint/control-access-from-unmanaged-devices
Very nice guideline mate!
Awesome post comrade, love the attention to detail and technical accuracy!
while this does block successful attempts, meaning they have the password. it does nothing to stop the invalid password attempts. I would like a way to stop invalid attempts.
You cannot block this across all services, but for some, such as Exchange Online, you can limit auth attempts as well. Take a look at auth policies: https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/disable-basic-authentication-in-exchange-online#authentication-policy-procedures-in-exchange-online
“Take that, random Chinese guy trying to brute force my account!”
except that brute force attacks are generally done using basic authentication which bypasses conditional access.
This is the issue I run into. Is there a work around to block countries for basic authentication?
Thank for article, but seem like requires Enterprise Mobility + Security license or Azure AD premium to do this. Is this right?
That, or Azure AD Premium, as any other Conditional access policies.
Pretty cool, though I’ve found the countries one might want to block aren’t the best at keeping track of their IP spaces. For example, earlier this year I was traveling in South America, but some of my devices were reporting in as Florida, USA. Presumably global ISPs lease address space from other countries.