When we talk about accessing resources and applications today, we always talk about security as well. In almost all cases the access applications and resources must be protected with Multi-Factor Authentication and in some cases an extra security layer is required. That extra security layer in the past could only be applied based on IP address(es) or country (still based on IP), called a named location in Azure AD. As you may know already IP address(es) can be spoofed and with VPN servers you can easily ‘proxy’ all your traffic through a country/endpoint which is still on the allow list. That means hackers and attackers can, relatively easily, work around these security measurements.

To make it even more complex some organizations are using services like ZScaler as a proxy for their endpoints and are whitelisting their IP addresses. While ZScaler offers great functionality it’s not a best practice to whitelist their IP addresses. This as by whitelisting these IP addresses provided by a service like ZScaler, you’re whitelisting other organizations as well which are using the same service. Or even worse: what if hackers and attackers are using ZScaler as well? They would be using the same browsing addresses which is then most likely whitelisted within your Azure Active Directory.

Apart from the fact that the above doesn’t match a zero-trust scenario in some cases, we simply need to make sure that sign-in activities are blocked within specific countries. For that Microsoft has now introduced a new feature within the Azure Active Directory ‘Named Locations’ feature, which today is in public preview, and is called ‘Determine location by GPS Coordinates’.

This new functionality is simply grabbing the GPS location of the end user via the Authenticator App which is installed and enrolled on the user’s mobile phone. Based on the GPS coordinates of the mobile device, Azure Active Directory knows where the user is currently located and therefore access can be granted, if additional security controls are satisfied (conditionally), or can simply be denied.

Keep in mind that the location shared is accurate on a country-level, so scenarios where you would want to check whether someone is on/at Office location X in city/city-block Y are not possible.

An example of this behavior is shown above where a sign-in was blocked, this as the user was in a country (based on GPS Coordinates) which wasn’t allowed to be used to sign-in to an application attached to Azure Active Directory.

Now to use this functionality there are four important things to keep in mind which are described below:

• Applying the GPS coordinates function for access to all resources (“All cloud apps” in Conditional Access) isn’t recommended, as you will end up in a loop for the enrollment of the Authenticator App itself. Therefore, use this functionality wisely and only apply it to applications which contain very sensitive information / data for which you want to restrict / secure access.
• The user must have the Authenticator App enrolled and must use it for sign-in for resources which are secured in this manner. If the user didn’t enroll for the Authenticator App yet the user will be prompted to enroll the Authenticator App (otherwise access won’t be granted).
• The user will need to allow access to their GPS coordinates for the Authenticator-app. The app will request that access when the location is requested. Keep in mind that if you are thinking of a scenario in which you want to definitively block access, you are requiring/forcing the user to share this information. This might not be something everyone is on-board with from a privacy point of view.
• Preparing a Conditional Access rule and configuring the rule to the state ‘Report-only’ will still trigger that the GPS location needs to be shared via the Authenticator app as well. So be careful with this and only include users within a pilot which are informed upfront of this behavior!

Now you know what functionality is offered by GPS location-based sign-in let’s see which steps you need to take from a technical perspective to use this feature within your environment and how that looks from an end user perspective so you can drive the right adoption as well!

Step 1: Make the necessary configuration steps in Azure Active Directory

To make sure your users can use this new GPS feature as a Named Location from Conditional Access let’s start with the required steps. For that go to ‘Azure Active Directory’, click on ‘Security’ and hit ‘Named Locations’. Within the ‘Named Locations’ pane hit ‘+ Countries location’.

Give this new location a Friendly Name and make sure to select ‘Determine location by GPS coordinates (Preview)’. In the list of counties select the countries which you want to make a member of this named location (i.e. if your named location is called Europe, select all countries of Europe).

Once finished hit ‘Create’.

As you can see in the list of ‘Named locations’ the location has been added with location type ‘Countries (GPS)’ and doesn’t have the ‘trusted’ state as we do have with IP ranges (which is logical as we don’t want to trust a whole country 😊).

Now this new named location is created, it is there but it’s not used at all yet. Therefore, we need to go to Conditional Access which you can find under ‘Azure Active Directory’ and by going to the ‘Security’ blade. In here we are going to create a new Conditional Access rule, in this example I’m going to create a rule which will block the sign-in of the end user from the Netherlands based on the users GPS coordinates when using the Slack application.

Within the New Conditional Access Policy wizard give the policy a ‘Friendly Name’ and select a ‘user’ or a ‘group of users’ which you want to target with this policy.

In the ‘Cloud apps or actions’ select ‘Select apps’ and include the individual app(s) which you want to include within this conditional access rule, in my example we therefore use Slack.

NOTE: As Microsoft states within the docs, this functionality should only be used to protect very sensitive apps where this behavior is acceptable or where access needs to be restricted to a specific country or region.

Next step is to configure the ‘Conditions’ and to be more specific, the ‘Locations’ setting within conditions. In here make sure that ‘Configure’ is set to ‘Yes’, select ‘Selected locations’ and make sure the named location we just created is included.

As this rule is called ‘Block Sign-in from NL (GPS)’, make sure the ‘Grant’ settings are set to ‘Block access’.

Once all is configured, verify all the settings within the Conditional Access Policy, then make sure the policy state is set to ‘On’ and hit ‘Save’.

NOTE: If you configure the policy to the ‘Report-only’ state, users are still prompted within the Authenticator app to share their location via GPS so please be aware of this behavior.

Step 2: User experience for a user who is already using the Authenticator app

In this first example the user ‘johny.bravo@identity-man.eu’ was already using the Microsoft Authenticator App for the second factor approvals. So, the user will receive a prompt to approve his sign-in, however as shown below the user needs to share his location as well when going to the ‘Slack’ application for sign-in.

Within the authenticator app the user therefore must ‘Approve’ his sign-in.

In normal second factor behavior, hitting ‘Approve’ would be enough and the sign-in would be completed, however as we targeted this user with conditional access policy for which we need his GPS location, the Authenticator App is requesting the user to share this data. The user therefore must click ‘Continue’. If the user doesn’t click on ‘Continue’ the sign-in simply isn’t completed and the user is therefore blocked from accessing resources.

Once the user has clicked on ‘Continue’ the user is presented with three choices: ‘Allow Once’, ‘Allow While Using App’ or ‘Don’t Allow’. If users hit ‘Allow Once’ the user will be presented with the same prompt over and over again (which results in bad user experience if you would ask me). If the user hits ‘Allow While Using App’ the user only receives this prompt once and lastly, if the user hits ‘Don’t Allow’ the GPS can’t be shared and therefore the user will get an access denied notification as we can’t determine the users GPS location.

When the user did select ‘Allow While Using App’ the user is presented with another prompt asking if the user wants to have this setting retained to ‘Only while using’ the app or to change it to ‘Always Allow’.

IMPORTANT NOTE: It’s important here for the user to change this to ‘Always Allow’ as in the next 24 hours from the moment the user approved his sign-in and whereby the user is still accessing the resource, the device GPS location is shared silently once per hour. This can of course only be verified when the user did select ‘Always Allow’.

If all the steps above have been executed correctly the user will be blocked from signing into Slack while being in the Netherlands, as shown below.

We can also see this easily within the Conditional Access logs whereby we can see that sign-in state is ‘Failure’ and the Conditional Access State is ‘Failure’.

If you look at the basic info in one of these lines, we can see that ‘Access has been blocked by Conditional Access Policies’.

Once we than look in the location info we can see the user has shared their Authenticator App Location and is therefore matching the named location ‘Netherlands’.

And lastly, when we look in the Conditional Access info we can see that the ‘Block Sign-in from NL (GPS)’ policy is causing this Failure (which in our example is a good result, as we want to block a sign-in from the Netherlands in this example).

The configuration and example behavior for our test was now completed for a user who was already using the Authenticator App.

Step 3: User experience for a user who is NOT yet using the Authenticator app

Now let’s have a look at what happens for a user which isn’t using the authenticator app yet, for all applications except Slack the behavior won’t change, and in my example the user is still presented with a text challenge when accessing Exchange Online as shown in the example below.

However, when the user now goes to the Slack application the user will instantly be thrown a message stating, ‘More information required’.

When the user hits ‘Next’ the Authenticator app experience is launched and once completed this will be set to the new default method for the user as second factor.

From here the same experience applies for the next steps as explained above in Step 2 whereby in the end my sign-in to Slack is blocked (as I was still located in the Netherlands).

Considerations and summary

Added value summary

To conclude this blog post, using GPS via the Authenticator App as trusted location within Conditional Access is much more precise when it comes to the actual user’s location. Especially compared to using a trusted location based on IP, this as with VPN servers and IP Spoofing these can be bypassed rather easily wheras with GPS this becomes much more complex. Although spoofing of GPS-information is possible on mobile devices as well, this does add an additional layer of security to your environment. The same goes for the usage of Tor/Onion networks: No matter what type of “browser” is used, actual GPS location data is shared, which makes it harder to spoof.

Considerations (on privacy)

Although this functionality can add an additional layer of security, it also requires something from the user. You are requesting users to divulge their location, which some of your users may not be happy granting access to. You could consider adding an addendum to your usage agreement or Terms of Use stating that for specific apps this is required and that this information is handled carefully.

Always consider what you are asking your users and think about the scenario you are going for. For example: Do you need their location? If it is not available, would a compliant device or a low sign-in risk also be enough as a “fallback” or alternative?

Guidance

And again, keep in mind that when you are exploring to use this feature in your environment Microsoft does not recommend you to configure this functionality on ‘All cloud apps’ within Conditional Access, but specifically is referring today to use this functionality only to protect very sensitive applications.

In conclusion

I hope you again enjoyed reading my blog about this feature and stay tuned for some more new great features of the authenticator app in the future!

Blogs in this series:

• Nudging your users to the Microsoft Authenticator App for MFA
• Improving the Authenticator App enrollment experience for your end users
• Using GPS Coordinates from the Authenticator app to approve or block access.