This post is part of the overall MS-500 Exam Study Guide. Links to each topic as they are posted can be found here.

This post will cover the following exam topics listed under the “Implement and Manage Device and Application Protection” section:

• Configure and manage non-Windows device encryption
• Plan for securing applications data on devices
• Implement application protection policies

In Part 1  and Part 2 of this post, we looked at configuring different aspects of Windows devices through Intune. In this part we will look at configuring and managing non-Windows devices and applications.

Configure and Manage non-Windows Device Encryption

We previously looked at requiring compliance on Windows devices using Intune. We can also manage non-Windows devices in the same way. To prepare for this configuration, I have enrolled an iOS device into my Intune portal as a managed device however we can also manage Android and macOS in a similar manner.

To ensure our corporate data is secured on the device, we will create a Mobile Application Management (MAM) policy. MAM policies differ from device configuration policies by targeting just the corporate applications and not the entire device. This allows us to encrypt the application that connects to our tenant and it’s associated data.

To create MAM policy, navigate to “Apps” -> “App Protection Policies” in the Endpoint Manager portal and create a new policy for iOS or Android. We can also use create a policy for Windows 10 to apply Windows Information Protection, I’ve covered this previously here.

As usual, fill out the basics and hit next.

Next we add in the apps that we want to protect. We can also choose to target apps on managed or unmanaged devices differently. For now, let’s target both managed and unmanaged devices and add in the Microsoft Outlook app. The list of supported apps can be found here.

Next we can configure the data protection settings of our policy to protect the app. We can control actions such as copy/paste, backups, printing etc. For our policy, we will configure the “Encrypt org data” and set to “Require”.

On the next page we can control access settings for our apps, here we can do things like enforce a pin/biometrics to open the app. We won’t configure these settings for now.

Next, we configure the conditional launch settings, these settings allow us to add conditions like how long the phone can be offline before the app data is removed, how many pad PIN attempts are allowed etc.

Finally, we assign the policy to a group. I’ve created a group for iOS device owners with all users who use iOS. In production, we could use this group in Conditional Access to only allow iOS devices to be used by these users. We could also target different levels of restrictions to different user groups.

When we review and create the policy, we’re good to go.

As a tip, to ensure our data is accessed securely and subject to our policy, we can use the “Require app protection policy” grant control in Conditional Access to ensure that users connecting to our services use an app that is supported.

Plan for Securing Applications Data on Devices and Implement Application Protection Policies

In the above section we looked at encrypting Applications Data on non-Windows devices. This is just one of the controls available to us using MAM policies though. Let’s take a look at some of the other controls we have available.

The controls available differ between Android and iOS, in the below example, we are looking at iOS controls specifically.

To edit our existing app protection policy, open up the policy and select “Properties”. Let’s first open the Data protection settings by clicking the edit option.

In the data protection section of the policy, we have the following controls available to us:

• Backup org data to iTunes and iCloud Data – We can prevent users taking backups of organizational data using iTunes and iCloud
• Send org data to other apps – Define is organization data within this app can be sent to other app
• Save copies of org data – Can users save a copy or organization data they open in the app. This can be restricted to SharePoint / OneDrive only to allow data to remain within our corporate controlled space
• Transfer Telecommunications data to – Define if calls can be performed based on data within this app (i.e. when a user is sent a phone number via email, can that number be transferred to the dialler app)
• Receive data from other apps – Can data be brought into this app from other apps
• Restrict cut, copy, paste between other apps – Can data be cut, copied, pasted from this app to other apps. We can specify only other managed apps can receive content from this app. We can also assign a character limit for what can be copied
• Third party keyboard – We can block third party keyboards which may pose a security risk
• Encrypt org data – Enforce encryption for the organizational data within the app
• Sync policy managed app data with native apps – Block the syncing of data from Outlook to native apps (Contacts, Calendar)
• Printing org data – Block printing of organizational data from the app
• Restrict web content transfer with other apps – When opening web content, we can restrict the capabilities such as only allowing opening in Edge
• Org data notifications – Allow notifications from organizational data such as email notifications

Next we can edit the access requirements to control how our users access the app. In Access requirements we have the following settings (for iOS):

• Pin for access – Require a PIN before the user can open the app
• Pin type – Define numeric or passcode PIN for access
• Simple Pin – Are simple PINs such as “1234” allowed
• Select minimum PIN length – Minimum length of PIN
• Touch ID instead of PIN for access – Is touch ID allowed instead of PIN to access the app
• Override biometrics after PIN timeout – After a period of inactivity, enforce PIN rather than biometrics
• Timeout – Minutes before biometrics and overridden by PIN requirement
• PIN reset after number of days – Should the PIN require a reset after a certain number of days
• Number of days – How manway days before a PIN reset is required
• App PIN when device PIN is set – Should a PIN still be required to access the app if the device has a PIN set already
• Work or school account credentials for access – Should the user be required to enter their corporate credentials to open the app
• Recheck the access requirements after – How long should access last before they are required again

Once we have updated our policy, we can edit our assignments to select the appropriate groups and save to deploy the changes.

Summary

MAM policies are extremely useful for both corporate owned devices and BYOD. We have a lot of flexibility to protect our data while still making it available to users so they can work effectively from anywhere. We didn’t look at Windows Information Protection in this post as I have previously uploaded a full post about WIP.

While it’s not called out directly in the exam topics, I recommend also being familiar with device configuration profiles and enrolment settings for non-Windows devices also.

This section of the exam topics seems to leave out a lot of key concepts of device management such as publishing apps, device compliance and configuration profiles which I do recommend checking out using the below links:

Microsoft Intune documentation | Microsoft Docs

What is Microsoft Intune device enrollment – Microsoft Intune | Microsoft Docs

Device features and settings in Microsoft Intune – Azure | Microsoft Docs

Device compliance policies in Microsoft Intune – Azure | Microsoft Docs

Protect devices with Microsoft Intune – Microsoft Intune | Microsoft Docs