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.

A new discovery method: Meet the Azure Active Directory User Discovery!

This week a blog post about the addition of a new discovery method, as Configuration Manager 1706 introduces the Azure Active Directory User Discovery. This discovery method enables organizations to search Azure AD for user information. It adds the cloud-only users to the Configuration Manager environment and it adds additional attributes to the existing on-premises user objects. The attributes that are discovered are objectId, displayName, mail, mailNickname, onPremisesSecurityIdentifier, userPrincipalName and AAD tenantID. In this post I’ll show how to configure the Azure Active Directory User Discovery and I’ll show a couple of challenges that I faced during the configuration. I’ll end this post with the administrator experience. The configuration options for the administrator and the important places for the administrator to look for the additional information.

Configuration

Let’s start with the configuration, which actually can be as simple as walking through a wizard. During the steps shown below, I’ll show the required steps for the initial cloud services configuration. Some screenshots will indicate that I’ve got multiple cloud services configured already. Before starting with the configuration, it’s good to mention that I always create a separate web app for every cloud service. By doing that I make sure that every web app only has the required permissions for it’s specific use case. Having said that, follow the next steps to configure the Azure Active Directory User Discovery by creating new web apps.

1 Open the Configuration Manager administration console and navigate to Administration > Overview > Cloud Services > Azure Services;
2 On the Home tab, click Configure Azure Services to open the Azure Services Wizard;
3

ASW_AzureServiceOn the Azure Services page, select Cloud Management and click Next;

Note: When this is the first cloud services that is configured, this page also contains the option to select OMS Connector, Upgrade Readiness Connector and Windows Store for Business.

4 On the App Properties page, click Browse with Web app to open the Server App dialog box;
5 On the Server App dialog box, click Create to open the Create Server Application dialog box;
6

On the Create Server Application dialog box, provide the following information and click OK to return to the Server App dialog box;

  • ASW_CreateServerAppApplication Name: Provide a friendly name for the app (max 200 characters);
  • HomePage URL: Provide the homepage URL for the app (max 200 characters);
  • App ID URI: Provide the identifier URL for the app (max 200 characters);
  • Secret key validity period: Select 1 Year or 2 Years for the key validity period;
  • Azure AD Admin Account: Sign in with the tenant administrator account;
  • Azure AD Tenant Name: Automatically populated after signing in;

Note: Once a web app is already created for the cloud management service, pressing OK will result in an informational message stating “An Azure AD Web App already exists for this Tenant. Use the pre-existing app and then click OK

7 ASW_ServerApp2Back on the Server App dialog box, select the just created web app and click OK to return to the App Properties page.
8 Back on the App Properties page, click Browse with Native Client app to open the Client App dialog box;
9 On the Client App dialog box, click Create to open the Create Client Application dialog box;
10

On the Create Client Application dialog box, provide the following information and click OK to return to the Client App dialog box;

  • ASW_CreateClientAppApplication Name: Provide a friendly name for the app (max 200 characters);
  • Reply URL: Provide the reply URL for the app (max 200 characters);
  • Azure AD Admin Account: Sign in with the tenant
    administrator account;
  • Azure AD Tenant Name: Automatically populated after signing
    in;
11 ASW_ClientApp2Back on the Client App dialog, select the just created native app and click OK to return to the App Properties page;
12 ASW_AppBack on the App Properties page, verify the created and selected apps and click Next;
13

ASW_DiscoveryOn the Configure Discovery Settings page, select Enable Azure Active Directory User Discovery and click Next;

Note: Click Settings to configure the full discovery polling schedule and the delta discovery. The default schedule for the full discovery is once every 7 days and the default interval for the delta discovery is an interval of every 5 minutes.

14 On the Confirm the settings page, click Next;
15 On the Completion page, verify the results and close the wizard.

Challenges

During my initial configuration of the Azure Active Directory User Discovery , I encountered a few challenges. The most important challenges that I faced, are the following.

1 AzureReqPermUnauthorized error: After the Azure Active Directory User Discovery started, it immediately failed with an unauthorized error message. This was related to the permissions of the just created web and native app. The permissions were set correctly. However, it needed a trigger, by clicking Grant Permissions, to grant the permissions for all the accounts in the directory.
2 Unknown error: After the Azure Active Directory User Discovery started with a successful authentication, it failed again. This time with an unknown error message. This was related to an orphaned user account in Azure AD. For some reason Azure AD still contained an user account that was already removed from the on-premises AD, a long time ago. Removing the orphaned user account from Azure AD solved this challenge.

Administrator experience

Now let’s end this post with the most interesting part, the administrator experience. From an administrative perspective, this configuration introduces at least the following new items.

1 CloudManPropDiscover method: One of the most interesting items is the new Azure Active Directory User Discovery. After the configuration is finished the discovery method can be found by navigating to Administration > Overview > Cloud Services > Azure Services. Selecting the cloud management Azure service, provides the option Run Full Discovery Now. The properties of the cloud management Azure service, provide the option to reconfigure the discovery configuration of the Azure Active Directory User Discovery (as shown on the right).
2 AzureADDiscoverAgentLog file: One of the most important items is the new log file SMS_AZUREAD_DISCOVERY_AGENT.log. This log files provides the information about the full and delta discoveries of the Azure Active Directory User Discovery (as shown on the right). The nice part is that the log files also provides information about the Microsoft Graph requests that it uses for the discovery.
3 CloudOnlyUserCloud-only users: The most useful item is the availability of the cloud-only users in the on-premises environment. These users can be recognized by only having the Agent Name of SMS_AZUREAD_USER_DISCOVERY_AGENT (as shown on the right). The availability of the cloud-only users in the Configuration Manager environment, and the availability of the new attributes for existing users, enables a whole lot of new scenarios. Most of these scenarios are related to managing Windows 10 Azure AD joined devices with an Configuration Manager client.
4

SQL_svUserUser properties: The overall most interesting, most important and most useful item is by far the information in the database. The main user tables and views now contain additional fields for cloud-related information. Some nice information can be found on the right, were I used a simple query to get information about user that contain attributes from the Azure Active Directory User Discovery. The query I used here was:

SELECT Unique_User_Name0,User_Principal_Name0,AADTenantID,AADUserID,CloudUserId
FROM v_R_User
WHERE AADTenantID IS NOT NULL

More information

For more information about the Azure AD user discovery and how to use and configure it, please refer to the following articles:

Windows 10, MAM-WE and Office desktop apps

The last couple of weeks I did blog posts about the configuration and the end-user experience of Windows 10 and MAM-WE. One of the most common questions I received was, “what about the Office desktops apps?”. In this blog post I’ll provide the steps to get the required information about the Office desktop apps, for usage within MAM-WE app policies (or any other WIP-related policies). I’ll also show how to use that information in the MAM-WE app policy and I’ll show the end-user experience. Including some of the current challenges with the end-user experience.

Important: Keep in mind that the Office desktop apps are not yet mentioned on the list of enlightened Microsoft apps for use with WIP (see this article). That could mean that the apps might behave different than expected. As my end-user experience section will show, make sure to test carefully before implementing.

Get Office desktop information

Lets start by getting the required information about the Office desktop apps. These methods are the same for every desktop app that must be configured with any WIP-related policy. There are two methods available, the first method is using the Get-AppLockerFileInformation cmdlet, and the second method is using the Local Security Policy editor to create an AppLocker configuration XML file. I’ll use the PowerShell method in this post. Simply using the mentioned cmdlet, as shown below, provides the information that is needed for adding desktop apps to the MAM-WE app policy,

(Get-AppLockerFileInformation -Path “C:\Program Files\Microsoft Office\root\Office16\excel.exe”).Publisher

For the most common Office desktop apps, version 1609, this results in the following information.

PublisherName ProductName BinaryName BinaryVersion
O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US MICROSOFT OFFICE 2016 EXCEL.EXE 16.0.7369.2130
O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US MICROSOFT OFFICE 2016 OUTLOOK.EXE 16.0.7369.2130
O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US MICROSOFT OFFICE 2016 POWERPNT.EXE 16.0.7369.2130
O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US MICROSOFT OFFICE 2016 WINWORD.EXE 16.0.7369.2130

Add Office desktop information

The next step is to add the Office desktop app information, to the MAM-WE app policy. For the step-by-step activities, please refer to my post about configuring MAM-WE app policies for Windows 10. Here I’ll only show the required actions for adding the Office desktop app information to a MAM-WE app policy. The following steps go through adding the Office desktop apps to an existing Windows 10 MAM-WE app policy.

1 Open the Azure portal and navigate to Intune mobile application management;
2 Select App policy to open the App policy blade;
3 On the App policy blade, select the [Windows 10 MAM-WE app policy] to open the [Windows 10 MAM-WE app policy] blade;
4 On the [Windows 10 MAM-WE app policy] blade, select Allowed apps to open the Allowed apps blade;
5

On the Allowed apps blade, click Add apps to open the Add apps blade. On the Add apps blade, select Desktop apps. On the Desktop apps blade, provide the following information and click OK to return to the Allowed apps blade.

  • NAME: Provide a name for the desktop app;
  • PUBLISHER: Provide the PublsherName of the Get-AppLockerFileInformation cmdlet;
  • PRODUCT NAME: Provide the ProductName of the Get-AppLockerFileInformation cmdlet
  • FILE: Provide the BinaryName of the Get-AppLockerFileInformation cmdlet
  • MIN VERSION: (Optional) Provide a minimum version of desktop app. This can be used to, for example, make sure that at least a version is used that’s WIP enlightened;
  • MAX VERSION: (Optional) Provide a maximum version of desktop app.

MAMWE_AddOffice

6

Back on the Allowed apps blade, click Save to save the adjustments.

Note: At this moment the Allowed apps blade will show the same NAME as the PRODUCT NAME for manually added apps.

End-user experience

Now let’s end this post by having a look at the end-user experience. I’ll show the end-user experience by opening a work document. The first action is to open a work document via Word Online. Once opened I’ll select Edit Document > Edit in Word. This provides me with the question “How do you want to open this?”, as shown below on the left. It doesn’t mention that Word 2016 opens work and personal files, but I can open the document with Word 2016. Once opened, I’m still able to copy content to non-managed apps. When I choose Word Mobile, I’m not able to copy content to non-managed apps.

The second action is to download a work document from SharePoint Online. Once downloaded I select Open with. This provides me with the question “How do you want to open this work file?”, as shown below on the right. It correctly shows that Word 2016 opens work and personal files. However, again I’m still able to copy content to non-managed apps. When I choose Word Mobile, I’m not able to copy content to non-managed apps.

MAMWE_OfficeWord1 MAMWE_OfficeWord2

This clearly shows that this configuration enables the end-user to use Office desktop apps for work data. However, at this moment, it also clearly shows that it provides the end-user with more options on work data than the company might like.

More information

For more information about enlightened apps and Microsoft apps, please refer to:

Windows 10 and MAM-WE – Part 2: End-user experience

This week part 2 of my blog post about Windows 10 and MAM-WE. Last week it was about the configuration, this week it’s about the end-user experience. I’ll start this post with a short introduction about the settings that are configured for the end-user experience in this post. After that I’ll show the end-user experience with the enrollment, with accessing data and after enrollment.

Introduction

As I explained last week, there are a few Important settings that should be considered. The end-user experience shown throughout this post is based on the following configuration:

  • Allowed apps: Microsoft Edge, PowerPoint Mobile, Excel Mobile, Word Mobile, IE11, Microsoft Remote Desktop, Microsoft Paint, Microsoft OneDrive, Notepad;
  • Required settings:
    • Windows Information Protection mode: Allow Overrides;
  • Advanced settings:
    • Network boundary: All Microsoft cloud services;
    • Revoke encryption keys on unenroll: On;
    • Show the enterprise data protection icon: On.

Enroll device

Now let’s start with the end-user experience for enrolling the Windows 10 device. Keep in mind that the end-user must be Microsoft Intune licensed and must be using at least Windows 10, version 1703. The en-user can now navigate to Settings > Accounts > Access work or school and click Connect (see below on the left). This will start the enrollment experience that is similar to a normal MDM enrollment. The difference is in the background process. Once MAM enrollment is enabled, Windows 10, version 1703, will enroll the device for MAM. After enrollment this can be verified by selecting the work or school account and by clicking Info. This will show the information about the Management Server Address that points to the MAM check-in URL (see below on the right).

MAMWE_Enrollment1 MAMWE_Enrollment2

Note: After enrolling the device, an administrative user can find an additional device for the end-user in Azure AD. That device has the Trust Type attribute set to Workplace and the Managed By attribute set to None.

Access cloud work data

After enrolling the device it’s possible to connect to the configured Microsoft cloud services, like SharePoint Online. With and without conditional access configured. Browsing to SharePoint  Online will show the enterprise data protection icon, the briefcase, next to the URL (see below on the top). When clicking on the enterprise data protection icon, a message will show indicating that the website is managed (see below on the bottom).

petervanderwoude.nl
petervanderwoude.nl

Access local work data

When connecting to the configured Microsoft cloud services, like SharePoint Online, it’s also possible to download data, like documents. The downloaded documents will be marked as work data. The fact that it’s work data, ensures that the documents are encrypted. The work data can be recognized by the enterprise data protection icon, the briefcase, and by the File ownership. The File ownership will be set to the company (see below on the left). Work data can only be opened with managed apps. A clear example will show when using Open with > Choose another app. That will show the programs that can be used to open the document, including information about if the program can open work or personal files (see below on the right).

MAMWE_Local1 MAMWE_Local2

Copy work data

Now that it’s possible to open work data, it’s good to have a look at the behavior with copying content. In this case, opening work data, like a document, in Word Online (as shown below on the left) and Word Mobile (as shown below on the right).

MAMWE_WordOnline MAMWE_WordMobile

When copying content to an unmanged app, like WordPad, the end-user will be prompted for giving temporary access to use work content (as shown below). After clicking Give access, the content will be copied and the action will be logged.

MAMWE_Confirm

Note: Keep in mind that every activity related to accessing work data, is logged, in the Event Viewer, In the EDP-Audit-Regular log.

Switch owner

After enrolling the device it’s possible to switch the owner of local data. It’s even possible to switch the owner of the data, when selecting to download it. That enables the end-user to switch personal data to company data and company data to personal data (as shown below). When marked as work data, the data will be encrypted. When marked as personal data, the data will be unencrypted and free accessible.

MAMWE_Switch

Note: Keep in mind that every activity related to switching the owner of work data, is logged, in the Event Viewer, in the EDP-Audit-Regular log.

Unenroll device

Another important end-user action is unenrolling the device. With the current configuration this will revoke the encryption keys, which will revoke the end-user access to downloaded work data (as shown below on the left). It’s also really important to know that setting Revoke encryption keys on unenroll to Off will not revoke the end-user access to downloaded work data (as shown below on the right). The indication that it’s work data is still available, but the end-user has full access.

MAMWE_Unenroll1 MAMWE_Unenroll2

Note: Keep in mind that setting Revoke encryption keys on unenroll  to No, should only be used in specific scenarios. Using it in a normal production configuration will create major data leakage.

Windows 10 and MAM-WE – Part 1: Configuration

This week another blog post about Windows 10. This time in combination with mobile app management without enrollment (MAM-WE). Due to the size of the blog post, I’ve decided to divide this post in 2 parts. This weeks post will provide a short introduction, followed by the required configurations. Next weeks blog post will be about the end-user experience.

Introduction

MAM-WE, for Windows 10, relies on Windows Information Protection (WIP) in combination with a new enrollment flow in Windows 10, version 1703. That new enrollment flow enables users to enroll their personal device for receiving only MAM policies. Those MAM policies are only applicable to activities performed by the work account and do not apply to the personal account. The part that makes it a bit funny is that it’s named MAM-WE and it’s still required to do an enrollment. However, that enrollment is only for MAM. It’s correct that it’s without MDM enrollment. In other words, no policies are applied to the personal device of the user. This is a very powerful combination with conditional access. 

Configuration

Now let’s have a look at the configuration of the MAM-WE enrollment, the configuration options of the MAM-WE app policy and the assignment of the MAM-WE app policy. I’ll show the locations of the configuration options and the available configuration options. In addition I’ll provide additional information about settings, to clarify the available configuration options.

Enable MAM-WE enrollment

Let’s start with the first step, which is enabling MAM-WE enrollment. The following steps will go through the steps to enable MAM-WE enrollment in the Azure portal.

1 Open the Azure portal and navigate to Azure Active Directory > Mobility (MDM and MAM);
2 Select Microsoft Intune to open the Configure blade;
3

Configure_MAMOn the Configure blade, configure a MAM User scope. To enable MAM-WE for Windows 10 devices this should be configured to either Some or All. Also, make sure that the MAM Discovery URL is correct. To be absolutely sure simply select Restore default MAM URLs. The other URLs are optional. Click Save to enable the functionality.

Create MAM-WE app policy

Let’s continue with the second step, which is creating the MAM-WE policy. The following steps will go through the steps to create the MAM-WE app policy in the Azure portal. The first 4 steps are required actions, the last 4 steps are mainly used for providing information about the available settings.

1 Open the Azure portal and navigate to Intune mobile application management;
2 Select App policy to open the App policy blade;
3 On the App policy blade, click Add a policy to open the Add a policy blade;
4

MAM-WE_Policy1On the Add a policy blade, provide an unique name for the MAM-WE app policy and select Windows 10 as the Platform. This will enable the required configuration options. At this moment the Enrollment state will be automatically configured to Without enrollment. It will also show an informational message about configuring the MAM-WE enrollment.

Now let’s go through the remaining configurations. Allowed apps in step 5, Exempt apps in step 6, Required settings in step 7 and Advanced settings in step 8. After going through these steps simply click Create to create MAM-WE policy;

5

MAM-WE_Policy2On the Allowed apps blade, click Add apps to open the Add apps blade. On the Add apps blade, it’s possible to configure Recommended apps, Store apps and Desktop apps.

  • The Recommended apps selection contains apps that are preconfigured and guaranteed enlightened for WIP;
  • The Store apps selection contains empty lines for manually adding store apps. To get the required information, simply use the Windows Store for Business website;
  • The Desktop apps selection contains empty lines for manually adding desktop apps. To get the required information, simply use the Get-AppLockerFileInformation cmdlet.

Note: Make sure that every configured app is enlightened for WIP. Without that confirmation the app can behave different than expected. For a lot more information see this article.

6 MAM-WE_Policy3On the Exempted apps blade, click Add apps to open the Add apps blade. On the Add apps blade, the configuration options are the same as with the Allowed apps. The only difference is that there are no Recommended apps preconfigured;
7

MAM-WE_Policy4On the Required settings blade, the Corporate identity and the MDM discovery URL are preconfigured. Only the Windows Information Protection mode must be configured. Choose between:

  • Hide overrides: WIP blocks inappropriate data sharing;
  • Allow overrides: WIP prompts the end-user for inappropriate data sharing;
  • Silent: WIP runs silently. It only logs and doesn’t block or prompt;
  • Off: WIP is turned off.

Note: Make sure to start with Silent or Allow overrides for a pilot group. This enables the administrator to add the used apps to the allowed apps list.

8

MAM-WE_Policy5On the Advanced settings blade, configures additional settings in the categories Network perimeter, Data protection and Access. A few important setting that should be considered are:

  • The Add network boundary setting in the Network perimeter category. This settings should be used to define a boundary of the work resources. Use this as a good starting point for defining cloud resources. Also, when using that as a starting point, make sure to also configure conditional access for those resources. This will complete the circle and will make sure that the end-user must do a MDM enrollment or MAM-WE enrollment before using work data;
  • The Revoke encryption keys on unenroll setting, in the Data protection category. This setting should be used to prevent the end-user from accessing locally stored encrypted work data after unenrolling;
  • The Show the enterprise data protection icon setting in the Data protection category. This setting should be used to make sure that the end-user is aware when working with work data.

Note: Make sure to be aware of the remaining available settings related to subjects like RMS and Windows Hello for Business, before finalizing the configuration.

Assign the MAM-WE app policy

The third and last step is assigning the MAM-WE app policy. The following steps will go through the steps to assign the MAM-WE pp policy to an Azure AD user group in the Azure portal.

1 Open the Azure portal and navigate to Intune mobile application management;
2 Select App policy to open the App policy blade;
3 On the App policy blade, select the just created policy to open the {policyname} blade;
3 MAM-WE_Policy_AssignmentOn the {policyname} blade, select User groups to open the User groups blade. On the User groups blade, select Add user group to open the Add user group blade. On the Add user group blade, select an AAD user group and click Select.

More information

For more information about app policies and WIP, please refer to:

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:

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: