Force Protected Apps or Devices | CA Scenarios for Success (3 of 4)

 

 

We are back today for part two of our four part series on conditional access scenarios for success. Today, we will discuss how to restrict resource access from mobile devices unless they are managed by Intune (and compliant) or using an approved application (like Outlook mobile). You may want to protect your corporate data, but also want to balance the experience that end-users have while using these protected resources. To do this, customers can leverage Conditional Access rules to go through and secure email access, but give end users a choice on which mail client they would like to use.

 

Many users love using the native applications on their mobile devices to access email, while others may be fine using Outlook mobile instead. We can allow users to access email in the application they want while staying secure. Regardless of the choice your end users make, IT can rest assured that they will be accessing mail in a secure way. In this scenario, your users have two choices:

• Use the native mail client, but enroll my device in to Microsoft Intune
• Use Outlook mobile with Intune App Protection policies applied to secure the corporate data

This scenario enables users to securely access corporate data from their mobile device while giving them options; IT achieves the sweet spot of securing corporate resource access in a way that promotes positive end-user experiences.

 

Scenario Requirements

This scenario is simple to fulfill- all it requires is setting up a conditional access policy. That's it!

• One Conditional Access policy
  • Policy: scoped to EXO/SPO, targets Mobile Apps and Desktop Clients for Modern Auth and Exchange ActiveSync, and requires devices be either Compliant or using the Approved Client App

With this single policy, we target both the modern auth and Exchange ActiveSync channel, ensuring that with either option a user chooses they will be protected (see  Additional Options on how to secure Office 365 for how to protect third party apps).  This gives end users the flexibility they are looking for, while ensuring that corporate data remains secure.

 

Configuration Steps

• Create the Conditional Access policy to require mobile devices either be enrolled or using an Approved App to access corporate data

 

 

Once enabled, this policy will do everything that you need in regards to setting this scenario up.

 

End User Experience

Let's take a look at how these policies impact the end user experience.

When a user tries to set up the native mail client on an iOS 11 device, they will see this message prompting them to enroll in to Intune:

 

 

Since this is a modern auth client, we stop them before they can even finish setting up the mailbox on the device. The experience differs a bit using the legacy EAS authentication channel, which allows the mailbox to be set up, but quarantines the device in EXO and prompts the user to enroll. That message looks like this:

 

 

So these are the two prompts your end users may get when you set this scenario up, so make sure that you provide some communications to them on what to expect if they are trying to use the native mail client on their device.

If users are using Outlook mobile, they will be prompted to set up the "broker" app on their device based on their device platform. On iOS devices, they will need to install the Microsoft Authenticator app; on Android, they will need to install the Company Portal (so if you are using Intune App Protection for Android today, end users should already have this installed). Part of this process of installing the broker app is also registering the device with Azure AD. The broker app becomes the manager for connections to Azure AD/Office 365 and is in charge of determining that the application trying to connect to cloud services is indeed an approved application. You can read more about this here: /en-us/intune/app-based-conditional-access-intune

 

Additional options to secure Office 365

We have also recently had the option arrive in Conditional Access to block legacy authentication. Until this was available, Conditional Access only worked with modern authentication and EAS clients. We can now block all traffic coming in to Office 365/Azure AD with Conditional Access (including Exchange Web Services, SMTP, POP, IMAP, etc). We strongly recommend you create a simple policy in Conditional Access to target "Other Clients" and block that traffic. This ensures that legacy mail clients using other connection options than modern auth or EAS will be blocked. You can read more about this new functionality here: https://cloudblogs.microsoft.com/enterprisemobility/2018/06/07/azure-ad-conditional-access-support-for-blocking-legacy-auth-is-in-public-preview/

 

In Review

Scenario Goal: Protect corporate data on mobile device while giving users a choice on how they want to use their mobile device

Scenario Scope: iOS/Android

Recommended when…

• Customers are concerned about protecting mobile access to Office 365
• There is an end-user population who uses the native applications today
• Customers want to provide options to end-users in how they access Office 365 data

In the next post of this series, we will shift our focus to how we can ensure users are accessing web content via the Managed Browser instead of the native device browsers. Have more questions about securing mobile device access to Office 365? Have you tried out these conditional access scenarios? Let us know in the comments below!

 

-Josh and Sarah