Conditional access and requiring app protection policy

This week is focused on conditional access and the recently introduced grant control of Require app protection policy (preview). I already tweeted about it a couple of weeks a go, but I thought that it would be good to also write a little bit about this grant control. The Require app protection policy (preview) grant control could be seen as the successor of the Require approved client app grant control. The main difference is that the new Require app protection policy (preview) grant control will be more flexible. In this post I’ll start with a short introduction about this new grant control, followed by a configuration example. That example will be about a scenario for accessing Exchange Online. I’ll end this post by showing the end-user experience.

Introduction

Now let’s start with a short introduction about the Require app protection policy (preview) grant control. This grant control is not static and will be flexible as it will simply require that the user received an app protection policy for the app that is used for accessing the respective cloud app. That immediately checks a couple of boxes, as it will require the user to have an Intune license, it will require the user to receive app protection policies and it requires apps to be configured to receive an app protection policy. Besides that, this will also enables organizations to start using third-party apps and line-of-business apps in combination with conditional access. That should be a big advantage compared to the Require approved client app grant control.

There are also a couple of things keep in mind; the Require approved client app grant control only supports iOS and Android and the apps should be using the Intune App SDK. Also, at this moment, this grant control only applies to Microsoft OneDrive and Microsoft Outlook.

Configuration

Let’s continue by having a look at the configuration options, by looking at a simple scenario that is focused on the Require approved client app grant control. That scenario is requiring an app protection policy on any platform, for accessing Exchange Online. Not supported platforms should be blocked. The following seven steps walk through that scenario.

1 Open the Azure portal and navigate to Microsoft Intune > Conditional access > Policies or to Azure Active Directory > Conditional access > Policies to open the Conditional Access – Policies blade;
2 On the Conditional Access – Policies blade, click New policy to open the New blade;
3

RAPP-UsersGroupsOn the New blade, provide a unique name and select the Users and groups assignment to open the Users and groups blade. On the Users and groups blade,, on the Include tab, select All users and click Done to return to the New tab;

Explanation: This configuration will make sure that this conditional access policy is applicable to all users.

4

RAPP-CloudAppsOn the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, on the Include tab, select Select apps and click Select to open the Select blade. On the Select blade, select the Office 365 Exchange Online cloud app and click Done to return to Cloud apps blade and click Done to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy is only applicable to Exchange Online.

5

On the New blade, there is no need to select the Conditions assignment;

Explanation: This configuration will make sure that this conditional access policy is applicable to all platforms, locations, client apps and device states. That will also make sure that platforms, which are not supported by this grant control, will be blocked.

6

RAPP-GrantOn the New blade, select the Grant access control to open the Grant blade. On the Grant blade, select Grant access, select Require app protection policy (preview) and click Select to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy will grant access for the assigned users, to the assigned cloud apps, when using an app with app protection policy applied.

7 Open the New blade, select On with Enable policy and click Create;

Note: Keep in mind that the Require app protection policy control is still in preview.

End-user experience

Now let’s end this post by having a look at the end-user experience on an iOS device. Specifically in scenarios when the end-user will be blocked. When the end-user wants to configure their email in the native iOS mail app, the end-user will receive a notification as shown below. It basically explains the end-user that this app is not approved.

IMG_0026

When the end-user wants to configure their email in the Outlook app, but no app protection policy is assigned to the app, the end-user will receive a notifications as shown below. It simply explains the end-user that no app protection policy is applied.

IMG_0027

Note: Keep in mind that this is still a preview feature. In some of my test I would receive the (returning) message in the Outlook app, but I could still send and receive email.

More information

For more information regarding conditional access and requiring app protection policies, please refer to the following articles:

Remotely selective wipe WIP without enrollment devices

This week week a relatively short blog post about the ability to remotely selective wipe Windows Information Protection Without Enrollment (WIP-WE) devices. Almost two years ago I already wrote about app protection for Windows 10 (back than referred to as MAM-WE). That was the first piece of the without-enrollment-puzzle for Windows 10 devices. The second piece of that puzzle is just recently introduced, and is the subject of this post, which is the ability to remotely selective wipe those WIP-WE devices. In my opinion the third and yet still missing piece of that puzzle would be conditional access (require a managed app). Hopefully we can complete that puzzle soon. In this post I’ll show the remote action to selectively wipe a WIP-WE device, followed by pieces of the end-user experience.

Remote action

WIP-WE allows organizations to protect their corporate data on Windows 10 devices without the need for full MDM enrollment. Once documents are protected with a WIP-WE policy, the protected data can be remotely selectively wiped by a Microsoft Intune administrator. The following steps walk through the process of sending a remote wipe request to a Windows 10 device, to make sure that all protected corporate data will become unusable.

1 Open the Azure portal and navigate to Microsoft Intune > Client apps > App selective wipe to open the Client apps – App selective wipe blade;
2 On the Client apps – App selective wipe blade, click Create wipe request to open the Create wipe request blade;
3a

WIPWE-RequestOn Create wipe request blade, provide the following information and click Create:

  • User: See step 3b for more details;
  • Device: See step 3c for more details;
3b

WIPWE-UserOn the User blade, search for the specific user and click Select:

Note: This can be any user available in Azure AD.

3c

WIPWE-DeviceOn the Select Device blade, select the specific device(s) and click Select:

Note: This will only show the available devices for the selected user.

WIPWE-Success

Note: The permissions required to perform this wipe action, are Managed apps > Wipe.

End-user experience

Now let’s have a look at the end-user experience. I won’t go in to details about the min-enrollment that should be performed, as I’ve shown that before. What I do want to show is the name of the management account, below on the left, as that name is also displayed in the unenrollment message. Below on the right is the message that the end-user will receive once the remotely selective wipe is triggered. It will clearly show that the workplace account is removed. Personally I think that this message could use some adjustments to better explain the impact.

WIPWE-Enrolled WIPWE-Message

The unenrollment directly impacts the end-user experience. It doesn’t remove the locally saved corporate data, but it does revoke the encryption keys. That effectively removes the access to the locally saved corporate data. Below on the right is a locally saved corporate document, while the user is still enrolled. Below on the right is that locally saved corporate document, after being remotely selective wiped. Imagine how powerful this will become once we can require a managed device, or a managed app, in conditional access, for Windows 10 devices.

WIPWE-Encrypted WIPWE-EncryptedRevoked

Note: Make sure that the advanced setting Revoke encryption keys on unenroll is set to On. That’s the only way to actually revoke the access to the encrypted files.

More information

Fore more information regarding WIP, the current limitations of WIP and the creation of WIP-WE policies, please refer to the following articles:

Quick tip: Intune Diagnostics for App Protection Policies via about:intunehelp

This week a relatively short blog post about a feature that already exists for a long time, but that is not that known. That feature is the Intune Diagnostics for App Protection Policies (APP). The Intune Diagnostics can be really useful with troubleshooting APP. Especially when looking at APP for apps on unmanaged devices.  The Intune Diagnostics provides information about the device, provides the ability to collect logs and provides the ability to look at the applied APP for the different apps. The Intune Diagnostics can be accessed on iOS devices, by using the Intune Managed Browser or by using Microsoft Edge. In this post I’ll only look at the experience when with the Intune Diagnostics.

The experience

Let’s start at the beginning, which is to get to the Intune Diagnostics. This can be achieved by opening the Intune Managed Browser or Microsoft Edge and simply type about:intunehelp as the address. That will open the Intune Diagnostics page, as shown below. The Intune Diagnostics page contains two sections, 1) the Collect Intune Diagnostics section and 2) the Shared Device Information section. The first section can be used to collect logs of all Microsoft Intune managed apps and the second section provides information about the device and the managed apps.

IMG_0155

When clicking on the Get Started link in the Collect Intune Diagnostics section, it will open the Collect Intune Diagnostics page, as shown below. The Collect Intune Diagnostics page can be used to actually share the Microsoft Intune managed apps logs with an administrator (or with Microsoft), by simply clicking on the Share Logs link.

IMG_0156

When clicking View Intune App Status link in the Shared Device Information section, it will open the Intune App Status page, as shown below. The Intune App Status page can be used to actually look at the info about the installed managed apps. By selecting an app in the top of the page, it will show the currently applied policy (including information regarding the app version and the policy check-in). This can be really useful with for example verifying if the latest APP is applied.

IMG_0157

For simplifying the end-user experience, an app configuration policy can be used for the Intune Managed Browser and Microsoft Edge to add a bookmark. That can be achieved by using the following information:

  • key: com.microsoft.intune.mam.managedbrowser.bookmarks
  • value: Intune Diagnostic|about:intunehelp

More information

For more information about the Intune Diagnostics page, please refer to the following articles:

Block app access for unapproved device manufacturers or device models

This week is all about app protection. More specifically, this week is all about the just introduced capability to block app access for Android devices with unapproved device manufactures , or for iOS devices with unapproved device models. That capability actually has two separate actions to choose from, 1) block app access and 2) selective wipe of corporate data within the app. This capability will help with preventing access from untrusted devices to corporate data. Really useful, as we all can think of some low-end devices (loaded with malware, almost for free) that should not be used for accessing corporate data. In this post I’ll show the available configuration options, followed by the end-user experience.

Configuration

Now let’s start by having a look at the available configuration options. I’ll do that by walking through the steps for creating and configuring an app protection policy. These steps are shown below, with an extra focus on the policy settings (see step 5a and 5b). After the creation of the app protection policy, simply assign it the applicable user group.

1 Open the Azure portal and navigate to Intune > Mobile apps > App protection policies;
2 On the Mobile apps – App protection policies blade, click Add a policy to open the Add a policy blade;
3

On the Add a policy blade, select iOS or Android with Platform and select Yes with Target to all app types.

Note: The main configuration of this post can be used in combination with managed devices and unmanaged devices.

4 On the Add a policy blade, select Apps to open the Apps blade. On the Apps blade, select one or more apps from the list to associate them with the policy and click Select. Depending on the platform continue with step 5a, or step 5b;
5a

On the Add a policy blade, select Settings to open the Settings blade. On the Settings blade, and having iOS selected with Platform, navigate to Access Action and select Device model(s) on a new line as SETTING. As a VALUE specify the allowed models, select as ACTION to either Allow specified (Block non-specified) or Allow specified (Wipe non-specified) and click OK;

Note: The iOS model identifier can be found under the “Device Type” column in HockeyApp’s support documentation and to specify multiple allowed device models, use a semi-colon (;) to separate them.

MSIS-App-Protection-iOS
5b

On the Add a policy blade, select Settings to open the Settings blade. On the Settings blade, and having Android selected with Platform, navigate to Access Action and select Device manufacturer(s) on a new line as SETTING. As a VALUE specify the allowed manufacturers, select as ACTION to either Allow specified (Block non-specified) or Allow specified (Wipe non-specified) and click OK;

Note: To specify multiple allowed device manufacturers, use a semi-colon (;) to separate them.

MSIS-App-Protection-Android
6 On the Add a policy blade, click Create;

Note: On iOS devices, this feature requires the participation of applications (such as WXP, Outlook, Managed Browser, Yammer) to integrate the Intune APP SDK for this feature to be enforced with the targeted applications. On Android, this feature requires the latest Company Portal app.

End-user experience

Now let’s end this post by having a look at the end-user experience. I’ll do that by showing the end-user behavior on an iOS device. For experiencing the different messages, I made sure that my iPad would not be allowed. Below on the left is an example of the App Access Blocked message in the Outlook app, which clearly explains to the end-user that the iOS model is not allowed. Below on the right is an example of the Org Data Removal message in the Outlook app, which clearly explains to the end-user that the iOS model is not allowed and that associated data will be removed.

IMG_0139 IMG_0140

More information

For more information about blocking access for unapproved device vendors or models, refer to this article about Selectively wiping data using app protection policy access actions in Intune.

App protection policies and device management state

This week is all about creating some additional awareness for the capability of assigning app protection policies and differentiating between the management state of the devices of the user. Since recently it’s possible to assign app protection policies to either Intune managed devices or unmanaged devices. This can help with differentiating between Intune managed devices and unmanaged (MAM only) devices. For example, have more strict data loss prevention configurations for MAM only devices compared to MDM managed devices. In this post I’ll show the available configuration followed by results from an administrator perspective.

Configuration

Let’s start by having a look at the available configuration options. I’ll do that by walking through the steps for creating and configuring an app protection policy. These steps are shown below, with an extra focus on the targeted app types (see step 3a and 3b). After the creation of the app protection policy, simply assign it the applicable user group.

1 Open the Azure portal and navigate to Intune > Mobile apps > App protection policies;
2 On the Mobile apps – App protection policies blade, click Add a policy to open the Add a policy blade. Depending on the platform continue with step 3a, or step 3b;
3a

MAM-iOSOn the Add a policy blade, select iOS as Platform and select No with Target to all app types. This enables the App types selection. In the App types selection choose between Apps on unmanaged devices and Apps on Intune managed devices;

Note: This enables the administrator to differentiate between MAM only devices and MDM managed devices.

3b MAM-Android

On the Add a policy blade, select Android as Platform and select No with Target to all app types. This enables the App types selection. In the App types selection choose between Apps on unmanaged devices, Apps on Intune managed devices and Apps in Android Work Profile;

Note: This enables the administrator to differentiate between MAM only devices, MDM managed devices and MDM managed devices with Android Enterprise.

4 On the Add a policy blade, select Apps to open the Apps blade. On the Apps blade, select one or more apps from the list to associate them with the policy and click Select;
5 On the Add a policy blade, select Settings to open the Settings blade. On the Settings blade, configure the policy settings related to data relocation (data movement in and out apps) and access (access apps in work context) and click OK;
6 On the Add a policy blade, click Create;

Note: This post is focused on iOS and Android devices, but for Windows 10 it’s also possible to differentiate between devices with enrollment and devices without enrollment.

Result

Now let’s end this post by looking at the results of the configuration. There are many things to look at, but it will be hard to show the difference in behavior via screenshots. That’s why an overview of my policies is the easiest way to show the difference in policies. Below is an overview of the different platforms and the different management types.

MAM-Policy-Overview

More information

For more information about app protection polices in combination with device management state, please refer to this article How to create and assign app protection policies – Target app protection policies based on device management state.