Using Conditional Access To Protect Student and Staff Identity With Location Based Policies

Overview of Conditional Access

This post was inspired by recent conversations with partners and IT Admins in schools who were wanting to provide a layer of additional protection for students without requiring them to use MFA (usually, because younger students do not always have access to mobile phones). 

It’s a lengthy post, however provides a good step by step overview on how to protect users from overseas identity attacks by blocking international authentication attempts through the use of Conditional Access without requiring MFA. The following sections are included:

  1. Why Identity Protection
  2. What is Conditional Access?
  3. How To
  4. Implications of this Approach
  5. Final Thoughts

Why Identity Protection?

Attempts by bad actors to exploit weak or compromised passwords is one of the most common attack vectors experienced by organizations globally and education is no exception. In fact, in a 2019 Microsoft Security blog it was noted:

There are over 300 million fraudulent sign-in attempts to our cloud services every day … MFA can block over 99.9 percent of account compromise attacks. With MFA, knowing or cracking the password won’t be enough to gain access. To learn more, read Your Pa$$word doesn’t matter. (source)

MFA, or Multi Factor Authentication, is a process whereby a second form of identification is required (usually a smartphone app or SMS code message) which works very effectively, however can be challenging or time consuming for some end users. This is particularly true in education where schools often have younger students who may not have a phone with which to perform the MFA action.

Whilst weak passwords can be relatively easily avoided by schools and universities by applying minimum password complexity rules, the reality is many users will leverage the same password in other online platforms (e.g. social media, fitness apps and other websites where they have created accounts) and it may be that those platforms have their user database compromised. In those circumstances, a good place to check is the website Have I Been Pwned? where simply entering your email address will reveal if your account has been compromised online. Having obtained compromised account details, would-be attackers can launch automated drive by attacks on many online platforms, including M365. MFA will go a long way towards stopping this, however Conditional Access is another tool available to M365 users that is effective even without MFA which may be unavailable due to age or skill of end users.

Given that the vast majority of attackers are likely to be attempting authentications from overseas, Conditional Access will allow you to automatically block those attempts, adding an invisible layer of protection to all users without slowing down the authentication process at all. I was talking to an IT partner recently who supports multiple schools and he commented:

[Conditional Access is a] quick easy way to stop 99% of our student accounts getting compromised, probably staff as well… [other solutions] don’t have any product offerings outside of MFA … Conditional Access is a game-changer!”

What Is Conditional Access?


Conditional Access policies at their simplest are if-then statements, if a user wants to access a resource, then they must complete an action. (source)

As part of Microsoft’s security approach based on Zero Trust, Conditional Access provides an excellent set of tools to the IT Administrator to allow employees or students and teachers the ability to carry out necessary tasks and actions, whilst ensuring security policy is applied with the least imposition possible.

Conditional Access uses a few terms interchangeably, so for clarity sake keep the following three ideas in your mind:

  • A Condition needs to be met. This is the “if” statement and is made up of common signals. Common examples of conditions or if statements include
    • User or group membership; IP location information (i.e. where the end user is connecting to the internet from); Device (e.g. OS or device state); Application (e.g. using authorized apps only); as well as advanced 1st Party Microsoft Identity Protection Tools such as Microsoft Cloud App Security (MCAS)
  • A Decision is made to Grant access to a resource (or, alternatively, block it) based on the Condition / if statement. This is the “then” statement completed for each Condition. Common decisions include:
    • Block access (clearly the most restrictive decision); Grant Access with optional additional layers required such as MFA, only from compliant or hybrid AAD joined device or from an approved app only (e.g. official Outlook app for iOS and not the native Mail client).
  • Like all policies in M365, a Conditional Access policy must be Assigned to a valid user/group or users/groups before it becomes effective.

Common examples of Conditional Access policies used by organizations include:

  • Requiring multi-factor authentication for users with administrative roles
  • Requiring multi-factor authentication for Azure management tasks
  • Blocking sign-ins for users attempting to use legacy authentication protocols
  • Requiring trusted locations for Azure Multi-Factor Authentication registration
  • Blocking or granting access from specific locations
  • Blocking risky sign-in behaviors
  • Requiring organization-managed devices for specific applications

How To

There are a bunch of great tutorials out there (this is a super simple one to follow) and the official documentation is always highly recommended to read, but if you want to follow my steps then read on. In this example I will be setting up a Conditional Access policy to block all authentications from outside New Zealand, but allowing any internal authentications to process without requiring MFA. A policy like this, tweaked for your location, would provide the additional layer of protection for your accounts without adding any additional steps for your end users.

  • Start at the AzureAD Admin Centre (accessible via the M365 Admin Centre menu options) and scroll down to locate the Security menu


  • Create a Named Location where you will define your Country IP address range


Which should look like this:


This will be important as Conditional Access Policies will be relying on Named Locations that you’ve created. You can also define specific IP address ranges rather than entire countries if you choose.

  • It’s now time to create your Conditional Access Policy and use the Named Location you created above. In the blade menu choose Conditional Access:


  • Then look to create a new Policy:


When creating a Conditional Access Policy there are three steps you need to always consider:

  • What’s the Condition that needs to be met? (the If statement)
  • What access will you Grant? (the Then statement)
  • Which Users and/or Groups will you Assign the policy to?

Setting up the Condition to block all logins but to exclude your named location(s) such as New Zealand in my location requires two steps. First, include Any Location:


And then exclude the Named Location you created:


  • With your Condition defined, you now need to Grant the access you want associated with this policy:


In this example I have chosen to simply “Block Access” – remember, this will now apply to all locations I “Included” in the above Condition (which was ‘anywhere’) but critically will exclude the Named Locations I selected – New Zealand. In effect, this means that any attempt to sign into M365 outside of New Zealand will be blocked immediately. You’ll note there are other good options to consider such as enforcing Multi Factor Authentication (MFA) and more advanced options such as ensuring that the device is compliant from a security posture assessment.

  • The final step to complete setting this up is to Assign the new policy – this process follows the standard M365 Administrative workflow of selecting a user(s) or group(s)


It’s worth noting that you can set the policy to “Report-only” – this is a great thing to do initially when testing to ensure that you’re not locking yourself out of your tenant! Assign the policy and then monitor the impact

  • To Monitor the sign-in activity and check the impact of your Conditional Access Policy, return to the main AzureAD Admin Portal and under the “Monitoring” section of the menu you’ll see “Sign-ins” which should look something like this:


From an end user perspective, they would receive a message like this:


Implications Of This Approach

Multi Factor Authentication (MFA) is obviously one of the best ways to protect accounts, however the above example shows that a simple Conditional Access policy can go a long way towards protecting student and teacher accounts without negatively impacting their authentication sign in process. This can be used effectively in situations where end users do not have any means of completing MFA (such as, no mobile phone or access to a fixed landline to receive an automated MFA call).

The power of Conditional Access is that it can still be used in conjunction with MFA, as it could easily be tweaked to allow a teacher or student travelling overseas to still log into M365 but they would necessarily be prompted for MFA to ensure the integrity of their authentication.

For those educational institutes looking to provide the maximum level of protection around their accounts they should consider AzureAD Identity Protection which works by collating and analyzing many signals and making automated decisions based on the risk profile of the sign-in attempt.

Identity Protection uses the learnings Microsoft has acquired from their position in organizations with Azure AD, the consumer space with Microsoft Accounts, and in gaming with Xbox to protect your users. Microsoft analyses 6.5 trillion signals per day to identify and protect customers from threats.

The signals generated by and fed to Identity Protection, can be further fed into tools like Conditional Access to make access decisions, or fed back to a security information and event management (SIEM) tool for further investigation based on your organization’s enforced policies. (source)

With Identity Protection, the following risk classifications are analyzed:


Risk detection type


Atypical travel

Sign in from an atypical location based on the user’s recent sign-ins.

Anonymous IP address

Sign in from an anonymous IP address (for example: Tor browser, anonymizer VPNs).

Unfamiliar sign-in properties

Sign in with properties we’ve not seen recently for the given user.

Malware linked IP address

Sign in from a malware linked IP address.

Leaked Credentials

This risk detection indicates that the user’s valid credentials have been leaked.

Password spray

Indicates that multiple usernames are being attacked using common passwords in a unified brute force manner.

Azure AD threat intelligence

Microsoft’s internal and external threat intelligence sources have identified a known attack pattern.

The “Atypical Travel” is an interesting one that I’ve encountered given my work across Asia – I’ll be prompted for MFA when signing in at locations I rarely travel to.

Identity Protection then creates three levels of risk:

  1. Low
  2. Medium
  3. High

A smart approach for schools and universities would be to automatically block Medium and High risk sign in attempts and in doing so, significantly bolstering their security posture when it comes to Identity Protection.

Final Thoughts

There are many ways organisations can add additional layers of protection to the authentication process to reduce the chance their users are compromised and the potential of serious damage is limited. There is always a balance between security and inconvenience (which risks non-adherence from end users), and therefore the beauty and power of Conditional Access should be very appealing to IT Administrators in schools and universities. Of course, Multi Factor Authentication (MFA) and AzureAD Identity Protection provide some of the highest levels of protection possible, but I would personally strongly encourage every organization to start with Conditional Access based on location and blocking overseas authentication attempts.

If you’ve got other strategies for protecting your users’ accounts, drop them in the comments below.


  1. Yang September 10, 2020
    • Sam McNeill September 10, 2020
  2. Paul October 7, 2020
    • Sam McNeill October 7, 2020

I am always keen to discuss what I've written and hear your ideas so leave a reply here...

%d bloggers like this: