How to leverage Conditional Access policies to make MFA less annoying: Require only for unmanaged devices
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.
Comments (10)
What qualifies as being “Intune compliant”? Just full Intune MDM? Hopefully not, since based on your earlier description, it sounds like overkill for most.
It mentions Hybrid Azure AD join as the other way. I assume that excludes normal “Azure AD join.” Hybrid Azure AD join sounds like something not undertaken casually.
So, the barrier for entry of what you’re describing in this article may be high. I hope I’m wrong.
Great job on all these recent posts. I’m just catching up with them now, since I knew so many of them didn’t apply without AAD Premium. Ironically, a couple times you mentioned the new 50-seat option for non-profits, which we have now but which I only found accidentally this week when using the Admin portal.
Hybrid join is pretty easy and low impact. You can do it manually by bopping into the Settings > Accounts area on any Windows 10 device, or you can do it via Azure AD Connect for the whole domain. The Intune compliance thing is interesting. Even without specifying any MDM policy, you can register the device against MDM, and since there are no policies, it would technically be compliant. However, by far (if security is your numero uno goal), it would indeed be better to manage the devices with full blown MDM, and turn on conditional access (don’t allow access until they register). But again, that may not match up to your goals–in some cases it is necessary to pull out all the stops like this and strictly manage devices. If you want to have a good grasp on inventory of what is out there and connecting back into your resources, you would need something like this. It is not impossible to do with Exchange Online, since you can use a PowerShell script to dump all the mobile device info to do an audit when the fancy strikes you, but it isn’t going to be a nice as having the all devices inventory view in Intune, for instance. I will need to write an article that describes two different paths for device management–one using Intune and the other using other tools.
(I’ve been meaning to ask: any idea why Chrome and Chromium browsers render the font used in comments so extremely poorly? It’s almost like it’s subbing in one from Windows circa 1985).
That article would be appreciated, since it’s the linchpin of the whole scheme.. As can be seen here, there is some confusion out there on just the meaning of the Win10 ones alone:
https://social.technet.microsoft.com/Forums/en-US/e9c20049-bbf7-44e8-909d-f620f894e4a9/difference-between-azure-ad-join-and-registration
There are two ways of going about things in Settings->Accounts, only one of which is available to PCs joined to local AD (“registered” status via “Set up a work or school account”). For those not on AD, there’s that or “Join this device to AAD” available, the latter of which gets you “Azure AD joined” status.
It’s unclear which of those would suffice for the task given the specific mention of the third one, “Hybrid Azure AD join,” which requires Azure AD Connect.
https://docs.microsoft.com/en-us/azure/active-directory/devices/hybrid-azuread-join-managed-domains
Then there’s Mac devices and mobile to think about, since unfortunately, it’s not all Win10. We have one mobile device enrolled in stock MDM–with all the rest not there at all–and it’s listed as “Azure AD registered.”
Yes, inventory and all that would be nice (though I would never use remote wipe, which seems to be key for many), but the more hoops users have to jump through, the less likely it will be accepted. Hoops aren’t an issue for company Win10 PCs, which are setup for users, but for everything user-owned, mainly phones but sometimes laptops, it is.
Hi Alex
Great article but Im a little confused as to how the “authorised” users with “managed” devices would be able to get access to 365? This article suggests they would be completely excluded from the policy which would mean they would not be able to get any access. Is there therefore another policy for them?
Thanks
Antony Brookman
I do not follow the logic here, sorry. You would not exclude users. The policy would be for all users. The access control you are applying to all the users, is to require MFA. You can exclude the managed devices (MDM or Hybrid Joined). Meaning that if users sign in on an unmanaged device, MFA challenge happens. If they sign-in on either Intune compliant or Hybrid Joined device, this policy is not applied to them.
Hi Alex,
We use MobileIron as our MDM Provider. Also we apply MAM Policies to the Microsoft Apps via MobileIron and have them sync with the App Protection Policies, so that unmanaged devices need to open apps with a PIN and MobileIron managed devices without any PIN.
Does a device which is managed by MobileIron and having MAM config applied to its microsoft apps qualify as a managed device?
Thanks.
Conditional access defines managed device in one of two ways:
Device is hybrid Azure AD joined (Win 10 only)
Device is marked as compliant in Intune
The question is, why maintain a third-party MDM when you can have a one-stop shop where it’s all integrated?
Thanks for clarifying :)
At the moment we have to have certain apps and settings within MobileIron, but that’s a different story.
Eventually we will move to Intune, but that’s going to take a bit.
Thanks for the write up. Challenge I’m facing is we want company owned (Corporate) devices to be able to bypass MFA. We also have personal devices that we want to help configure and give access to resources but we want them to refresh and MFA every couple days. It seems like I should be able to have separate CA policies between Corporate and Personal devices that are both compliant.
Yes that is certainly possible. This article is a bit dated. I no longer make any exceptions for MFA. It is required period. As well, Azure AD has built-in algorithms that will challenge users at the appropriate times, so you do not have to force a refresh. If you want to you can of course, but it is not necessary, in my opinion.