Why not to use ActiveSync rules to control access to Exchange Online

What are Allow/Block/Quarantine lists

Allow/Block/Quarantine (ABQ) lists have been available in Exchange Server since version 2010 and allow administrators to manage mobile ActiveSync device access based on specific type, product family or manufacturer. For example, we can set that only iPhone XS and Samsung S10 phones can connect to our Exchange server and all other devices to be blocked or the Exchange server can automatically quarantine them and the administrator will then later decide if the device is to be allowed or denied access. This is useful if we have purchased the above devices for our employees in bulk through a retail channel and do not want them to use different ones.

Especially using quarantine with manual “unblocking” of devices is still quite a popular process to manage devices when using on-prem Exchange server. For cloud-based Exchange Online we may encounter some disadvantages.

Why not to use ABQ lists

So what's the problem? It is not completely secure because the Exchange server trusts the information that the end device sends about itself. So the cell phone can report to us as the latest iPhone just unpacked from a beautiful white box but in fact it can be a malicious PC testing access to our emails via EAS with basic authentication (btw in October 2020 Microsoft will globally disable basic authentication when using ActiveSync to connect to Exchange Online).

To avoid the above, we can deploy conditional access through Azure AD and require device enrollment which will check the device thoroughly and give us more control over some of its settings. But here we have a hidden stumbling block. If a user is managed by a conditional access rule in Azure AD then the ABQ lists on the Exchange server are completely ignored - this is true even if the user has an exception set in the Azure AD rule, which is essential to know - it is common to apply conditional access to all users in AD and select exceptions (guests, external collaborators, employees with limited licenses, etc.). This is also indicated in the documentation for ABQ lists:

In practice, we have encountered cases where a client uses Azure AD to apply conditional access rules to all users and exempts external collaborators from them. Then he believes that the next buffer zone is the Exchange server where the ABQ rules are applied. Unfortunately, this is not the case, and the device is automatically allowed access - no matter that we are blocking unmanaged devices on the Exchange server - once a user is affected by conditional access in Azure AD in any way, which includes him being listed in an exception in a particular rule setting, then the ABQ rule on the Exchange server is completely ignored.

Of course, the above can be solved by setting conditional access rules not to all users but only to selected groups so that we do not have to set exceptions. But are you sure that you will cover all your AD users? I believe that the margin for error in the settings is not negligible in this case.

How to allow specific device types in Intune?

Well, we already know that ABQ rules are inappropriate when using conditional access. So how do you limit which device types can be enrolled to Intune for management? In case of iOS devices, we can limit the registration based on serial numbers. Unfortunately, in case of Android 10 phones and "fully managed Android Enterprise" enrolment, it is not possible. The enrolment requires a QR code that is one unique for the entire organization and is unchangeable. IT administrators have no choice but to enrol devices purchased through retail channel themselves and guard the QR code. This is a disadvantage, also it is not yet possible to manage Google’s Zero-touch deployment directly in Intune. We will see if Microsoft comes up with something in 2020 to allow the IT department to pass the enrolment procedure onto end users.