Back to Blog

Conditional Access to Exchange Online and Office 365

Image of Steve Goodman
Steve Goodman
Exchange Online and Conditional Access

Traditionally, restricting where and from which device users could access their Mailbox in Office 365 required substantial configuration within Active Directory Federation Services (ADFS), or more recently, relied heavily on registration of compatible devices within Intune.

However, there’s a range of functionality available within Azure Active Directory Premium, and Intune App Protection worth considering. Although Azure AD Premium has had Conditional Access functionality hidden away for some time, it’s recently become a lot more flexible.

What can you do with Azure Active Directory Conditional Access?

If you need to put restrictions on how and what users connect to in Office 365 and other services registered with Azure AD, you can use conditional access within Azure AD.

By configuring Azure AD conditional access, you can define the conditions that must be met before a user can access specific services. If a user and device matches the defined conditions, you specify the controls that will be used to enforce the policy, and then the applications they will access to.

Within Azure AD, you can define multiple policies to capture the requirements for users and devices. These might overlap—for example to enforce rules against the same users when they sign-in from domain-joined devices within your network or when they sign-in on a mobile device that is unmanaged.

The conditions may include group memberships, location, device platform, whether the device is lost or stolen, and factors such as sign-in and user risk (inherited from Azure AD identity protection).

You can then place specific controls against the user matching the conditions. These can include requiring multi-factor authentication, allowing or blocking access based on the location, or whether the device is domain-joined or Intune-managed.

Finally, you define which applications the conditional access policy applies to. This could be all Azure AD secured services, or specific applications. For example, you might allow a user to access Yammer on any device, but only allow access to Exchange Online from domain-joined or Intune managed devices.

What can you do with Intune App Protection Conditional Access policies?

Intune App Protection, otherwise known as Mobile Application Management (MAM), allows you to use conditional access policies to ensure that Office 365 services can only be accessed from specific Microsoft mobile applications.

This differs from Intune Mobile Device Management (MDM) which, by managing the entire mobile device, can have conditional access policies that allow for legacy built-in clients using services like Exchange ActiveSync.

Instead, Intune App Protection allows you to use conditional access policies for access to Exchange Online and SharePoint Online. Just like Azure AD conditional access, you define the groups or users who this applies to (and doesn’t apply to).

To access those services from a mobile device, users affected by these policies must install the Microsoft app, which will then benefit from being able to enforce protection policies to ensure that synchronized email or files are managed according to organizational policies.

When you configure Azure AD conditional access policies and Intune App Protection conditional access policies that apply to the same users and same devices, these are evaluated together.

Our Example Scenario

We’ll use a simple, common scenario to demonstrate how to configure both Azure AD Conditional Access policies and Intune App Protection Conditional Access policies.

Goodman Enterprises needs to ensure the following:

Windows PCs

All devices accessing Office 365 Exchange Online must be domain-joined, and if accessing the service from outside the network, must use multi-factor authentication.

Mobile Devices

All mobile devices can only use the official Outlook App on Android or iOS to access email. Data must not be shared outside of managed applications and must be encrypted. These do not need to be managed by a Mobile Device Management solution.

In our example scenario, we won’t be creating Azure AD conditional policies or Intune App Protection policies to restrict access to other services.

Before we get started...

Before we get started, we’ll need to ensure that users who are affected by implementing Conditional Access policies have the correct licences assigned. In this case, Azure AD Premium and Intune licences will be required. These are included within the Enterprise Mobility and Security (EMS) E3 plan.

We’ll also assume that mailboxes have been migrated to Office 365, running Outlook within mainstream support, and Azure AD Connect is installed and functional, including synchronization of domain-joined devices, with users in-scope for these policies assigned appropriate licenses and enabled for multi-factor authentication; for example, the Office 365 E3 plan and EMS E3 plan.

Because conditional access policies rely on Modern Authentication, we’ll also need to ensure this is enabled for Exchange Online. If you are configuring policies that affect services including SharePoint, you will need to disable access from legacy protocols.

For our iOS and Android users we will also need to ensure they use the Outlook App, available from each respective mobile app store. In addition, iOS users will need to install the Azure Authenticator app, and Android users will need to install the Intune Company Portal (though they won’t need to enrol their device with MDM).

Configuring Azure AD Conditional Access Policies

We will configure two conditional access policies, aimed at enforcing conditions depending on whether a Windows device is inside or outside of the corporate network:

  • Windows – On Network
  • Windows – Off Network

To do this, navigate to Select Azure Active Directory, then choose Conditional Access. First, we will configure the trusted networks that will determine if clients are on or off network.

05302017 Steve Goodman 01.png

Defining Trusted Networks

In the conditional access section of Azure AD, we’ll first need to define our trusted IP addresses. To do this, navigate to Named Locations, and then select Configure Trusted IPs:

05302017 Steve Goodman 02.png

The Azure AD multi-factor authentication settings page will open. Within the Service Settings tab, select Skip multi-factor authentication for requests from federated users on my intranet, then enter the IP addresses that clients appear to originate from. These will be the internet-facing IP addresses used by your router or proxy server, rather than the internal IP addresses of your local LAN:

05302017 Steve Goodman 03.png

Creating Our On-Network Policy for Windows Devices

With the trusted networks defined, we are ready to create our first conditional access policy. Navigate to Policies, then choose New Policy:

05302017 Steve Goodman 04.png

The new policy will be shown. First, enter an appropriate name, in this case Windows – On network, then scroll down and select Users and groups within the Assignments section. We can select either Azure AD Groups, Azure AD Users or in this case we will choose All Users:

05302017 Steve Goodman 05.png

If you are configuring this for the first time, consider selecting a specific user or group first to limit the effect of your policy before applying it to all users.

Next, we’ll define the applications that this applies to. In our case, we are not defining a policy that affects all of Office 365 services (although we could) and will choose Office 365 Exchange Online.

05302017 Steve Goodman 06.png

Under the Conditions heading we’ll first select Device Platforms to define the operating systems that this policy applies to. We can select Android, iOS, Windows Phone and Windows. As we want this to affect Windows PCs, we’ll select Windows:

05302017 Steve Goodman 07.png

To ensure that this policy applies to our on-network devices, we’ll select Locations and then within the Include tab, choose All trusted IPs:

05302017 Steve Goodman 09.png

Our final condition will include Client apps. We’ll select this and then choose both Browser and Mobile apps and desktop clients. This will ensure that both Outlook on the web and the desktop Outlook client will be included within the policy:

05302017 Steve Goodman 10.png

Finally, we will configure the Access Controls that this policy will use to allow access. For our on-network Windows devices, we’ll select Grant access and then check Require domain joined device:

05302017 Steve Goodman 11.png

We’ll then choose to save the policy.

Creating Our Off-Network Policy for Windows Devices

When creating the Windows – Off network policy we will select the same settings for Users and Groups and Cloud Apps to ensure that the policy affects the same users and service.

We’ll also, within Conditions select the same Device Platform, Windows; and select Browser and Mobile apps and desktop clients from within Client Apps.

Within Conditions, our only difference is when we configure Locations, the settings begin to differ. We’ll include All locations, then choose the Exclude tab to exclude All trusted IPs from our policy:

05302017 Steve Goodman 12.png

After configuring Users and groups and Conditions, we’ll then select the appropriate access controls for our off-network scenario. Within Access Controls, we’ll select Grant access then check both Require multi-factor authentication and Require domain joined device. We’ll also ensure Require all the selected controls is selected to make sure than both conditions are enforced together.

05302017 Steve Goodman 13.png

After saving our configuration, we should see two policies listed:

05302017 Steve Goodman 14.png

Configuring Intune App Protection Conditional Access policies

Intune App Protection allows us to control the Microsoft mobile apps when accessing data within our tenant. Additionally, we can restrict access to only these apps by configuring conditional access. For Exchange Online, this will prevent all access to ActiveSync by users within the policy. This overrules any Exchange quarantine policies for device access and is very effective for enforcing use of the Outlook App.

Although not essential, it is logical to create basic App polices for the Outlook App, and other apps we wish users to use. This allows us to ensure that data is encrypted within the apps, data cannot be transferred outside of the Microsoft apps, and implement a PIN for access to the app itself – along with other functionality.

Creating App Policies

We’ll begin by creating two policies: one for iOS devices like iPhones and iPads and another for Android devices. To do this, navigate to Intune App Protection within the Azure portal, select App Policy, then select Add a policy:

05302017 Steve Goodman 15.png

First, give the policy a name. Each policy can only be for one platform, including iOS, Android and Windows 10. We’ll therefore give each App Policy a corresponding name – in this example, iOS Outlook App Policy.

Next, after choosing the iOS platform, we’ll select Apps. We can then select the available iOS apps that can be managed by Intune App Protection, and in this example we will choose Outlook:

05302017 Steve Goodman 16.png

Before saving the policy, we will configure settings. Sensible defaults, such as require a PIN for access are enable by default, so in our example, we will configure additional settings to ensure data cannot be transferred out of applications that are not managed by an Intune App protection policy:

05302017 Steve Goodman 17.png

After saving the policy, and creating a similar Android App Policy, we should have two policies in place:

05302017 Steve Goodman 18.png

At this point, any user with the Outlook Apps installed should soon see the additional restrictions enforced by the app.

Configuring Conditional Access Policies

To ensure that users must use the Outlook App, we’ll navigate to the Conditional Access section of Intune App Protection and select Exchange Online:

05302017 Steve Goodman 19.png

First, we’ll define the Allowed apps, and choose to Allow apps that support Intune App policies:

05302017 Steve Goodman 20.png

Next, we’ll need to specify a specify Azure AD group that the conditional access policy will apply to within the Restricted user groups section. We can’t select All Users, and therefore we’ve select an Azure AD group that contains users that must be affected by this policy:

05302017 Steve Goodman 21.png

We also have the ability to exclude specific users from this policy. If this is required, select Exempt user groups, then add an Azure AD Group. This can be useful if you have a group containing All Staff but want to exclude one or two people without modifying their group membership of the All Staff group.

05302017 Steve Goodman 22.png

With this configuration in place, users must then go through a sign-in process to the Outlook App that will enforce Azure AD join of the mobile device. If users have been using the Outlook App on its own, they will at this point be prompted for re-authentication and to download either the Azure Authenticator app, or Intune Company Portal on iOS or Android devices respectively. ActiveSync users who are affected by the policy will be prevented from synchronizing, and provided a link to download the Outlook app.


In this article, we explored how relatively simple it is to use conditional access policies to restrict access to Exchange Online in our Office 365 tenant. You can use this functionality to create complex policies that apply to various scenarios you need to accommodate for your users, whilst still ensuring that you have control over where, how and from what users login to your Office 365 and Exchange Online environment.

Authentication Key

Conditional Access for Office 365

Image of Matthew Levy
Matthew Levy

Azure Active Directory Conditional Access has been around since 2016. Conditional Access governs...

Read more
modify client access rules

New Client Access Rules for Exchange Online

Image of Nathan O'Bryan MCSM
Nathan O'Bryan MCSM

There are many ways you can manage and control the way your end-users connect to Office 365....

Read more