A common Conditional Access policy is to add trusted locations as an exception to multi-factor authorisation requirements. The logic goes, if you accessing resources such as Office 365 from a location such as the corporate office, that’s an element of verification in itself that your login should be trusted, so we should improve your user experience by removing MFA. Personally, I support the use of MFA regardless of where you are authenticating (at the very least, if you have an Azure AD admin role assigned). However, doing something like this is a great option if you are introducing MFA from scratch: you will improve user buy in the less you change their standard experience. Then, increase the scope gradually.
Recently, I was asked how to bypass MFA if accessing from a trusted location, just like described above, but also only on managed devices. Managed devices refer to those that have some kind of IT control over them. In the realm of Microsoft 365, Azure AD, and Conditional Access, this specifically means devices that are Intune MDM enrolled and meet our compliance policy, or Hybrid Azure AD Joined (HAADJ). Adding this additional requirement to the MFA bypass goal removes a few weaknesses, such as personal devices using the company Wi-Fi.
However, it’s not as simple as you may think due to the way the logical operators work.
Conditions are like a big checklist of criteria an authentication session has to meet in order to be controlled by the policy: operating system, location, risk level, app/protocol, etc. The session must meet all the criteria you set up, but we can also add exclusions. If one exclusion is applicable, that means the remainder of the checklist doesn’t matter: the policy isn’t applicable.
For example, you may start to build a CA policy that enforces MFA then excludes trusted locations and managed devices – makes sense, right? The problem here is in the way the logic works: as soon as one exclusion criteria is met, the inclusions are not enough. You’re not saying exclude the device when it’s both managed and in a trusted location, you’re saying if it’s either.
The way around this particular requirement is two policies; one for each location boundary. Conditional Access policies, if more than one qualify for a session, are applied together in the most restrictive way. You can set these up like this:
Policy 1 – Trusted Locations
This policy will be applied if a user is in a trusted location, but not if they’re on a managed device.
- Conditions
- Locations
- Include: trusted locations
- Device state
- Exclude: compliant and HAADJ
- Locations
- Access controls
- Grant
- MFA
- Grant
Policy 2 – Untrusted Locations
This policy will be applied if a user isn’t in a trusted location.
- Conditions
- Locations
- Include: any locations
- Exclude: trusted locations
- Locations
- Access controls
- Grant
- MFA
- Grant
Policy 1 only applies to unmanaged devices in trusted locations. This does the job of making our managed devices in trusted locations not need MFA. But what about those same devices in untrusted locations? For that, we need a second policy, which scoops up any untrusted location logins and enforces MFA.
Hopefully, this explains a little more about how exclusions for conditions work in Conditional Access. You want to keep your policy number as low as possible for manageability, but if you have a requirement such as this, you will have to add in additional rules to cater for those exclusions.
Remember that trusted locations are based on IP range, so best as accurate as you can with the IPs that you manage, and don’t introduce an MFA bypass like this on a whim: can you really trust a connection just because it comes from a known IP or device?
