Deploy: Native Exchange ActiveSync with Conditional Access and Intune while blocking legacy auth?

I’ve seen many companies struggle with EAS (Exchange ActiveSync) configuration, in relation how to adapt strong authentication and trusted devices approach for native mail clients. Thus I’d like to present three possible scenarios for EAS handling with Conditional Access/Intune mostly

Update: Microsoft will be initially deprecating basic auth for EAS, which some of the options presented below do rely. Efforts for Supporting non-modern auth activesync methods will be in vain once the deprecation is in effect

The options

1. Allow EAS go unchecked (not recommended)
2. Allow compliant (enrolled) native clients
3. Use only Outlook App / Don’t allow native clients (Using Approved Client App option in Conditional Access)
4. Mix of 2 and 3 with different policies

• Option 1. Not recommended (even without Intune)
• Option 2. Recommend to most who are unsure whether they can transition from Native mail clients to using Outlook app (Option 3), which gives the best control, if you’re considering having Outlook as managed application

• Its also worth mentioning, that IOS native mail client has supported modern authentication for a good while. Meaning, that If it’s you’re only client for Native Mail, you don’t need necessarily a separate policies for EAS
• For org’s without Conditional Access and Intune, there is less flexible, but similar option available to scenario 2 – Which I’ve addressed in another blog post (So no reason really for option 1

---

Before configuration guide, lets address these two strange sentences

• ”Apply only to supported platforms”
• ”Exchange ActiveSync currently does not support all the other conditions”

”Apply only to supported platforms”

The heading ”Apply only to supported platforms” is super confusing. From a security point of view I’d think that unsupported platforms would go past Conditional Access? (as they aren’t other clients, which we handle in another block policy)

It boils down to this:

”if you have chosen to block clients that aren’t supported by Intune, use the Apply policy only to supported platforms option”

See, when the device isn’t supported by Intune (thus unable to ever get the Compliant status for ActiveSync access) it won’t get past Conditional Access.

Unsupported clients (Linux and such) checked against what-if tool, indicate that they wouldn’t be then blocked. But all the guides, including the MS one rely on using the following policy option ’  Apply policy only to supported platforms’

---

https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/concept-sign-ins#filter-sign-in-activities

Exchange ActiveSync currently does not support all the other conditions

The supported conditions for Native Mail Apps Are

• In Users / Groups selection of specific users/groups, or all users (include and exclude both seem to apply)
• In Cloud Apps only Exchange Online is selected
• In Conditions: Apply only to supported platforms
• In Conditions – Client Apps only ActiveSync is selected (and in scope of this blog, and other recommendations it’s recommended to narrow it down to ’Apply policy only to supported platforms’
• In Access Controls only ’ Require device to be marked as compliant’ is the only supported condition

You may have varying mileage with other conditions, but I’d recommend sticking with recommendations in MS articles

---

Policy examples

• Exclude Exchange Online from other policies before configuring specific policies for it:

• In my example I haven’t specified mobile platform specific policies for ActiveSync, since the configuration options in ActiveSync are very limited. I don’t see thus much (or any value) of separating for example IOS and Android into their respective policies, unless you wan’t to define Block Policy for mobile platform (in this case bare in mind, that the platform selection is based often on User-Agents, meaning that if you really need to block mobile platform, ensure that the allowed mobile platforms are narrowed down also in protocol, apps and in Intune policies
• There is many ways to deal with service accounts with the following policies. I will be providing another post on how to deal with service accounts in Conditional Access, to keep this post tidy 🙂
  • Any way as a single mention is that, when you want to bypass certain account or action remember to narrow the bypass conditions so that for example the IP based bypass for a single service account is possible only for one application (meaning that Service account even in ”trusted location” won’t have any more access than the single app – unless specified otherwise.

EXO (Modern auth and browser clients)

EXO – Activesync (Compliant only)

General – Block ’Other Clients’

Note! you could possibly also use one of the built in baseline rules, as it doesn’t block EAS. I am opting for non-baseline policy because I may want to exclude some directory roles (service accounts) to another policy. The Policy also lists that it blocks the Native Android Mail Client, which I supported is still to some extent supported platform, and I want to maintain it in separate policy

Expected behaviour

1. Newly added devices will be quarantined in EXO
2. Client will receive mail prompting to enroll the company portal app
3. After enrollment phone will stay in the quarantine, while the compliance information is propagating
4. On success
   1. CA device info will display ”join type = Azure AD Registered”
   2. CA Policy for ’require compliant device’ result = Success
   3. Exchange display DeviceAccessState = Allowed, DeviceAccessStateReason = ExternallyManaged

Below is short the process shortly

Intune Configuration

Keywords for troubleshooting

EXO powershell Module

”DeviceAccessState : Quarantined”
”DeviceAccessStateReason : ExternalEnrollment”

During the enrollment the devices will stay in quarantine, until the enrollment is complete (device gets registered ID in AAD, and Azure AD displays Success for Conditional Access 

Once successful the states and reasons should be as following

”DeviceAccesState : Allowed”
”DeviceAccessStateReason : ExternallyManaged”

---

Company Portal App Android

”Company Access Setup is Incomplete”

”Email account Activation”

with Android devices even after successful enrollment and Conditional Access working as supposed (and with DeviceAccessState in EXO) – I suppose this is some bug for the enrollment not being able to display the status correctly (tested on Android 7xx and 8xx)

---

References

LINK to MS article regarding blocking legacy auth

https://docs.microsoft.com/en-us/intune/conditional-access-intune-reassign