How to leverage Conditional Access policies to make MFA less annoying: Require only for unmanaged devicesAlex Fields
Multi-factor authentication is something I strongly believe in and recommend to all of my customers. But no matter how much I harp on it, most of them don’t want to implement it, or they try it out, then beg me to roll back, because… well… it’s annoying. Users hate being prompted for a second factor–it means another step: a text message, an app code or push notification–something that requires them to take another action when entering their passwords. But there is good news: you can leverage conditional access to make this whole thing way less annoying.
I have previously blogged about Conditional Access policies on this site, which allow us to define a set of “conditions” or controls, which must be met before access can be granted to corporate resources. This feature is available in Azure AD Premium P1 and P2, and as part of the Enterprise Mobility & Security bundles E3 and E5 (this subscription is also bundled with Microsoft 365 Enterprise E3 and E5 plans).
In my previous post on this topic, I covered how to leverage the Trusted IP’s feature, to bypass multi-factor authentication (MFA) when the user signs in from a trusted location. But some users are always changing locations–especially sales folks who tend to travel a lot. In today’s demonstration, I want to show you how easy it is to require MFA, but only if the user is signing in from an untrusted or “unmanaged” device.
Step 1: Create a new policy
Find Conditional Access in the Azure AD admin center. Go to Policies > New policy.
Step 2: Included and excluded users
In this policy, I want All users included (but I will also have an admin account excluded, just in case I mess something up).
Now switch over to the Exclude section, and pick Users and groups. It is best practice not to apply new Conditional Access policies globally, as you could accidentally lock out all accounts, including admins, from accessing Azure AD or any applications in the cloud (for that matter, you might want to narrow the scope down to a smaller test group under Include also, until you know it is working). But at a minimum, exclude an admin account from this policy.
Step 3: Pick the apps
I am just applying this across the board, but you could choose to apply the rule only to specific apps such as Exchange Online, or SharePoint for instance.
Step 4: Choose Conditions
To scope this as wide as possible, I will select All platforms, and All locations. With regard to Client apps: MFA is not a supported access control for Exchange ActiveSync, so we cannot select that option here. We must make other provisions for EAS. Additionally, I usually like to block access to “Other clients” (meaning legacy apps that do not support Modern authentication). So accomplishing that is also a different policy–you need not select it here. Also, I generally recommend requiring MFA for all web browsers (more on that later), but that can be covered by another policy in either case. If you have another policy covering web browsers, you do not need to select it here, either (but you can if you feel comfortable excluding managed devices from MFA, even with web browsers). For now I will leave it selected.
The magic of this policy happens under what you will be excluding. So under Device state, choose Yes to Configure, then use the Exclude tab and select both Device Hybrid Azure AD joined and Device marked as compliant.
This means that any device that is either joined with Azure AD or enrolled with Intune (and compliant with Intune policies) will be excluded from the rule.
Step 5: Apply access controls
Now the goal is to challenge users with multi-factor authentication (but again, the exclusions we just applied in the step above will be exempt from the requirement). To accomplish this, simply choose Require multi-factor authentication and the option to Require one of the selected controls.
Step 6: Test it!
On an unmanaged device that is not joined to Azure AD, I should expect to see an MFA prompt when I log in. And… I do.
And there we go–now users will only be challenged for MFA on devices that are not already enrolled/managed by corporate IT. And this is a great thing: generally lost or stolen corporate IT devices would be reported as such, and then blocked/wiped remotely using Intune. If the device is not enrolled, you can rest assured that access will require the user to prove and then re-prove who they really are, raising your confidence level in those access requests.