Require minimum platform version or app version when using MAM-WE

This week a relatively short blog post about the recently introduced feature to require a minimum platform version, app version and Intune app protection policy SDK version, when using MAM-WE. This enables organizations to require end-users to update their personal devices when using apps to connect to company resources. That can be very useful when specific platform and/or app updates introduce important new features, or fix important bugs. In other words, a great feature! In this post I’ll go through the available settings, the configuration options and the end-user experience.

Configuration

Let’s start by having a look at the configuration. I’ll do that by first going through the available settings, followed by going through how to configure those settings in an app protection policy.

Available settings

Since May 2017 it’s possible to set additional requirements for MAM-WE that enforces the following policies before connecting to company data:

  • Minimum app version;
  • Minimum platform version;
  • Minimum Intune app protection policy SDK version (iOS only).

Most of these settings are available for both Android and iOS. Microsoft Intune supports minimum version enforcement for platform versions, app versions, and Intune app protection policy SDK. Setting a minimum version enforcement for the Intune app protection SDK, is currently only available for iOS. The configuration is also available when configuring an app protection policy for Android, but in that case the configuration will not work and will not save (at this moment).

Configure app protection policy

Now let’s have a look at configuring the available settings in an app protection policy. I’ll do that by going through the steps for creating an app protection policy for iOS that provides a warning message when the iOS platform is not at the specified minimum version. Configuring the remaining settings can be done by following similar steps, as shown in the screenshot in step 6. That screenshot shows all the new available settings. Also, keep in mind that it might require multiple app protection policies when targeting specific apps and versions.

1 Open the Azure portal and navigate to Intune App Protection > App policy;
2 Select Add a policy to open the Add a policy blade;
3 On the Add a policy blade, provide a unique name for the app protection policy and select Apps to open the Apps blade;
4 On the Apps blade, select the required apps and click OK to return to the Add a policy blade;
5 Back on the Add a policy blade, select Settings to open the Settings blade;
6

APP_NewSettingsOn the Settings blade, select Yes with Require minimum iOS operating system (Warning only), specify a minimum version with iOS operating system and click OK to return to the Add a policy blade;

Note: When specifying a version number it’s required to specify at least a major and minor version. Only a major version is not sufficient. In my example I used 10.3.3 for easy testing, as the current iOS version is 10.3.2.

7 Back on the Add a policy blade, click Create;

Note: When creating an app protection policy for Android devices, the option to configure a specific minimum Intune SDK version is available. However, it won’t be configurable.

End-user experience

Let’s end this post by looking at the end-user experience. Depending on the configuration, the end-user might be unable to access the targeted application if the minimum requirements through the app protection policy are not met at the three different levels mentioned above. Let’s start mildly. Below are examples of an iOS device trying to use the Outlook app to connect to Exchange Online. On the left is an example of a warning notification about the platform version and on the right is a warning notification about the app version. These notifications can be closed and the app can be used as normal.

IMG_0110 IMG_0111

Now let’s take it one step further. Below are examples of an Android device trying to use the Outlook app to connect to Exchange Online. On the left is an example of a blocking notification about the platform version and on the right is an example of a blocking notification about the app version. At this moment, the end-user may either remove their account (for multi-identity applications), or go back to close the app and update the version of the app or platform.

Screenshot_20170715-080322 Screenshot_20170715-081738

More information

For more information about the available app protection policies, please refer to:

Combining MAM-WE and app configuration

This blog post is about a potentially really great feature, which is a combination of MAM-WE and app configuration policies. This enables the administrator to provide a preconfigured app, once the end-users signs in to the app with company credentials. I named it a potentially really great feature, because the availability of apps that support this combination of features will make or break the use of this feature. In this post I’ll provide a quick introduction to this feature, followed by a configuration example with the Intune Managed Browser.I’ll end this post with the end-user experience.

Introduction

Let’s start with a quick introduction. MAM-WE with app configuration, also known as MAM targeted configuration, allows an app to receive configuration data through the Intune App SDK. The format and variants of this data (the keys and values) must be defined and communicated by the application owner/developer. The Microsoft Intune administrators can target and deploy the configuration data via the Intune Azure console. The app configuration data is pushed through the MAM Service directly to the app, instead of through the MDM channel.

Configuration

The configuration in this post will be based on the Intune Managed Browser, which is, to my knowledge, currently the only app that works with this great combination of features. At this moment, MAM targeted configuration is available on iOS and Android. For iOS, the app must have incorporated Intune APP SDK for iOS (v 7.0.1) and be participating in app configuration settings.

Available settings

Before starting with the actual configuration, let’s start by looking at the available configuration settings. The nice thing is that very recently a few configuration keys have been released by Microsoft. The Intune Managed Browser can now be preconfigured for Azure AD App Proxy redirection, with a specific homepage, with a list of bookmarks and with a list of allowed or block websites. That provides  us with the following list of keys and example values. The name of the keys provide a clear indication of their configuration usage.

Key Example value
com.microsoft.intune.mam.managedbrowser.AppProxyRedirection true
com.microsoft.intune.mam.managedbrowser.homepage https://www.petervanderwoude.nl
com.microsoft.intune.mam.managedbrowser.bookmarks Search|https://www.google.nl
com.microsoft.intune.mam.managedbrowser.AllowListURLs https://*.petervanderwoude.nl/*
com.microsoft.intune.mam.managedbrowser.BlockListURLs https://*.facebook.com/*

Note: The separation character for multiple bookmarks is || and the separation characters for multiple allow/block URLs is |.

Configure app configuration policy

After looking at the available settings, let’s have a look at the actual configuration. The configuration of MAM targeted configuration, can be done by using the Azure portal and following the steps below. After creating the app configuration policy, don’t forget to assign it to an user group.

1 Open the Azure portal and navigate to Intune App Protection > App configuration;
2 Select Add Config to open the Add app configuration blade;
3 AAC_NameOn the Add app configuration blade, provide a unique name for the app configuration policy and select App to open the Targeted apps blade;
4 AAC_AppsOn the Targeted apps blade, select the Managed Browser (Android), the Managed Browser (iOS) and click OK to return to the Add app configuration blade;
5 Back on the Add app configuration blade, select Configuration to open the Configuration blade;
6

ACC_ConfigOn the Configuration blade, provide similar information as the earlier mentioned NAME and VALUE (examples) pairs and click OK to return to the Add app configuration blade;

7 Back on the Add app configuration blade, click Create;

End-user experience

Let’s end this post by looking at the end-user experience. I created an app configuration, as mentioned in this post, but added a couple more bookmarks. Below are a couple of examples of the Intune Managed Browser on an iOS device. On the left is an example of an app configuration including a homepage, and on the right is an example of an app configuration excluding a homepage.

IMG_0108 IMG_0109

More information

For more information about configuring the Intune Managed Browser, please refer to this article about Manage Internet access using Managed browser policies with Microsoft Intune.

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 for managed apps

After a great MVP Summit and a session at a great Experts Live, it’s finally time for a new blog post. This blog post will be about conditional access for managed apps (MAM CA). About a month ago, I did a first post about this feature when it was still in preview. The good news is that the first part of this feature is now production ready for all tenants. In this post I’ll go through an introduction of MAM CA, the flow of MAM CA, the prerequisites of MAM CA, the configuration of MAM CA and the end-user experience of MAM CA.

Introduction

By now, I think, everybody should be familiar with the mobile app management without enrollment (MAM-WE, previously also referred to as MDM-less MAM) feature. MAM-WE helps with making sure that company data and resources are protected, even though the device is not managed. MAM CA adds an additional layer to that picture. MAM CA helps with making sure that only mobile apps that support Intune MAM policies are allowed to access Office 365 services (for now only Exchange Online). That enables us to allow access to Office 365 services, without the need to require enrollment and only for apps that can be managed.

Flow

Now let’s have a look at the flow that is used by MAM CA, by going through the steps in the picture shown below.

CA_MAMWE

Note: In the above picture CP is referring to the Company Portal app on Android and AA is referring to the Azure Authenticator app on iOS.

  1. Start: The end-user signs in to a managed app;
  2. App Approved?: When the end-user is restricted with MAM CA policies, a check is done to see if it’s an approved app. The approved apps are stored on a list in Azure AD and during the sign-in the app is validated with that list. When the app is not on the list, the end-user will be prompted that it’s not allowed to sign in via the app;
  3. CP/AA Present?: When it’s an approved app, a check is done to see if the broker app is installed on the device. On iOS this is the Azure Authenticator app and on Android this is the Company Portal app. When the broker app is not installed on the device, the end-user will be prompted to install the app;
  4. AAD Registered?: When the broker app is installed, and the end-user is signed in, a check is done to see if the device is registered in Azure AD. When the device is not registered in Azure AD, the end-user will be prompted to register the device.
  5. Approved: When the device is registered in Azure AD, the end-user can access Exchange Online via the managed app.

Note: The device registration in Azure AD will create a device record and certificate against which tokens are issued. There is no management profile installed on the device and there are no policies applied to the device. The device record in Azure AD only contains the alternativeSecurityIds, the deviceOSType, the deviceOSVersion and the displayName properties.

Configuration

After knowing what MAM CA is and knowing how MAM CA works, it’s time to look at the perquisites and the configuration.

Prerequisites

Before starting looking at the configuration, it’s good to be aware of the following prerequisites/ requirements/ limitation.

  • The end-user must be licensed for Enterprise Mobility + Security or Azure Active Directory premium;
  • At this moment MAM CA is only available for Exchange Online;
  • The end-user must install the broker app on their device;
  • MAM CA relies on modern authentication.

Configuration options

Now let’s have a look at the configuration options for MAM CA. The MAM CA polices contain three different configuration sections. These three sections together are the targeted MAM CA policy. Let’s go through these three section and see how they can be used.

1

MAMCA_AllAppsThe first configuration section is Allowed apps. The Allowed apps is used to select the mobile apps for iOS and Android that are allowed to access Exchange Online.

MAMCA_ManagedAppsTo allow apps to connect to Exchange Online the administrator can choose between selecting Allow all apps and Allow apps that support Intune app policies. The latter selection currently contains Skype for Business, Excel, PowerPoint, Word, OneNote, Outlook, Microsoft SharePoint and OneDrive for Android and iOS.

2 MAMCA_RestrUsGrThe second configuration section is Restricted user groups. The Restricted user groups section is used as the targeting mechanism for the MAM CA policy. Every available group in Azure AD can be selected. The selected group will be restricted by the MAM CA policy, immediately after saving the MAM CA policy.
3 petervanderwoude.nlThe third configuration part is Exempted user groups. The Targeted apps section is used as an exemption mechanism for the MAM CA policy. Every available group in Azure AD can be selected. The selected group will be exempted from the MAM CA policy, immediately after saving the MAM CA policy.

Additional considerations

An additional consideration for MAM CA is to close the gap for apps that don’t support modern authentication. Without closing that gap, apps that don’t support conditional access might still be able to connect. Let’s go through a method to close that gap.

4

ADFS_ModernAuthAn additional consideration is to use AD FS to block non-modern authentication. This can be achieved in AD FS 2016 by creating an Access Control Policy and assigning it to the Microsoft Office 365 Identity Platform Relying Party Trust.

That Access Control Policy must contain at least a rule to Permit users with Endpoint Path contains (/adfs/ls)|(/adfs/oauth2) in the request. This will make sure that only apps, using modern authentication, can connect to any cloud services that uses the Microsoft Office 365 Identity Platform Relying Party Trust.

End-user experience

After configuring MAM CA, it’s time to have a look at the end-user experience. I’m going to show the end-user experience of an end-user signing in to an approved app. However, before showing that experience it’s good to mention a few important facts about the end-user experience.

  • Every Exchange Active Sync mail client, including the built-in mail clients on iOS and Android, will be blocked. Instead end-users receive an email informing them that they need to use the Outlook mail app (see also this post);
  • If an end-user is targeted with MAM CA and “normal” conditional access (Device CA) policies, the end-user must meet one of the two requirements:
    • The used app is allowed by MAM CA;
    • The used device is managed by Microsoft Intune (hybrid or standalone) and compliant, or it’s a domain-joined PC.

Now let’s have a look at the Microsoft Outlook app and the flow that I described earlier. The end-user signs in to the Microsoft Outlook app and is prompted to install the Azure Authenticator app (see first screenshot). Once the end-user signs in to the Microsoft Outlook app and the Azure Authenticator app is installed, the end-user is prompted to open the Azure Authenticator app (see second screenshot).

Azure Authenticator app not installed Azure Authenticator app is installed
IMG_0098 IMG_0099

After switching to, and signing in to, the Azure Authenticator app, and the device is not registered, the end-user is prompted to register the device (see first screenshot). Once the device is successfully registered, and the end-user is successfully signed in, the end-user will be allowed access and receive the configured MAM policies (see second screenshot).

Device is not registered Device is registered
IMG_0100 IMG_0101

More information

Fore more information about MAM CA and related components, please refer to: