In this video, Pete Zerger explains how you can implement location-based access requirements in your Azure AD conditional access strategy to increase security, while optimizing the user experience in Azure MFA scenarios.
- [Instructor] Now we're going to talk about location-based access requirements in the context of conditional access. Conditional access takes multi-factor authentication in Azure AD a step further by enabling us to create policies that evaluate the conditions surrounding an authentication request. Since these policies can be applied to groups, we can be selective in how and to whom we apply them. The location uses the location of the user at the time of login to trigger multi-factor authentication, or use block controls to simply deny access altogether, or even to implement other adaptive remediation actions, like a password reset.
The location is one of the five conditions of conditional access. Location awareness only comes with Azure AD Premium P1, and we can use location in conjunction with other factors, such as the platform the user is authenticating from, and the health of that device, the app that they're authenticating with, their group memberships, or even their sign-in risk, understanding that sign-in risk only comes with that P2 tier of Azure AD Premium and the identity protection feature.
For example, if a user is attempting to access the HR application from outside trusted corporate locations, we can enforce an additional MFA challenge, or even enforce that they're accessing the application from a healthy, managed device. Assuming you choose to enable location as a condition, we can configure location and conditional access in a couple of different ways. We can configure conditional access to trigger MFA for untrusted locations by excluding trusted IP ranges.
We can configure conditional access to trigger MFA for all locations. And bear in mind, if you don't exclude trusted locations, users will receive the second MFA challenge on every login, which is sure to be annoying when they're located at the office on a trusted device. So, to configure trusted locations, we can click on the all trusted locations link within our conditional access policy, or we can specify specific ranges. When we configure these over in the classic portal, we're configuring these to apply globally across all of our MFA events, and we can have up to 50 IP ranges.
The preferred way to handle this in conditional access, if we want to be granular in our application, is to use the named locations feature, which only appears in the conditional access settings. Here, I can provide a friendly name along with an IP range, or I can even upload a range of IPs from a text file. This is super handy if the network team maintains spreadsheets or databases of IP address ranges to site mappings. Unlike trusted IPs, which are applied globally, I can incorporate named locations selectively into my conditional access policies.
There are always exceptions to every rule, and today, not all apps support device health as a condition, such as some Office 365 online browser-based apps today. So, location plays an even more important role in these scenarios. In fact, Exchange ActiveSync is actually an exception, in that conditional access policies for MFA and location are not enforced for Exchange ActiveSync. Another great reason to get away from a legacy technology like ActiveSync.
So, just a note on impossible travel to atypical locations. The system has an initial learning period of 14 days, during which it learns a new user's typical sign-in behavior. During this time, it learns what normal means for a specific user. Your configuring trusted IP ranges increases the accuracy of this protection, giving the machine learning of the Microsoft Intelligent Security Graph additional context.
As you can see, location awareness and conditional access gives us a new level of granularity over trusted locations in MFA, enabling us to optimize that user experience.
In this course—the first in the series—Microsoft MVP Pete Zerger takes you through the basics of setting up endpoint protection. He begins by explaining how to set up Azure Active Directory Premium. Next, he goes into enabling multi-factor authentication, followed by setting conditions for secure access. To wrap up, Pete covers managing mobile devices with Intune, and publishing applications with Azure AD App Proxy.
- Setting up Azure Active Directory for an organization
- Enabling user-level and application-level multi-factor authentication
- Setting conditions for secure access
- Planning a mobile device management (MDM) strategy
- How Intune (standalone) MDM works
- How Intune mobile application management works
- Publishing applications with Azure AD App Proxy
- Assigning users and groups