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, Windows 10 and Microsoft Intune: What are the compliance options?

Recently Microsoft released a couple of blog posts about The Path to Modernizing Windows Management and about Clear & Simple Guidance: When ConfigMgr and Intune should be used with Windows 10, which should be really helpful with deciding how to managing the Windows 10 devices within an organization. I would really recommend everybody to read those posts. This blog post will not be directly related, but will continue on a more detailed level about the options for conditional access and Windows 10 devices.

In this blog post I will provide nice tables of the different compliance rules, for Windows 10 devices, that are currently available for Microsoft Intune standalone and Microsoft Intune hybrid. In those tables I’ll show the different management scenarios and the currently available applicable compliance rules.

Overview

Before I’ll start with the overview, it’s good to provide a short explanation about the distinction between the conditional access policy and the compliance policy.

The conditional access policy is a required configuration to enable conditional access on a particular service and to help secure access to that particular service. In the conditional access policy, the targeted platforms and the targeted users of devices are configured. Also, important for Windows 10 devices, in the conditional access policy it is possible to determine if Windows 10 devices must be compliant or domain joined.

The compliance policies, on the other hand, are optional additional rules that can evaluate settings like PIN and encryption. The devices of targeted users must be compliant to those additional rules. When there are no compliance policies deployed, the device will automatically be evaluated as compliant.

Microsoft Intune standalone

Now let’s start with the overview of available compliance rules in Microsoft Intune standalone. In Microsoft Intune standalone, a Windows 10 device can be managed by the Microsoft Intune client and it can be enrolled as a mobile device. Those two options will be mentioned in the following overview table. Spoiler, there are no compliance rules available for the Microsoft Intune client. That makes being domain joined the only additional configuration for those devices.

Intune client MDM
Allow simple passwords N/A Yes (Mobile only)
Maximum Windows Phone or Windows 10 Mobile version N/A Yes (Mobile only)
Maximum Windows version N/A Yes (Desktop only)
Minutes of inactivity before password is required N/A Yes
Minimum password length N/A Yes
Minimum Windows Phone or Windows 10 Mobile version N/A Yes (Mobile only)
Minimum Windows version N/A Yes (Desktop only)
Require a password to unlock an idle device N/A Yes (Mobile only)
Password expiration N/A Yes
Remember password history – Prevent reuse of previous passwords N/A Yes
Required password type – Minimum number of character sets N/A Yes
Require a password to unlock mobile devices N/A Yes (Mobile only)
Require devices to be reported as healthy N/A Yes
Require encryption on mobile device N/A Yes

Microsoft Intune hybrid

Let’s continue with the overview of available compliance rules in Microsoft Intune hybrid. In Microsoft Intune hybrid, a Windows 10 device can be managed by the Microsoft Intune client, the ConfigMgr client and it can be enrolled as a mobile device. Those three options will be mentioned in the following overview table. Spoiler, there are no compliance rules available for the Microsoft Intune client. That makes being domain joined  the only additional configuration for those devices.

Intune client ConfigMgr client MDM
All required updates installed with a deadline older than X days N/A Yes N/A
Allow simple passwords N/A N/A Yes (Mobile only)
File encryption on mobile device N/A N/A Yes
Maximum operating system version N/a N/A Yes
Minimum classification of required updates N/A N/A Yes
Minimum operating system version N/A N/A Yes
Minimum password length N/A N/A Yes
Minutes of inactivity before password is required N/A N/A Yes
Require a password to unlock an idle device N/A N/A Yes (Mobile only)
Reported as healthy by Health Attestation Service N/A N/A Yes
Require Antimalware N/A Yes N/A
Require BitLocker drive encryption N/A Yes N/A
Require password settings on mobile devices N/A N/A Yes
Require registration in Azure Active Directory N/A Yes N/A

More information

For information about about conditional for Windows 10 devices with Microsoft Intune standalone or Microsoft Intune hybrid, please refer to:

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:

Conditional access for PCs managed by ConfigMgr

This blog post is about a pre-release feature, which means that it’s included in the product for early testing in a production environment, but should not be considered production ready.

This week a blog post about the Conditional access for managed PCs feature that is introduced in ConfigMgr 1602. This feature is introduced as a pre-release feature. The requirements for using Conditional access for managed PCs are similar to the requirements of the blog series that I did a few months ago about Conditional access for PCs. Make sure that those requirements are in-place before starting with the configurations described in this post.

Introduction

Conditional access for managed PCs is basically an additional level of restricting access to Exchange Online and SharePoint Online. Before the only level of restricting access was that device had to be enrolled via Microsoft Intune, or that the device had to be domain joined. Now it’s also possible to create additional compliance policies for managed PCs. Managed PCs by ConfigMgr. Those compliance policies can contain the following rules:

  • Require registration in Azure Active Directory: This rule checks if the end-user device is workplace joined to Azure AD. If not, the device is automatically registered in Azure AD. Automatic registration is currently only supported on Windows 8.1.
  • All required updates installed with a deadline older than a certain number of days: This rule checks to see if the end-user device has all required updates within the configured deadline and grace period. If not, any pending required updates are automatically installed.
  • Require BitLocker drive encryption: This is a check to see if the primary drive on the device is BitLocker encrypted. If not, access to Exchange Online and SharePoint Online is blocked.
  • Require Antimalware: This is a check to see if the antimalware software is enabled and running. If not, access to Exchange Online and SharePoint Online is blocked. At this moment only supported for System Center Endpoint Protection and Windows Defender.

Configuration

Now lets have a look at the configuration. I will briefly mention the conditional access policy, because I’ve written a lot about those in my previous blog series about Conditional access for PCs. After that I’ll go through all the required steps for creating the compliance policy and I’ll end this configuration section with the effect on the client.

Pre-release feature

As Conditional access for managed PCs is a pre-release feature, it must be specifically turned on. This can be achieved by simply performing the following 2 steps.

1 In the Configuration Manager administration console, navigate to Administration > Overview > Cloud Services > Updates and Servicing > Features;
2 Right-click Pre-release – Conditional access for managed PCs and select Turn on.

Conditional access policy

The reason why I do have to mention the conditional access policy, is one specific configuration setting. That specific setting is that the setting Windows must meet the following requirements is selected and configured to Devices must be compliant. This is very important, as any other configuration would make a domain join enough to be compliant, while in this configuration I want to create an additional compliance policy. That setting can be configured as shown below for Exchange Online and SharePoint Online.

Exchange Online Policy SharePoint Online Policy
CA_ConfigMgr_ExchangeOnline CA_ConfigMgr_SharePointOnline

Compliance policy

More interesting is the new compliance policy. Within the compliance policy it’s now possible to create a compliance policy specifically for devices managed with the ConfigMgr client. 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_ConfigMgr_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 with the Configuration Manager client with Specify the type of compliance policy that you want to create
4

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

  • CA_ConfigMgr_CP_PlatformAll Windows 7 (64-bit)
  • All Windows 7 (32-bit)
  • All Windows 8.1 (64-bit)
  • All Windows 8.1 (32-bit)
  • All Windows 10 (64-bit)
  • All Windows 10 (32-bit)
5 On the Rules page, click New… to open the Add Rule dialog box;
6

In the Add Rule dialog box, select the following rules one-by-one and click OK to return to the Rules page;

  • CA_ConfigMgr_CP_AddRuleRequire registration in Azure Active Directory
  • All required updates installed with a deadline older than X days
  • Require BitLocker drive encryption
  • Require Antimalware
7

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

Note: As this screenshot shows, none of the rules require additional configuration except for the software updates rules. That rule requires the selection of the number of days that a deadline has been passed.

8 On the Summary page, click Next
9 On the Completion page, click Close.

Policy effect

A good place to look at the effect of the compliance policy, is to look at the reports. More specifically, the reports Compliance Access Compliance for Users and Compliance Access Compliance Report. However, I still like to think that the log files are the best place to look at the effect of the compliance policy. More specifically, the DcmWmiProvider.log. That log file provides detailed information about the compliance checks that are performed. Below is a log snippet about a successful compliance check.

CreateInstanceEnumAsync called for the provider
Class name CCM_SoftwareUpdateCompliance
Days 5
CCMSoftwareUpdateCompliance 20160313160716
CCMSoftwareUpdateCompliance Select * from CCM_UpdateCIAssignment
Determined 0 as not compliant with deadline exceeded by 5 days
CCMEncryptionCompliance: Get instance of CCM_EncryptionCompliance
Detected virtual machine: Drive encryption not applicable. Setting compliance to true
Setting Encryption Compliance to: 1
CheckWPJCert – Checking Machine\ cert store
Found WorkplaceJoin cert
   Status: 2
   Error: 0
CCMAntimalwareCompliance: Get instance of CCM_AntimalwareCompliance
Retrieved RealTimeProtectionEnabled property = 1
Retrieved AntivirusEnabled property = 1
Setting Antimalware Compliance to: 1

This log snippet provides clear information about the 4 rules, of the compliance policy, that are being checked. It clearly shows the software update check, the BitLocker encryption check, the workplace join check and the antimalware check. The log snippet even provides some details about how those checks are performed. For example, it shows that my test device was a virtual machine and that, because of that, the encryption check was skipped and that the compliance, for that check, was automatically set to true.

End-user experience

Now it’s time to look at the end-user experience. At this moment the end-user experience is as shown below. When a non-compliant managed PC tries to access Exchange Online, or SharePoint Online, it will get a message as shown below. A compliant managed PC will be able to simply access Exchange Online and SharePoint Online. To get the detailed information about the compliance of the managed PC, the end-user can use the Device compliance section in Software Center, as shown below.

Non compliant Compliant
CA_ConfigMgr Not applicable. A compliant managed PC will automatically have access. Meaning there is no special screen that the en-user will get.
CA_SoftwareCenter_01 CA_SoftwareCenter_02

More information

For more information about conditional access for PCs that are managed by ConfigMgr, please refer to this article about Manage access to O365 services for PCs managed by System Center Configuration Manager.

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.