Intune and Exchange ActiveSync (Part 6)

If you would like to read the other parts in this article series please go to:

Conditional Access

So far, amongst several other things, we have seen how to enroll mobile devices in Intune and how to use Exchange ActiveSync (EAS) to manage mobile devices that have not been enrolled with Intune. But what if we only want to allow enrolled devices to use EAS? How do we force users with non-enrolled devices that try to configure ActiveSync to enroll them? Note that we are not trying to block EAS, but rather force users to enroll their device in order to use ActiveSync.

Intune’s Conditional Access feature is the answer. This feature enables Intune tenants to restrict EAS access to Exchange to only those users who have enrolled their devices for management. This is crucial for many organizations that want to enable a Bring Your Own Device (BYOD) strategy and where protecting data on mobile devices is essential. By requiring that only managed and compliant devices be allowed to synchronize email, organizations can provide an extra layer of protection.

Conditional Access can be used to secure email, and other services depending on conditions we specify, and restrict access to:

  • Exchange On-premises and Online;
  • Microsoft Office 365 Dedicated;
  • SharePoint Online.

EAS clients attempting to access mail in Exchange Online will be evaluated for two basic properties:

  1. Is the device managed and registered with Azure AD?
  2. Is the device compliant?

To get to this state, the device will need to enroll with Intune, perform an operation called workplace join (which on most platforms happens automatically with enrollment), and be evaluated for device policy. These states are written by Intune into Azure AD and then read by Exchange the next time the EAS client tries to get email. If the device is not registered, the user will get a message in their inbox with instructions on how to do this (which we will shortly see). If the device is not compliant, the user will get a different message in their inbox that redirects them to the Intune web portal where they can get information on the compliance problem as well as how to remediate it.

To implement conditional access, we configure two policy types in Intune:

  • Compliance Policies, which we already looked at, are optionally deployed to users and devices to define the rules and settings that the device must comply with in order to be allowed access to services. These rules include passcode, encryption, whether the device is jailbroken or rooted, and whether email on the device is managed by an Intune policy. If a compliance policy is not deployed, then the conditional access policy will treat the device as compliant;
  • Conditional Access Policies are configured for a particular service, and define rules such as which Azure AD security groups or Intune groups will be targeted and how devices that cannot enroll with Intune will be managed.

Unlike other Intune policies, we do not deploy conditional access policies. Instead, we configure these once, and they apply to all managed devices.

A typical flow for conditional access (taken from TechNet) might look as follows:

Image
Figure 1

The requirements for conditional access depend if we want to use it with Exchange Online or Exchange on-premises. For Exchange Online, the following is required/supported:

  • Windows 8.1 and later (enrolled);
  • Windows Phone 8.1 and later;
  • iOS 6.0 and later;
  • Android 4.2 and later;
  • The connector is not required to use compliance policies or conditional access policies, but is required to run reports that help evaluate the impact of conditional access. However, if we want to use conditional access for both Exchange Online and Exchange on-premises, we cannot configure the service to service connector.

As to Exchange on-premises and Office 365 Dedicated, the following is required/supported:

  • Windows 8 and later (enrolled);
  • Windows Phone 8 and later;
  • iOS devices that use Exchange ActiveSync (EAS) email clients;
  • Exchange 2010 and later;
  • Exchange ActiveSync can be configured with certificate based authentication or user credential;
  • The on-premises Exchange connector connects Intune to Exchange on-premises and lets us manage devices through the Intune console.

Compliance Policy

Now that we know what is required, let us start by creating and deploying a Compliance Policy and then a Conditional Access Policy. A Compliance Policy defines what it means for a device to be compliant in order to access Exchange. Intune will determine whether a device meets these criteria and will then set a property in Azure AD which is then used by Exchange. These are separate from Configuration Policies (security settings and resource access profiles) in order to make it clear as to what rules will actually result in a user getting blocked from their email.

A Compliance Policy can require that a device have a passcode, encryption enabled, not be jailbroken/rooted, and to have an email profile managed by Intune. If a device is capable of remediating a setting, it will. However, if auto-remediation is not possible, then the device will be marked as not compliant and it will be blocked from Exchange until the user remediates the issue.

Compliance Policies support the following device types:

Device type

PIN or password configuration

Device encryption

Jailbroken/rooted device

Email profile

Windows 8.1 and later

Remediated

N/A

N/A

N/A

Windows Phone 8.1 and later

Remediated

Remediated

N/A

N/A

iOS 6.0 and later

Remediated

Remediated (by setting PIN)

Quarantined (not a setting)

Quarantined

Android 4.0 and later

Quarantined

Quarantined

Quarantined (not a setting)

N/A

Samsung KNOX Standard 4.0 and later

Quarantined

Quarantined

Quarantined (not a setting)

N/A

Remediated – compliance is enforced by the device operating system (for example, the user is forced to set a PIN). There is never a case when the setting will be noncompliant.

Quarantined – the platform does not enforce compliance (for example, Android devices do not force the user to encrypt the device). In this case, the device will be quarantined until the policy becomes compliant.

To create a Compliance Policy follow these steps:

  1. In the Microsoft Intune administration console, click POLICY > Compliance Policies > Add;
  2. On the Create Policy page, configure the following settings as required:

Image
Figure 2

  1. Click Save Policy and when asked to deploy the policy click Yes:

Image
Figure 3

  1. Select the group(s) you want this policy to apply to and click OK:

Image
Figure 4

Evaluate the impact of the conditional access policy

After the Exchange Connector is successfully configured, it identifies devices that are not managed by Intune, and that connect to your organization’s Exchange resources. You can then use the Mobile Device Inventory Reports to discover which devices in your organization will be blocked from accessing Exchange when you configure the conditional access policy. In the report parameters, select the group you want to evaluate and, if required, the device platforms to which you will restrict the policy.

After you run the report, examine the Management Channel column, which displays one of the following values:

  • Managed by Exchange ActiveSync – The device is accessing Exchange, but is not managed by Intune
  • Managed by Microsoft Intune – The device is managed by Intune, but is not accessing Exchange
  • Managed by Microsoft Intune and Exchange ActiveSync – The device is both managed by Intune and is accessing Exchange

When a device is a member of a group to which a conditional access policy is targeted, devices that display Managed by Exchange ActiveSync will be blocked.

Image
Figure 5

To inform the users of these devices before you deploy the policy:

  1. Export the results of the report
  2. In Excel, filter for devices that are managed by Exchange ActiveSync
  3. Retrieve the users email address from the Email Address column

Conclusion

In this part of this article series we started exploring Intune’s Conditional Access feature. In the next part we will conclude it and look at the experience from a user’s perspective.

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top