The Chronicles of MAM

The Chronicles of MAM

This blog will be about the managed and unmanaged App Protection Policies and how you could make sure it also works like it should on IOS devices.

I will divide this blog into multiple parts

  1. Introduction
  2. Conditional Access
  3. App Protection Policies
  4. Android App Protection
  5. IOS App Protection
  6. IOS App Configurations
  7. Results

1. Introduction

When we want to protect the company data we have got multiple options to choose from.

Are you going to require compliant mobile IOS/Android devices, so each device needs to be enrolled (MDM)? Or do you have a lot of front line workers and you only want the apps to be secured (MAM)? Or maybe a combination?

In this example, we did both. We wanted to make sure users who had a Microsoft 365 Business Premium license needed to have their mobile devices managed/enrolled and all the other users could access office365 without their devices needed to be enrolled. Of course, we will need to apply app protection for each option.

You have to choose which of the options is the best to protect the company data. Managed devices need to get the Managed devices app protection policy and the unmanaged devices need to get their unmanaged devices app protection policy.

2. Conditional Access Rule

So let’s begin with locking down the environment with some Firewall Conditional Access rules. Assuming you already have blocked legacy authentication, we are going to create 2 additional conditional access rules..

*The first CA rule will require ms365Business licensed users to have IOS/Android compliant devices.

*And a second CA rule to make sure approved apps are required when you want to access the Office365 data. Please beware Teams and Require app protection may not go well together, so the best option you got is only requiring Approved apps (Microsoft Apps) to access office 365 data.

UPDATE: Please read my blog about the require app protection misunderstanding:

3. App Protection Policies

After the CA rules were created, we need to create the App protection policies. As shown below we created multiple App protection policies. One App protection policy for Managed devices and one for unmanaged devices

In my opinion, devices which are managed don’t need an additional password to open the app because you probably already made sure you have setup a compliance policy and a device configuration policy. Maybe you want to loosen the screws a bit on managed devices?

Another good example would be the possibility to let managed devices send org data to other apps but to block these actions on an unmanaged/personal device. I have created a blog about which option you could choose and how it works in detail.

4. Android Apps

When only working with Android devices, this setup is good enough. You only need to make sure your users will have the company portal app installed. You only need to install it, there is no need for any configuration as it functions as the broker on android devices.

But when you have users with IOS mobile devices (I bet you do) you will need some additional configuration.

5. IOS Apps

First, we need to make sure all the apps which need the managed app protection policies are added. Because as mentioned earlier we need to define an App Configuration Policy for each app and how could we do this without any apps?

If you reading my blogs often, you will probably know the whole setup can be scripted. When you need to do this manually, it will take some time so why not deploy it with PowerShell:

https://call4cloud.nl/wp-content/uploads/2021/03/IOS.zip

6. App Configuration

Now we have all the apps installed on the devices we need to push an app configuration, to make sure the IntuneMAMUPN is configured for each application (some apps do not support this config). Please visit this Microsoft Doc for all the apps that do support it!

Supported Microsoft Intune apps | Microsoft Docs

You will need to configure the IntuneMAMUPN for each app because it is required for devices that are managed by Intune to identify the enrolled user account. This is very important because you really want to make sure the protected app have the correct app protection policy applied!

Let’s create a new managed app configuration policy and select the Outlook app.  Again, you will need to create an app configuration with the IntuneMAMUPN for each app.

Please beware the App configuration keys are case sensitive. Use the proper casing to ensure the configuration takes effect.

7. Results

After a while and I mean really a while, it will start working. I have created a blog on how to troubleshoot App protection policies.

The sum of all App protection policies – Call4Cloud

In the link above, I also showed you how to monitor/troubleshoot the app protection policies. So let’s take a look at which app’s understood the IntuneMAMUPN configuration.

When taking a look at the edge app configuration, you can check if the configuration did apply succesfully.

As shown above, I guess Edge does not respond on the configuration policy but Teams/Onedrive and Outlook did.

EDIT: 18-03-2021: The app assignment was configured as available instead of required. After (re)installing the already installed app from the company portal and recreating the app configuration it worked like expected.

When you are at the customer and you want to determine which app protection policies were applied, you could do so by opening edge and type: about:intunehelp

Conclusion:

You will need to find the golden middle when securing your office 365 data, otherwise, lines will be drawn in the sand. On your left, there is data to protect and on your right side, there are users who need to get their job done. You really need to let the end-users understand why it’s important.

Baby Cow confused idiot insult james corden GIF

Leave a Reply

Your email address will not be published. Required fields are marked *

3  +  4  =