"It's Not You, It's Me"How to exclude ActiveSync from Azure MFA when using Office 365 Exchange Online
If you are planning to deploy Azure MFA you probably already know that you need to ‘deal’ with ActiveSync and the challenge that it brings to an MFA deployment.
As George Costanza would say: “It’s not you, it’s me!”
It’s not Azure MFA’s fault, it’s actually ActiveSync’s. ActiveSync is an older protocol that does not support modern authentication which is required for multi-factor authentication flow. No multi-factor authentication system can support it.
The dilemma is that basically all smartphones use ActiveSync for the default email client when connecting to an Exchange mailbox.
The common answer is just don’t allow ActiveSync, and there is some merit to that as it is not as secure and there is limited control you can have over native mail clients on smartphones but that is a discussion for another blog… In this scenario, you would block ActiveSync and only allow an email client that supports modern authentication such as the Outlook App. This is a more secure and fully manageable application and would be the recommended approach from a security perspective.
That being said, if you do not want to go that route then you need one of the following workarounds:
Use the App Password.
Microsoft has come up with an alternative solution to the “don’t allow ActiveSync” option.
Microsoft’s workaround is called an App Password. This is a special system generated password that a user can create in their Azure AD Security portal that would be used with an application that only supports legacy authentication such as our friend ActiveSync. This password would be used instead of the user’s regular password and would satisfy the MFA requirement.
While this method works, it tends to be a bit challenging as the process is not very intuitive. For one, the password prompt dialog doesn’t specify that it is looking for the App Password so very often a user will continuously try their regular password until:
- They lock their account
- The lightbulb goes off and they realize it wants the App Password and hopefully, they have it handy or know how to login to the security portal and create a new one
- They open a support case
Or even worse, since this password is not generated by the user and is a random string, it is more prone to being jotted down on a sticky note or saved in an insecure text file somewhere which negates any positive security measures that are being put in place.
Only require Azure MFA for applications that support modern authentication and bypass it for applications that don’t.
Typically when you are rolling out MFA, you would just enable it for a user in the MFA portal. At that point, any access attempt made by that user for any application will require MFA (or an app password for legacy apps). This is the standard deployment scenario.
The alternative approach is rather than categorically require MFA for a user, we create a conditional access policy that requires MFA for applications that support modern authentication (cloud apps) for the user. This essentially will exclude apps that do not support modern authentication from requiring MFA.
This can be accomplished by:
- Don’t enable MFA for the user in the MFA portal.
- Create a conditional access policy with the following attributes:Assignments
- Include users in the scope of your test
- Include all cloud apps
- Include any location. Note that here is where you can exclude an IP whitelist created in the MFA portal by clicking on the exclude tab and selecting ‘MFA Trusted IPs’
- Grant access
- Require multi-factor authentication
What this accomplishes is:
- If an application identifies itself as supporting modern authentication… we will require MFA.
- If an application does not identify itself as supporting modern authentication… we will not require MFA.
It should be noted again that this approach is less secure and would also allow other legacy clients such as older versions of Outlook (prior to 2016) to bypass MFA.
MDS recommends hardening your security posture by enforcing a managed application, however, if allowing ActiveSync without using an App Password is a requirement of your organization, then this is how you can accomplish it.