Limiting access to Office 365 by country

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! 🙂

This entry was posted in Azure AD, Office 365. Bookmark the permalink.

29 Responses to Limiting access to Office 365 by country

  1. Joe Beineke says:

    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?

  2. Jorel says:


    Is there a way to do this via Powershell?


  3. Kevin S says:

    Hi Vasil, is it a good practice if i add a trusted country, then block access from “Any Location” & exclude my trusted country?

    • Vasil Michev says:

      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.

  4. Dean Gross says:

    Do you know of a way to block users after working hours?

    • Vasil Michev says:

      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.

  5. Moses Juma says:

    Guys how do I block personal laptops and desktops from login In to Microsoft Teams without using CASB

    • Vasil Michev says:

      CASB or conditional access policy are your options there. Or you might be able to restrict login to just specific IPs.

  6. Eskimo says:

    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

  7. Kevin says:

    @ 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?

  8. Mike M says:

    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)

  9. Dominik says:

    Very nice guideline mate!

  10. Boyan says:

    Awesome post comrade, love the attention to detail and technical accuracy!

  11. ME says:

    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.

  12. vice says:

    “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.

  13. Pingback: Office 365 Brute Force Attack – Manly-Boots

  14. Linh Nguyen Nhu says:

    Thank for article, but seem like requires Enterprise Mobility + Security license or Azure AD premium to do this. Is this right?

  15. mike crowley says:

    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.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.