Advice through experience in Office 365, Security, and Azure
Email Phishing Protection Guide – Part 5: Define Geographic Logon Restrictions for Office 365 and Azure Services

Email Phishing Protection Guide – Part 5: Define Geographic Logon Restrictions for Office 365 and Azure Services

The Email Phishing Protection Guide is a multi-part blog series written to walk you through the setup of many security focused features you may already own in Microsoft Windows, Microsoft Office 365, and Microsoft Azure. By implementing some or all of these items, an organization will increase their security posture against phishing email attacks designed to steal user identities. This guide is written for system administrators with skills ranging from beginner to expert.

Email Phishing Protection Guide Index:

Introduction: Email Phishing Protection Guide – Enhancing Your Organization’s Security Posture

Part 1: Customize the Office 365 Logon Portal

Part 2: Training Users with the Office 365 Attack Simulator

Part 3: Deploy Multi Factor Authentication (MFA)

Part 4: Deploy Windows Hello

Part 5: Define Country and Region Logon Restrictions for Office 365 and Azure Services

Part 6: Deploy Outlook Plug-in to Report Suspicious Emails

Part 7: Deploy ATP Anti-Phishing Policies

Part 8: Deploy ATP Safe Link Policies

Part 9: Deploy ATP Safe Attachment Policies

Part 10: Deploy and Enforce Smart Screen for Microsoft Edge, Microsoft Internet Explorer and Google Chrome

Part 11: Monitor Phishing and SPAM Attacks in Office 365

Part 12: Discover Who is Attacking Your Office 365 User Identities

Part 13: Update Your User Identity Password Strategy

Part 14: Prevent Brute Force and Spray Attacks in Office 365

Part 15: Implement the Microsoft Azure AD Password Protection Service (for On-Premises too!)

Part 16: Disable Office 365 Legacy Email Authentication Protocols

Part 17: Control Application Consent Registrations in Microsoft Office 365 and Microsoft Azure

Part 18: Increase Security with Microsoft Secure Score

Part 19: Email Phishing Protection Security Checklist

Part 20: Recommended Security and Anti-Phishing Training from Microsoft Ignite 2018


Part 5: Define Country and Region Logon Restrictions for Office 365 and Azure Services

We are on a journey in this series of blogs to increase the security posture of your organization against phishing emails. We are setting up a variety of locks that an attacker will need to pick, limiting the chances of a security breach from an email phishing attack. In this next blog I discuss a feature in Azure Active Directory called Conditional Access that has several capabilities, including a way to permit a logon from only the countries or regions where your organization operates.

From a security perspective, being able to define who can access an organization’s resources by countries or regions is another way you can further enhance the security posture of an organization. If a user receives a well-crafted phishing email, clicks on the malicious link, and then provides his or her Office 365 credentials, the attacker would normally be able to logon to the account (assuming other controls are not in place) from anywhere in the world. However, let’s consider that you are the administrator to a small doctor’s office in North Dakota, USA and you have implemented a Conditional Access policy that limits access only from locations in the United States and Canada. If the attacker tried to logon with the stolen identity from anywhere other than these two defined countries, the access would be blocked – protecting the valuable and sensitive information at the doctor office.

For organizations with users who do not travel out of their home country, this is a straight forward policy to configure. Generally, for small to mid-size organizations you can define geographic regions your users are most likely to logon from. For larger organizations, you may need to be more selective in the countries you select as acceptable logon locations. For organizations that are continuing to expand into new areas, this may not be a static list of countries. Rather, acceptable logon locations should be reviewed on a frequent basis to balance access for traveling users conducting business and protecting the organization from external threats.

Keep in mind that this is not a perfect solution, but rather another lock an attacker trying to steal identities will need to pick through. In our doctor office scenario above of only allowing logons from the United States and Canada, this policy will prevent an attacker external of these locations from directly logging into the site. However, a sophisticated attacker may have access to remote systems in these countries with which they can logon from. It is the quantity of strategic locks you implement in your organization that prevent attacks from being successful.

For more information about creating Location Conditions in a Conditional Access policy, see this link.

Caution: Before you proceed with the steps in this document, you must set this up first in a lab environment to verify intended behavior. A misconfigured access rule in a production environment could prevent access to business users. Be sure you have researched, tested, and piloted these steps before proceeding into production.

Below are steps about how to setup Conditional Access to restrict logons by geographic regions:

  1. Logon to with an account assigned to the Global Administrator role.

  2. Enter the password.

  3. When logged into the Microsoft Azure portal, click on Azure Directory on the lower left. Then, scroll down the options and select Conditional Access.

  4. In the Conditional Access configuration area, we will first define the locations for trusted access. Select Named Locations. Then select +New Location.

  5. Give your location a new name. In my example, I defined United States and Canada Only. Then select Countries/Regions and choose these two countries in our example.

  6. With the two countries selected, I also chose to Include Unknown Areas as well using the option below.

  7. When ready with your selections, choose to Create the new location with the Create option at the bottom of the screen.

  8. The new location is now defined as shown below.

  9. With a Named Location now defined, we can setup a policy to use it. Select Policies at the top left of the screen.
  10. Select New Policy

  11. Within the new policy, create a name. For this example, I called mine Trusted Logon Location. Then select Conditions, and then Locations.

  12. Select Yes to Configure the location on the right of the screen. Select the Any Locations option.

  13. Next, select the Exclude tab as highlighted below. Choose the option for Selected Locations. Highlight the Select option and place a check in the boxes next to MFA Trusted IPs and United States and Canada Only.

  14. At the bottom of the screen, click Select to save the settings. Then select Done to close Locations and select Done to Save Conditions. Finally, choose to enable the policy by selecting On.

  15. Back in the policy creation area, notice that you can now Enable the policy, but that Create at the bottom is not an option to finalize the policy. We still need to define an Access Control.

  16. Under the Access Controls section, select Grant.

  17. Then select the option to Block Access. Click Select at the bottom to define the policy.

  18. Caution: Before proceeding, be sure you have tested these steps in a demo environment and that you understand the intended behavior. A failure to correctly configure this rule could prevent you from accessing your own organization.

    Notice at the bottom of the new Conditional Access policy that the Create option is now available. Select the On option and then click Create to enable the policy.

  19. Log out of the browser and close the session. Allow several minutes for the rule to apply, then open a new browser session and logon to verify access.

Conclusion: In this blog we have reviewed one of the areas of a Conditional Access policy we can define to prevent logons to Office 365 or Azure services from countries or regions outside of where your organization operates. While this is another lock to protect from phishing attackers using stolen identities, it is not perfect. More advanced attackers could remote control systems inside the countries and regions you have defined for access to work around this policy.

Leave a Reply

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

%d bloggers like this: