Notify end-user about non-compliant device

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

Introduction

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

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

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

Configuration

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

Step 1: Configure notification

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

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

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

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

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

Step 2: Configure device compliance policy

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

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

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

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

5

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

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

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

End-user experience

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

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

IMG_0120

More information

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

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

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

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

Introduction

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

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

Configuration

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

Zimperium configuration

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

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

Zimperium_MTRP

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

Microsoft Intune configuration

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

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

Intune_DHP

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

Azure AD configuration

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

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

AzureAD_CAP

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

End-user experience

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

Screenshot_20171011-204124 Screenshot_20171011-210635

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

IMG_0118 IMG_0119

More information

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

Intune and Zimperium – Part 1: Configure the integration

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

Introduction

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

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

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

Configuration

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

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

Zimperium configuration

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

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

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

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

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

4b EditMDM02_zConsoleZimperium zConsole needs the following permissions:

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

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

4c EditMDM02_zIPSiOSZimperium zIPS iOS needs the following permissions:

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

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

4d EditMDM02_zIPSAndroidZimperium zIPS Android needs the following permissions:

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

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

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

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

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

Microsoft Intune configuration

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

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

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

Results

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

MDMSettings_Results01 MDMSettings_Results02

More information

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

More differentiation options for device health attestation

This week a short blog post, as it’s written during my vacation, about the new differentiation options in device health attestation for compliance policies. This post is basically an addition to my post about conditional access and health attestation. Back then, a compliance policy could only check for the overall health status reported by the Health Attestation Service. That is changed now. Now it’s possible to differentiate between the different data points of the Health Attestation Service. In this post I’ll briefly go through these new configuration options for Microsoft Intune hybrid and Microsoft Intune standalone.

Configuration

Now let’s have a look at the new configuration options for the differentiation between the different data points of the Health Attestation Service. Below are the configuration guidelines for Microsoft Intune hybrid and Microsoft Intune standalone. The guidelines for Microsoft Intune hybrid require Configuration Manager 1706, or later, and both guidelines also contain the configurable data points.

Environment Configuration guidelines
Microsoft Intune hybrid HAS_HybridThe configuration in Microsoft Intune hybrid can be performed by starting the Create Compliance Policy Wizard in the Configuration Manager administration console. Make sure to select Compliance rules for devices managed without Configuration Manager client on the General page and to select Windows 10 on the Supported Platforms page. Now select New on the Rules page and the condition Reported as healthy by Health Attestation Service can be added. After selecting the condition it’s possible to configure the required status per data point. This includes BitLocker, Secure Boot, Code Integrity and Early Launch Anti-Malware (ELAM).

Microsoft Intune standalone (Azure portal)

HAS_StandaloneThe configuration in Microsoft Intune standalone, in the Azure portal, can be performed by creating a Device compliance policy. Create a new policy, select Windows 10 and later as Platform and select Settings > Device Health. This enables the configuration of the the required status per data point of the Health Attestation Service. This includes BitLocker, Secure Boot and Code Integrity.

Note: This enables new scenarios in which it’s possible to not require BitLocker on VMs, or in which it’s possible to not require ELAM due to it’s quirks with hibernation.

Conditional access for Skype for Business Online

Microsoft_Skype_for_Business_215x215This week another post about conditional access. This time about conditional access for Skype for Business Online. With this post I want to create more awareness for the availability of this feature and I want to show the currently available configuration options. During this post I’ll go into more detail about the prerequisites, the configuration and the end-users experience. The configurations that I’ll provide, are provided for Microsoft Intune standalone and Microsoft Intune hybrid.

Prerequisites

Before starting with the configuration steps for conditional access for Skype for Business Online, there are a few technical prerequisites that should be in place, or should be known.

  • Modern authentication must be enabled for Skype for Business Online. At this moment modern authentication must be enabled by enrolling into this Microsoft Connect program;
  • The end-user must use Skype for Business Online. Conditional access will not be applied to end-users who are in a Skype for Business on-premises deployment;
  • The end-user must use an Android or an iOS device. At this moment conditional access for Skype for Business Online is only supported for Android and iOS devices.

Configuration

The configuration of conditional access for Skype for Business Online contains two steps. The first step is to configure the Skype for Business Online policy and the second, and also optional, step is to configure the compliance policy.

Step 1: Skype for Business Online policy

Let’s start with the first step, which is the configuration of the Skype for Business Online policy. This policy makes sure that only managed and compliant devices can access Skype for Business Online. This policy will be be stored and targeted in Azure AD. The configuration of the Skype for Business Online policy is the same for Microsoft Intune standalone and Microsoft Intune hybrid. The configuration has to be done through the Microsoft Intune administration console. Keep in mind that after saving the policy, it takes effect immediately

Environment Configuration
Microsoft Intune standalone and Microsoft Intune hybrid

SfBPolicyIn the Microsoft Intune administration console navigate to Policy > Conditional Access > Skype for Business Online Policy;

To enable the Skype for Business Online policy select Enable conditional access policy and select the platforms to apply the conditional access policy to. The options are iOS and Android.

To make sure that the Skype for Business Online policy is targeted to specific users, configure an Azure AD security group as a Targeted Group and, when there are users that need to be exempted, make sure to configure an Azure AD security group as an Exempted Group.

Step 2: Compliance policy

The next step is the configuration of the compliance policy. This policy defines the rules and settings that a device must comply with in order to be considered compliant by conditional access polices. The configuration of the compliance policy differs between Microsoft Intune standalone and Microsoft Intune hybrid. After creating the compliance policy, it can be deployed to users like any other policy. Keep in mind is that it’s not required to configure and deploy a compliance policy. When no compliance policy is configured and deployed, the device will automatically be considered compliant.

Environment Configuration
Microsoft Intune standalone

MSIntuneSA_CPIn the Microsoft Intune administration console navigate to Policy > Conditional Access > Compliance Policies and click Add….

To configure a compliance policy,  choose, based on the requirements, between the applicable Password, Advanced Password Settings, Encryption, Email Profiles, Windows Device Health Attestation, Jailbreak and Operating System Version settings.

Microsoft Intune hybrid

MSIntuneHy_CPIn the Configuration Manager administration console navigate to Assets and Compliance > Overview > Compliance Settings > Compliance Policies and click Create Compliance Policy.

To configure a compliance policy, choose, based on the requirements, during the Create Compliance Policy Wizard the Supported Platforms and choose between the applicable Password, Advanced Password Settings, Encryption, Email Profiles, Windows Device Health Attestation, Jailbreak and Operating System Version Rules.

Note: Compliance policies can be used independently of conditional access. When used independently, the targeted devices are evaluated and reported with their compliance status.

End-user experience

After the configuration of the Skype for Business Online policy and the compliancy policy is completed, it’s time to look at the end-user experience. An enrolled and compliant device will give the end-user the normal experience. A not enrolled device, or a not compliant compliant device, will give the end-user a message based on the status of the device, when the end-user is trying to access Skype for Business Online. Those messages are shown below, using an iOS device as an example.

Not enrolled Not compliant
IMG_0038 IMG_0039

More information

For more information about conditional access, related to the Skype for Business Online Policy and the Compliance Policies, please refer to the following articles:

Conditional access and health attestation

This week another blog post about conditional access. And another blog post that is triggered by a feature that is introduced in ConfigMgr 1602. However, this time it’s about a feature that already did exist in Microsoft Intune standalone. I’m talking about the new conditional access rule that uses the Health Attestation Service. This new rule creates the ability to ensure that Windows 10 devices have trustworthy BIOS, TPM, and boot software configurations enabled.

In this blog post I’ll show the detailed configuration steps for Microsoft Intune hybrid and I’ll briefly note the most important configurations for Microsoft Intune standalone.

Introduction

Device health attestation is an additional level of restricting access to Exchange Online and SharePoint Online for Windows 10 devices. Currently only available for Windows 10 devices that are managed via OMA-DM. It adds the ability to create compliance policies that require Windows 10 devices to report as healthy. Device health attestation can be used to ensure that the following trustworthy configurations are enabled:

  • BitLocker: BitLocker provides encryption for all data stored on the Windows operating system volume.
  • Code integrity: Code Integrity provides improvements to the security of the operating system by validating the integrity of a driver, or system file, each time it is loaded into memory.
  • Early-launch antimalware (only applies to PCs): Early launch anti-malware (ELAM) provides protection for computers when they start up and before third-party drivers initialize.
  • Secure boot: Secure boot provides a security standard, which is developed by members of the PC industry, to help make sure that a PC boots with only software that is trusted by the PC manufacturer.

Note: A Windows 10 device must be compliant to all of the applicable configurations to be reported as healthy by the Health Attestation Service.

Pre-configuration

Before looking at the configuration of conditional access and device health attestation, I will begin with mentioning a new client setting and the health attestation dashboard. This is at least as important, as it will provide a good understanding about the impact of using conditional access based on the status reported by the Health Attestation Service.

Default client settings

To start with collecting information about the status, reported by the Health Attestation Service, of Windows 10 devices, it’s good to start with enabling the communication with the Health Attestation Service,. The following 2 steps will make sure that the information will be collected.

1 In the Configuration Manager administration console, navigate to Administration > Overview > Client Settings and open the Default Client Settings;
2

CA_ClientSettings_HAIn the Default Client Setting, navigate to Computer Agent and select Yes with Enable communication with Health Attestation Service and click OK to close the Default Client Settings..

Health attestation dashboard

After configuring the Default Client Settings, the information of the Health Attestation Service, on Windows 10 devices, will start showing in the health attestation dashboard and the List of devices by Health Attestation state report. This information can be used to get a good understanding about the impact of enabling conditional access based on the  status reported by the Health Attestation Service. The health attestation dashboard is available by navigating to Monitoring > Overview > Security > Health Attestation and will look like the following example.

CA_Intune_HealthAttestation

Note: In Microsoft Intune standalone similar reports are available, in the Reports section, named Health Attestation Reports.

Configuration

Let’s continue with looking at the real configuration for conditional access. I will start with briefly mentioning the conditional access policy and I’ll end this configuration section with going through all the required steps for creating the compliance policy.

Conditional access policy

Now that I know what the impact will be of using the health of a Windows 10 device, reported by the Health Attestation Service, I can start with enabling conditional access. Just like last week, I’ll only mention the conditional access policy briefly. It’s important that the setting Windows must meet the following requirements is selected and configured to Devices must be compliant. Also, for supporting Windows 10 mobile, it’s important to also select Windows 10 Mobile. These settings can be configured as shown below for Exchange Online and SharePoint Online.

Exchange Online Policy SharePoint Online Policy
CA_ExchOnl_Win10 CA_SPOnl_Win10

Compliance policy

Like last week, the more interesting configuration is the configuration of the new compliance policy. The following 9 steps will go through the creation of the compliance policy. After the creation of the compliancy policy, it can be deployed, like any other policy, to users.

1 In the Configuration Manager administration console, navigate to Assets and Compliance > Overview > Compliance Settings > Compliance Policies;
2 On the Home tab, click Create Compliance Policy to open the Create Compliance Policy Wizard;
3

On the General page, specify the following information and click Next;

  • CA_ConfigMgrIntune_CP_GeneralName: [Specify a unique name for the compliance policy]
  • Description: [Specify details that help identifying the compliance policy]
  • Select Compliance rules for devices managed without the Configuration Manager client with Specify the type of compliance policy that you want to create
    • Select Windows 8.1 and Windows 10

Note: Select Windows Phone and Windows 10 Mobile for supporting the configuration on Windows 10 Mobile devices.

4

On the Supported Platforms page, select the following platforms and click Next;

  • CA_ConfigMgrIntune_CP_PlatformAll Windows 10 (64-bit)
  • All Windows 10 (32-bit)

Note: Select All Windows 10 Mobile and higher for supporting the configuration on Windows 10 Mobile devices.

5 On the Rules page, click New… to open the Add Rule dialog box;
6

ICA_ConfigMgrIntune_CP_AddRulen the Add Rule dialog box, select the Reported as healthy by the Health Attestation Service rule and click OK to return to the Rules page;

7

CA_ConfigMgrIntune_CP_RulesBack on the Rules page, verify the created configuration and click Next;

8 On the Summary page, click Next
9 On the Completion page, click Close.
CA_Intune_CompliancePolicyNote: In Microsoft Intune standalone a similar compliance policy setting is available, in the Device Health section, named Require devices to be reported as healthy.

End-user experience

Now it’s time to look at the end-user experience. This time I won’t show the end-user experience of a non-compliant device connecting to Exchange Online, or SharePoint Online, as it’s similar to the messages shown during last weeks post. This time I’ll only show the end-user experience in the Company Portal app on a Windows 10 Desktop device and a Windows 10 Mobile device. The messages will be similar as shown below. It will not just show a non-compliant device, it will actually show which configuration is reported as not healthy by the Health Attestation Service.

Non-compliant Compliant
CA_Intune_CompanyPortal CA_Intune_CompanyPortal2
wp_ss_20160319_0001 wp_ss_20160319_0002

More information

For more information about conditional access, Windows 10 device health attestation and the HealthAttestation CSP, please refer to:

My Experts Live session and content

ExpertsLive2015November has been a crazy month for me so far. The frequent visitors of my blog might have noticed a complete silence the last couple of weeks. Well, it’s time to break that silence again! This month started with my first MVP Summit and I have to say that it would be awesome to be there again next year!

After that I had the great opportunity to present on Experts Live 2015. I had a session about conditional access and mobile application management. This post will contain the slide deck of that session and the movies of the demos. The sessions were not recorded, but as I always create movies of my demos, as a backup scenario, I thought lets post those movies instead.

Slide deck

ExpertsLive_SlideLet’s start with the slide deck of my session. The PDF of my slide deck will be made available on the site of Experts Live and is available for download on my own site by clicking on picture of my slide deck here on the side. This will start a direct download.

Demos

Let’s continue with the bigger part of this post, the movies of my demos. These movies were created as a backup scenario, in case there would be a problem with the Internet connection. Even to those that attended my session, these movies will include new information. During my session I could only show the Microsoft Intune hybrid configurations, due to time considerations. These movies also include the Microsoft Intune standalone configurations.

Demo – Conditional access on Exchange Online and SharePoint Online

During this demo I’ll walkthrough the end-user experience for conditional access. This provides a clear overview of what conditional access is and what it will be for the end-user. During this demo I’ll go through the following actions, on a Dutch iPad:

  • Go to Settings > General and show the missing Management Profile;
  • Go to Settings > Mail and add <user>@petervanderwoude.nl;
  • Open the native mail app and show the conditional access email;
  • Open the Microsoft Outlook app and show the enrollment message for <user>@petervanderwoude.nl;
  • Open the Microsoft Intune Company Portal app and walkthrough the steps to enroll the device;
  • During the enrollment solve the issue with the configured mail profile;
  • Open the native mail app and show the access to <user>@petervanderwoude.nl;
  • Open the Microsoft Outlook app and show the access to <user>@petervanderwoude.nl.

Demo – Configuring conditional access on Exchange Online and SharePoint Online

During this demo I’ll walkthrough the settings that are available for configuring compliance policies and conditional access on Exchange Online and SharePoint Online for Microsoft Intune standalone and hybrid. This demo is cut in four parts, one for conditional access on Exchange Online, one for conditional access SharePoint Online, one for compliance policies in Microsoft Intune hybrid and one for compliance policies in Microsoft Intune standalone. During the first part I’ll go through the following actions:

  • Open the Configuration Manager console and navigate to Assets and Compliance;
  • Navigate to Compliance Settings > Conditional Access > Exchange Online;
  • Select Configure conditional access policy in the Intune console;
  • Select Enable conditional access policy for Exchange Online;
  • Walkthrough the settings for apps using modern authentication;
  • Walkthrough the settings for apps using basic authentication;
  • Walkthrough the targeted and exempted groups;
  • (Additional) Show the Service to Service Connector.

During the second part I’ll go through the following actions:

  • Open the Configuration Manager console and navigate to Assets and Compliance;
  • Navigate to Compliance Settings > Conditional Access > SharePoint Online;
  • Select Configure conditional access policy in the Intune console;
  • Select Enable conditional access policy for SharePoint Online;
  • Walkthrough the settings for apps using modern authentication;
  • Walkthrough the targeted and exempted groups.

During the third part I’ll go through the following actions:

  • Open the Configuration Manager console and navigate to Assets and Compliance;
  • Navigate to Compliance Settings > Compliance Policies;
  • Select Create Compliance Policy;
  • Walkthrough the available Rules and the impact of the selected Platform;
  • Walkthrough the Deployment Settings.

During the fourth part I’ll go through the following actions:

  • Open the Microsoft Intune console and navigate to POLICY > Configuration Policies;
  • Select Add…;
  • Walkthrough the available Policies Settings;
  • Walkthrough the Deployment options.

Demo – Mobile application management

During this demo I’ll walkthrough the end-user experience for mobile application management. This provides a clear overview of what can be achieved with mobile application management and what the experience will be for the end-user. This demo is cut in two parts, one for starting to manage an app and one for the managed app experience. During the first part of this demo I’ll go through the following actions, on a Dutch iPad:

  • Go to Settings > General and show the missing apps in the Management Profile;
  • Open the Microsoft Intune Company Portal app;
  • Install, configure and allow management of the Microsoft Outlook app;
  • Go to Settings > General and show the Microsoft Outlook app in the Management Profile.

During the second part of this demo I’ll go through the following actions, on an English iPad:

  • Open the Microsoft Outlook app;
  • Walkthrough the behavior of blocked and allowed URLs from company email;
  • Walkthrough the behavior of copying and pasting content from company email;
  • Walkthrough the behavior of attachments in company email.

Demo – Configuring mobile application management

During this demo I’ll walkthrough the settings that are available for configuring mobile application management for Microsoft Intune standalone and hybrid. This demo is cut in two parts, one for Microsoft Intune hybrid and one for Microsoft Intune standalone. During the first part I’ll go through the following actions:

  • Open the Configuration Manager console and navigate to Software Library;
  • Navigate to Application Management > Application Management Policies;
  • Select Create Application Management Policy;
  • Walkthrough the Policy Types and the impact on the Policy Settings;
  • Walkthrough the Deployment options.

During the second part I’ll go through the following actions:

  • Open the Microsoft Intune console and navigate to POLICY > Configuration Policies;
  • Select Add…;
  • Select Software > Mobile Application Management (iOS 7.1 and later);
  • Select Create a Custom Policy;
  • Walkthrough the available Policies Settings;
  • Walkthrough the Deployment options.

Demo – Retire mobile device

The last demo showed the impact of retiring a mobile device. This is the only demo that I didn’t record, simply because I made it up at the last moment and I didn’t decide until the end of the session how I was going to retire the mobile device. Depending on the available time I would pick between the Configuration Manager console, PowerShell, or the iPad.

The three layers of protection with conditional access for Exchange email

In this blog post I would like to write a little about, what I like to call, the three layers of protection with conditional access for Exchange email. No, I don’t mean that a device has to be 1) enrolled in Microsoft Intune, 2) workplace joined and 3) compliant with any Microsoft Intune compliance policies. What I do mean is related to company data, in this case company email, and the protection of it on mobile devices. That means three different layers of protection for Exchange email on mobile devices. From basic protection to almost complete protection.

The first layer of protection

ConditionalAccess_Level1The first, basic, layer of protection is simply using an Exchange Online Policy, or an Exchange On-premises Policy. These policies make it possible to protect Exchange email by blocking the access, via ActiveSync, to Exchange. It, of course, doesn’t block connections via OWA.

By enabling these policies, a mobile device, of an user that’s in a Targeted Group and not in an Exempted Group, will be blocked from ActiveSync when it’s not enrolled in Microsoft Intune, and/or not compliant with any targeted Microsoft Intune compliance policies. When no compliance policy is targeted, the device will automatically be evaluated as compliant. Also, not supported and exempted platforms can be blocked access through these policies.

I like to call this the first layer of protection, as it provides very basic protection, to the Exchange email, on the mobile device, by simply making sure that the mobile device is enrolled in Microsoft Intune. That enrollment makes sure that the connected mobile devices are known by the IT organization.

The second layer of protection

ConditionalAccess_Level2The second layer of protection is adding a few requirements, by using a Conditional Access Policy. A Conditional Access Policy can be used to add additional requirements to the mobile devices that want to connect to Exchange email, via ActiveSync.

These policies can be used to specify additional requirements to the password and encryption of the mobile device. Besides that it’s possible to, in case of iOS, block jailbroken mobile devices and, in case of Android, rooted mobile devices.

I like to call this the second layer of protection, as it already adds another form of protection, to the Exchange email, on the mobile device, by requiring additional configurations to mobile devices.

The third layer of protection

ConditionalAccess_Level3The third layer of protection is adding another, very important, requirement, by using a Conditional Access Policy in combination with an Email Profile.

This is basically nothing more than an additional configuration in the Conditional Access Policy, but it adds a lot more. It requires that the mobile device (currently only iOS) can only connect to Exchange email, via ActiveSync, when it’s using a specific Email Profile that’s configured via Microsoft Intune.

I like to call this the third layer of protection, as it adds almost complete protection to the company email that’s available on the mobile device. As the mobile device can only connect via an Email Profile, configured via Microsoft Intune, the company email will also be removed when the device is removed from Microsoft Intune.

Conclusion

These three layers of protection together make a very powerful combination for protecting company email. Especially by adding the third layer, it ensures that the available company email will also be removed again.

A good thing to know is that the (managed) Microsoft Outlook app can also still connect to Exchange email, via ActiveSync, as long as the mobile device is enrolled and compliant. More about this in my next blog post.

Note: Even though this post only shows Microsoft Intune standalone screenshots, the same is applicable to Microsoft Intune hybrid.

More information

For a lot more information about conditional access and compliance policies, please refer to the following links.