iOS

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

On 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

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

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.

Configure the Severity for a Threat. This configures the actual threat level that is reported to Microsoft Intune;

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;

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;

The conditional access policy must be enabled. This makes sure that the policy is applied;

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.

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

More information

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

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.

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;

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;

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;

Azure AD determines, based on the configured access controls, in the Conditional Access Policy, if the device is allowed access to the cloud app.

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

At Step 1, select Microsoft Intune and click Next;.

4a

At 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

Zimperium 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

Zimperium 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

Zimperium 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

At Step 3, verify the information and click Next;

6

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

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

More information

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

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

On the Conditional access – Terms of use blade, click New to open the New terms of use blade;

3

On 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

Navigate 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

The 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

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

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.

On 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

On 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

On 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!

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.

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

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

Android: 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.

iOS: 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:

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.

On the Corporate device identifiers blade, select Add to open the Add identifiers blade;

3

On 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;

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.

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.

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.

This week a relatively short blog post about the recently introduced feature to require a minimum platform version, app version and Intune app protection policy SDK version, when using MAM-WE. This enables organizations to require end-users to update their personal devices when using apps to connect to company resources. That can be very useful when specific platform and/or app updates introduce important new features, or fix important bugs. In other words, a great feature! In this post I’ll go through the available settings, the configuration options and the end-user experience.

Configuration

Let’s start by having a look at the configuration. I’ll do that by first going through the available settings, followed by going through how to configure those settings in an app protection policy.

Available settings

Since May 2017 it’s possible to set additional requirements for MAM-WE that enforces the following policies before connecting to company data:

Minimum app version;

Minimum platform version;

Minimum Intune app protection policy SDK version (iOS only).

Most of these settings are available for both Android and iOS. Microsoft Intune supports minimum version enforcement for platform versions, app versions, and Intune app protection policy SDK. Setting a minimum version enforcement for the Intune app protection SDK, is currently only available for iOS. The configuration is also available when configuring an app protection policy for Android, but in that case the configuration will not work and will not save (at this moment).

Configure app protection policy

Now let’s have a look at configuring the available settings in an app protection policy. I’ll do that by going through the steps for creating an app protection policy for iOS that provides a warning message when the iOS platform is not at the specified minimum version. Configuring the remaining settings can be done by following similar steps, as shown in the screenshot in step 6. That screenshot shows all the new available settings. Also, keep in mind that it might require multiple app protection policies when targeting specific apps and versions.

1

Open the Azure portal and navigate to Intune App Protection > App policy;

2

Select Add a policy to open the Add a policy blade;

3

On the Add a policy blade, provide a unique name for the app protection policy and select Apps to open the Apps blade;

4

On the Apps blade, select the required apps and click OK to return to the Add a policy blade;

5

Back on the Add a policy blade, select Settings to open the Settings blade;

6

On the Settings blade, select Yes with Require minimum iOS operating system (Warning only), specify a minimum version with iOS operating system and click OK to return to the Add a policy blade;

Note: When specifying a version number it’s required to specify at least a major and minor version. Only a major version is not sufficient. In my example I used 10.3.3 for easy testing, as the current iOS version is 10.3.2.

7

Back on the Add a policy blade, click Create;

Note: When creating an app protection policy for Android devices, the option to configure a specific minimum Intune SDK version is available. However, it won’t be configurable.

End-user experience

Let’s end this post by looking at the end-user experience. Depending on the configuration, the end-user might be unable to access the targeted application if the minimum requirements through the app protection policy are not met at the three different levels mentioned above. Let’s start mildly. Below are examples of an iOS device trying to use the Outlook app to connect to Exchange Online. On the left is an example of a warning notification about the platform version and on the right is a warning notification about the app version. These notifications can be closed and the app can be used as normal.

Now let’s take it one step further. Below are examples of an Android device trying to use the Outlook app to connect to Exchange Online. On the left is an example of a blocking notification about the platform version and on the right is an example of a blocking notification about the app version. At this moment, the end-user may either remove their account (for multi-identity applications), or go back to close the app and update the version of the app or platform.

More information

For more information about the available app protection policies, please refer to:

This blog post is about a potentially really great feature, which is a combination of MAM-WE and app configuration policies. This enables the administrator to provide a preconfigured app, once the end-users signs in to the app with company credentials. I named it a potentially really great feature, because the availability of apps that support this combination of features will make or break the use of this feature. In this post I’ll provide a quick introduction to this feature, followed by a configuration example with the Intune Managed Browser.I’ll end this post with the end-user experience.

Introduction

Let’s start with a quick introduction. MAM-WE with app configuration, also known as MAM targeted configuration, allows an app to receive configuration data through the Intune App SDK. The format and variants of this data (the keys and values) must be defined and communicated by the application owner/developer. The Microsoft Intune administrators can target and deploy the configuration data via the Intune Azure console. The app configuration data is pushed through the MAM Service directly to the app, instead of through the MDM channel.

Configuration

The configuration in this post will be based on the Intune Managed Browser, which is, to my knowledge, currently the only app that works with this great combination of features. At this moment, MAM targeted configuration is available on iOS and Android. For iOS, the app must have incorporated Intune APP SDK for iOS (v 7.0.1) and be participating in app configuration settings.

Available settings

Before starting with the actual configuration, let’s start by looking at the available configuration settings. The nice thing is that very recently a few configuration keys have been released by Microsoft. The Intune Managed Browser can now be preconfigured for Azure AD App Proxy redirection, with a specific homepage, with a list of bookmarks and with a list of allowed or block websites. That provides us with the following list of keys and example values. The name of the keys provide a clear indication of their configuration usage.

Note: The separation character for multiple bookmarks is || and the separation characters for multiple allow/block URLs is |.

Configure app configuration policy

After looking at the available settings, let’s have a look at the actual configuration. The configuration of MAM targeted configuration, can be done by using the Azure portal and following the steps below. After creating the app configuration policy, don’t forget to assign it to an user group.

1

Open the Azure portal and navigate to Intune App Protection > App configuration;

2

Select Add Config to open the Add app configuration blade;

3

On the Add app configuration blade, provide a unique name for the app configuration policy and select App to open the Targeted apps blade;

4

On the Targeted apps blade, select the Managed Browser (Android), the Managed Browser (iOS) and click OK to return to the Add app configuration blade;

5

Back on the Add app configuration blade, select Configuration to open the Configuration blade;

6

On the Configuration blade, provide similar information as the earlier mentioned NAME and VALUE (examples) pairs and click OK to return to the Add app configuration blade;

7

Back on the Add app configuration blade, click Create;

End-user experience

Let’s end this post by looking at the end-user experience. I created an app configuration, as mentioned in this post, but added a couple more bookmarks. Below are a couple of examples of the Intune Managed Browser on an iOS device. On the left is an example of an app configuration including a homepage, and on the right is an example of an app configuration excluding a homepage.

This week a relatively short blog post related to conditional access. More specifically, about the ability to create a compliance policy with an apps that cannot be installed list. Before starting, let’s start with the minor detail that this is a Microsoft Intune hybrid only configuration at this moment. Introduced in Configuration Manager 1702. I’ll start this post with a short introduction, followed by the required configurations. Including how to find the required information. I’ll end this post with the end-user experience on an iOS and Android device.

Introduction

Let’s start with a short introduction about the apps that cannot be installed list. The apps that cannot be installed list is an additional rule that can be configured as part of a compliance policy. When the end-user installs an app from the apps that cannot be installed list, the end-user will be blocked when trying to access corporate email and other corporate resources that support conditional access. The end-user will be blocked until the app is removed from the device. This rule requires the app name and the app ID when adding an app to the apps that cannot be installed list, defined by the admin. The app publisher can also be added, but it’s not required.

Configuration

Now let’s walk through the steps to add an app to the apps that cannot be installed rule of a compliance policy. Let’s start by getting the required app ID, followed by the steps to use that information in a compliance policy.

Get app ID

First get the app ID, as it’s required information for the apps that cannot be installed rule. An app ID is the identifier that uniquely identifies the app within the Apple and Google application services. I’ll use the OWA app as an example.

Android

The app ID for Android can easily be found in the Google Play store URL that was used to browse to the app. As an example see the app ID for the OWA app in the following URL (bold): https://play.google.com/store/apps/details?id=com.microsoft.exchange.mowa&hl=en

iOS

The app ID for iOS is a bit more challenging. To find the app ID, follow the next steps.

1

Find the ID number in the iTunes store URL. As an example see the ID for the OWA app in the following URL (bold): https://itunes.apple.com/us/app/owa-for-ipad/id659524331?mt=8;

2

Open a web browser and navigate to the following URL, using the example ID of the OWA app: https://itunes.apple.com/lookup?id=659524331;

3

Download and open the 1.txt file;

4

In the 1.txt file, search for the text bundleId. The value with the text is the app ID. With the OWA app example, the app ID is com.microsoft.exchange.mowa.

Configure compliance policy

After finding the app ID, it’s now time to use that information in a compliance policy. Below are the required steps for creating a compliance policy and adding the OWA app to the apps that cannot be installed list. After creating the compliance policy, simply deploy it like any other policy.

On the Rules page, click New to open the Add Rule dialog box. In the Add Rule dialog box, select Apps that cannot be installed and click Add to open the Add app to blocked application list dialog box. In the Add app to blocked application list dialog box, specify the Name and App ID of the app and click OK, OK, Next;

6

On the Summary page, click Next;

7

On the Completion page, click Close.

End-user experience

When the configuration is done, let’s have a look at the most important thing, the end-user experience. Below on the left is the end-user experience when connecting to corporate resource with conditional access enabled. This is a standard message for non-compliant devices. Below on the right is the additional information in the Company Portal app. In this case it will clearly show (at least on iOS) that the end-user must first uninstall the OWA app to get a compliant device. The first row is an iOS device, the second row is an Android device.

Note: From an administrator perspective, have a look at Monitoring > Overview > Deployments for a clear view of which end-users are non-compliant for the compliance policy.

Award

Subscribe to updates

About

I’m Peter van der Woude, born in 1983 and I’m living together with my wife and two sons in the Netherlands.

Currently I work for KPN Consulting. At this moment my main focus is Enterprise Client Management via Microsoft Intune and/ or System Center Configuration Manager (ConfigMgr 2007/ 2012/ CB) and I love it!