Azure AD

This week is all about deploying the ConfigMgr client via Microsoft Intune. Like last week, this is also a nice addition in combination with Windows AutoPilot. The idea is to install the ConfigMgr client next to the MDM agent and to create a co-management scenario. The main use case to do something like this is when an organization is making the transition from traditional management to modern management. In that scenario the organization can use co-management to make a phased move to the cloud. For example, use ConfigMgr for patch management and use Microsoft Intune for configurations and compliance. In this post I’ll provide a short introduction to co-management, followed by the prerequisites for the ConfigMgr client installation and the end result.

Introduction

Starting with Configuration Manager, version 1710, co-management enables organizations to concurrently manage Windows 10, version 1709, devices by using both Configuration Manager and Microsoft Intune. There are two main paths to reach to co-management:

Microsoft Intune provisioned devices that are enrolled in Microsoft Intune and then installed the Configuration Manager client to reach a co-management state (focus of this post).

I can continue with a long story about co-management and the capabilities that it provides, or how co-management is the bridge between traditional management and modern management, but the following picture shows close to all of that.

Prerequisites

Now let’s start by having a look at the prerequisites that must be in place to enable the second path to co-management, which is deploying the ConfigMgr client to Microsoft Intune enrolled devices. The following technical prerequisites must be in place:

MDM authority set to Microsoft Intune;

Device is Azure AD joined;

Windows 10, version 1709 or later;

Configuration Manager, version 1710 or later;

Cloud Management Gateway (CMG);

Cloud Distribution Point (CDP);

Co-management enabled;

Management Point (MP) set to HTTPS;

Synchronization of Azure AD users enabled;

Configuration

Let’s continue by having a look a the configuration. I’ve divided the configuration in three steps. The first step is to get the required command line, the second step is to explain the command line (and add some additional parameters) and the third step is to actually deploy the ConfigMgr client.

Step 1: Get the command line

The first step is to get the required command line. The following three steps walk through the easiest method to get the required command line.

Note: As I’m using certificates from my internal PKI-environment, I also needed to deploy the root certificate of my environment to the Trusted Root Certification Authorities store of the devices. That could be easily achieved by using a Device configuration profile and using the Trusted certificate profile type option.

Result

Now let’s end this post by looking at the end result. The first place to look, after the ConfigMgr client installation, is Microsoft Intune. Below is an overview of my Azure AD joined devices that are managed by MDM and ConfigMgr. By looking at the compliance state, it’s clear that my workload for compliance policies is set to Intune.

The second place to look, after the ConfigMgr client installation, is the Configuration Manager console. Below is an overview of the same devices from a ConfigMgr perspective. By looking at the device online information, it’s clear that those devices are connecting over the Internet via CMG.

More information

For more information about deploying the ConfigMgr client via Microsoft Intune, please refer to the following articles.

This week a short post about enabling Windows Automatic Redeployment form the login screen. It’s a follow up on enabling password reset and PIN reset from the login screen, as it enables another feature on the login screen, and a nice addition in combination with Windows AutoPilot. Windows Automatic Redeployment might be a familiar feature, but I couldn’t find much written information about it yet. In this post I’ll provide a brief introduction to Windows Automatic Redeployment, followed by the required configuration and the end-user experience.

Introduction

Now let’s start with a brief introduction about Windows Automatic Redeployment. Starting with Windows 10, version 1709, administrators can use Windows Automatic Redeployment to quickly remove personal files, apps, and settings, by resetting Windows 10 devices from the login screen at any time. That reset will apply the original settings and device management enrollment, so the devices are ready to use once the reset is completed. The device management enrollment is related to Azure Active Directory and Microsoft Intune (or other third-party MDM-providers).

In other words, Windows Automatic Redeployment allows administrators to reset devices to a known good managed state while preserving the management enrollment. After Windows Automatic Redeployment is triggered, the devices are ready for use by standard users.

Configuration

The configuration actually only contains one specific setting. To get that specific setting, the first step explains the location of the setting and the second step explains the usage of the setting.

Step 1: Get the required setting

The first step is to get the required setting. The Policy CSP contains CredentialProvider policies. One of those policies is DisableAutomaticReDeploymentCredentials. That policy is introduced in Windows 10, version 1709, and is used to enable or disable the visibility of the credential provider that triggers the reset on a device. This policy does not actually trigger the reset. This policy enables the administrator to authenticate and trigger the reset on the device. This setting supports the following values:

0 – Enable the visibility of the credentials for Windows Automatic Redeployment;

Step 2: Configure the required setting

The second step is to actually configure the required setting to enable the option to automatically redeploy Windows from the login screen. In other words, the second step is to configure a device configuration profile with at least a custom OMA-URI setting. The following three steps walk through the creation of a new device configuration profile, including the required OMA-URI setting. After that simply assign the created profile to a user group.

1

Open the Azure portal and navigate to Intune > Device configuration > Profiles;

2

On the Devices configuration – Profiles blade, click Create profile to open the Create profile blade;

3a

On the Create profile blade, provide the following information and click Create;

Name: Provide a valid name;

Description: (Optional) Provide a description;

Platform: Select Windows 10 and later;

Profile type: Select Custom;

Settings: See step 3b.

3b

On the Custom OMA-URI Settings blade, provide the following information and click Add to open the Add row blade. On the Add row blade, provide the following information and click OK (and click OK in the Custom OMA-URI blade);

End-user experience

Let’s end this post by looking at the end-user experience. I’ll do that by showing how to trigger Windows Automatic Redeployment, followed by a screenshot of the start of the process and a screenshot of the end of the process.

To trigger the Windows Automatic Redeployment, press the combination of Ctrl ++ R on the login screen. As shown below, this will provide the user with the option to provide an administrator account to automatically redeploy Windows.

Once administrator credentials are provided the redeployment process will be triggered. As shown below, when the process is finished a success message will be shown.

Now the device is ready to go. Keep in mind that the device is still Azure AD joined and Microsoft Intune managed with the original account. So, the main use case for this reset is for information workers and students.

This week is all about providing an overview of the best and easiest option for doing some initial testing of conditional access policies. The conditional access What If tool. The What If tool will help with easily understanding what to expect from the configured conditional access policies. It provides an overview of how the different conditional access policies will impact the user(s) under various sign-in conditions. In this post I’ll provide an overview of the What If tool, followed by the available evaluation settings and the evaluation results.

Important: At this moment the What If tool is still in public preview.

Introduction

Let’s start with a short introduction about the What If tool. The What If tool allows administrators to understand the impact of the conditional access policies in the environment. Instead of testing the conditional access policies by performing multiple sign-ins manually, the What If tool enables administrators to evaluate a simulated sign-in of a user. The simulation estimates the impact that a sign-in has on the conditional access policies and generates an evaluation report. That report lists the conditional access policies that apply (and not apply) to the simulated sign-in and it shows the classic conditional access policies, if they exist.

Available settings

Overview

Now let’s continue with an overview of the What If tool. The What If tool is available in the conditional access section of the Azure portal. The following two steps walk through navigating to the What If tool, followed by an overview of the available settings.

1

Open the Azure portal and navigate to Intune > Conditional access or to Azure Active Directory > Conditional access to open the Conditional access – Policies blade;

2

On the Conditional access – Policies blade, click What If to open the What If blade;

—

Settings

After looking at an overview of the What If tool, it’s time to look at the available evaluation settings. Within the What If tool the following six sections are available for testing conditional access policies.

1

When selecting the User section, the Users blade is opened that allows the administrator to select one or more users to mimic the Users and groups assignment of a conditional access policy.

This is the only required selection;

2

When selecting the Cloud apps section, the Cloud apps blade is opened that allows the administrator to select one or more cloud apps to mimic the Cloud apps assignment of a conditional access policy.

This is not a required selection. When nothing is selected, the default is All cloud apps;

3

The IP address section allows the administrator to provide a single IPv4 address to mimic the Locations condition of a conditional access policy.

This is not required input. When nothing is provided, any network location is part of the network location evaluation. Also, when used, this should be the Internet facing IP address;

4

The Device platform section allows the administrator to select one or more device platforms to mimic the Device platforms condition of a conditional access policy.

This is not a required selection. When nothing is selected, any device platform is part of the device platform evaluation;

5

The Client apps section allows the administrator to select one or more client apps to mimic the Client apps condition of a conditional access policy.

This is not a required selection. When nothing is selected, any client app is part of the client app evaluation;

6

The Sign-in risk section allows the administrator to select one or more sign-in risk levels to mimic the Sign-in risk condition of a conditional access policy.

This is not a required selection. When nothing is selected, any sign-in risk level is part of the sign-in risk evaluation;

—

Evaluation results

Let’s end this post by looking at the evaluation results of the What If tool. After making the selections, as shown above, to the settings to evaluate, and clicking the What If button, the tool What If tool generates a report of the affected conditional access policies. That report is divided into two tabs.

The first tab, which is shown below, contains the conditional access policies that apply to the selected user(s), in combination with the selected conditions. It also provides an overview of the grant controls that the user must satisfy to get access to the selected cloud apps.

The second tab, which is shown below, contains the conditional access policies that will not apply to the selected user(s), in combination with the selected conditions. It also provides an overview of the reasons why the conditional access policy doesn’t apply. Good to know, when there are multiple reasons for a conditional access policy to not apply, it only shows the first reason.

Note: When classic conditional access policies still exist in the environment, the orange exclamation mark is shown above the evaluation results. Even when these conditional access policies are already disabled.

This week I’m going through the required steps for configuring Windows AutoPilot. I know that a lot has been written already about this subject, but I have the feeling that this subject needs a place on my blog. Also, the attentive reader might have noticed that I’m specifically using Microsoft Intune in the title of my blog, for the first time in over a year. That’s with a reason. This post is focused on configuring Windows AutoPilot via Microsoft Intune and will show that, at this moment, the Microsoft Store for Business is also required to complete the Microsoft Intune configuration.

In this post I’ll provide a short introduction about Windows AutoPilot, followed by walking through the required configurations. I’ll end this post by quickly looking at the result, from the end-user perspective and from the administrator perspective.

Introduction

Before looking at the configuration, let’s start with a short introduction about Windows AutoPilot. The Windows AutoPilot deployment program simplifies device provisioning. With Microsoft Intune and Windows AutoPilot, it’s possible to give new devices to end-users without the need to build, maintain, and apply custom operating system images to the devices. Windows AutoPilot covers the provisioning of the devices and Microsoft Intune makes it possible to manage policies, profiles, apps, etc. on the devices after they are enrolled. Once devices are registered for Windows AutoPilot, the following OOBE customization options are available for Windows 10, starting with version 1703:

Add sign-in experience with company or school brand (optional configuration);

Prevent the account used to set-up the device from getting local administrator permissions (optional configuration).

Configuration

Now let’s have a look at the required configurations to create the full Windows AutoPilot experience. That includes looking at the prerequisites, adding devices and adding a company branding. To get this full experience, simply walk through the six steps below.

Prerequisites

Before walking through the required configuration steps, make sure that the following prerequisites are in-place. Everything else will be covered in this post.

Devices have to be pre-installed with Windows 10, version 1703 or later;

Step 1: Get device information

The first step is to get the device information, as the devices must be registered to the organization. At this moment, it’s still required to acquire the device serial number, the Windows product ID and the hardware ID of the devices and to register the devices. Microsoft is actively working with various hardware vendors to enable them to provide the required information to organizations, or upload it on their behalf. To capture the required information, use the Get-WindowsAutoPilotInfo PowerShell script, by performing steps similar to the following four steps.

Run Install-Script -Name Get-WindowsAutoPilotInfo to install the PowerShell script;

4

Run Get-WindowsAutoPilotInfo.ps1 -OutputFile C:\Windows\Temp\MyComputer.csv to get the required device information;

—

Step 2: Add devices

The second step is to add the gathered device information. This cannot be achieved by using Microsoft Intune, at this moment, but can be achieved by using the Microsoft Store for Business or by using the Partner Center. To use the Microsoft Store for Business, perform the following three steps.

On the Add devices to an AutoPilot deployment group, select No, thanks as I want to use Microsoft Intune for assigning a deployment profile.

—

Step 3: Synchronize devices

The third step is to synchronize the added device information into Microsoft Intune. That will enable me to use Microsoft Intune for assigning a deployment profile to those devices. To synchronize the devices into Microsoft Intune, perform the following three steps.

On the Windows AutoPilot devices (Preview) blade, click Sync to synchronize the devices to Microsoft Intune.

—

Step 4: Create deployment profile

The fourth steps is to create a deployment profile in Microsoft Intune. The deployment profiles are used to configure the AutoPilot devices. To create a deployment profile in Microsoft Intune, perform the following four steps.

On the Windows AutoPilot devices (Preview) blade, select the just imported device and click Assign profile to open the Assign profile blade.

4

On the Assign profile blade, select the just created deployment profile and click Assign;

—

Step 6: Add company branding

The sixth step is the finishing touch, by making the company branding appear during the OOBE. This cannot be achieved by using Microsoft Intune, at this moment, but can be achieved by using the Azure AD. To configure the company branding, perform the following steps.

1

Open the Azure portal and navigate to Azure Active Directory > Company branding;

2

On the Company branding blade, click Configure to open the Configure company branding blade;

3

On the Configure company branding blade, provide the following information and click Create.

Note: I’ve only configured a couple of items that will clearly show that the Windows AutoPilot deployment is part of my company.

Result

Now let’s end this post by looking at the result of the configurations. Let’s start by looking at the end-user experience. Yes, I can show the remaining screens during the OOBE, but I thought that was not that exciting. Instead, I’ve got the main enrollment screen that includes the company branding.

From an administrator perspective, the most interesting place, to look for the end result, is the Azure portal. When navigating Intune > Device enrollment > Windows Enrollment > Devices, the overview of devices won’t show any difference. However, the administrator can filter on Enrolled devices to get a list of devices that are successfully enrolled via the Windows AutoPilot deployment. Also, when selecting a device, it provides a list of interesting information. The most important one of that is the Enrollment State. As shown on the right, this will be set to Enrolled after the device is successfully enrolled via the Windows AutoPilot deployment.

More information

Fore more information about Windows AutoPilot, in combination with Microsoft Intune and the different configuration options, please refer to:

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 is all about creating awareness for the automatic MDM enrollment feature, using ‘Group Policy, that is introduced in Windows 10, version 1709. In some scenarios that might not sounds very interesting. Especially when looking at cloud only scenarios. However, this feature is very interesting in scenarios when organizations want to move to the cloud. Think about co-management. Co-management helps organizations to slowly move their device management capabilities to the cloud, by allowing multiple device management agents on a single device. Microsoft just released co-management in Microsoft Intune and co-management is also available in the latest Technical Preview releases of Configuration Manager. So, imagine a scenario in which a currently Configuration Manager managed device can receive a Group Policy setting to also auto-enroll the device in Microsoft Intune. Very helpful in the transition to the cloud.

In this post I’ll provide a short introduction to auto-enrollment for Windows 10 devices, followed by an overview of the requirements to enable auto-enrollment for Windows 10 devices. I’ll end this post with how to verify the results of a successful auto-enrollment.

Introduction

Let’s start by looking at an introduction to automatic MDM enrollment of Windows 10 devices. Well, actually more describing what will happen when configuring automatic enrollment. Automatic enrollment relies on the presence of an MDM service in Azure Active Directory and the Azure Active Directory registration of a Windows 10 device. Starting with Windows 10, version 1607, once an organization has registered its Active Directory with Azure Active Directory, a Windows 10 device that is Active Directory domain joined is automatically Azure Active Directory registered.

When the auto-enroll Group Policy is enabled, a scheduled task is created that initiates the MDM enrollment. That scheduled task will start deviceenroller.exe with the AutoEnrollMDM parameter, which will use the existing MDM service configuration, from the Azure Active Directory information of the user, to auto-enroll the Windows 10 device. If multi-factor authentication is required, the user will get a prompt to complete the authentication. Once the enrollment is completed, the scheduled task will be removed and a folder will be created with the “standard” MDM-related tasks.

Note: In Windows 10, version 1709, when the same setting is configured via Group Policy and via MDM, the Group Policy setting wins. This might change in future releases of Windows 10.

Requirements

Before starting with the configuration, let’s start by having a look at the list of requirements that must be in place to facilitate the auto-enroll configuration.

Active Directory is integrated with Azure Active Directory;

MDM service is configured in Azure Active
Directory;

Device is running Windows 10, version 1709, or later;

Device is Active Directory joined;

Device is Azure Active Directory registered.

As in my posts the main focus is at the management of the devices, let’s highlight the configuration requirement of the MDM service in Azure Active Directory.

1

Open the Azure portal and navigate to Azure Active Directory > Mobility (MDM and MAM);

2

On the Mobility (MDM and MAM) blade, click Add application to add the applicable MDM app. As I’m using Microsoft Intune, the MDM app was already added and preconfigured;

3

Select the MDM app, in my case Microsoft Intune, and make sure the settings are configured.

Configuration

Now let’s have a look at the main configuration of this post, the configuration of the required Group Policy setting. It’s actually quite simple, but it’s all about being aware. Simply install the latest ADMX-files for Windows 10, version 1709, or later and perform at least the following 3 steps.

1

Create a new GPO, or open an existing GPO, in the Group Policy Management Editor and navigate to Administrative Templates > Windows Components > MDM;

Result

Once the configuration of the Group Policy is done, and the policy is enabled and linked, it’s time to look at the results. The following 3 locations, are the easiest locations, on the local Windows 10 device, to look for a success of the auto-enrollment.

Event Viewer – The first place to look for a success is the Event Viewer. The Event Viewer contains a specific location for device management related events. That location can be found at Microsoft > Windows > DeviceManagement-Enterprise > Diagnostics > Provider > Admin. That location should show Event ID: 75, with the message “Auto MDM Enroll: Succeeded”.

Task Scheduler – The next place to look for a success is the Task Scheduler. The Task Scheduler contains a specific location for device management tasks. That location can be found at Microsoft > Windows > EnterpriseMgmt. That location previously contained a task named “Schedule created by enrollment client for automatically enrolling in MDM from AAD Properties”. After a successful auto-enrollment, that task should be gone and a folder with a guid name should show.

Settings – Another place to look for a success is the Settings panel. The Settings panel contains a location that provides information about the connected work and school environments. That location can be found via Start > Settings > Accounts > Access work or school. Without a successful auto-enrollment it simply shows a connected Active Directory domain. Once the auto-enrollment is successful, the connected Active Directory domain can be selected and the Info button can be used to see the MDM enrollment information.

Note: The Windows 10 device can also be located in the Azure Active Directory. However, I thought that providing the information above provides more insights in what’s actually happens. Besides that, a screenshot of a Windows 10 device in Azure Active Directory, is simply boring.

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!

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!