Android Enterprise fully managed devices and the Google Play store

This week another post about an Android Enterprise configuration. Last week was related to company owned single-use (COSU) devices (also known as dedicated devices), while this week is related to company owned business only (COBO) devices (also known as fully managed devices). More specifically, about adding a personal touch to fully managed devices. Microsoft Intune doesn’t know the company owned personally enabled (COPE) devices, yet, but there is a feature within the fully managed devices configuration that can at least enable some more personal options to the user. That can be achieved with a simple configuration to allow access to all apps in the Google Play store. I’ll start this post with the configuration steps (and a little introduction) and I’ll end this post by having a look at the end-user experience.

Configuration

Let’s start with a quick introduction about the setting that should be configured and the impact of that setting. The setting Allow access to all apps in Google Play store must be set to Allow. Once it’s set to Allow, users get access to all apps in Google Play store. Apps can be sort of blocked by the administrator by assigning an uninstall of the apps to the user (or device). That will simply remove the app (over-and-over) again. When it’s set to Not configured, users are forced to only access the apps the administrator makes available (or required) via the Google Play store.

The following 3 steps walk through the process of creating a device restrictions policy that enables access to the Google Play store for users.

1 Open the Azure portal and navigate to Microsoft Intune > Device configuration > Profiles to open the Device configuration – Profiles blade;
2 On the Device configuration – Profiles blade, click Create profile to open the Create profile blade;
3a

AEFMD-CreateProfileOn the Create profile blade, provide the following information and click Create;

  • Name: Provide a valid name
  • Description: (Optional) Provide a valid description
  • Platform: Select Android Enterprise
  • Profile type: Select Device Owner > Device restrictions
  • Settings: See step 3b
3b On the Device restrictions blade, select Applications to open the Applications blade; and click OK to return to the Add configuration policy blade;
3c On the Applications blade, select Allow with Allow access to all apps in Google Play store and click OK and OK to return to the Create profile blade;
AEFMD-Applications

Note: This profile can be assigned to user and device groups.

End-user experience

Now let’s end this post by having a look at the end-user experience. Depending on the exact configuration the end-user can end up with one of the three scenarios as shown below.

  1. Below on the left is showing the Google Play store for the work account only, without access to all apps in the Google Play store.
  2. Below in the middle is showing the Google Play store for the work account only, with access to all apps in the Google Play store. Even though my store is in Dutch, the number of items in the menu, and the apps shown in the background, show the difference.
  3. Below on the right is showing the Google Play store for the work account when also a personal account is added (see the purple circle with a “P”). It provides the same options as shown in the middle, but also enables the user to switch between accounts.
Screenshot_20190729-172606_Google Play Store Screenshot_20190729-181300_Google Play Store Screenshot_20190724-210437_Google Play Store

The combination for the user to add a personal account to the device and being able to install apps via the Google Play store, will at least give the user some options to personalize the device.

More information

For more information about the device configuration options for Android Enterprise fully managed devices, please refer to the Device owner section in the documentation about Android Enterprise device settings to allow or restrict features using Intune.

Create a custom multi-app kiosk mode

This week is all about creating a custom multi-app kiosk mode for Android Enterprise dedicated devices. The Android Enterprise dedicated device settings also contains multi-app kiosk settings, but in some scenarios those settings can still be a little bit limiting. To create a multi-app kiosk mode, Microsoft Intune relies on the Managed Home Screen app. The fun part is that the Managed Home Screen app already contains a few more settings that are currently only available via app configuration policies. In this post I’ll start with a quick overview of the app configuration options that exist nowadays, followed by showing an app configuration example for the Managed Home Screen app to add a non-Managed Google Play Store app. Technically speaking I’ll add a single app, using the multi-app configuration option. Really adding multiple apps is more of the same. I’ll end this post by showing the end-user experience.

It’s important to keep in mind that the preferred and advised method to configure multi-app kiosk mode settings is still by using the dedicated device settings.

App configuration options

Let’s start this post by having a look at the app configuration options that are available nowadays. In the early days it was still required to manually configure configuration keys and values. These days Intune can prepopulate configuration keys that are available within the Android apps. Below is a quick overview of the 2 app configuration options that are available :

Configuration designer: The Configuration designer can be used to configure simple settings via the UI. It will automatically populate the available configuration keys within the app and allows the administrator to configure the simple configuration values. As long as the value type is not BundleArray
MSH-ConfigurationDesigner
JSON data: The JSON data can be used to configure all settings via a JSON template. The template will automatically populate the available configuration keys within the app and allows the administrator to configure all the configuration values.

MHS-JSONEditor

Configure the Managed Home Screen app

Now the app configuration options are clear. Let’s have a look at the app configuration of the Managed Home Screen app. As an example I want to use a setting that is only configurable via JSON data, as the value type is a BundleArray. That setting is to add (custom non-Managed Google Play Store) apps to the Managed Home Screen app. The following 3 steps walk through the process of creating an app configuration policy that enables the built-in Settings app to the multi-app kiosk mode.

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

MHS-AddConfigPolicyOn the Add configuration policy blade, provide the following information and click Add;

  • Name: Provide a valid name
  • Description: (Optional) Provide a valid description
  • Device enrollment type: Select Managed devices
  • Platform: Select Android
  • Associated app: See step 3b
  • Configuration settings: See step 3c
  • Permissions: See step 3d

Note: The main focus of this post is the configuration around the configuration settings (step 3c). That doesn’t mean that the permission configuration (step 3d) can’t be really useful when the app needs specific permissions. As it’s not the key part of this post, I won’t go into to much details for now.

3b

On the Associated app blade, select Managed Home Screen and click OK to return to the Add configuration policy blade;

Note: When the Managed Home Screen app is not available make sure that that the app is approved and synchronized with Intune.

3c

On the Configuration settings blade, select Enter JSON data with Configuration settings format. Now either click Download JSON template, for offline editing, or use the JSON editor to directly configured the required configuration keys. Before clicking on OK to return to the Add configuration policy blade, go through the following 3 steps (see also the screenshot below):

  1. Navigate to the applications configuration key to add the required apps for the custom multi-app kiosk mode. In my example, I add the Settings app (com.android.settings) to my multi-app kiosk mode. The valueString should be the app package name. To add another app simply copy the complete managedProperty and adjust the valueString.
  2. To be able to save the configuration, make sure to change all the values that need to be configured and still state something like STRING_VALUE. When a setting is not needed it can also be removed.
  3. The red areas on the scrollbar show the locations of values that must be adjusted or removed before the configuration can be saved.

Note: Make sure that the settings in the app configuration policy don’t overlap with settings in the dedicated device configuration.

MHS-JSONEditor-Config
3d On the Permissions blade, click Add to open the Add permissions blade. The Add permissions blade can be used select permissions that should be overridden. Select the required permissions and click OK to return to the Permissions blade and click OK to return to the Add configuration policy blade.

Note: At some point in time these configuration options will probably become available in the multi-app kiosk mode settings for dedicated devices.

End-user experience

Let’s end this post by having a look at the end-user experience. When the device is enrolled and the assigned apps are installed, the device will ask to select a home screen app (the message will actually show after the installation of the Managed Home Screen app). After selecting the Managed Home Screen app, the home screen will show as configured in the app configuration policy.

As shown on the right, I only get the Settings app (Instellingen is the Dutch version of Settings) as app on my home screen. That’s exactly what I wanted. Also, I configured a blue theme and I removed nearly all the other options from the end-user.

Note: The experience might be different from the configuration via the dedicated device settings. The main difference might be that in some cases the end-user might receive a message to configure a home screen app. So make sure to carefully test the end-user experience, to see if it matches the expectations.

Screenshot_20190721-195426

More information

For more information about configuring the Managed Home Screen app, please refer to the documentation about Configure the Microsoft Managed Home Screen app for Android Enterprise .

Android Enterprise fully managed devices and conditional access

This week is all about Android Enterprise fully managed devices. More specifically, the recently introduced functionality to use Android Enterprise fully managed devices in combination with conditional access. To support this functionality Microsoft introduced a new app, named Microsoft Intune app, and a new profile type for device compliancy policies for the Android Enterprise platform. Together these 2 features enable Android Enterprise fully managed devices to be registered as compliant device and to successfully work with conditional access. In this post I’ll provide some information about the Microsoft Intune app and I’ll show how to configure that app, followed by some information about the compliance policy for device owner scenarios and how to configure that policy. I’ll end this post by showing the end-user experience.

Keep in mind that Android Enterprise fully managed devices is still preview functionality. There are still scenarios that will not fully work at this moment. One of those scenarios is related to app protection policies. I specifically mention that scenario, as it can conflict with the scenario in this post. Apps with app protection policies assigned, will still prompt for the Company Portal app.

Microsoft Intune app

The first part in using Android Enterprise fully managed devices in combination with conditional access is the Microsoft Intune app. The Microsoft Intune app is a new modern and light-weight app that will enable the Company Portal app experiences for end-users on fully managed devices. That includes managing compliance for their device. Keep in mind that the Microsoft Intune app is only for the fully managed device scenario. As Android Enterprise fully managed devices require the Managed Google Play Store, the following 4 steps walk through the process of adding the Microsoft Intune app by using the Managed Google Play Store. After that the Microsoft Intune app can be assigned as any other app.

Keep in mind that after the May 2019 service roll out of Microsoft Intune, the Microsoft Intune app will automatically be added to the Intune admin console after connecting the tenant to managed Google Play.

1 Open the Azure portal and navigate to Microsoft Intune > Client apps > Apps to open the Client apps – Apps blade;
2 On the Client apps – Apps blade, click Add to open the Add app blade;
3a MIapp-AddAppOn the Add app blade, provide the following information and click Sync;

  • App type: Managed Google Play;
  • Managed Google Play: See step 3b – 3f;
3b On the Search managed Google Play blade, search for the Microsoft Intune app;
MIapp-SearchApp
3c On the Search managed Google Play blade, select the required app and click Approve to open a dialog box with app permissions;
MIapp-ApproveApp
3d

MIapp-ApproveAppDB01On the dialog box with app permissions, click Approve to continue to the selection about handling new app permissions;

Important: Keep in mind that this will accept these permissions on behalf of the organization.

3e

MIapp-ApproveAppDB02On the dialog box about handling new app permissions, select Keep approved when app requests new permissions and click Save to return to the Search managed Google Play blade;

Important: Keep in mind that this decision might impact the future app permissions and/or the future user experience.

3f On the Search managed Google Play blade, click OK;
MIapp-ApproveAppOK
4 Back on the Add app blade, click Sync;

Note: These steps will approve the app in the Managed Google Play store and sync the approved app in to Microsoft Intune..

Compliance policy for device owner

The second part in using Android Enterprise fully managed devices in combination with conditional access is the compliance policies. Since recently it’s possible to create compliance policies for fully managed devices. The list of available compliance settings is smaller than other platforms. The main reason for that is because those settings are only applicable to fully managed devices. And fully managed devices are, as the name already implies, fully managed. In other words, fully managed devices already follow strict configuration policies. The following 5 steps walk through the process of creating a device compliance policy for Android Enterprise fully managed devices. After configuring the device compliance policy assign it to a user group like any other device compliance policy.

1 Open the Azure portal and navigate to Microsoft Intune > Device compliance > Policies to open the Device compliance – Policies blade;
2 On the Device compliance – Policies blade, click Create Policy to open the Create Policy blade;
3a

AEfmd-CreatePolicyOn the Create Policy blade, provide the following information and click Create;

  • Name: Provide a valid name;
  • Description: (Optional) Provide a description;
  • Platform: Select Android Enterprise;
  • Profile type: Device owner
  • Settings: See step 3b and 3c;
  • Actions for noncompliance: Leave default (for this post);
  • Scope (Tags): Leave default (for this post);

Note: Configuring non-standard values for Actions for noncompliance and Scope (Tags), is out of scope for this post;

3b

AEfmd-DevicePropertiesOn the Device owner blade, select Device Properties to open the Device Properties blade. On the Device Properties blade, configure the required device properties and click OK to return to the Device owner blade;

3c AEfmd-SystemSecurityBack on the Device owner blade, select System Security to open the System Security blade. On the System Security blade, configure the required system security settings and click OK to return to the Device owner blade;
4 Back on the Device owner blade, click OK to return to the Create Policy;
5 Back on the Create Policy blade, click Create to create the policy.

Note: To take full advantage of this device compliance policy configuration, it must be used in combination with a conditional access policy that requires the device to be marked as compliant.

End-user experience

Now let’s end this post by looking at the end-user experience. Below, from left to right, is an overview of the different steps in the Microsoft Intune app to get a device from a noncompliant state to a compliant state. When the user has a noncompliant device state, the user can start the process by clicking on “You need to update settings on this device”. That will bring the user to the screen to setup access to resources. On that screen the user can simply continue. The next screen will show the user the settings that need to be updated and by clicking on a setting the user will receive information to resolve the issue. Once all the issues are resolved, the device state will switch to compliant.

AEfmd-Experience01 AEfmd-Experience02 AEfmd-Experience03
AEfmd-Experience04 AEfmd-Experience05

Note: Keep in mind that this is still preview functionality. When using app protection policies, the protected apps will still prompt for the installation of the Intune Company Portal app.

More information

For more information regarding the Microsoft Intune app and Android Enterprise fully managed devices, please refer to the following articles:

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:

The conditional access policy flow

This week is still all about conditional access. However, this week it’s not about a specific configuration. This week it’s about the conditional access policy flow. The flow that will help with determining if a conditional access policy is applicable to the user’s attempt to access a cloud app and if access will be allowed or blocked. The idea is similar to the What if tool. The big difference is that the What if tool does a technical check to see which conditional access policy is applicable and this flow can help with determining why a conditional access policy is applicable, or not. Also, almost as important, this flow will clearly show how many options are available to exclude specific users and devices. This is important to know, because if no conditional access policy is applicable, the user’s attempt to access a cloud app (which means company resources) will be allowed. The flow is shown below.

TheConditionalAccessFlow

Note: The sign-in risk condition is left out of this flow, as it requires Azure AD Identity Protection. The idea for that condition would be similar to the other conditions. Also, the session controls are left out of this flow. The idea for that control should be similar to other controls, except that this control will not directly block access as it will only provide a limited experience.

The main idea of this flow is to make it very clear that there can be many reasons for a conditional access policy to not be applicable (see all the yellow ovals in the flow above). The flow goes through the following conditions and controls:

  • Conditions (can be used to filter):
    • Users and groups: Required condition, which is captured in this flow with “Is the policy assigned to the user?”. This should be the result of the included and excluded user groups;
    • Cloud apps: Required condition, which is captured in this flow with “Is the policy assigned to the cloud app?”. This should be the result of the included and excluded cloud apps;
    • Sign-in risk: Condition not part of this flow (see note);
    • Device platforms: Optional condition (“Is the device platform condition enabled?”), which is captured in this flow with “Does the policy include the device platform?”. This should be the result of the included and excluded device platforms;
    • Locations: Optional condition (“Is the device locations condition enabled?”), which is captured in this flow with “Does the policy include the location?”. This should be the result of the included and excluded locations;
    • Client apps: Optional condition (“Is the client app condition enabled?”), which is captured in this flow with “Does the policy include the client app?”. This should be the result of the included and excluded client apps;
    • Device state: Optional condition (“Is the device state condition enabled?”), which is captured in this flow with “Does the policy include the device state?”. This should be the result of the included and excluded device states;
  • Controls (can be used to set an action)
    • Grant: Optional control that can be used to block or grant access, which is captured in this flow with “Does the policy grant access?”, and when used to grant access it must set requirements, which is captured in this flow with “Does the device and/or app meet the requirements?”.
    • Session: Control not part of this flow;

The main message of this flow is awareness. Be aware of which users and devices are excluded from the conditional access policy. Those users and devices should be assigned to separate conditional access policies, to make sure that the conditional access configuration creates a secure environment without any (unknown) backdoors.

More information

For more information about conditional access, please refer to the docs that are available here: https://docs.microsoft.com/en-us/intune/conditional-access

Conditional access and blocking downloads

This week is all about using conditional access for blocking downloads. I already did something similar before by using app enforced restrictions for Exchange Online and SharePoint Online. This time I’m going to take it one step further by looking at recently adjusted functionality for Conditional Access App Control. Conditional Access App Control enables administrators to control user sessions by redirecting the user through a reverse proxy instead of directly to the app. From then on, user requests and responses go through Cloud App Security rather than directly to the app. This creates an additional layer that can be used to filter actions. In this blog post I’ll start with a short introduction about Conditional Access App Control, followed by the configuration steps and the end-user experience.

Note: Cloud App Security can be licensed as part of EMS E5 or as a standalone service.

Introduction

Now let’s start with a short introduction about Conditional Access App Control. Conditional Access App Control uses a reverse proxy architecture and is directly integrated with conditional access. Conditional access enables administrators to route users to Cloud App Security, where data can be protected. That can be achieved by applying Conditional Access App Control session controls. That created route enables user app access and sessions to be monitored and controlled in real time, based on access and session policies in Cloud App Security. Those policies can also be used to further refine filters and set actions to be taken on a user. In other words, Conditional Access App Control enables administrators to control user sessions by redirecting the user through a reverse proxy instead of directly to the app.

Configuration

Let’s continue by having a look at the configuration options, by looking at a specific scenario. That scenario is blocking downloads on unmanaged devices, for any supported cloud app. The following seven steps walk through that scenario. After the creation of the conditional access policy, it can be assigned to a user group like any other conditional access policy.

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;
3a

CAS-UsersGroups-IncludeOn the New blade, 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 Exclude to open the Exclude tab;

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

3b

CAS-UsersGroups-ExcludeOn the Exclude tab, select Directory roles (preview) > Global administrator and click Done to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy will exclude global administrators.

4

CAS-CloudApps-IncludeOn the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, on the Include tab, select All cloud apps and click Done to return to the New blade;

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

5a

CAS-DeviceState-IncludeOn the New blade, select the Conditions assignment to open the Conditions blade. On the Conditions blade, select Device state (preview) to open the Device state (preview) blade. On the Device state (preview) blade, click Yes with Configure, on the Include tab, select All device state and and click Exclude to open the Exclude tab;;

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

5b

CAS-DeviceState-ExcludeOn the Exclude tab, select Device Hybrid Azure AD joined, select Device marked as compliant and click Done to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy will exclude managed and compliant devices.

6

CAS-Session-CAACOn the New blade, select the Session access control to open the Session blade. On the Session blade, select Use Conditional Access App Control, select Block downloads (preview) and click Select to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy will block downloads for the assigned users, from the assigned cloud apps, on unmanaged devices. The latest options within this configuration are the built-in options Monitor only and Block downloads, which are both still in preview and Use custom policy…. The latter option requires a custom policy within Cloud App Security. The other options two basically provide preconfigured options, of which Block downloads provides the behavior that I need for this scenario.

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

Note: Conditional Access App Control supports any SAML or Open ID Connect app that is configured with single sign-on in Azure AD, including these featured apps.

End-user experience

Now let’s end this blog post by having a look at the end-user experience. Below are example for the behavior with SharePoint Online and Exchange Online. I deliberately choose those apps, to show the difference in end-user experience compared to using app enforced restrictions (which I mentioned in the beginning of this post). The big difference is that app enforced restrictions are handled by the app, while this configuration is handled by Cloud App Security.

Below on the left is an example of the end-user accessing SharePoint Online on an unmanaged device. The end-user receives a clear message that the access is monitored. Below on the right is an example of the end-user trying to download a file from SharePoint Online, while being directed via Cloud App Security. The end-user receives a clear message that the download is blocked.

CAS-Example-SPO01 CAS-Example-SPO02

Below are similar examples for Exchange Online. On the left the message that the end-user receives when access Exchange Online on an unmanaged device and on the right the message that the end-user receives when trying to download an email attachment.

CAS-Example-EXO01 CAS-Example-EXO02

More information

For more information regarding Cloud App Security and conditional access, please refer to the following articles:

Easily managing Managed Google Play apps directly in Microsoft Intune

This week is all about the simplified experience for managing Managed Google Play apps directly in Microsoft Intune. The Managed Google Play store is used to deploy apps to devices managed via Android Enterprise. Before it was required to separately navigate to the Manage Google Play store to approve apps and after approval it was required to synchronize the approved apps with Microsoft Intune. Now the approval (and deletion) of Managed Google Play apps can be achieved by using Microsoft Intune only. Besides the better user experience, the fact that Google announced the deprecation of the device admin management API, means that it’s really time to look at the Managed Google Play store and apps and Android Enterprise in general.

In this post I will not look at Android Enterprise and the different deployment models. that might be something for another post, but I will look specifically at managing Managed Google Play apps. I’ll do that by quickly showing how to connect Microsoft Intune with Managed Google Play, followed by the steps and experience for adding and deleting Managed Google Play apps in Microsoft Intune.

Connect Microsoft Intune and Managed Google Play

The first configuration that should be in place, before any configuration related to Android Enterprise can be performed, is the connection between Microsoft Intune and Managed Google Play. The following three steps walk through connecting Microsoft Intune and Managed Google Play to enable managing Android Enterprise devices and deploying Managed Google Play apps. As this is not the main subject of this post, the steps describe the main actions.

1 Open the Azure portal and navigate to Microsoft Intune > Device enrollment > Android enrollment to open the Device enrollment – Android enrollment blade;
2 On the Device enrollment – Android enrollment blade, click Managed Google Play to open the Managed Google Play blade;
3

On the Managed Google Play blade, complete the following two steps:

  1. Select I agree with I grant Microsoft permission to send both user and device information to Google
  2. Click Launch Google to connect now and walk through the Google Play steps

Note: Connecting Microsoft Intune and Managed Google Play is required for managing Managed Google Play apps by using Microsoft Intune.

Add a Managed Google Play app

Once the connection between Microsoft Intune and Managed Google Play is configured, Microsoft Intune can be used for managing Managed Google Play apps. Even without the need to authenticate with every action regarding managing Managed Google Play apps. The following three steps walk through the process of adding a Managed Google Play app by using Microsoft Intune. I’m using the NBA app as an example and after adding the app, it can be assigned to a user and/or device group like any other app.

1 Open the Azure portal and navigate to Microsoft Intune > Client apps > Apps to open the Client apps – Apps blade;
2 On the Client apps – Apps blade, click Add to open the Add app blade;
3a

MGP-AddApp01On the Add app blade, provide the following information and click Sync;

  • App type: Managed Google Play;
  • Managed Google Play: See step 3b – 3f;
3b On the Search managed Google Play blade, search for the required app;
MGP-AddApp02
3c On the Search managed Google Play blade, select the required app and click Approve to open a dialog box with app permissions;
MGP-AddApp03
3d

MGP-AddApp04On the dialog box with app permissions, click Approve to continue to the selection about handling new app permissions;

Important: Keep in mind that this will accept these permissions on behalf of the organization.

3e

MGP-AddApp05On the dialog box about handling new app permissions, select Keep approved when app requests new permissions and click Save to return to the Search managed Google Play blade;

Important: Keep in mind that this decision might impact the future app permissions and/or the future user experience.

3f On the Search managed Google Play blade, click OK;
MGP-AddApp06

Note: These steps will approve the app in the Managed Google Play store and sync the approved app in to Microsoft Intune.

Delete a Managed Google Play app

Similar to adding Managed Google Play apps, these apps can now also be deleted by using Microsoft Intune. The following three steps walk through the process of deleting a Managed Google Play app by using Microsoft Intune. I’m using the NBA app as an example again.

1 Open the Azure portal and navigate to Microsoft Intune > Client apps > Apps to open the Client apps – Apps blade;
2 On the Client apps – Apps blade, search for the required app, select the three dots and click Delete to open an Are you sure? dialog box;
MGP-DeleteApp01
3 On the Are you sure? dialog box, click Yes;
MGP-DeleteApp02

Note: These steps will programmatically un-approve the app in the Managed Google Play store and sync the result to Microsoft Intune.

More information

For more information regarding managing Managed Google Play apps via Microsoft Intune, please refer to this article about Adding Managed Google Play apps to Android enterprise devices with Intune.

Block access to all cloud apps for unsupported platforms

This week something different compared to the last couple of weeks. This week is all about conditional access, but not about particular new functionality. This week I want to show a relatively simple method to make conditional access policies as secure and complete as possible. By using device platforms as an example, I want to show how to make sure that only device platforms supported by the IT organization can access company data. And really only those device platforms. In this post I’ll provide a short introduction of this method, followed by the related configurations. I’ll end this post by showing the end-user experience.

Introduction

Let’s start with a short introduction about this method to make sure that only specific device platforms, supported by the IT organization, can access company resources (with company resources I’m referring to all the cloud apps, used by the organization, that are integrated with Azure AD). When creating conditional access policies, it’s possible to apply the conditional access policies only to specific device platforms. However, that will make sure that the conditional access policies are not applicable to any other device platform. That might create a backdoor in the conditional access setup. To prevent this type of backdoors, it’s the best to use at least two conditional access policies:

  1. Block access: The block access conditional access policy is used to block access for all device platforms with the exclusion of specific device platforms supported by the IT organization;
  2. Grant access: The grant access conditional access policy is used to grant access for the device platforms, excluded from the block access policy, supported by the IT organization. This can also be multiple conditional policies, when it’s required to differentiate between device platforms.

Note: Similar constructions can be created for basically any configuration within a conditional access policy that can differentiate between include and exclude configurations.

Configuration

Now let’s continue by looking at the actual configuration. The configuration contains at least two conditional access policies, which are explained below.

Block configuration

The first and main configuration is the block access configuration. This conditional access policy will be used to make sure that device platforms, that are unsupported by the IT organization, are not allowed to access company resources. Simply follow the seven steps below.

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

CAB-UsersGroups-IncludeOn the New blade, 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 Exclude to open the Exclude tab;

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

3b

CAB-UsersGroups-ExcludeOn the Exclude tab, select Directory roles (preview) > Global administrator and click Done to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy will exclude global administrators. As global administrators should not be treated as normal users (to prevent a potential lock out) and usually have a separate conditional access policy applied.

4

CAB-CloudAppsOn the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, select All cloud apps and click Done to return to the New blade;

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

5a

CAB-DevicePlatforms-IncludeOn the New blade, select the Conditions assignment to open the Conditions blade. On the Conditions blade, select Device platforms to open the Device platforms blade. On the Device platforms blade, click Yes with Configure, on the Include tab, select All platforms (including unsupported) and click Exclude to open the Exclude blade;

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

5b

CAB-DevicePlatforms-ExcludeOn the Exclude tab, select Android, iOS and Windows and click Done to return to the Conditions blade. On the Conditions bade, click Done to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy will exclude specific device platforms that are supported by the IT organization and that will be covered with different conditional access policies. Keep in mind that every device platform that is excluded from this conditional access policy should be part of a separate conditional access policy (include).

6

CAB-Grant-BlockOn the New blade, select the Grant access control to open the Grant blade. On the Grant blade, select Block access and click Select to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy will block access for all device platforms that are not supported by the IT organization and that are not part of a separate conditional access policy (include).

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

Allow configuration

The second configuration is the allow access configuration. This conditional access policy (or conditional access policies) will be used to make sure that the device platforms, excluded from the block configuration and that are supported by the IT organization, are allowed access to company resources when those devices meet specific requirements. To configure a conditional access policy like this simply follow the seven steps below.

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

On the New blade, 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 Exclude to open the Exclude tab;

Explanation: This configuration will make sure that this conditional access policy is applicable to all users. Keep in mind that this can also be any user group that should be assigned, as long as in the end picture every user, using an excluded platform, is part of a conditional access policy. Also, when using Azure AD Sync it might be useful to exclude the service account, to enable the Azure AD synchronization.

3b

On the Exclude tab, select Directory roles (preview) > Global administrator and click Done to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy will exclude global administrators. As global administrators should not be treated as normal users (to prevent a potential lock out) and usually have a separate conditional access policy applied.

4

On the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, on the Include tab, select All cloud apps and click Done to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy is applicable to all connected cloud apps. Keep in mind that this can also be any specific cloud app that should be assigned, as long as in the end picture every cloud app, that can be accessed by an excluded platform, is part of a conditional access policy. Also, when assigning all cloud apps it might be useful to exclude the Microsoft Intune Enrollment app, to enable enrollment for the devices.

5

On the New blade, select the Conditions assignment to open the Conditions blade. On the Conditions blade, select Device platforms to open the Device platforms blade. On the Device platforms blade, click Yes with Configure, on the Include tab, select Select device platform and select Android, iOS and Windows and click Done to return to the Conditions blade. On the Conditions bade, click Done to return to the New blade;

Explanation: This configuration will make sure that this conditional access policy is applicable to all the earlier excluded device platforms. Keep in mind that this can also be any specific device platform, as long as in the end picture every device platform, that was initially excluded, is part of a conditional access policy.

6

On the New blade, select the Grant access control to open the Grant blade. On the Grant blade, select Grant access, select Require device to be marked as compliant and select Require Hybrid Azure AD joined device, select Require one of the selected controls 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 different device platforms, as long as the device meets the selected requirements. Keep in mind that this can be any of the available requirements.

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

Note: This configuration is not showing any screenshots as the screenshots are similar to the screenshots used within the block configuration.

End-user experience

Now let’s end this post by looking at the end-user experience. To make it a bit confusing, I’ll use a Windows 10 device to show the experience of a blocked user. Assuming Windows was not excluded by the block configuration, the end-user will receive a message similar to the message shown below. It doesn’t provide the end-user with the option to register the device, as the device is simply blocked.

CAB-Windows10

A good place to look for the end-result, from an administrator perspective, is to look at the sign-in information in the Azure portal (Azure Active Directory > Sign-ins). That will provide a failure message with a clear reason “Access has been blocked due to conditional access policies”.

CAB-Windows10-AAD

More information

For more information regarding conditional access, please refer to the following articles:

Configure email profile for the Outlook app

This week is all about configuring an email profile for the Outlook app. Actually preconfiguring an email profile for the users, making sure that the users only need to provide their password. Depending on the exact infrastructure, this can save a lot of (adaption) work in providing guidelines to the users. Some even want to look at this for preconfiguring an email profile for Exchange Online. I’m not that sure about that specific use case. Having said that, I do use that configuration as an example configuration. Simply because I’ve got that available in my lab. In this post I’ll show the available keys for configuring an email profile and I’ll show the configuration steps. I’ll end this post by showing the end-user experience, which will also show why I think that the added value for Exchange Online might be minimal.

Available keys and values

Let’s start by having a look at the available keys and values for configuring an email profile for the Outlook app. Below is an overview of the available keys, the value types, the default value, a short description of the accepted value and if the key is required. All the mentioned keys start with com.microsoft.outlook.EmailProfile.. I removed that prefix to make the table a bit more readable.

Key Value type Default value Accepted value Required
EmailAccountName String <blank> Display name Yes
EmailAddress String <blank> Email address Yes
EmailUPN String <blank> UPN or username Yes
ServerAuthentication String “Username and Password” Authentication method No
ServerHostName String <blank> Hostname Yes
AccountDomain String <blank> Domain name No
AccountType String BasicAuth Authentication model No

Note: Please don’t forget that all of these keys start with com.microsoft.outlook.EmailProfile..

Configuration

Now let’s continue by having a look at the configuration of the actual email profile. The following 7 steps walk through the configuration of the app configuration policy that configures an Exchange Online profile for the Outlook app on iOS.

1 Open the Azure portal and navigate to Intune > Client apps > App configuration policies;
2 On the client apps – App configuration policies blade, click Add to open the Add configuration policy blade;
3 On the Add configuration policy blade, provide a Name, select Managed devices with Device enrollment type, select iOS with Platform and select Associated app to open the Associated app blade;
4 On the Associated app blade, select Outlook and click OK to return to the Add configuration policy blade;
5 On Add configuration policy blade, select Configuration settings to open the Configuration settings blade;
6 On the Configuration settings blade, select Use configuration designer with Configuration settings format, provide the following information and click OK to return to the Add configuration policy blade;

com.microsoft.outlook.EmailProfile.EmailAccountName {{username}}
com.microsoft.outlook.EmailProfile.EmailAddress {{mail}}
com.microsoft.outlook.EmailProfile.EmailUPN    {{userprincipalname}}
com.microsoft.outlook.EmailProfile.ServerHostName https://outlook.office365.com/
com.microsoft.outlook.EmailProfile.AccountDomain petervanderwoude.nl

Note: The mentioned key and value pairs are sufficient to set the required settings for Office 365, including an additional setting to set a value to all configurable fields.

iOS-mail-app-configuration
7 On the Add configuration policy blade, click Add to add the app configuration policy.

Note: This configuration requires a managed device to apply the configuration to the app.

End-user experience

Let’s end this post with the end-user experience. Below on the left is the first screen of the Outlook app, after the app configuration policy is applied. This shows an Exchange configuration, even though this configuration will enable Exchange Online (Office 365). Basically every profile configured via these settings will be shown as an Exchange profile. Below on the right is the second screen of the Outlook app, after the user clicked on Add Account. It only requires the user to provide a password and to click on Sign-in. This also works in combination with a conditional access rule that blocks other clients (legacy authentication).

IMG_0149 IMG_0150

Note: As mentioned earlier, this email configuration prevents the user from typing the UPN. That makes it easier for the user. However, instead, it provides the user with a configuration screen that can be more confusing. A decision to make. I do see a big use case for Exchange on-premises infrastructure.

More information

For more information about configuring the Outlook app, refer to the following documentation:

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.