Intune: How On-Premise Exchange Conditional Access Can Work

Overview

When controlling access to Exchange email, there are generally two ways to go about it:

  • You can allow all devices and then block them after evaluating them.
  • You can block/quarantine all devices and then allow them after evaluating them.

The second option is more secure because access to email is not granted until the user’s device is deemed compliant.┬áBoth options are enforced through Exchange Activesync Settings, commonly known as ABQ:

How are these concepts implemented in Intune? Well, although there are multiple ways to go about this, Microsoft has documented their suggested process. Let’s cover those steps.

Steps 1-3: Getting Blocked

According to Microsoft, the suggested method is to actually become quarantined/blocked on purpose. When that happens, an EAS record will be created in Intune automatically, and the Exchange server will send a notification to the user. This notification can be customized to include steps on how to enroll the device into Intune for management. Below is what the automated email could look like.

Steps 4-8: Enrollment

After getting the blocked email and following the customized instructions, the user will then be able to go through the enrollment process. For iOS and Android devices, that means downloading the Intune Company Portal app, and then authenticating with an Azure AD Account that has an Intune license applied to it. Once the user’s subscription is verified, a trust will be established between the device and the Intune servers. Once the trust is established, then the device is managed by Intune. On the backend, Intune will take the already-blocked EAS record, and merge it with a now-compliant MDM record.

Steps 9-10: Exchange Conditional Access

Intune will check all enrolled devices on a timed interval, and allow any that are compliant to access email. The interval is around 15 minutes supposedly, but this information is not made public. In order to allow a device, Intune connects to the on-premise Exchange servers via Intune Exchange Connector. Once the connection is established, powershell cmdlets are run to mark the EAS device ID as “allowed” and thus able to access Exchange email.

Alternative process

Although above is the process that Microsoft has documented, note that it is not the only way to implement access control in a corporate environment. Another process would be to have users enroll before being blocked. That way, they never get a “blocked” email, which can be confusing to some. Once enrolled and compliant, the Intune Exchange Connector can allow the EAS ID, and the user will be able to access email on their mobile device.

Intune: If Migrating, Don’t Worry About Those EAS Records

If you have an existing MDM solution and are migrating devices over to Intune, you might notice some EAS records being created. These will be viewable as devices, even if the user did not enroll them into Intune. Sometimes, you’ll see these EAS records being created in Intune for users that have never even installed Company Portal! What is going on here?

The answer can be found in Microsoft’s KB about Intune Conditional Access:

The Intune Exchange connector pulls in all the Exchange Active Sync (EAS) records that exist at the Exchange server so Intune can take these EAS records and map them to Intune device records. These records are devices enrolled and recognized by Intune. This process allows or blocks e-mail access.

In other words, the Intune Exchange Connector actively reads the account information of active users, and if any ActivesyncIDs are detected, Intune automatically creates a record for that ID. This happens even if the device has never touched Intune! So if you are migrating users from one MDM environment to Intune (with the Exchange Connector configured), you will most likely see these “ghost” EAS records.

If you are confused because you don’t have conditional access enabled, you aren’t alone. The thing is, this behavior will happen even if conditional access is turned off! Being “disabled” apparently doesn’t mean “completely disabled” to Microsoft.

As long as your conditional access is not enabled though, you don’t need to stress too much:

  • These “ghost” EAS records will only be created for users that have an Intune license associated with their Azure AD account. So plan out your license distribution carefully.
  • If you don’t have conditional access turned on yet, these EAS records will have no impact to the user. Further note on this, you can even delete these records with no impact, but note that Intune will just re-create them again upon another scan.
  • If the user enrolls the EAS device into Intune, it will merge the MDM and EAS records together (provided that the UPN of the user is the same too).