Practical Protection: Azure AD Conditional Access – Location, Location, Location 

Conditional Access policies are one of the most versatile and flexible security features that Microsoft’s ever built. From their initial basic beginnings, their capabilities have expanded widely. For example, you can create policies using authentication contexts to restrict access to specific SharePoint sites, or you can use Conditional Access policies alongside Microsoft Defender for Cloud Apps to provide a reverse proxy for controlling app session access. All this magic can be yours, provided that you have the correct licenses to use Conditional Access. However, there’s one area that Conditional Access can help you protect that isn’t as well known—using IP restrictions to control where a specific app can be used. 

The Location Problem 

Certain operations require the operator to be in a known physical location. Think of launching nuclear missiles, sending uplink commands to satellites, and approving very large electronic funds transfers—all of these require the operator to use dedicated hardware on a dedicated network in a fixed set of locations. Of course, this kind of thing is antithetical to the idea of “work from anywhere,” and in any event, the worldwide Internet doesn’t really provide a reliable way to geolocate a user based on their network address. However, sometimes we really do want to restrict access to some object or service based on where the user is coming from. 

In the olden days, the most common way to do this was by network isolation. The structure of Internet address assignments meant that it was possible to fairly easily block out traffic from certain sources based on their Internet Protocol addresses. These measures didn’t always work, and sometimes there were unfortunate accidents with undesirable side effects. Some anti-malware tools still use a variant of this technique, on the assumption that mail appearing to come from IP ranges associated with e.g. North Korea (or appearing on a block list of known bad actors) probably aren’t legitimate. However, the explosive growth in the number of Internet-connected devices means that we now live in a world where the old hierarchical structure of network addressing isn’t much help as a security enforcement mechanism. 

“Everything not Allowed is Forbidden” 

The partial solution to this problem is to apply access controls that only allow access from specific IP addresses. The rationale behind this approach is that if you just block traffic from places that aren’t the desired location, you’ll be in good shape. While I wouldn’t say this is 100% true, it’s true enough that even Microsoft uses it—they publish a list of IP addresses that originate Microsoft 365 traffic so that you can base access control mechanisms on it. That’s great if you want to control the usage of Microsoft 365 and its applications, but it doesn’t help much if you want to control access to other Azure AD applications. The good news, though, is that there is a way to do this. In fact, there may be more than one way, depending on the application you’re trying to protect. 

Conditional Access Location Policies 

The simplest way to accomplish this is to create a Conditional Access policy that uses the network location of the user to decide whether to allow or deny access. One very important point here: the Conditional Access policy doesn’t apply until after the user has authenticated using whatever first authentication factor you specify. That is, this method does not block the actual connection; the user will still log in, and then when the policy is evaluated, access will be blocked if the location matches the block condition. 

To set this method up, first you have to tell Azure AD about your network locations. You can do this either by specifying a list of countries or by defining an IP range. What’s interesting about the country option is that you can decide whether you want to determine the requestor’s country by using IP geolocation information or by using GPS coordinates. If you pick the GPS option, when a policy that uses the defined location as a condition is triggered, the Microsoft Authenticator app on the user’s registered device will prompt the user to allow her location to be captured and passed to Microsoft. This mechanism obviously requires the user to both have the Microsoft Authenticator app installed and to be willing to share their location, but it’s much more reliable than using IP addresses to determine whether someone is in Denmark, Djibouti, or Denver. 

Once you’ve defined the locations you want to either allow or block, you can create a Conditional Access policy using the location condition, as described here. This is no different than defining any other Conditional Access policy, except that you use the locations you’ve defined as condition inputs. 

As always with Conditional Access policies, you should be very careful to test new policies thoroughly by using the report-only mode, and by excluding your “break-glass” accounts from the policies. It’s easy to make a policy that locks everyone, including your own administrator account, out of Azure AD. 

Protecting Your Own Apps 

You may also be able to use a related trick to control access to your own enterprise application objects, which might enable you to use Conditional Access policies with line-of-business applications you own or with other applications not made by Microsoft. The trick here is to remember that Conditional Access policies are only applied when someone requests a service from Microsoft. For example, imagine that you have an expense-management application you’ve registered for single sign-on with Azure AD. If you create a Conditional Access policy, it can only be evaluated when someone uses the application in a way that makes it request something from Microsoft, for example, by logging in with SSO, or by using a feature that retrieves contact data from the user’s mailbox. Therefore, you may not be able to consistently protect standalone applications registered in Azure AD, depending on how they work. 

If you want to try, you can use this same technique of defining IP address ranges to either block or allow, then create a CA policy that uses them as conditions. 

You Can’t Get There From Here 

Location-based access control isn’t infallible. For example, there are tools that let Android users fake their GPS location for phone apps, and of course, a smart attacker will use VPNs or other tools to let their traffic originate (or at least appear to!) from a location that you permit. However, as with multi-factor authentication, location-based controls are a valuable part of a defense-in-depth strategy—so while you shouldn’t depend on them alone, they add a useful layer of protection when you design and deploy them properly.