Block access to company resources if certain apps are installed

This week is all about device compliance. More specifically, this week is all about the just introduced capability to block access to company resources if certain apps are installed. This enables organizations to truly blacklist specific apps that are not allowed when using devices to access company resources. In this case it’s not about the apps used for accessing the company resources, but it’s really about the apps installed on the device. In this post I’ll provide the configuration steps, by using OWA for iPad as an example, followed by the end-user experience.

Configuration

Before starting with the actual configuration, it’s important to get the bundle ID of the iOS app that cannot be installed. These steps are very clearly documented here. I will use OWA for iPad as an example, which has the following bundle ID: com.microsoft.exchange.ipad.

Now let’s continue by having a look at the configuration steps. The following five steps walk through the creation of a device compliance policy with at least the configuration of OWA for iPad as a restricted app. Within a device compliance policy a restricted app is what was earlier described, in this post, as blacklisted apps. After the creation of the device compliance policy, simply assign it to the applicable user group.

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 Name, select iOS with Platform and select Settings to open the iOS compliance policy blade;

Note: This is currently an iOS only configuration. Android is expected a bit later.

4 On the iOS compliance policy blade, select System Security to open the System Security blade;
5

On the System Security blade, navigate to the Device Security section, provide the App name, the App Bundle ID and click Add, followed by and clicking OK, OK and Create.

Note: The provided App name will be mentioned in the potential non-compliance message to the end-user and the App Bundle ID is in this example the id of the OWA for iPad app.

MSI-RestrictApp

Note: To complete this configuration, it must be used in combination with a conditional access policy that requires the device to be marked as compliant.

End-user experience

Now let’s end this post with the end-user experience. Let’s do that by looking at the end-user experience on an iOS device with OWA for iPad installed. On the left is the default message that is displayed to the end-user when trying to access company data on a non-compliant device. On the right is the message that the end-user will receive in the Company Portal app related to the compliance state of the device. In this case it will provide the end-user with a list of disallowed apps that should be uninstalled. The list shows the name of the app, as provided in the compliance policy.

IMG_0143 IMG_0144

More information

For more information about blocking access if certain apps are installed, refer to the documentation about adding a device compliance policy for iOS devices in Intune.

Conditional access and legacy authentication

This week is still all about conditional access. More specifically, the recently introduced feature to create conditions based on the use of legacy authentication (including older Office versions), which is currently still in preview. By now, I’ve done my fair share of posts regarding blocking legacy authentication (see for example here and here), but now it’s literally getting super easy. And no need for AD FS anymore. This helps with easily closing another backdoor, as previously legacy authentication simply bypassed any conditional access policy. In this post I’ll walk through the required configurations followed by the end-user experience.

Configuration

Before going through the configuration let’s start with a quick reminder about legacy authentication. Very simplistically said, legacy authentication is basic authentication that uses a single authentication factor in the form of a username and password and cannot force a second authentication factor (think about protocols like, POP3, IMAP, SMTP, MAPI and EWS and apps like, Office 2010). As I have no need for legacy authentication in my environment, I will block all legacy authentication to my apps. The following seven steps walk through the simple configuration to create a conditional access policy that blocks the access to all cloud apps for all users when using legacy clients.

1 Open the Azure portal and navigate to Intune > Conditional access > Policies or to Azure Active Directory > Conditional access > Policies;
2 On the Policies blade, click New policy to open the New blade;
3 AAD_CA_UsersAndGroups02On 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 AAD_CA_CloudApps02On the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, select All cloud apps and click Done;
5 AAD_CA_ClientApps02On the New blade, select the Conditions assignment to open the Conditions blade. On the Conditions blade, select Client apps (preview) to open the Client apps (preview) blade. On the Client apps (preview) blade, click Yes with Configure, select Mobile apps and desktop clients > Other clients and click Done and Done;
6

AAD_CA_Grant02On the New blade, select the Grant access control to open the Grant blade. On the Grant blade, select Block access and click Select.

Note: Make sure that there are no apps within the environment that still need basic authentication, as this configuration will block all of it.

7 Open the New blade, select On with Enable policy and click Create;

Note: It can take up to 24 hours for the policy to take effect.

End-user experience

One of the best use cases is an old Office version. Office 2010 and the default configuration of Office 2013, both use basic authentication. Office 2016 and later use modern authentication by default. Due to the way basic authentication works the end-user experience is not pretty and will not be pretty. Below is an example of the end-user experience when using Outlook 2010 for connection to Exchange Online. As mentioned, it’s effective and not pretty.

BlockOutlook

More information

For more information about conditional access and device state, please refer to this article about Conditions in Azure Active Directory conditional access | Client apps.

Conditional access and device state

This week back in conditional access again. More specifically, the recently introduced feature to exclude devices based on the device state, which is currently still in preview. This enables organizations to exclude managed devices (Hybrid Azure AD joined and/ or compliant) from a conditional access policy. That means that the conditional access policy will only be applicable to unmanaged devices. This enables new scenarios and makes existing scenarios easier. Think about using session controls to enable a limited experience within cloud apps, for unmanaged devices only. In this post I’ll show the very simply and straight forward configuration, followed by the end-user experience.

Configuration

The configurations that make the most sense for using the device state are related to the access controls. At least, in my opinion. All other scenario’s can also be created by using the already available options. It just makes it a bit easier. By looking at the access controls, the session related controls are the most obvious configuration to start with. The Use app enforced restrictions session control enables organizations to enable a limited experience within a cloud app, for, in this case, unmanaged devices and the Use proxy enforced restrictions session control enables organizations to sent the user sign-in information to Microsoft Cloud App Security, also for, in this case, unmanaged devices. That enables additional actions based on the users sign-in activity. The following seven steps walk through the simple configuration to create a conditional access policy that uses the proxy enforced restriction session control.

1 Open the Azure portal and navigate to Intune > Conditional access > Policies or to Azure Active Directory > Conditional access > Policies;
2 On the Policies blade, click New policy to open the New blade;
3 AAD_CA_UsersAndGroups01On 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 AAD_CA_CloudApps01On the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, select All cloud apps and click Done;
5

AAD_CA_DeviceState01On the New blade, select the Conditions assignment to open the Conditions blade. On the Conditions blade, select Device state (preview) to open the Device state (preview) blade. On the Device state (preview) blade, click Yes with Configure, click Exclude, select Device Hybrid Azure AD joined and Device marked as compliant and click Done and Done;

Note: Think about the easier scenarios that can be created by using the option to exclude domain joined devices from the conditional access policy.

6

AAD_CA_Session01On the New blade, select the Session access control to open the Session blade. On the Session blade, select Use proxy enforced restrictions (preview) and click Select.

Note: Optionally configure additional a Cloud App Security Access policy or Cloud App Security Session policy to enable additional behavior based on the sign-in information of the user. For example, block the sign-in for a specific cloud app.

7 Open the New blade, select On with Enable policy and click Create;

Note: Basically the Azure AD conditional access policy and the Conditional Access App Control access or session policy will work together to perform real-time monitoring and control.

End-user experience

Let’s end this post with the end-user experience, followed with the administrator experience. As I only have connectors for Office 365 and Microsoft Azure in my Cloud App Security, I can only create access policies for the connected apps. These access policies can be used to simply monitor the activity or to actually block the session and display a custom block message. Besides that, the policy can also create alerts. In the dashboard, via email and via text message.

I created a policy that would block the session of the end-user with a custom message as shown below. Yes, I could have blocked the session already with conditional access itself, but this provides me with some more information about the sign-in.

CloudAppSecurity_Blocked01

When I’m now looking in the Cloud App Security dashboard, I can already see the alerts. When I navigate to either Investigate > Activity log or Alerts, I can look at the information as shown below. That provides me with the source, which, in this case. is Azure AD conditional access, the matched policy and information about the user and the device (as shown below). Pretty nice.

AppDashboard01

More information

For more information about conditional access and device state, please refer to this article about Conditions in Azure Active Directory conditional access | Device state.

Conditional access and guest users

This week back in conditional access. More specifically, the recently introduced feature to assign a conditional access policy to All guest users, which is currently still in preview. At the same time also the ability to assign to Directory roles was introduced. The idea for both is the same. The first is to specifically assign to guest users and the second is to assign to specific roles in the directory. This post will focus on the first scenario. I’ll show the very simply and straight forward configuration, followed by the end-user experience.

Configuration

Microsoft Teams is getting really hot for collaboration. This also creates a very low bar for inviting external parties (B2B) to collaborate with. Working together. Of course this should be facilitated to enable the productivity of the end-user. However, that doesn’t mean that there shouldn’t be additional security in-place. Even if it’s just to ensure the identity of the guest user. For example, enable multi-factor authentication for guest users. The following steps walk through the simple configuration to enable multi-factor authentication for guest users on Microsoft Teams.

1 Open the Azure portal and navigate to Intune > Conditional access > Policies or to Azure Active Directory > Conditional access > Policies;
2 On the Policies blade, click New policy to open the New blade;
3 AAD_CA_UsersAndGroupOn the New blade, select the Users and groups assignment to open the Users and groups blade. On the Users and groups blade, select Select users and groups > All guest users (preview) and click Done;
4 AAD_CA_CloudAppsOn the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, select Select apps > Microsoft Teams and click Done;
5

AAD_CA_GrantOn the New blade, select the Grant access control to open the Grant blade. On the Grant blade, select Grant access > Require multi-factor authentication and click Select.

6 Open the New blade, select On with Enable policy and click Create;

Note: Guest user matches any user account with the userType attribute set to guest.

End-user experience

Now let’s end this post by looking at the end-user experience. Once the (external) user is invited for using Microsoft Teams, it will first have to configure MFA (see screenshot on the left). After that the user will be able to access Microsoft Teams by using its favorite MFA option. In my example I picked the Microsoft Authenticator app, as it will clearly show that an external account was used (see screenshot on the right). It clearly shows #EXT and onmicrosoft.com.

Screenshot_MFA Screenshot_Authenticator

More information

For more information about conditional access and assignments, please refer to this article about Conditions in Azure Active Directory conditional access | Users and groups.

Default device compliance status

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

Introduction

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

Configuration

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

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

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

End-user experience

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

NoCompliancePolicy01 NoCompliancePolicy02

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

20180411_182037518_iOS Screenshot_20180411-205045_Company Portal

More information

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

Conditional access and Windows 7 domain joined devices

This week is all about conditional access in combination with Windows 7 domain joined devices. I know, simple solution, migrate as fast as possible to Windows 10. Having said that, it’s not always possible to simply migrate those devices to Windows 10 and in the mean time those devices do need access to Office 365. That’s why I thought it would be good to write something about those Windows 7 domain joined devices in combination with conditional access. As Windows 7 should not be a reason to not implement conditional access. In this post I’ll provide the details about the additional configurations that need to be in place, to allow Windows 7 domain joined devices access to Office 365. So, not directly about conditional access, but about the configurations that must be in place.

Prerequisites

Before looking at the configuration, let’s start with a list of prerequisites that need to be in place. These are the general configurations that also need to be in place for Windows 10. Also, the configurations are nowadays triggered and/or mentioned during the installation of Azure AD Connect.

  • Configure service connection point – The service connection point (SCP) object is used by devices, during the registration, to discover Azure AD tenant information;
  • Setup issuance of claims – In a federated Azure AD configuration, devices rely on AD FS to authenticate to Azure AD. Devices authenticate to get an access token to register against the Azure Active Directory Device Registration Service (Azure DRS).

Configurations

Now let’s continue with the configurations specific to Windows 7, and other down-level operating systems. Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012 and Windows Server 2012 R2, are considered down-level operating systems. Down-level operating systems require the following additional configurations:

  1. Configure Azure AD to enable users to register devices;
  2. Configure on-premises AD FS  to issue claims to support Integrated Windows Authentication;
  3. Add Azure AD device authentication end-point to the local Intranet zones;
  4. Install the Microsoft Workplace Join for non-Windows 10 computers package.

Configuration 1: Configure Azure AD

The first configuration, that must be in place, is that users must be enabled to register devices in Azure AD. The following 2 steps walk through that configuration. When using enrollment with Microsoft Intune, or MDM for Office 365, this configuration will be in place automatically.

1 Open the Azure portal and navigate to Azure Active Directory > Devices > Device settings to open the Device  Device settings blade;
2 On the Device – Device settings blade, select All with Users may register their devices with Azure AD and click Save;

W7_DeviceRegistration

Configuration 2: Configure on-premises AD FS

Before starting with the second configuration, it’s good to mention that it’s no longer required to have an on-premises AD FS to register domain joined computers with Azure AD. Having mentioned that, the second configuration, that must be in place, when using AD FS, is that the on-premises AD FS must support issuing the authenticationmehod and wiaormultiauthn claims when receiving an authentication request to the Office 365 relying party trust. This can be achieved by adding an issuance transform rule that passes-through the authentication method. The following 5 steps walk through that configuration by using AD FS 4.0 (Windows Server 2016).

1 Open the AD FS Management console and navigate to AD FS > Relying Party Trusts;
2 Right-click the Microsoft Office 365 Identity Platform relying party trust and select Edit Claim Issuance Policy;
3 On the Issuance Transform Rules tab, select Add Rule to open the Add Transform Claim Rule Wizard;
4 On the Choose Rule Type page, select Send Claims Using a Custom Rule and click Next;
5

W7_CustomClaimOn the Configure Claim Rule page, provide the following information and click Finish;

  • Claim rule name: Auth Method Claim Rule;
  • Claim rule: c:[Type == “http://schemas.microsoft.com/claims/authnmethodsreferences”] => issue(claim = c);

To finish the AD FS configuration, run the following PowerShell command to allow IWA, or MFA, for the Office 365 relying party trust.

Set-AdfsRelyingPartyTrust -TargetName “Microsoft Office 365 Identity Platform” -AllowedAuthenticationClassReferences wiaormultiauthn

Configuration 3: Add end-points to local intranet zones

The third configuration, that must be in place, is that the Azure AD device authentication end-point must be added to the local intranet zones. That should avoid certificate prompts. In my case the device registration would even fail, with a clear error in the Event Viewer (Event ID: 406). That event literally provides the solution of adding the URL to the local intranet zone. The following 6 steps walk through the configuration by assuming that an existing policy is available.

1 Open the Group Policy Management console and navigate to Group Policy Management > Forest > Domains;
2 Right-click an existing GPO and select Edit;
3 In the Group Policy Management Editor, navigate to Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page;
4 Right-click Site to Zone Assignment List and select Edit;
5 In the Site to Zone Assignment List dialog box, select Enabled and click Show;
6

W7_ShowContentsIn the Show Contents dialog box, provide the following information and click OK in the open dialog boxes;

  • Value name: https://device.login.microsoftonline.com
  • Value: 1

Note: In my case I also still had to add my identity provider to the local intranet zone (which is value 1).

Configuration 4: Install Microsoft Workplace Join for non-Windows 10 computers

The fourth configuration, that must be in place, is the installation of the Microsoft Workplace Join for non-Windows 10 computers package. The installation of that package creates a scheduled task on the system that runs in the user’s context. The task is triggered when the user signs in to Windows and silently registers the device with Azure AD.

The following 7 steps walk through the simple creation of an application, for the Microsoft Workplace Join for non-Windows 10 computers package, in Configuration Manager. That application can then be deployed to the required devices. Before starting with the steps below, make sure to download the Microsoft Workplace join for non-Windows 10 computers package.

1 Open the Configuration Manager administration console and navigate to Software Library > Overview > Application Management > Applications;
2 Click Create Application to open the Create Application Wizard;
3 On the General page, provide the name and location of the MSI and click Next;
4 On the Import Information page, click Next;
5

W7_CAWOn the General Information page, provide at least the following information and click Next;

  • Name: Microsoft Workplace Join for Windows;
  • Installation program: msiexec /i “Workplace_x64.msi” /q
  • Install behavior: Install for system
6 On the Summary page, click Next;
7 On the Completion page, click Close;

Result

Let’s end this post by looking at the configuration results. The result should be that the Windows 7 domain joined devices are registered to Azure AD. The first place to look for a success is the Event Viewer. Open the Event Viewer and navigate to Applications and Services Logs > Microsoft-Workplace Join. As shown below, for a successful device registration this log should show Event ID 201 (Workplace join operation succeeded).

W7_EventViewer

The second place to look for a success is PowerShell. Simply use the Get-MsolDevice cmdlet. Below is an example of 1 of my devices, which clearly shows the version of the operating system and Domain Joined trust type.

W7_MsolDevice

The third place to look for a success, and last place that I’ll show, is the Azure portal. Now simply navigate to Azure Active Directory > Devices > All devices. Below is and example, in which I selected 1 of my devices, which clearly shows the version of the operating system and the Hybrid Azure AD joined join type.

W7_APDevice

Once the Windows 7 domain joined device is successfully registered with Azure AD, the device can be granted access to Office 365 by using the access control of Require domain joined (Hybrid Azure AD) in conditional access.

More information

For more information about Windows 7 and conditional access, refer to the following articles:

Testing conditional access policies couldn’t be easier!

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;

CAWI_Overview

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

CAWI_UsersWhen 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

CAWI_CloudAppsWhen 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

CAWI_IPThe 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

CAWI_DevicePlatformThe 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

CAWI_ClientAppThe 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

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

CAWI_CompOverview

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.

CAWI_Results_PoliciesTWApply

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.

CAWI_Results_PoliciesTWNotApply

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.

More information

For more information about the What If tool, refer to this article about the Azure Active Directory conditional access what if tool – preview.

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

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

Introduction

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

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

Configuration

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

Zimperium configuration

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

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

Zimperium_MTRP

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

Microsoft Intune configuration

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

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

Intune_DHP

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

Azure AD configuration

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

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

AzureAD_CAP

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

End-user experience

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

Screenshot_20171011-204124 Screenshot_20171011-210635

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

IMG_0118 IMG_0119

More information

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

Intune and Zimperium – Part 1: Configure the integration

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

Introduction

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

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

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

Configuration

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

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

Zimperium configuration

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

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

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

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

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

4b EditMDM02_zConsoleZimperium zConsole needs the following permissions:

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

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

4c EditMDM02_zIPSiOSZimperium zIPS iOS needs the following permissions:

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

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

4d EditMDM02_zIPSAndroidZimperium zIPS Android needs the following permissions:

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

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

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

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

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

Microsoft Intune configuration

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

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

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

Results

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

MDMSettings_Results01 MDMSettings_Results02

More information

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

Conditional access and terms of use

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

Introduction

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

Configuration

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

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

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

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

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

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

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

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

End-user experience

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

IMG_0115 IMG_0116

More information

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