Conditional access for managed apps (preview)

This blog post is about an Azure preview feature. A preview may include preview, beta, or other pre-release features, services, software, or regions. Previews are subject to reduced or different service terms. In other words, previews are for early testing and should not be considered as fully production ready.

During the session Secure access to Office 365, SaaS, and on-premises apps and files with Azure AD and Intune, at Microsoft Ignite, a nice new feature for mobile app management without enrollment (MDM-less MAM) was shown. That new feature is conditional access for managed apps. During that session they showed the URL to that new feature. What makes it even better, that specific URL already works with existing tenants. It simply brings the administrator to a public preview feature.

During this blog post I’ll provide some information about this new feature, I’ll go through the currently available configuration options of this new feature, I’ll show the end-user experience with this new features and I’ll provide my first impression with this new feature.

Information

This new feature will enable an administrator to restrict access to Exchange Online and SharePoint Online so that access can come only from managed apps such as Outlook, Word, Excel, PowerPoint and OneDrive. This new feature also pairs up perfectly with Intune mobile app management (MAM) policies, as it enables the administrator to block access to built-in mail clients or other apps that have not been configured with the Intune MAM policies.

During my first tests with this new feature I noticed that on iOS the Microsoft Authenticator app is required and on Android the Microsoft Intune Company Portal app is required.

Configuration in the Azure portal

Now let’s have a look at the configuration of this new feature. The conditional access policies are configured through the Azure portal, just like the MDM-less MAM policies. I’ll first go through the different configuration options followed by the basic step-by-step configurations.

Different configuration options

The conditional access policies in the Azure portal, contain three different configuration sections. These three sections together are the targeted conditional access policy. Let’s go through these three sections and see how they fit together.

1

CA_EXOThe 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 and SharePoint Online.

CA_SPOAt this moment, Outlook is the only selectable app for iOS and Android with Exchange Online. For SharePoint Online there are more selectable apps. It has the option of Skype for Business, Excel, PowerPoint, Word, OneNote and Outlook for iOS and Android, Microsoft SharePoint, OneDrive for iOS only and OneDrive for Android only.

2 CA_RestrUsGrThe second configuration section is Restricted user groups. The Restricted user groups section is the same for Exchange Online and SharePoint Online. It must be used as the targeting mechanism for the conditional access policy. Every available group in Azure AD can be selected here.
3 CA_ExUsGrThe third configuration part is Exempted user groups. The Targeted apps section is the same for Exchange Online and SharePoint Online. It can be used as an exemption mechanism for the conditional access policy. Every available group in Azure AD can be selected here.

Basic steps

After getting familiar with the different configuration options, it’s time to look at the creation and the targeting of a conditional access policy. The following 10 straight forward steps will guide anyone through the configuration and targeting.

1 Open the Azure portal via this link and navigate to Intune mobile application management > Settings to open the Settings blade;
2 In the Settings blade, click Exchange Online to open the Exchange Online blade;
3 In the Exchange Online blade, click Allowed apps to open the Allowed apps blade;
4 In the Allowed apps blade, select the allowed apps.
5 Back in the Exchange Online blade, click Restricted user groups to open the Restricted user groups blade;
6 In the Restricted user groups blade, click Add user group to open the Add user group blade;
7 In the Add user group blade, select an user group and click Select to save the changes and to return to the Restricted user groups blade.
8 (Optional) Back in the Exchange Online blade, click Exempt user groups to open the Exempt user groups blade;
9 (Optional) In the Exempt user groups blade, click Add user group to open the Add user group blade;
10 (Optional) In the Add user group blade, select an user group and click Select to save the changes and to return to the Exempt user groups blade.

Note: The same steps are applicable to the configuration for SharePoint Online. The only real difference is the selection of SharePoint Online instead of Exchange Online.

End-user experience

Now it’s time to have a look at the end-user experience. When an end-user is targeted with a conditional access policy for managed apps and the end-users wants to use one of the blocked apps, the end-user will get the messages below after providing company credentials. The first message will show after adding a company email account to the native mail client and the second message will show after using a blocked app.

Native mail client Blocked app
IMG_0088 IMG_0089

First impressions

My first impressions of this new feature are mixed, from a great addition to leaving room for improvements. The idea of blocking apps that are not managed is great and is something that would be an awesome addition to the product. Especially when looking specifically at MDM without enrollment. However, at this moment it’s not blocking everything. There are three section that I can see a need for improvement:

  1. Only the native mail client on Android and iOS is blocked with Exchange Online. Other mail apps, not using modern authentication, are a hit-miss exercise;
  2. Only apps using modern authentication are blocked with SharePoint Online. Other apps can still connect and sync data;
  3. Browser access is not blocked.

More in control of mobile app management without enrollment

Earlier this year I did my first post about the ability to use mobile app management without enrollment. This week I want to continue on that specific subject. The main trigger for that is  the app reporting ability that was added during the April update of Microsoft Intune. In this post I want to show how this new feature can help with being more in control of the usage of mobile app management policies for mobile app management without enrollment (also known as MDM-less MAM).

Wipe requests

Before showing the app reporting ability, to monitor the managed apps that are used by a user, I’ll start with a little information about wipe requests. Not only will that show the added value for managed apps, it’s also useful for adding information to the app reporting overview.

The real added value of a wipe request is when a device is lost or stolen, or when an employee leaves the company. At that moment a wipe request can be used to make sure that company app data is removed from the device.

To selectively remove company app data, follow the next 9 steps. Once the request is completed, the next time the app runs on the device, company data is removed from the app.

1 In the Azure portal navigate to Intune mobile application management > Settings to open the Settings blade;
2 Wipe_RRIn the Settings blade, click Wipe requests to open the Wipe requests blade;
3 In the Wipe requests blade, click New wipe request to open the New wipe request blade;
4 In the New wipe request blade, click Select the user to open the Select user blade;
5 In the Select user blade, select the specific user and click Select to return to the New wipe request blade. The users that are shown, are all the available users in the Azure AD. Not just licensed users, or targeted users;
6 Back in the New wipe request blade, click Select the device to open the Select device blade;
7 In the Select device blade, select the specific device and click Select to return to the New wipe request blade. The devices that are shown, are all the devices that are used by the selected user to access managed apps.
8 Back in the New wipe request blade, click OK to return to the Wipe requests blade. This will immediately sent the new wipe request, without asking for an additional verification;
9 The Wipe requests blade will now show a status overview of all the wipe requests that have been sent to the selected users and their devices, including the status of those wipe requests. The status will be either complete, or pending, and will be listed for every app that was used by the selected user on the selected device.

App reporting

After configuring mobile app configuration policies, or sending wipe requests, it’s possible to monitor the compliance status in the Azure portal. This includes information about the users affected by the policy, the compliance status, and any issues that end-users might be experiencing. Basically it allows the administrator to search for the compliance status for a specific user.

MAM_UserStatusIt actually already starts with an User status tile in the Intune mobile application management blade. That tile already shows a quick summary of the compliance status. It shows the total number of users within the company that uses apps associated with policies, it shows the number of users that are using apps in the company context (MANAGED BY POLICY) and it shows the number of users that are using the apps associated with policies, but are not targeted by the company policies (NO POLICY).

To use app reporting for a specific user, follow the next 5 steps.

1 In the Azure portal navigate to Intune mobile application management > Settings to open the Settings blade;
2 Users_ARbUIn the Settings blade, click Users to open the App reporting blade;
3 In the App reporting blade, click Select user to open the Select user blade;
4 In the Select user blade, select the specific user and click Select to return to the App reporting blade. The users that are shown, are all the available users in the Azure AD. Not just licensed users, or targeted users;
5 The App reporting blade will now show a clear overview of the selected user and the status of every app that is targeted at the selected user. The next paragraph includes a couple of clear examples.

Administrator reporting experience

Now it’s time to have a look at the experience for the administrator. More importantly, let’s have a look at what the app reporting capability will bring to the administrator. I will show what the administrator will see before and after sending a wipe request. Basically, the administrator will see one of the following 3 statuses for every app and device combination for the specific user.

  1. Not checked in – This means that the policy was deployed to the user, but the app has not been used in the company context since then;
  2. Checked in – This means that the policy was deployed to the user and the app has been used in company context at least once;
  3. Wipe pending – This means that the app has been used in company context at least once, but the administrator has sent a wipe request after that.
Before wipe request After wipe request
MAM_AppReporting MAM_WipeReporting

More information

For more information about sending wipe request and app reporting for mobile app management policies, please refer to the following articles:

Frequently asked questions about mobile application management without enrollment

Last update: 08-04-2016

After my blog post a couple of weeks ago, I got many question related to mobile application management (MAM) without enrollment. That triggered me to create a quick frequently asked questions (FAQ) post. MAM without enrollment is online also referred to as MDM-less MAM, Azure MAM and sometimes even Intune MAM. As MDM-less MAM seems to be the most common used, and the shortest, I’ll start using that in this FAQ.

I’ll try to keep this FAQ as complete and up-to-date as possible. Just to be sure, I’ve added a last update date at the top of this post. That is the date that this content was reviewed the last. Also, if I’m missing some obvious question, please don’t hesitate to contact me and I will add them.

What is MDM-less MAM?

MDM-less MAM can protect company data with or without enrolling devices in a device management solution. It does this by implementing app-level policies, which can restrict access to company resources and keep data within the purview of the company.

Which platforms are supported by MDM-less MAM?

MDM-less MAM supports the following platforms:

  • iOS 8.1 and later;
  • Android 4 and later.

Which apps are supported by MDM-less MAM?

MDM-less MAM supports the following apps:

  • Microsoft Word for iOS;
  • Microsoft Excel for iOS;
  • Microsoft OneDrive for iOS and Android;
  • Microsoft OneNote for iOS;
  • Microsoft Outlook for iOS and Android;
  • Microsoft PowerPoint for iOS;
  • Microsoft Remote Dekstop for iOS and Android;
  • Microsoft Managed Browser for iOS and Android.

Which scenarios are supported by MDM-less MAM?

MDM-less MAM supports the following three scenarios:

  1. Devices that are managed and enrolled in Microsoft Intune;
  2. Devices that are managed and enrolled in a third-party solution;
  3. Devices that are not managed by any solution.

Which license do I need to have to use MDM-less MAM?

MDM-less MAM requires a Microsoft Intune license assigned to the end-user. A Microsoft Intune license is also included in an EMS license.

Where can I configure MDM-less MAM?

MDM-less MAM can be configured in the Azure portal.

Does MDM-less MAM affect personal accounts?

No. The restrictions of the MDM-less MAM policies only apply when the end-user signs into a supported app using a company account.

How can I disable the “Offline interval before app data is wiped (days)” MDM-less MAM policy setting?

This specific MDM-less MAM policy setting can be disabled by configuring a value of 0.

What happens when an end-user is targeted with MDM-less MAM policies and MDM MAM policies?

The end-user will be required to enroll the device. After enrollment the MDM-less MAM policies will take precedence in the supported apps.

Why do my end-users receive the message “Your company has required that you must first enable a device PIN to access this application”?

The end-user will receive this message when there is no device PIN configured and the MDM-less MAM policy requires encryption. Without a device PIN there is no use in encrypting the device.

Where can I find the TechNet documentation?

The TechNet documentation about MDM-less MAM is available here: https://technet.microsoft.com/en-us/library/mt627825.aspx