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.

Default device compliance status

This week I’m going to look at the recent introduction of the feature to configure the default compliance state for devices when no compliance policies are targeted. This enables additional security for all devices, as it enables administrators to mark devices as non compliant when no compliance policies are targeted to the device. In this post I’ll start with a short introduction about this security feature, followed by a walk through the configuration. I’ll end this post by looking at the end-user experience.

Introduction

As should be known by now, compliance policies are basically rules, such as requiring a device PIN, or requiring encryption. These device compliance policies define rules and settings that a device must follow to be considered compliant. The recently introduced security feature enables administrators to determine the default compliance state of devices when no compliance policies are targeted. The default state (for new tenants) is that devices are marked as compliant. From a security perspective it can be required to switch this to non complaint, as this will make sure that all devices that have access are actually compliant with the company requirements.

Configuration

Let’s have a look at the required configuration. This configuration is actually quite simple. To make sure that the default compliance status is switched to non compliant, simply follow the next 3 steps.

1 Open the Azure portal and navigate to Intune > Device compliance to open the Device compliance blade;
2 On the Device compliance blade, click Compliance policy settings to open the Device compliance – Compliance policy settings blade;
3 DC_SettingsOn the Device compliance – Compliance policy settings blade, click Non Compliant with Mark devices with no compliance policy assigned as;

Note: Compliant means the security feature is off and Non Compliant means that the security feature on.

End-user experience

Now let’s end this post by having a look at the end-user experience on the different platforms. The first platform is Windows 10. In a co-management configuration the compliance state can be seen in the Company Portal app and Software Center. So I’ll show them both. Below on the left is an example of Software Center and below on the right is an example of the Company Portal app.

NoCompliancePolicy01 NoCompliancePolicy02

The next platforms are iOS and Android. Nothing too fancy for these platforms. Below on the left is an example of the Company Portal app (latest update) on iOS and below on the right is an example of the Company Portal app on Android.

20180411_182037518_iOS Screenshot_20180411-205045_Company Portal

More information

For more information about compliance policies and Microsoft Intune, refer to this article named Get started with device compliance policies in Intune.

Notify end-user about non-compliant device

This week is all about device compliance policies. Well, actually it’s all about what actions can be triggered for non-compliant devices. Since recently it’s possible to configure actions for non-compliance. Previously the action for non-compliant devices was that the device would be marked as non-compliant. That action is still configured by default, but it’s now also possible to configure additional end-user notifications. In this blog post I’ll provide a short introduction to the actions for non-compliant devices, followed by the required configurations. I’ll end this post with the end-user experience.

Introduction

Let’s start with a short introduction. Device compliance policies now contains configuration properties for the configuration of Actions for noncompliance. The Actions for noncompliance allows administrators to configure a time-ordered sequence of actions that are applied to devices that don’t meet the device compliance policy criteria. By default, when a device does not meet the device compliance policy, Intune immediately marks it as non-compliant. The Actions for noncompliance gives administrators more flexibility to decide what to do when a device is non-compliant. There are two types of actions:

  • Send email to end user: Administrators can customize an email notification that can be sent to the end-users. Intune provides customization of the subject, message body, company logo, company name and contact information. A schedule can be defined to determine how many days after non-compliance the e-mail notification should be sent;
  • Mark device noncompliant: Administrators can define a schedule to determine how many days after non-compliance the device should actually be marked as non-compliant.

This combination enables the IT organization to decide not to block the device immediately. Instead, immediately sent the end-user a notification via e-mail and give the end-user a grace period to become compliant. A good use case for that configuration would be to force end-users to upgrade to the latest version of the platform.

Configuration

Now let’s continue by looking at the configuration. The configuration contains two required steps. The first step is to configure the actual notification and the second step is to configure the device compliance policy to actually use the created notification.

Step 1: Configure notification

The first step is to create the device compliance notification. That notification will contain the message that will be sent to the end-users. To create the notification, follow the next three steps.

1 Open the Azure portal and navigate to Intune > Device compliance > Notifications;
2 On the Device compliance – Notifications blade, click Create notification to open the Create Notification blade;
3

Intune_DevComNotificationOn the Create notification blade, provide the following information and click Create.

  • Name: Provide a name for the policy;
  • Subject: Provide a subject for the notification email;
  • Message: Provide a message that is part of the notification email;
  • Select Enable with Email header – Include company logo;
  • Select Enable with Email footer – Include company name;
  • Select Enable with Email footer – Include contact information.

Note: The last three settings use the information as configured with Intune > Mobile apps > Company Portal branding.

Step 2: Configure device compliance policy

The second step is to configure the actual Actions for noncompliance for a device compliance policy. Let’s do that by looking at an existing device compliance policy. To configure a notification for non-compliant devices, in an existing device compliance policy, follow the next 5 steps.

1 Open the Azure portal and navigate to Intune > Device compliance > Policies;
2 On the Device compliance – Policies blade, select an existing device compliance policy and click Properties to open the {PolicyName} – Properties blade;
3 On the {PolicyName} – Properties blade, click Actions for noncompliance to open the Actions blade;
4

On the Actions blade, click Add to open the Action parameters blade;

Note: By default this blade also shows the standard action named Mark device noncompliant. This action can not be deleted, but the schedule when it’s triggered can be configured (in days).

5

Intune_DevComActionOn the Action parameters blade, provide the following information and click Add.

  • Action: Select Send email to end user;
  • Message template: Select the just create notification;
  • Schedule (days after noncompliance): Specify how many days after non-compliance this notification should be send.

Note: Make sure that the notification message matches with the configured schedule for marking the device as noncompliant.

End-user experience

Now let’s end this post by looking at the end-user experience. Below is an example of an non-compliant iOS device and the notification e-mail that was received. The different section of the notification e-mail can be matched with the configuration (step 1.3), by looking at the numbers below.

  1. Email header – Include company logo;
  2. Message;
  3. Email footer – Include company name;
  4. Email footer – Include contact information;
  5. Subject.

IMG_0120

More information

For more information about notifying end-users about non-compliant devices, please refer to this article Automate actions for noncompliance.

Note: While I was writing this blog post, my colleague Arjan Vroege posted his version about this same subject. For his version, please have a look at this blog post.

Intune and Zimperium – Part 2: Conditional access and mobile threat defense level

This week the second part about the integration between Microsoft Intune and Zimperium. A quick reminder, Zimperium is one of the available third-party Mobile Threat Defense connectors for Microsoft Intune. The first part, which is available here, was mainly about integrating Zimperium with Microsoft Intune. Including an overview of the total solution. In this second part, I’ll be providing a short introduction about the mobile threat defense levels and I’ll show how to configure conditional access in combination with these threat levels. Including how the different configurations are related. I’ll end this post with the end-user experience.

Introduction

Like last week, I’ll start with short introduction. Last week this introduction was about providing an overview about the integrated solution. This week is all about looking at the Mobile Threat Response Policy, the Conditional access policy and the Device compliance policy. To understand how these policies work together, it’s important to know how the Severity of a Mobile Threat Response Policy in Zimperium is related to the Mobile Threat Level of a Device compliance policy in Microsoft Intune. Below is an overview of how these two are related and how it’s used within the Require the device to be at or under the Mobile Threat Level setting of a Device compliance policy in Microsoft Intune.

Intune Zimperium Explanation from Intune-perspective
Secured Normal This is the most secure. The device is compliant only if no threats are found. If any threats are found, the device is evaluated as non-compliant.
Low Low The device is compliant if only low level threats are present. If anything higher is found, the device is evaluated as non-compliant.
Medium Elevated The device is compliant if only low or medium level threats are present. If high level threats are found, the device is evaluated as non-compliant.
High Critical This is the least secure. The device is compliant, no matter what threats are found. It only requires devices to have the MTD app installed and activated.

Configuration

Now let’s have a look at the configuration. The configuration flow basically contains three configuration levels. First configure the Mobile Threat Response Policy in Zimperium to specify the Severity of a threat, second configure the Device compliance policy in Microsoft Intune to specify the minimal Mobile Threat Level of the device and third, configure the Conditional access policy in Azure AD to require a compliant device to connect to cloud apps.

Zimperium configuration

Let’s start with the first configuration, the Mobile Threat Response Policy in Zimperium. The following 2 steps show how to locate the Mobile Threat Response Policy and how the configurations in that policy can influence the compliance state of device.

1 Open the Zimperium zConsole and navigate to POLICY and select a group to open the related Mobile Thread Response Policy;
2 In the Mobile Threat Response Policy, there are 2 important configurations (see below) that impact the mobile threat defense level of a device in Microsoft Intune.

Zimperium_MTRP

  1. Configure the Severity for a Threat. This configures the actual threat level that is reported to Microsoft Intune;
  2. Configure the MDM Action and Mitigation Action for a Threat. This configures the if the configured threat level is reported to Microsoft Intune or not.

Microsoft Intune configuration

Let’s continue with the second configuration, the Device compliance policy in Microsoft Intune. The following 4 steps show the minimum configuration of a Device compliance policy that is required to use the Mobile Threat Level in the compliance state of a device.

1 Open the Azure portal and navigate to Intune > Device compliance > Policies;
2 On the Device compliance – Policies blade, click Create Policy to open the Create Policy blade;
3 On the Create Policy blade, provide a unique Name select a Platform (iOS or Android) and click Configure > Device Health to open the Device Health blade;
4 On the Device Health blade, configure Require the device to be at or under the Mobile Threat Level setting and click OK;

Intune_DHP

Note: As mentioned in the introduction, this Mobile Threat Level corresponds to the different Severity levels that are sent by Zimperium.

Azure AD configuration

Let’s finish with the third configuration, the Conditional access policy in Azure AD. This can also be done via the Microsoft Intune section, but I like to use the Azure AD section for conditional access (related) configurations. The following 4 steps show the minimum configuration of a Conditional access policy that is required to use the compliance state of a device to grant or block access to cloud apps.

1 Open the Azure portal and navigate to Azure Active Directory > Conditional access;
2 On the Conditional access – Policies blade, click New Policy to open the New blade;
3 On the New blade, provide a unique Name, configure the Assignment (Users and groups and Cloud apps) and click Grant to open the Grant blade;
4 On the Grant blade, there are 2 important configurations (see below) that are required to require a compliant device;

AzureAD_CAP

    1. The conditional access policy must be enabled. This makes sure that the policy is applied;
    2. Select Grant access and at least Require device to be marked as compliant. This configures that a device is required to be compliant to be able to access the configured cloud apps.

End-user experience

Now let’s have a look at the end-user experience, from a Microsoft Intune perspective. Basically the end-user can receive two separate compliance issues related to Zimperium. Below are those examples for an Android device. On the left is an example of when the Zimperium connector is active, the Require the device to be at or under the Mobile Threat Level setting is configured and the Zimperium app (zIPS) is not installed. On the right is an example of when zIPS is installed and a threat is detected with a higher threat level as configured in the Require the device to be at or under the Mobile Threat Level setting. In that case, the end-user will be advised to look at zIPS for more information.

Screenshot_20171011-204124 Screenshot_20171011-210635

For iOS the end-user will receive similar messages. Below are the same examples, in the same order, for an iOS device.

IMG_0118 IMG_0119

More information

For more information about Mobile Treat Defense, Zimperium and Microsoft Intune, please refer to the following articles:

Intune and Zimperium – Part 1: Configure the integration

This week and next week I’ll be looking at integrating Microsoft Intune with Zimperium. Zimperium is one the available third-party Mobile Threat Defense connectors for Microsoft Intune. This enables organizations to add an additional layer of protection to their corporate resources. More specifically, prevent access from compromised mobile devices. In the first part of this week I’ll be providing a short introduction about the integration and I’ll show how to configure the integration. I’ll end this post with the configuration results.

Introduction

Let’s start with a little introduction. Organizations can control mobile device access to corporate resources by using conditional access based on a risk assessment conducted by Zimperium. For this, Zimperium must be integrated with Microsoft Intune. The risk is assessed based on telemetry collected from devices running the Zimperium app. This enables organizations to configure conditional access policies based on the Zimperium risk assessment. The conditional access policy requires compliant devices and the compliance policy requires a minimum Mobile Threat Defense level. That combination enables organizations to allow or block non-compliant devices to access corporate resources based on detected threats.

To visualize this a bit more, it could be summarized in the following flow.

  1. The Zimperium app, on an iOS 8+ device or an Android 4.1+ device, detects a threat and sends an alert to the Zimperium cloud;
  2. The Zimperium cloud determines, based on the Mobile Thread Response Policy, the severity of the alert and sends the threat severity level to Microsoft Intune;
  3. Microsoft Intune determines, based on the configured mobile threat level, in the Device Compliance Policy, the compliance of the device and writes the device compliance to Azure AD;
  4. Azure AD determines, based on the configured access controls, in the Conditional Access Policy, if the device is allowed access to the cloud app.
ZimperiumFlow

Configuration

Now let’s have a look at the actual configuration of the integration between Zimperium and Microsoft Intune. The connector. Before starting with the configuration make sure that the following is available:

  • Microsoft Intune subscription;
  • Azure Active Directory administrative credentials;
  • Zimperium zConsole administrative credentials.

Zimperium configuration

The actual configuration starts in the Zimperium zConsole and not in the Intune section of the Azure portal. The Intune section in the Azure portal will only refer to the Zimperium zConsole. The 6 steps below walk through the configuration in cloud version of Zimperium.

1 Open the Zimperium zConsole and navigate to MANAGEMENT > MDM Settings;
2 Click Edit to open the Edit MDM dialog box;

Note: This environment had a previous MDM configuration. A clean environment has an Add MDM option. In that case every screen will show Edit instead of Add.

3 EditMDM01At Step 1, select Microsoft Intune and click Next;.
4a EditMDM02At Step 2, click Add to Azure Active Directory for the different components and click Next;

Note: Step 4b, 4c and 4d provide more details about the required permissions per component.

4b EditMDM02_zConsoleZimperium zConsole needs the following permissions:

  • Send device threat information to Microsoft Intune;
  • Read directory data;
  • Sign in and read user profile;
  • Read directory data.

Note: This makes sure that Zimperium can synchronize user and devices from Microsoft Intune and that Zimperium can sent threat information to Microsoft Intune.

4c EditMDM02_zIPSiOSZimperium zIPS iOS needs the following permissions:

  • Access Zimperium zConsole (Zimperium zConsole);
  • Sign in and read user profile.

Note: This makes sure that the Zimperium zIPS iOS app can use the auto sign-in functionality by using the Microsoft Intune enrollment user information.

4d EditMDM02_zIPSAndroidZimperium zIPS Android needs the following permissions:

  • Access Zimperium zConsole (Zimperium zConsole);
  • Sign in and read user profile.

Note: This makes sure that the Zimperium zIPS Android app can use the auto sign-in functionality by using the Microsoft Intune enrollment user information.

5 EditMDM03At Step 3, verify the information and click Next;
6 EditMDM04At Step 4, select the MDM group(s) that should be synchronized and used for the integration between Microsoft Intune and Zimperium and click Finish.

Note: The users in this group, and their devices, are synchronized to Zimperium.

Note: The connector between Zimperium and Intune automatically synchronizes and the synchronization schedule can be customized. This synchronization can also be manually triggered (see the Results section).

Microsoft Intune configuration

After performing the configuration in the Zimperium zConsole, the connector will be created in Microsoft Intune. This enables a few tuning options from Microsoft Intune perspective. The following 3 steps walk through the configuration options.

1 Open the Azure portal and navigate to Intune > Device compliance > Mobile Threat Defense;
2 On the Device compliance – Mobile Threat Defense blade, select the automatically created MTD CONNECTOR Zimperium;
3 IntuneZimperiumConnectorOn the Edit Connector blade, configure the connected devices and click Save.

Note: This enables the administrator to differentiate between the available platforms.

Results

When the configurations are completed, a successful configuration can be verified in the Zimperium zConsole (below on the right) and in the Azure portal (below on the left). Both will show the same synchronization time.

MDMSettings_Results01 MDMSettings_Results02

More information

For more information about Mobile Treat Defense, Zimperium and Microsoft Intune, please refer to the following articles:

Conditional access and terms of use

This week more about conditional access. More specifically, the ability to require end-users to consent to a terms of use, which is currently still in preview and was also highlighted during a couple of sessions on Microsoft Ignite. In this post, I’ll provide more information about the terms of use requirement and I’ll show how to configure that requirement. I’ll end this post with the end-user experience.

Introduction

It’s now possible to require an end-user in a tenant to consent to a terms of use before being granted access to a resource. Something like this was already possible for Microsoft Intune hybrid enrollment and Microsoft Intune standalone enrollment. However, that is Microsoft Intune only. This new requirement can be applied to any configurable Cloud app within a conditional access policy. Including Microsoft Intune enrollment. As an administrator, it’s now possible to configure and customize a terms of use by uploading a PDF document. If an end-user falls in scope of this control they will only be given access to the Cloud app if they agree, or have previously agreed, to the terms presented.

Configuration

Now let’s have a look at the configuration of a terms of use requirement in a conditional access policy. To configure a terms of use requirement in a conditional access policy. it actually requires two configurations 1) the actual terms of use and 2) the conditional access policy. The two configurations can be configured together at the same time, as shown below, or in two separate actions. To configure them together, follow the next 6 steps (of which the last 2 actually simply provide some overviews).

1 Open the Azure portal and navigate to Azure Active Directory > Conditional access > Terms of use;
2 On the Conditional access – Terms of use blade, click New to open the New terms of use blade;
3 NewTouOn the New terms of use blade, provide the following information and click Create;

  • Name: Provide a name for the policy;
  • Display name: Provide a display name for the policy. This is shown to the end-user;
  • Upload document: Upload a PDF document that contains the terms of use,of the organization, for the applicable cloud apps;
  • Select Create a policy, to automatically create a conditional access policy based on the selected Policy template.
4 NewTouCA01Navigate to Azure Active Directory > Conditional access > Policies and select the just created conditional access policy. Based on the Access to cloud apps template a conditional access policy will be created as shown on the right. This policy might need some tuning as it applies to All users and All cloud apps. At least the All users assignment needs some adjustments. With the default configuration it will also be applicable to the account used by Azure AD Connect during the directory synchronization. Either change the included group, or exclude the account that is used by Azure AD Connect.

Note: This is the error that will be generated by the directory synchronization, GetADALToken: interactive authentication error [unspecified] – Showing a modal dialog box or form when the application is not running in UserInteractive mode is not a valid operation. Specify the ServiceNotification or DefaultDesktopOnly style to display a notification from a service application.

5 NewTouCA02The just created conditional access policy contains the ability to select created terms of use in the Grant control.

Note: Every created terms of use will be selectable in the Grant control of the conditional access policy. An additional terms of use, will be an additional line like the one shown on the right.

6 NewTouCA03Navigate back to Azure Active Directory > Conditional access > Terms of use and select the just created terms of use. That provides an overview of the terms of use, the users that accepted and declined and the ability to preview the uploaded PDF.

Note: Specifically related to Microsoft Intune enrollment, think about which configuration to use. Both, the Microsoft Intune specific configuration and the Azure AD conditional access configuration, can be applied during Microsoft Intune enrollment.

End-user experience

Like last week, let’s end this post with the end-user experience. The first time the end-user falls within the assignment of the conditional access policy, the end-user will be prompted to accept the terms of use. Below are examples of an iOS device. On the left is an iOS device using the browser and on the right is an iOS device using a mobile app.

IMG_0115 IMG_0116

More information

For more information about conditional access and requiring end-users to consent to a terms of use, please refer to this article about Controls in Azure Active Directory conditional access.

Conditional access and approved client apps

This week back in conditional access. More specifically, the recently introduced requirement, in the grant control, to Require approved client apps, which is currently still in preview. That requirement feels a bit like MAM CA, but more about that later in this post. In this post, I’ll provide more information about the Require approved client apps requirements and I’ll show how to configure that requirement. I’ll end this post with the end-user experience.

Introduction

When configuring a conditional access policy, it’s now possible to configure the requirement to grant access only if a connection attempt was made by an approved client app. That’s done by using the Require approved client apps requirement. This requirement could be described as something similar as MAM CA, but with less options and straight from Azure AD. The main difference, from a configuration perspective, is that MAM CA provides more granular control over the client apps that can be used to access a specific cloud app, while this requirement in conditional access is simply on or off. On the other hand, this requirement in conditional access can be used with every cloud app, while MAM CA is only available for Exchange Online and SharePoint Online.

The approved client apps for the Require approved client apps requirement are the following apps (that all support Intune MAM):

  • Microsoft Excel
  • Microsoft OneDrive
  • Microsoft Outlook
  • Microsoft OneNote
  • Microsoft PowerPoint
  • Microsoft SharePoint
  • Microsoft Skype for Business
  • Microsoft Teams
  • Microsoft Visio
  • Microsoft Word

Keep in mind that the Require approved client apps requirement:

  • only supports iOS and Android as selected device platforms condition;
  • does not support Browser as selected client app condition;
  • supersedes the Mobile apps and desktop clients client app condition.

Configuration

Now let’s have a look at the required configuration of a conditional access policy in the Azure portal. To be able to use the Require approved client apps requirement, create a conditional access policy as shown below. The following 7 steps walk through the minimal configuration for, for example, Exchange Online.

1 Open the Azure portal and navigate to Azure Active Directory > Conditional access > Policies;
2 On the Policies blade, click New policy to open the New blade;
3 RACA_01On the New blade, select the Users and groups assignment to open the Users and groups blade. On the Users and groups blade, select All users and click Done;
4 RACA_02On the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, select Select apps to select Office 365 Exchange Online and click Done;
5

RACA_03On the New blade, select the Grant access control to open the Grant blade. On the Grant blade, select Grant access and select at least Require approved client app (preview) and click Select.

Note: This configuration will make sure that only the mentioned approved client apps can access Exchange Online.

End-user experience

As usual with this type of posts, I’ll end this post with the end-user experience. On the left is an example of the iOS 11 default mail app that is trying to connect with Exchange Online. This provides a clear message that the app can’t be used, as it’s not approved. On the right is an example of the iOS default browser that is trying to connect with outlook.office365.com. This provides a less clear message and refers to the Intune Managed browser, which is currently not on the approved apps list. This is very likely the reason why the browser functionality is currently not yet supported, but it’s very good to see that the access is blocked. That removes a big potential backdoor of a great feature!

IMG_0113 IMG_0114

More information

For more information about conditional access and requiring approved client apps, please refer to this article about Azure Active Directory Conditional Access technical reference | Approved client app requirement.

Block personally-owned devices

My last blog post just before a short vacation, is about using the differentiation between corporate-owned devices and personally-owned devices. The best scenario for this differentiation is preventing the MDM enrollment of personally-owned devices. In that scenario it’s still possible to use MAM-WE with personally-owned devices, as only the MDM enrollment will be blocked. In other words, it’s still possible to enable the end-users to securely access their corporate data on their personally-owned device. The ability to block personally-owned devices is introduced with Configuration Manager 1706 and was already available for a while in Microsoft Intune standalone. In this post I’ll walk through the configuration steps for Microsoft Intune hybrid and standalone. I’ll end this post with the end-user experience.

Configuration

Before starting with the configuration, it’s good to mention that Microsoft Intune hybrid and standalone classifies devices as personally-owned by default.

Microsoft Intune hybrid

The configuration for Microsoft Intune hybrid must be done by using the Configuration Manager administration console. At this moment Microsoft Intune hybrid only supports the restriction on personally-owned devices for Android and iOS. This can be configured by simply following the next steps.

1 Open the Configuration Manager administration console and navigate to Software Library > Overview > Cloud Services > Configure Platforms;
2 On the Home tab, click Configure Platforms > Android (3a) or iOS (3b) to open the Microsoft Intune Subscription Properties;
3a BlockPersonal_Android_HybridOn the General tab, select Block personally owned devices and click OK;
3b BlockPersonal_iOS_HybridOn the Enrollment Restrictions tab, select Block personally owned devices and click OK.

Note: To specify that a device is company-owned, add the IMEI or serial number to the Predeclared Devices list (as shown here), or enroll it using Apple DEP (iOS only).

Microsoft Intune standalone

The configuration for Microsoft Intune standalone must be done by using the Azure portal. At this moment Microsoft Intune standalone supports the restriction on personally-owned devices for Android, iOS and macOS. This can be configured by simply following the next steps.

1 Open the Azure portal and navigate to Intune > Device enrollment > Enrollment restrictions to open the Device enrollment – Enrollment restrictions blade;
2 On the Device enrollment – Enrollment restrictions blade, select Default in the Device Type Restrictions section, to open the All Users blade;
3 On the All Users blade, select Platform Configurations to open the All Users – Platform Configurations blade;
4

BlockPersonal_StandaloneOn the All Users – Platform Configurations blade, select Block, in the PERSONALLY OWNED column, for the platforms of which personal-owned devices must be blocked and click Save.

Note: To specify that a device is company-owned, ad the IMEI or serial number to the Predeclared Devices list (as shown here), or enroll it using Apple DEP (iOS only)..

End-user experience

Now let’s end this post by looking at the end-user experience for Android and iOS devices.

Screenshot_20170816-201942Android: Let’s walk through the steps, on an Android device, that the end-user needs to perform before the end-user will actually be told that it’s not allowed.

  • Open the Microsoft Intune Company Portal app and sign in;
  • On the Company Access Setup page, tap Begin;
  • On the Why enroll your device? page, tap Continue;
  • On the We care about your privacy page, tap Continue;
  • On the What comes next page, tap Enroll;
  • On the Activate device administrator? page, tap Activate;

Now a clear Couldn’t enroll your device message will show (as shown on the right). That message clearly mentions that the end-user is not authorized to enroll this device.

IMG_0112iOS: Let’s walk through the steps, on an iOS device, that the end-user needs to perform before the end-user will actually notice that it’s not allowed.

  • Open the Microsoft Intune Company Portal app and sign in;
  • On the Company Access Setup page, tap Begin;
  • On the Why enroll your device? page, tap Continue;
  • On the We care about your privacy page, tap Continue;
  • On the What comes next page, tap Enroll;
  • On the Install Profile page, tap Install;
  • On the dialog box, tap Install;

Now a terrible Profile Installation Failed message will show (as shown on the right). That message mentions that a connection to the server could not be established. This is ugly, but is currently the expected behavior.

More information

For more information about blocking personally-owned devices and how it can be configured via Microsoft Intune hybrid and standalone, please refer to the following articles:

Easily predeclaring corporate-owned devices

This week another post about (easily) predeclaring corporate-owned devices. Starting next week, I’ll introduce some new feature of Configuration Manager 1706. This post is basically a part 2 of my post about predeclaring corporate-owned devices. The big difference, this time it’s about Microsoft Intune standalone were this feature is just recently introduced. Predeclaring corporate-owned devices is an easy method to differentiate between corporate and personal devices and immediately tag those devices. I’ll start this post with a little bit information, followed by the configuration. I’ll end this post with the administrator experience.

Information

Let’s start with some information about predeclaring corporate-owned devices. An Intune administrator can now create and import a comma-separated values (.csv) file that lists International Mobile Equipment Identifier (IMEI) numbers or serial numbers. Intune uses these identifiers to set Ownership as Corporate. IMEI numbers can be declared for all supported platforms and serial numbers can be declared for iOS and Android devices only. Each IMEI or serial number can have details specified in the csv file for administrative purposes.

Configuration

Before I’m going to walk through the required configuration steps, it’s good to provide some information about the format of the csv files that can be used. To create the list, create a two-column csv list without a header. Add the IMEI or serial numbers in the left column, and the device details in the right column. A csv file can only contain or IMEI numbers, or serial numbers. The device details are limited to 128 characters and are for administrative use only. Details aren’t displayed on the device. The current limit is 500 rows per csv file. An example for serial numbers would look like the following.

RF8xxxxRZP,Company-owned Android device
F9FxxxxxxHK9,Company-owned iOS device

With this information and the example, I’ll now walk through the configuration steps.

1 Open the Azure portal and navigate to Intune > Device enrollment > Corporate device identifiers;
2 On the Corporate device identifiers blade, select Add to open the Add identifiers blade;
3

AddIdentifiersOn the Add identifiers blade, select Serial as Identifier type, select the created csv file with Import identifiers and click Add to return to the Corporate device identifiers blade;

Note: When importing IMEI numbers, simply select IMEI as Identifier type. Also, notice the message below the selected csv file, it already shows the total number of device identifiers that are found within the csv file.

4

Back on the Device identifiers blade it will now provide an overview of the just imported device identifiers;

SuccesImport

Administrator experience

Let’s end this post with the administrator experience. After a device of the csv file is enrolled, there are a few good places to look in the Azure portal. The first place is Intune > Device enrollment > Corporate device identifiers. This location shows the imported device identifiers and will now also show Enrolled as the STATE of the imported device identifier.

SuccesEnroll

The second place is Intune > Devices > All devices. This location shows all the enrolled devices and now also shows Corporate as OWNERSHIP of the device.

EnrollCorporate

This is the easiest method for an administrator to differentiate between corporate and personal devices. It enables the administrator to target specific actions only to corporate-owned devices and even enables the administrator to create an easy road to blocking personal devices. More about that in a later post. Also, keep in mind that the ownership will not change for already enrolled devices. The corporate identifiers must be imported before the devices are enrolled.

More information

For more information about predeclaring corporate-owned devices, please refer to this article about adding corporate identifiers.