5

Limiting access to Office 365 by country

 2 years ago
source link: https://www.michev.info/Blog/Post/2186/limiting-access-to-office-365-by-country
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

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


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK