Conditional access for Exchange Online to the max

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

ADFS_DenyOWAThe 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.

1

ExchangeOnlinePolicy_EASThe first component that I need to address is the Exchange Online Policy for conditional access. I don’t want Microsoft Intune to control the access for the Exchange ActiveSync apps with basic authentication, I want Exchange Online to take care of those apps. Within Exchange Online I’ve got the ability to easily block or allow access to specific device families and models. Microsoft Outlook is available as a device family.

To achieve that Microsoft Intune doesn’t control those apps, I need to make sure that the setting Block non-compliant devices on platforms supported by Microsoft Intune and the setting Block all other devices on platforms not supported by Microsoft Intune are disabled in the conditional access policy for Exchange Online.

2

EA_AccessSettingsThe second component that I need to address are the Exchange ActiveSync access settings. Within these settings I can define the default behavior of Exchange Online when a device isn’t managed by a rule or personal exemption. In this case I want to block access to all mobile devices that are not part of the rule that I will define.

To achieve that every device is blocked when it’s not managed by a rule, I need to configure the Exchange ActiveSync Access settings to Block access.

3

EA_DeviceAccessThe third component that I need to address is the Device Access Rule. With a rule like this I can define which device families and models are allowed, blocked or quarantined. In this case I want to allow access to all mobile devices that use Outlook to connect.

To achieve that all mobile devices that use Outlook are allowed, I need to create a Device Access Rule with the Outlook device family and for All models.

Note: It’s even possible to specifically select Outlook for iOS and Android as model, but at this moment that cannot be enforced.

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.

ADFS_DenySafariDefault 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”);

ADFS_DenyChrome

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:

Share

More in control of mobile app management without enrollment

Earlier this year I did my first post about the ability to use mobile app management without enrollment. This week I want to continue on that specific subject. The main trigger for that is  the app reporting ability that was added during the April update of Microsoft Intune. In this post I want to show how this new feature can help with being more in control of the usage of mobile app management policies for mobile app management without enrollment (also known as MDM-less MAM).

Wipe requests

Before showing the app reporting ability, to monitor the managed apps that are used by a user, I’ll start with a little information about wipe requests. Not only will that show the added value for managed apps, it’s also useful for adding information to the app reporting overview.

The real added value of a wipe request is when a device is lost or stolen, or when an employee leaves the company. At that moment a wipe request can be used to make sure that company app data is removed from the device.

To selectively remove company app data, follow the next 9 steps. Once the request is completed, the next time the app runs on the device, company data is removed from the app.

1 In the Azure portal navigate to Intune mobile application management > Settings to open the Settings blade;
2 Wipe_RRIn the Settings blade, click Wipe requests to open the Wipe requests blade;
3 In the Wipe requests blade, click New wipe request to open the New wipe request blade;
4 In the New wipe request blade, click Select the user to open the Select user blade;
5 In the Select user blade, select the specific user and click Select to return to the New wipe request blade. The users that are shown, are all the available users in the Azure AD. Not just licensed users, or targeted users;
6 Back in the New wipe request blade, click Select the device to open the Select device blade;
7 In the Select device blade, select the specific device and click Select to return to the New wipe request blade. The devices that are shown, are all the devices that are used by the selected user to access managed apps.
8 Back in the New wipe request blade, click OK to return to the Wipe requests blade. This will immediately sent the new wipe request, without asking for an additional verification;
9 The Wipe requests blade will now show a status overview of all the wipe requests that have been sent to the selected users and their devices, including the status of those wipe requests. The status will be either complete, or pending, and will be listed for every app that was used by the selected user on the selected device.

App reporting

After configuring mobile app configuration policies, or sending wipe requests, it’s possible to monitor the compliance status in the Azure portal. This includes information about the users affected by the policy, the compliance status, and any issues that end-users might be experiencing. Basically it allows the administrator to search for the compliance status for a specific user.

MAM_UserStatusIt actually already starts with an User status tile in the Intune mobile application management blade. That tile already shows a quick summary of the compliance status. It shows the total number of users within the company that uses apps associated with policies, it shows the number of users that are using apps in the company context (MANAGED BY POLICY) and it shows the number of users that are using the apps associated with policies, but are not targeted by the company policies (NO POLICY).

To use app reporting for a specific user, follow the next 5 steps.

1 In the Azure portal navigate to Intune mobile application management > Settings to open the Settings blade;
2 Users_ARbUIn the Settings blade, click Users to open the App reporting blade;
3 In the App reporting blade, click Select user to open the Select user blade;
4 In the Select user blade, select the specific user and click Select to return to the App reporting blade. The users that are shown, are all the available users in the Azure AD. Not just licensed users, or targeted users;
5 The App reporting blade will now show a clear overview of the selected user and the status of every app that is targeted at the selected user. The next paragraph includes a couple of clear examples.

Administrator reporting experience

Now it’s time to have a look at the experience for the administrator. More importantly, let’s have a look at what the app reporting capability will bring to the administrator. I will show what the administrator will see before and after sending a wipe request. Basically, the administrator will see one of the following 3 statuses for every app and device combination for the specific user.

  1. Not checked in – This means that the policy was deployed to the user, but the app has not been used in the company context since then;
  2. Checked in – This means that the policy was deployed to the user and the app has been used in company context at least once;
  3. Wipe pending – This means that the app has been used in company context at least once, but the administrator has sent a wipe request after that.
Before wipe request After wipe request
MAM_AppReporting MAM_WipeReporting

More information

For more information about sending wipe request and app reporting for mobile app management policies, please refer to the following articles:

Share

Frequently asked questions about mobile application management without enrollment

Last update: 08-04-2016

After my blog post a couple of weeks ago, I got many question related to mobile application management (MAM) without enrollment. That triggered me to create a quick frequently asked questions (FAQ) post. MAM without enrollment is online also referred to as MDM-less MAM, Azure MAM and sometimes even Intune MAM. As MDM-less MAM seems to be the most common used, and the shortest, I’ll start using that in this FAQ.

I’ll try to keep this FAQ as complete and up-to-date as possible. Just to be sure, I’ve added a last update date at the top of this post. That is the date that this content was reviewed the last. Also, if I’m missing some obvious question, please don’t hesitate to contact me and I will add them.

What is MDM-less MAM?

MDM-less MAM can protect company data with or without enrolling devices in a device management solution. It does this by implementing app-level policies, which can restrict access to company resources and keep data within the purview of the company.

Which platforms are supported by MDM-less MAM?

MDM-less MAM supports the following platforms:

  • iOS 8.1 and later;
  • Android 4 and later.

Which apps are supported by MDM-less MAM?

MDM-less MAM supports the following apps:

  • Microsoft Word for iOS;
  • Microsoft Excel for iOS;
  • Microsoft OneDrive for iOS and Android;
  • Microsoft OneNote for iOS;
  • Microsoft Outlook for iOS and Android;
  • Microsoft PowerPoint for iOS;
  • Microsoft Remote Dekstop for iOS and Android;
  • Microsoft Managed Browser for iOS and Android.

Which scenarios are supported by MDM-less MAM?

MDM-less MAM supports the following three scenarios:

  1. Devices that are managed and enrolled in Microsoft Intune;
  2. Devices that are managed and enrolled in a third-party solution;
  3. Devices that are not managed by any solution.

Which license do I need to have to use MDM-less MAM?

MDM-less MAM requires a Microsoft Intune license assigned to the end-user. A Microsoft Intune license is also included in an EMS license.

Where can I configure MDM-less MAM?

MDM-less MAM can be configured in the Azure portal.

Does MDM-less MAM affect personal accounts?

No. The restrictions of the MDM-less MAM policies only apply when the end-user signs into a supported app using a company account.

How can I disable the “Offline interval before app data is wiped (days)” MDM-less MAM policy setting?

This specific MDM-less MAM policy setting can be disabled by configuring a value of 0.

What happens when an end-user is targeted with MDM-less MAM policies and MDM MAM policies?

The end-user will be required to enroll the device. After enrollment the MDM-less MAM policies will take precedence in the supported apps.

Why do my end-users receive the message “Your company has required that you must first enable a device PIN to access this application”?

The end-user will receive this message when there is no device PIN configured and the MDM-less MAM policy requires encryption. Without a device PIN there is no use in encrypting the device.

Where can I find the TechNet documentation?

The TechNet documentation about MDM-less MAM is available here: https://technet.microsoft.com/en-us/library/mt627825.aspx

Share

Mobile application management without enrollment

At the end of last year Microsoft introduced the very nice feature of mobile application management without the requirement of device enrollment. What makes it even better is that it can also be used in combination with third-party mobile device management and it can be used in combination with Microsoft Intune mobile device management. In this blog post I’ll go through the configuration options, I’ll go through the configuration steps and I’ll go through the end-user experience.

Configuration in the Azure portal

Now let’s start with the configuration of this type mobile application management policies. The first difference, with the normal mobile application management policies, is that the configuration is done through the Azure portal. The rest of the configuration experience is also completely different. However, the configuration options are pretty similar.

Different configuration options

The mobile application management policies in the Azure portal, contain four different configuration parts. These four parts together are the targeted mobile application management policy. Let’s go through these four parts and see how they fit together.

1 iOSMAMPolicy_GenThe first configuration part is General. The General part is pretty straight forward, it has a required field for the Name of the mobile application management policy and an optional field for the Description of the mobile application management policy. This is the same or iOS and Android.
2

iOSMAMPolicy_UserGroupsThe second configuration part is User groups. The User groups part is normally the part that’s configured the last. It simply can’t be done earlier, as it’s basically the deployment of the mobile application management policy to the users. Every group available in the Azure AD can be selected here. This is the same for iOS and Android.

3 iOSMAMPolicy_TargetedAppsThe third configuration part is Targeted apps. The Targeted apps part is used to select the mobile apps that will be managed by the mobile application management policy. At this moment, only OneDrive is available for Android and OneDrive, Excel, PowerPoint and Word are available for iOS. In the near future this list will grow.
4

iOSMAMPolicy_PolicySettingsThe fourth configuration part is Policy settings. The Policy settings part is used to define the behavior of the mobile applications. This is divided in two categories of settings, Data relocation settings and Access settings. Data relocation settings are applicable to data movement in and out of the apps and Access settings determine how the end-user accesses the apps.

At this moment there are a few differences between the settings on Android and iOS. These differences are caused by simple fact that these two are completely different platforms. On Android it’s possible to configure Prevent Android backups, while on iOS it’s possible to configure Prevent iTunes and iCloud backups. On Android it’s possible to configure Block screen capture and Android Assistant, while on iOS it’s possible to configure Allow fingerprint instead of PIN.

All of the other settings are the same, or at least similar, for Android and iOS. Also, most of the settings are the same as the normal mobile application management policy settings. However, there is one additional, and very nice, setting. That’s the setting Offline interval (days) before app data is wiped. This allows the administrator to specify a number of days that a device can be offline before the company data is wiped. When the value is set to 0, this setting will be disabled.

Important: Only users that are member of the selected group AND have a Microsoft Intune license assigned, are affected by the mobile application management policy.

Basic steps

After getting familiar with the different configuration options, it’s time to look at the creation and the deployment of a mobile application management policy. The following twelve straight forward steps will guide anyone through the configuration and deployment.

1 In the Azure portal navigate to Intune mobile application management > Settings to open the Settings blade;
2 In the Settings blade, click App policy to open the App policy blade;
3 In the App policy blade, click Add a policy to open the Add a policy blade;
4 In the Add a policy blade, provide a Name for the policy, select the Platform and click Apps to open the Apps blade.
5 In the Apps blade, select at least one app and click Select to return to the Add a policy blade;
6 Back in the Add a policy blade, click Settings to open the Settings blade;
7 In the Settings blade, configure the Data relocation settings and the Access settings and click OK to return to the Add a policy blade;
8 Back in the Add a policy blade, click Create to create the policy and to return to the App policy blade;
9 Back in the App policy blade, click the <NewPolicy> to open the <NewPolicy> blade;
10 In the <NewPolicy> blade, click User groups to open the User groups blade;
11 In the User groups blade, click Add user group to open the Add user group blade;
12 In the Add user group blade, select an user group and click Select to save the changes and to return to the User groups blade.

End-user experience

Now it’s time to have a look at the end-user experience. When an end-user is targeted with a mobile application management policy and wants to use one of the configured apps, the end-user will get the messages below after providing company credentials. The first message will show after the initial configuration and the second message will show after removing the configuration again.

Initial configuration Removal configuration
IMG_0007 IMG_0009

More information

For more information about mobile application management, the supported apps and even more, please refer to:

Share