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.

Conditional access and approved client apps

This week back in conditional access. More specifically, the recently introduced requirement, in the grant control, to Require approved client apps, which is currently still in preview. That requirement feels a bit like MAM CA, but more about that later in this post. In this post, I’ll provide more information about the Require approved client apps requirements and I’ll show how to configure that requirement. I’ll end this post with the end-user experience.

Introduction

When configuring a conditional access policy, it’s now possible to configure the requirement to grant access only if a connection attempt was made by an approved client app. That’s done by using the Require approved client apps requirement. This requirement could be described as something similar as MAM CA, but with less options and straight from Azure AD. The main difference, from a configuration perspective, is that MAM CA provides more granular control over the client apps that can be used to access a specific cloud app, while this requirement in conditional access is simply on or off. On the other hand, this requirement in conditional access can be used with every cloud app, while MAM CA is only available for Exchange Online and SharePoint Online.

The approved client apps for the Require approved client apps requirement are the following apps (that all support Intune MAM):

  • Microsoft Excel
  • Microsoft OneDrive
  • Microsoft Outlook
  • Microsoft OneNote
  • Microsoft PowerPoint
  • Microsoft SharePoint
  • Microsoft Skype for Business
  • Microsoft Teams
  • Microsoft Visio
  • Microsoft Word

Keep in mind that the Require approved client apps requirement:

  • only supports iOS and Android as selected device platforms condition;
  • does not support Browser as selected client app condition;
  • supersedes the Mobile apps and desktop clients client app condition.

Configuration

Now let’s have a look at the required configuration of a conditional access policy in the Azure portal. To be able to use the Require approved client apps requirement, create a conditional access policy as shown below. The following 7 steps walk through the minimal configuration for, for example, Exchange Online.

1 Open the Azure portal and navigate to Azure Active Directory > Conditional access > Policies;
2 On the Policies blade, click New policy to open the New blade;
3 RACA_01On 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 RACA_02On the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, select Select apps to select Office 365 Exchange Online and click Done;
5

RACA_03On the New blade, select the Grant access control to open the Grant blade. On the Grant blade, select Grant access and select at least Require approved client app (preview) and click Select.

Note: This configuration will make sure that only the mentioned approved client apps can access Exchange Online.

End-user experience

As usual with this type of posts, I’ll end this post with the end-user experience. On the left is an example of the iOS 11 default mail app that is trying to connect with Exchange Online. This provides a clear message that the app can’t be used, as it’s not approved. On the right is an example of the iOS default browser that is trying to connect with outlook.office365.com. This provides a less clear message and refers to the Intune Managed browser, which is currently not on the approved apps list. This is very likely the reason why the browser functionality is currently not yet supported, but it’s very good to see that the access is blocked. That removes a big potential backdoor of a great feature!

IMG_0113 IMG_0114

More information

For more information about conditional access and requiring approved client apps, please refer to this article about Azure Active Directory Conditional Access technical reference | Approved client app requirement.

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 and apps that cannot be installed on the device

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

Introduction

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

This rule is supported on iOS 6+, Android 4.0+ and Samsung KNOX Standard 4.0+.

Configuration

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

Get app ID

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

Android

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

iOS

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

1 Find the ID number in the iTunes store URL. As an example see the ID for the OWA app in the following URL (bold): https://itunes.apple.com/us/app/owa-for-ipad/id659524331?mt=8;
2 Open a web browser and navigate to the following URL, using the example ID of the OWA app: https://itunes.apple.com/lookup?id=659524331;
3 Download and open the 1.txt file;
4 1_txtIn the 1.txt file, search for the text bundleId. The value with the text is the app ID. With the OWA app example, the app ID is com.microsoft.exchange.mowa.

Configure compliance policy

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

1 Open the Configuration Manager administration console and navigate to Assets and Compliance > Overview > Compliance Settings > Compliance Policies;
2 Click Create Compliance Policy to open the Create Compliance Policy Wizard;
3 On the General page, provide a unique name, select Compliance rules for devices managed without the Configuration Manager client and click Next;
4 On the Supported Platforms page, select iPhone or/and iPad or/and Android or/and Android For Work and click Next;
5

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

6 On the Summary page, click Next;
7 On the Completion page, click Close.

End-user experience

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

IMG_0107 IMG_0106
Screenshot_20170624-075046 Screenshot_20170624-074745

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

Conditional access and named locations

This week another blog post about a recently introduced feature that can be used in commination with conditional access, named named locations. Within conditional access policies, named locations can be used like trusted IPs. The complication with trusted IPs was that it’s actually a feature configuration of multi-factor authentication. That did not really make a lot of sense. In this post I’ll look at the configuration of named locations and how those configurations can be used within a conditional access policy.

A very good scenario for named locations in a conditional access policy is using Office 365 in a terminal services environment. It enables organizations to make an exclusions for a specific named location. In this post I’ll use an example that will blocks access to SharePoint Online with the exception of the configured named location.

Configuration

Now let’s start with having a look at the configuration of named locations and how those named locations can be used within conditional access policies.

Named location

Named locations is a feature of Azure AD that enables administrators to label trusted IP address ranges in their organizations. In the environment, administrators can use named locations in the context of the detection of risk events to reduce the number of reported false positives for the Impossible travel to atypical locations risk event type. However, since recently named locations are also available for use in Azure AD conditional access policies under preview. To create a named location in Azure AD, use the following 3 steps.

1 Open the Azure portal and navigate to Azure Active Directory > Conditional access > Named locations;
2 On the Named locations blade, click New location to open the New blade;
3

CA_NamedLocationOn the New blade, provide a Name and IP range, and click Create;

Note: Even though the example shows that a private IP range is used, for usage with conditional access policies that doesn’t make sense. Use a public IP range. When a device arrives with Azure AD, for authentication, it provides the public IP address to Azure AD (see also the blocked example in the end-user experience section).

Conditional access policy

Using named locations within conditional access policies, is similar to using trusted IPs in conditional access policies. The biggest difference is the location of the configuration. Trusted IPs is a feature configuration of multi-factor authentication, while named locations is a feature configuration of conditional access. To use the configured named location within a conditional access policy, to block all external access to SharePoint Online, follow the 7 steps below.

1 Open the Azure portal and navigate to Azure Active Directory > Conditional access > Policies;
2 On the Policies blade, click New policy to open the New blade;
3 CA_UsersGroupsOn 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 CA_SharePointOnlineOn the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, select Select apps to select Office 365 SharePoint Online and click Done;
5 CA_ExcludeLocationOn the New blade, select the Conditions assignment to open the Conditions blade. On the Conditions blade, select Locations to open the Locations blade. On the Locations blade select Yes with Configure, select All locations on the Include tab, select All trusted IPs in the Exclude tab and click Done. Back in the Conditions blade, click Done;
6

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

Note: This configuration will make sure that all locations are blocked access to SharePoint Online, with the exclusion of the named location. The devices within the named location can now connect to SharePoint Online without any additional requirements.

7 On the New blade, select On with Enable policy and click Save.

End-user experience

As usual, let’s end this post with the end-user experience. Below on the left is an example of a connection to SharePoint Online within the configured named location and below on the right is an example of a connection to SharePoint Online outside of the named location. The blocked example clearly shows the external IP address that’s used to connect to SharePoint Online and that it’s blocked by conditional access.

SP_AllowedAccess SP_BlockedAccess

Note: Yes, the blocked example shows the same IP address, as the named location configuration. To simulate a good test, I simply temporarily adjusted the IP range of the named location. That allowed me to easily test the blocked behavior on my devices.

More information

For more information about conditional access and named locations, please refer to:

Quick tip: View device in Azure Active Directory

This week a quick and short blog post about the feature, in Configuration Manager, to view a device in Azure AD. This is small new feature that was introduced in Configuration Manager 1702 and is mainly used for getting additional information about the compliance state of domain joined devices. Devices managed by a Configuration Manager client. In this post I’ll show the steps to use that feature and I’ll show the provided information.

View device in Azure AD

The feature to view a device in Azure AD, is only available when looking at non-compliant or compliant devices.  This can be achieved by going through the steps below.

1 Open the Configuration Manager administration console and navigate to Monitoring > Overview > Compliance Settings > Compliance Policies;
2 In the Overall Device Compliance overview, click on the Non-Compliant, or the Compliant, section of the donut and the Overall Device Compliance – Non-Compliant, or Overall Device Compliance – Compliant node will show;
3a ViewDevice_SelectOption 1: Select the device and click View Device in Azure Active Directory in the Home tab;
3b ViewDevice_RightOption 2: Right-click the device and click View Device in Azure Active Directory;
4 When the current user is not an administrative user in Azure AD, an additional dialog box will show. Simply provide the credential of an administrative user that has the permissions to view the device information and logon;
5 ViewDevice_AzureADThe View Device in Azure Active Directory dialog box will show. This dialog box provides up-to-date information about the compliance state of the device, including the important property Compliance Expires. That provides the administrator with the information about when the current compliance status expires. 

Conditional access and Google Chrome on Windows 10

This week a short blog post to create some awareness about conditional access for Google Chrome on Windows 10. Starting with Windows 10, version 1703, it’s now possible to use Google Chrome in combination with conditional access. It will no longer simply being blocked. This can be achieved by installing and enabling the Windows 10 Accounts extension in Google Chrome. The screenshot below contains the name and URL of the extension.

Win10AccountsExt

Introduction

The Windows 10 Accounts extension for Google Chrome provides a single sign-on experience, to supported websites, to end-users that have a Microsoft supported identity on Windows 10,. Also, the Windows 10 Accounts extension for Google Chrome is required when the organization has implemented conditional access policies, to get the expected end-user experience. Currently, the Windows 10 Accounts extension for Google Chrome supports Azure AD identities.

End-user experience

Now let’s have a look at the end-user experience on a Windows 10, version 1703, device. I’ll go through the expected end-user behavior, with and without the Windows 10 Accounts extension for Google Chrome.

Chrome_WithOutExt_CAScenario: Google Chrome without the Windows 10 Accounts extension and with a conditional access policy that requires a compliant or domain joined device.

In this scenario, even when the device is complaint or domain joined, the device will be blocked when not using the Windows 10 Accounts extension. In this scenario, the end-user will receive a message that the current browser is not supported.

Chrome_WithOutExtScenario: Google Chrome without the Windows 10 Accounts extension and with a conditional access policy that uses app enforced restrictions on browsers of non-compliant or non-domain joined devices.

In this scenario, even when the device is complaint or domain joined, the device will have a limited experience when not using the Windows 10 Accounts extension. In this scenario, the end-user will receive a message that a limited experience is applied.

Chrome_WithExtScenario: Google Chrome with the Windows 10 Accounts extension and with a conditional access policy that requires a compliant or domain joined device, or with a conditional access that use app enforced restrictions on browsers of non-compliant or non-domain joined devices.

In these scenarios, with the Windows 10 Accounts extension enabled, the end-user experience will be the same as with Microsoft Edge or Internet Explorer. In this scenarios, the end-user will get the full experience.


Note
: The blue Windows-logo is an indication that the Windows 10 Accounts extension is enabled in Google Chrome.

Conditional access and app enforced restrictions

This blog post is about a recently introduced feature in conditional access, named Session controls. More specific, the Session control of app enforced restrictions. Session controls enable a limiting experience within a cloud app. The great thing about Session controls is is that those controls are enforced by the cloud apps and that those controls rely on additional information provided by Azure AD to the cloud app, about the session. In other words, these controls can be used to require Azure AD to pass the device information to the cloud app. This enables the cloud app to know if the user is coming from a (non-)compliant device or (non-)domain joined device.

Currently Session controls are only supported with SharePoint Online as the cloud app. In this post I’ll go through the required configuration to get SharePoint Online configured with conditional access and app enforced restrictions. I’ll end this post with the end-user experience with app enforced restrictions.

Configuration

The administrator can block or limit access to SharePoint Online content on devices that are not managed, not compliant and/or not joined to a domain. To block access, the administrator usually configures one conditional access policy. To limit access, the administrator should configure two conditional access policies and configure a setting in the SharePoint Online. In this section I’ll start with a few important notes and follow that by the required steps to make the earlier mentioned configurations.

Important notes

Before configuring the limited access to SharePoint Online, be sure to be familiar with the  following important notes:

  • A subscriptions to Azure AD Premium is required;
  • A subscription to Microsoft Intune is required;
  • (At this moment) First Release must be enabled in Office 365;
  • Limited access will also apply to users on managed devices, if they use one of the following browser and operating system combinations:
    • Chrome, Firefox, or any other browser other than Microsoft Edge or Microsoft Internet Explorer in Windows 10 or Windows Server 2016;
    • Firefox in Windows 8.1, Windows 7, Windows Server 2012 R2, Windows Server 2012, or Windows Server 2008 R2.

Block access to mobile apps and desktop clients

The first configuration to limit access to SharePoint Online, is to block access for mobile apps and desktop clients. These apps will not get the limited experience, which means that these apps should be blocked to prevent users from using company data on non-compliant or non-domain joined devices. To create a conditional access policy that will block access for mobile apps and desktop clients to SharePoint Online, follow the 7 steps below.

1 Open the Azure portal and navigate to Azure Active Directory > Conditional access;
2 On the Policies blade, click Add to open the New blade;
3 AP_CA_UsersGroupsOn 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, or select Select users and groups to specify a specific group, and click Done;
4 AP_CA_CloudAppsOn the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, select Select apps to select Office 365 SharePoint Online and click Done;
5 AP_CA_ClientApp_MobileAppsOn the New blade, select the Conditions assignment to open the Conditions blade. On the Conditions blade, select Client apps to open the Client apps blade. On the Client apps blade select Yes with Configure, select Select client apps and Mobile apps and desktop clients, and click Select. Back in the Conditions blade, click Done;
6 AP_CA_GrantOn the New blade, select the Grant access control to open the Grant blade. On the Grant blade, select Grant access and at least one of the requirements, and click Select.
7 On the New blade, select On with Enable policy and click Save.

Use app enforced restrictions for browsers

The second configuration to limit access to SharePoint Online, is to enforce restrictions to browsers. This will make sure that browsers will get the limited experiences in SharePoint Online, on non-compliant or non-domain joined devices. To create a conditional access policy that will enforce restrictions for browsers to SharePoint Online, follow the 7 steps below.

1 Open the Azure portal and navigate to Azure Active Directory > Conditional access;
2 On the Policies blade, click Add to open the New blade;
3 AP_CA_UsersGroupsOn 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, or select Select users and groups  to specify a specific group, and click Done;
4 AP_CA_CloudAppsOn the New blade, select the Cloud apps assignment to open the Cloud apps blade. On the Cloud apps blade, select Select apps to select Office 365 SharePoint Online and click Done;
5 AP_CA_ClientApp_BrowserOn the New blade, select the Conditions assignment to open the Conditions blade. On the Conditions blade, select Client apps to open the Client apps blade. On the Client apps blade select Yes with Configure, select Select client apps and Browser, and click Select. Back in the Conditions blade, click Done;
6 AP_CA_SessionOn the New blade, select the Session access control to open the Session blade. On the Session blade, select Use app enforced restrictions and click Select.
7 On the New blade, select On with Enable policy and click Save.

Allow limited access in SharePoint Online

The third configuration to limit access to SharePoint Online, is a configuration within SharePoint Online. The cloud app must be configured to use limited access for devices that aren’t compliant or domain joined. When the administrator configures limited access, users will be able to view but not edit Office files in SharePoint Online. The Download, Print, Sync, Open in desktop app, Embed, Move to, and Copy to buttons won’t appear in the new SharePoint Online experiences. To configure this limited access, follow the 2 steps below.

1 Open the SharePoint admin center and navigate to device access;
2

SPO_ControlAccessOn the Restrict access based on device or network location page, specify the following information and click OK:

  • In the section Control access from devices that aren’t compliant or joined to a domain, select Allow limited access (web-only, without the Download, Print, and Sync commands) with Select the appropriate SharePoint enforced restriction and choose between Allow downloading and Block downloading with For files that can’t be viewed on the web;
  • In the section Control access from apps that don’t use modern authentication, select Block with The setting applies to third party apps and Office 2010 and earlier.

End-user experience

Now let’s end this post with the end-user experience. I’ll do that by showing the limited access experience on Windows 10 (Surface Pro), iOS (iPad) and Android (Samsung Galaxy). Also in that order. Below are examples of of the limited access message in SharePoint Online on the left and the limited access experience in Word Online on the right.

Windows10_SPO Windows10_SPO_Doc
IMG_0102 IMG_0103
Screenshot_20170409-075823 Screenshot_20170409-081417

More information

For more information about conditional access and app enforced restrictions, please refer to: