Intune MAM for iOS/iPadOS – Back 2 Basics

As the title suggests, this post is all about brushing up our knowledge about the basics of Intune MAM (App Protection policy) for the iOS/iPadOS platform.

Deciding Policy Type

When you embark upon creating an App Protection policy from Intune for the iOS/iPadOS platform, the very first step is to decide the Management type applicability of the policy – is the policy being created to work for

• MAM-only (without enrolment) scenario (the device is unmanaged or managed via 3rd-party MDM), or
• MAM + MDM scenario (the device is Intune managed)

The behavior of the policy is controlled by the setting named Target to apps on all device types.

When Target to apps on all device types is set to Yes means the policy is intended for both MAM-only (MAM-WE) as well as MDM+MAM scenarios.

This works well if you want to keep the same protection settings for both COD and BYOD devices in the environment.

However, if you require to keep a separate set of policies due to differences in protection settings for your COD and BYOD devices, then you need to create two separate sets of app protection policies for device types.

• For BYOD (unmanaged devices, or MAM-WE scenario)

Target to apps on all device types should be set to No with Device types selected as Unmanaged.

• For COD (managed devices, or MDM + MAM scenario)

Thus, if you prefer to keep your policies segregated, you will mostly end up with two app protection policies for the iOS/iPadOS platform.

Policy #1 - Device type is Unmanaged for MAM-WE scenario (or device is managed with 3rd-party MDM)

Policy #2 - Device type is Managed for MDM + MAM scenario (device can be ADE or non-ADE, doesn't matter!)

Targeting Apps

As the stage is set for the policy, next is deciding the applications to which the policy will apply.

Only those apps that have been integrated with the Intune App SDK or wrapped with the Intune App Wrapping Tool can be managed using Intune app protection policies. Here is the official list of Intune-managed apps available for public use. LOB apps need to be either built with Intune App SDK integrated or wrapped to make them work with Intune MAM policies.

This is where MS introduced the app categories (introduced with service release 2109) to help IT Pros better target app protection policies by adding applications dynamically to the policy as per the category selected. The applications for each category are managed by Microsoft.

As already listed in MS documents, here is what the categories refer to

• All Apps include all Microsoft and partner apps that have Intune SDK integrated.
• Microsoft Apps includes all Microsoft apps that have Intune SDK integrated.
• Core Microsoft Apps include the following apps: Edge, Excel, Office, OneDrive, OneNote, Outlook, PowerPoint, SharePoint, Teams, To Do, and Word.

After you make a selection for the app category,  you can select View a list of the apps that will be targeted to view the app list that will be affected by this policy.

What these app categories help us with is saving us from the effort of having to add an application and update the existing app Protection policies, every time a new Intune SDK enabled app is released. 

However, if the predefined categories do not suit your need, you can always revert back to manual control of adding applications to your app protection policy as shown below.

When you choose to target individual apps by selecting Selected apps in the Target policy dropdown box, you get to add two types of applications to the policy

• Public apps – Apps available in public stores that are from Microsoft and partners and supported for app protection with Microsoft Intune by virtue of having Intune SDK integrated.

• Custom apps – LOB apps that have been integrated with the Intune SDK or wrapped by the Intune App Wrapping Tool.

Configuring DLP settings

This is where you get to configure the DLP restrictions to be applied to the managed app(s) via the policy.

There are groups of settings to be configured under three main categories – Data Transfer, Encryption, and Functionality. The settings themselves are pretty self-explanatory and most have the “info” icon that you can hover the mouse over to get further information.

Under the Data Transfer category, the first setting that we get is Backup org data to iTunes and iCloud backups, which lets you decide whether to Allow or Block the managed applications (to which the policy applies to) from backing up org data to the mentioned public cloud services.

The next setting Send org data to other apps is about deciding how you want your protected apps to handle the transfer of organization data to other apps (managed or unmanaged apps!).

The values that you can set for the setting are as below.

• All apps: Allow transfer to any app. The receiving app will have the ability to read and edit the data.

• None: Do not allow data transfer to any app, including other policy-managed apps. If the user performs a managed open-in function and transfers a document, the data will be encrypted and unreadable.

• Policy managed apps: Allow transfer only to other policy-managed apps.

When you set Send org data to other apps to Policy managed apps, users may be able to transfer content via Open-in or Share extensions to unmanaged apps on unenrolled devices or enrolled devices that allow sharing to unmanaged apps. Transferred data is encrypted by Intune and unreadable by unmanaged apps.

• Policy managed apps with OS sharing: Only allow data transfer to other policy managed apps, as well as file transfers to other MDM-managed apps on enrolled devices.

When you set Send org data to other apps to Policy managed apps with OS sharing, this is applicable to MDM enrolled devices only. If this setting is targeted to a user on an unenrolled device, the behavior of the Policy managed apps value applies. Users will be able to transfer unencrypted content via Open-in or Share extensions to any application allowed by the iOS MDM allowOpenFromManagedtoUnmanaged setting, assuming the sending app has the IntuneMAMUPN and IntuneMAMOID configured.

• Policy managed apps with Open-In/Share filtering: Allow transfer only to other policy managed apps, and filter OS Open-in/Share dialogs to only display policy managed apps.

When you set Send org data to other apps to Policy managed apps with Open-in/Share filtering, it requires both the app(s) acting as the file/document source and the app(s) that can open this file/document to have the Intune SDK for iOS version 8.1.1 or above.

Users may be able to transfer content via Open-in or Share extensions to unmanaged apps if Intune private data type is supported by the app. Transferred data is encrypted by Intune and unreadable by unmanaged apps.

There are some exempt apps and services to which Intune allows data transfer by default, even if you have configured to allow data sharing to policy managed apps only. This is for functionality and usability and is not a threat or risk.

In addition, if you need to allow data to transfer to a 3rd-party app that doesn’t support Intune App Protection, you can add the app to the exempt list by using its URL scheme. Check data transfer exemptions for more information.

How to find URL scheme of an app?

You would either have to work with the app developer to get the details or need to have access to the app source .ipa file from which you can get the PLIST file within which you will find the URL schemes supported by the app (if they exist!) under the CFBundleURLSchemes key.

<key>CFBundleURLTypes</key>
<array>
  <dict>
    <key>CFBundleURLSchemes</key>
    <array>
      <string>AppUrlScheme</string>
    </array>
  </dict>
</array>

The next setting Save copies of org data is about deciding how you want your protected apps to handle the storage of organization data. When set to Block, this basically prevents the user from using the Save As option in the app to save a copy to the device’s local storage. Instead, you can decide to allow users to save to managed locations using the options provided.

This setting is only configurable when the setting Send org data to other apps is set to Policy managed apps, Policy managed apps with OS sharing or Policy managed apps with Open-In/Share filtering.

The end user must have a license for Microsoft 365 Apps for business or enterprise and the subscription must include and have the Office apps on mobile devices enabled.

If the managed location is set to OneDrive for Business, the OneDrive app must also be targeted by the same app protection policy deployed to the end user.

Sharepoint in the list refers to Sharepoint Online and not SharePoint on-premises as it is not supported (or considered) as a managed location for Intune MAM.

The value of the next setting Transfer telecommunication data to determine how managed apps will handle the transfer of hyperlinked phone number(s) to a dialler app.

When you select A specific dialer app, you get to provide the Dialer App URL Scheme.

This setting requires Intune SDK 12.7.0 and later. If your apps rely on dialer functionality and are not using the correct Intune SDK version, as a workaround, consider adding “tel;telprompt” as a data transfer exemption. Once the apps support the correct Intune SDK version, the exemption can be removed.

The next setting Receive data from other apps is about deciding how the managed app should handle incoming data. The values that you can set for the setting are as below.

• All apps: Allow data transfer from any app.
• None: Do not allow data transfer from any app, including other policy-managed apps.
• Policy managed apps: Allow transfer only from other policy-managed apps.
• All apps with incoming Org data: Allow data transfer from any app. Treat all incoming data without a user identity as data from your organization. The data will be marked with the MDM enrolled user’s identity as defined by the IntuneMAMUPN setting.

All apps with incoming Org data value is applicable to MDM-enrolled devices only. If this setting is targeted to a user on an unenrolled device, the behavior of the Any apps value applies.

The setting Restrict cut, copy and paste between other apps, as the name suggests, controls the cut, copy, and paste actions based on the value you choose.

• Blocked: Don’t allow cut, copy, and paste actions between this app and any other app.
• Policy managed apps: Allow cut, copy, and paste actions between this app and other policy-managed apps.
• Policy managed with paste in: Allow cut or copy between this app and other policy-managed apps. Allow data from any app to be pasted into this app.
• Any app: No restrictions for cut, copy, and paste to and from this app.

The setting Third-party keyboards determine the use of other keyboards than the default iOS/iPadOS keyboard.

When set to Block, it affects both the organization and personal accounts of multi-identity applications which comes with Intune SDK version 12.0.16 or later.

Under Encryption, there is the single setting Encrypt org data via which you can enable encryption of work or school data in the managed app(s).

For iOS/iPadOS, device-level encryption gets enabled as soon as the user sets up the device PIN. If the device PIN is not set up and encryption is required by Intune app protection policy, then the user is prompted to set up the device PIN. This is because Intune uses device-level encryption to protect app data while the device is in a locked state. Further, the managed apps may optionally be configured to encrypt app data using the Intune SDK encryption, which basically leverages iOS/iPadOS cryptography methods to apply 256-bit AES encryption to app data.

Only data marked as “corporate” is encrypted according to the IT administrator’s app protection policy. Data is considered “corporate” when it originates from a business location. For the Office apps, Intune considers the following as business locations: email (Exchange) or cloud storage (OneDrive app with a OneDrive for Business account). For line-of-business apps managed by the Intune App Wrapping Tool, all app data is considered “corporate.”

Under Functionality, the setting Sync policy managed app data with native apps or add-ins controls the managed app(s) behavior for saving data to the device’s native apps (Contacts, Calendar, and widgets) and to prevent the use of add-ins within the policy managed apps.

Basically, this setting lets you determine if your Outlook contacts should sync with the native Contacts app on the phone. App selective wipe will remove such synced contacts from the Contacts app. However, contact data synced from the Contacts app to another external source (iCloud backup, etc.) can’t be removed with Intune app selective wipe.

Next setting in line is Printing org data, which as from the name you might have already guessed (!), helps to determine if the managed app(s) can export and print data identified as “corporate”.

Next is the Restrict web content transfer with other apps that determines how web content (http/https links) is opened from policy-managed applications. The values that you can set for the setting are as below.

• Any app: Allow web links in any app.
• Microsoft Edge: Allow web content to open only in Microsoft Edge. This browser is a policy-managed browser.
• Unmanaged browser: Allow web content to open only in the unmanaged browser defined by the Unmanaged browser protocol setting. The web content will be unmanaged in the target browser.

And finally comes the last setting which is Org data notifications that determine how Org data is shared via OS notifications for Org accounts. The values that you can set are

• Blocked: Do not share notifications.
  • If not supported by the application, notifications will be allowed.

• Block org Data: Do not share Org data in notifications. Example – “You have new mail”.
  • If not supported by the application, notifications will be allowed.

• Allow: Shares Org data in the notifications.

Intune MAM data protection settings do not control the Apple-managed open-in feature on iOS/iPadOS devices.

Configuring Access Requirements

This section of settings is about controlling how the users can access the managed app(s) by enforcing security like requiring PIN and/or Work or school account credentials.

You may choose to require PIN for access which will enforce the end-user to create an app PIN at initial setup and then use the same to access the app.

Or, you may choose not to require a PIN for app access, but instead, require work or school account credentials which will enforce end-user to sign in with their corp account to access the app every time.

Or you may choose to enforce both which will require the end-user to enter corp credential and either PIN or Biometric (if allowed) to access the managed app(s). [For me, this is an overkill for sure and your users are not going to like it at all!)

The setting App PIN when device PIN is set lets user to not create a separate app PIN but instead continue to authenticate to the managed app(s) using device PIN to prove identity. However, it works only for enrolled devices and for managed app(s) configured with IntuneMAMUPN for the app (Intune SDK) to be able to detect enrolment state of the device.

Configuring Conditional Launch Parameters

The next batch of settings determines the condition(s) that needs to be met by the app and/or the device for the app launch to happen upon access.

With these, you can control things like wrong PIN attempts during access, whether the app should work on a jailbroken device, or if your protected app should run on older OS versions, etc.

Successful app access (PIN or credential verification) does not imply a successful app launch, as it would still need to satisfy the set criteria defined as part of the MAM policy and present the user with data.

It is recommended that the Intune App SDK version requirement, as part of Conditional Launch parameters, be configured only upon guidance from the Intune product team for essential blocking scenarios.

Creating Policy Assignment

Making assignments is pretty self-explanatory. This is where you define the groups (stick to user groups for App Protection policy assignment since MAM works on the basis of user identity), members of which will be under the policy’s purview.

You can either

• choose to make assignments at this stage if you have your groups defined and ready, or
• choose to proceed to the final section Review + create, review and confirm policy config to proceed with policy creation and make the assignment later on.

At this point, you should have your Intune MAM app protection policy created and ready for use, for the iOS/iPadOS platform.

The End

Intune MAM has been one of the USPs of Intune since its inception, giving it a competitive advantage over its competition.

It helps to protect corporate data at the app level, ensuring that sensitive data from managed apps (Microsoft or 3rd-party) is not sent or copied to other unmanaged applications, all without requiring control of the whole device. And this makes the employees using their own devices at work feel more at ease.

Thus it becomes quite a useful and essential tool in our arsenal to tackle BYOD where MDM management is not preferred and/or expected.

However, as is the case with any DLP policy, when working on protecting organization data, as an IT admin, we always need to find the middle ground between security and usability.

Because on one side there is the data that we need to protect, and on the other side, there are users who need to access those data to get their job done. And as always, the moment we start getting more restrictive with our DLP policies, thereby hindering or breaking the users’ normal flow of work, we risk the introduction of shadow IT.