This week I want to show another look at conditional for Exchange Online. I want to do that by providing a scenario. That scenario will cover more than just conditional access. Mainly because conditional access simply blocks access to non-compliant devices, but what if I want to take it one step further? What if I also want to prevent potential data leakage? In that case I can’t just look at conditional access. In that case I also need to add mobile app management to the playing field. This post will address those subjects for Exchange Online.
Scenario
Now lets start with the scenario that I want to cover. Even though I know that I will use Microsoft Intune and related technologies to do the configuration, I want the scenario to describe functional requirements. The configuration should address the following requirements:
- Email access is only allowed on managed and compliant devices;
- Email data leakage must be prevented on managed and compliant devices;
- Email access is available via the browser;
- Email access is supported on iOS, Android and Windows 10.
Configuration
Now lets have a look at what I need to configure to address that scenario. The good news is that I can support this scenario with Microsoft Intune. However, the default configuration is not sufficient. I need to get creative. To address this scenario I need to make sure that email access is only available through browsers and apps that can be managed by mobile app management (MAM) policies or by Enterprise Data Protection (EDP)/ Windows Information Protection (WIP). No back doors allowed. That means that to address this scenario I need to add the following technical configurations on top of the standard conditional access and MAM (and WIP):
- The OWA app for iOS and Android must be blocked;
- ActiveSync apps that use basic authentication must be blocked;
- The default browsers on iOS and Android must be blocked.
Block the OWA app
The first thing that I want to configure is a deny for the Microsoft OWA app. That specific app bypasses every form of conditional access. Luckily that doesn’t mean that there is nothing that I can do to block the app. I can use AD FS to deny specific client user agent claims for the Microsoft OWA app.
The following example claim will deny every active claim that arrives via the AD FS proxy with a client user agent that contains MOWAHost. That should be distinctive enough to only deny the Microsoft OWA app. However, keep in mind that the Microsoft OWA app will only be blocked once it tries to verify the credentials.
Claim |
exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”]) && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path”, Value == “/adfs/services/trust/2005/usernamemixed”]) && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “MOWAHost”]) => issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”); |
Block Exchange ActiveSync apps with basic authentication
The second thing I want to configure is a deny on every Exchange ActiveSync app with basic authentication, like the default mail app on iOS and Android. Those apps are aware of conditional access, but can’t work with MAM (and WIP) policies. In other words, those apps can still leak data. The combination of the following three components allows me to only allow the Microsoft Outlook app, which is capable of working with MAM policies, on mobile devices.
Block default browsers on iOS and Android
The third thing that I want to configure is a deny on the default browsers on iOS (Safari) and Android (Chrome). Those browsers are aware of conditional access, but can’t work with MAM (and WIP) policies. In other words, those browsers can still leak data. Luckily that doesn’t mean that there is nothing that I can do to block those browsers.
Default browser iOS (Safari)
I can use AD FS to deny specific client user agent claims for the Safari browser. However, the Safari browser is tricky. There are many, many apps and browsers that use client user agent claims that include a reference to Safari. That isn’t only applicable to iOS, but also to Android and Windows.
The following example claim will deny every passive claim that arrives via the AD FS proxy with a client user agent that contains Safari, but doesn’t contain Windows or Android. That should be distinctive enough to deny the Safari browser on iOS devices.
Claim |
exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”]) && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path”, Value == “/adfs/ls/”]) && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “Safari/”]) && NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “Windows|Android”]) => issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”); |
Default browser Android (Chrome)
I can also use AD FS to deny specific client user agent claims for the Chrome browser. However, the Chrome browser is also tricky. There are many, many apps and browsers that use client user agent claims that include a reference to Chrome. That isn’t only applicable to Android, but also to iOS and Windows.
The following example claim will deny every passive claim that arrives via the AD FS proxy with a client user agent that contains Chrome and Android, but doesn’t contain PKeyAuth or ManagedBrowser. That should be distinctive enough to deny the Chrome browser on Android devices.
Claim |
exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”]) && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path”, Value == “/adfs/ls/”]) && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “Chrome/”]) && exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “Android”]) && NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “PKeyAuth|ManagedBrowser|Windows”]) => issue(Type = “http://schemas.microsoft.com/authorization/claims/deny”, Value = “true”); |
Result
The result is awesome, in my personal opinion. I’ve successfully tested this configurations on iOS, Android and Windows 10 devices with multiple browsers and apps. This configuration, in combination with conditional access and MAM (and WIP), provides the following results:
- Email access is only available on managed and compliant iOS and Android devices via the Managed Browser and on managed and compliant Windows 10 devices via Internet Explorer and Microsoft Edge. These browsers can be managed via MAM and WIP to prevent data leakage. Other browsers will be blocked by conditional access, or AD FS;
- Email access is only available on managed and compliant iOS and Android devices via the Microsoft Outlook app on managed and compliant Windows 10 devices via Outlook. These apps can be managed via MAM and WIP to prevent data leakage. Other apps will be blocked by Exchange Online;
- Known back doors are closed. The OWA app will be blocked by AD FS.
More information
Fore more information about conditional access for Exchange Online and mobile app management, please refer to:
- Restrict email access to Exchange Online and new Exchange Online Dedicated with Intune: https://docs.microsoft.com/en-us/intune/deploy-use/restrict-access-to-exchange-online-with-microsoft-intune
- Protect app data using mobile app management policies with Microsoft Intune: https://docs.microsoft.com/en-us/intune/deploy-use/protect-app-data-using-mobile-app-management-policies-with-microsoft-intune
- Manage email access in System Center Configuration Manager: https://technet.microsoft.com/en-us/library/mt629504.aspx
- Protect apps using mobile application management policies in System Center Configuration Manager: https://technet.microsoft.com/en-us/library/mt613194.aspx
- Enforcing Outlook App in Exchange Online and Intune Conditional Access: https://blog.kloud.com.au/2016/04/29/enforcing-outlook-app-with-exchange-online-with-intune-conditional-access/
Discover more from All about Microsoft Intune
Subscribe to get the latest posts sent to your email.
He Peter,
I think you need to edit the Android user agent string a bit, as Microsoft has Android + Chrome stated both on a Windows Phone device in Edge.
Claim from W10 Mobile (slow ring latest update)
http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path
/adfs/ls/
http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent
Mozilla/5.0 (Windows Phone 10.0; Android 6.0.1; WebView/3.0; Microsoft; Lumia 950) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.79 Mobile Safari/537.36 Edge/14.14393
I think it should add Windows or Edge to it to be able to login with Windows Phone.
&& NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent”, Value =~ “PKeyAuth|ManagedBrowser|Windows”])
Hi Nils,
You’re correct! Not sure how I’ve missed that, but I’ll adjust the client user agent string in the post.
Thank you,
Peter
Im confused in my Intune tenant in Conditional Access Exchange Online I did not had the Windows Mobile option am I missing something? I use Intune Standalone
Hi Filip,
Are you referring to the Windows option? If so, that’s still in preview and is available via this connect program: https://connect.microsoft.com/ConfigurationManagervnext/CABWPC2
Regards,
Peter
Hi Peter,
Where in ADFS do I create the claim rule? Is this on the relying party and which tab? And what kind of rules are they, transform, passthrough?
Hi Filip,
Yes, these claims are issuance authorization rules on the Microsoft Office 365 Identity Platform relying party trust.
Peter
Hi Peter,
Do you know if there is a way to restrict Exchange access by times? For example, we only want hourly people to have access to email between 8AM and 6PM M-F. Is there any way to currently configure that?
Thanks,
Keith
If I’m not mistaken there are examples on the web on doing something like that on Exchange. However, as I’m not an Exchange expert, I can’t say if that’s a good practice or not.
Peter, if we want to allow non-enrolled (not managed) mobile device to access email via outlook app only, we can still follow the above instruction by selecting conditional access rule “Specific platform” and unchecked IOS/Android?
Hi Anna,
As long as the user is not targeted with the conditional access policy, the user can still use the normal channels for connecting to email.
Peter
I tried using Exchange Online settings to block native email client and also disabled the option you mentioned in the Intune console but I am able to access native email on Android and iOS. Is something has changed recently or am I missing something?
Keep in mind that it includes creating a default rule in Exchange Online to block access and an access rule that only allows the Outlook app.
Hey Peter, when setting this Exchange active sync to block, does this block ALL machines? by all machines, I mean, the regular users who use company laptops or desktops. Will they also be blocked by this policy? Or is this policy only enforced on mobile devices, and if so, what is meant by mobile devices?
You can excluded users and/or devices from being targeted by the conditional access policies.
Hi Peter,
I am trying to figure out if there is a way of accessing archive mailbox from a mobile device without using the OWA app? I know the archive mailbox is not supported with Exchange ActiveSync, so I need to find a different way of doing it but I also need to prevent potential data leakage.
Thanks
Sha
Hi Sha,
I’m sorry, but I can’t help you with that question as I simply don’t know. However, if you do find the answer, please don’t hesitate to post the answer.
Peter
Hey Peter great article. Here is the issue I am having. I have a 365 Hybrid tenant with Conditional Access policies in place. The conditions require Hybrid domain joined, multifactor etc. We continue to have machines that are not registered able to still access email in Outlook. They cannot from browser, that is intended. Any idea how we can block outlook on non domain joined?
Thanks!
Hi Joel,
Which version of Outlook are those devices running?
Regards, Peter