Intune

Deploying ‘IntuneMAMUPN’ for applying different iOS App Protection Policies depending on device’s management state

In this post, we shall learn about the significance of ‘IntuneMAMUPN‘ and how we can deploy different MAM policies to iOS devices depending upon their management state.

My name Saurabh Sarkar and I am an Intune engineer in Microsoft. I have a YouTube channel and you can subscribe to the same to learn more about Microsoft Intune.

The entire explanation and demonstration of this topic can be found below in my Youtube post-

Background:

• In today’s cloud word, as most of the users are roaming, for organizations, its very common to allow end users to use both MDM managed devices (COD) and unmanaged devices (usually BYOD) to access corporate resources.
• As an admin, one of the major value add we get by using Intune as compared to other MDMs is- The functionality of MAM without Enrollment. (in this case we manage an application in the device but not the entire device, hence is ideal for BYOD kind of a scenario)

Also, its very common for the admin to have different level of control/restriction on the application depending upon the kind of device in picture.

• Meaning, we can have one app protection policy for the application running in an unmanaged device (MAM without Enrollment) which is strict.
• On the other hand, we can have an app protection policy for the same user and the same application running in a managed device (MAM with Enrollment) which is comparatively less strict.

The ability to do the above provides the best possible user experience based on the device’s state while meeting the security requirements of the IT folks

The NEED for such a setup:

Lets say user access his emails from-

• His personal phone (BYOD)- not enrolled
• As well as company provided phone (COD)- enrolled

• Now given that the company provided phone already has a mandatory password set and 3rd party installations blocked, the admin might be little at ease.
• So the admin might decide that there need to be no PIN that needs to be setup while accessing the outlook application from the device. (or a less restrictive pin)
• This is for the end user’s ease so that he does not have to enter password during the device unlock and again a strict password while launching the app (which might be cumbersome)
• We might wanna give the user an option to open any hyperlinks from outlook in any browser or not set a minimum OS version requirement on this COD device for the application to run as an example

On the other hand, when the user accesses the same outlook application from a personal device, we as an IT admin are not really sure of how secure the device in itself is.

• The device might not have a passcode set/might have a lot of 3rd party applications installed/might be a shared device which makes the same more prone to security attacks.
• Herein we might only allow the outlook hyperlinks to open in managed browsers only, so as to ensure that the data is not leaking or set a minimum OS version requirement for the app to run to ensure that the device is patched and updated.
• On such a device the IT admin might want to impose a stricter policy control on the outlook application as we are not really sure how safe the device is.
• In this case the admin might enforce a stricter password/pin control on the application as an example.

USE CASE:

Let’s understand a practical use case with the below figure.

We have a user ‘gregs’ who is using outlook in 2 devices, one enrolled and one unenrolled

The admin has created 2 app protection policies viz-

• MAM with Enrollment (less restrictive with 4 digit PIN)
• MAM without enrollment (more restrictive with 10 digit PIN)

Both the policy is targeted to the same user “gregs”

The requirement is-

• MAM without enrollment policy should come down to the unenrolled device.
• MAM with enrollment policy should come down to the enrollment device

THE CHALLENGE:

The setup looks perfect as of now, however unfortunately it doesn’t quite work like that! ( a bummer!)

By default, for iOS, the MAM without enrollment policy takes precedence over the MAM with enrollment policy in an enrolled device.

Meaning, the device enrolled by ‘gregs’ in the above example also gets the MAM-without-Enrollment policy which is not the requirement. Hence our observation does not meet our requirement.

Observed Behavior:

As seen below, when we enroll an iOS device with the account ‘gregs’ it gets the “MAM-without Enrollment” policy!
This is confirmed by-

• We are prompted to set a PIN of 10 digits (as set in MAM-without-Enrollment policy) and not 4 digits
• When we check the MAM-checkin for the user/application we can see the relevant policy being evaluated

THE FIX:

• The IntuneMAMUPN is needed so that we achieve the above usecase.
• This needs to be deployed via an App Configuration policy for the application

The ‘IntuneMAMUPN’ App configuration policy’s job is to tell the app that it is not supposed to get the MAM-without-enrollment policy, but is supposed to get the MAM-With-Enrollment policy as the device is in enrolled state.

Note: We need to make sure that the above application needs to be managed via Intune.

• Even if the app was already there in the device, the user gets a prompt like “i.manage.microsoft.com” wants to take over the management of the application.
• The best way to make sure of this is, deploy the app via Intune. (preferably as required to eliminate user dependency)

Setting up the ‘INTUNEMAMUPN’:

As shown below, so set this up, we just have to deploy an App Configuration policy with the below setting for each application.

Policy Type	Policy Selection	Policy location (in the portal)	Application Name	Configuration Key	Value Type	Configuration Value
App Configuration	Managed Devices	Microsoft Intue>Client Apps>App Configuration	Outlook/(relevant app)	IntuneMAMUPN	String	{{UserPrincipalName}}

AFTER-EFFECTS:

As seen below, once the IntuneMAMUPN key has been deployed, when we enroll an iOS device now with the account ‘gregs’ it gets the “MAM-with-Enrollment” policy.
This is confirmed by-

• We are now prompted to set a PIN of 4 digits (as set in MAM-with-Enrollment policy) and not 10 digits
• When we check the MAM-checkin for the user/application we can see the relevant policy being evaluated

Conclusion:

As seen above, now the relevant policies are coming down to the devices.
This is useful if the organization wants to impose a different level of restriction on a device depending on the device’s management state.