After a great MVP Summit and a session at a great Experts Live, it’s finally time for a new blog post. This blog post will be about conditional access for managed apps (MAM CA). About a month ago, I did a first post about this feature when it was still in preview. The good news is that the first part of this feature is now production ready for all tenants. In this post I’ll go through an introduction of MAM CA, the flow of MAM CA, the prerequisites of MAM CA, the configuration of MAM CA and the end-user experience of MAM CA.
By now, I think, everybody should be familiar with the mobile app management without enrollment (MAM-WE, previously also referred to as MDM-less MAM) feature. MAM-WE helps with making sure that company data and resources are protected, even though the device is not managed. MAM CA adds an additional layer to that picture. MAM CA helps with making sure that only mobile apps that support Intune MAM policies are allowed to access Office 365 services (for now only Exchange Online). That enables us to allow access to Office 365 services, without the need to require enrollment and only for apps that can be managed.
Now let’s have a look at the flow that is used by MAM CA, by going through the steps in the picture shown below.
Note: In the above picture CP is referring to the Company Portal app on Android and AA is referring to the Azure Authenticator app on iOS.
- Start: The end-user signs in to a managed app;
- App Approved?: When the end-user is restricted with MAM CA policies, a check is done to see if it’s an approved app. The approved apps are stored on a list in Azure AD and during the sign-in the app is validated with that list. When the app is not on the list, the end-user will be prompted that it’s not allowed to sign in via the app;
- CP/AA Present?: When it’s an approved app, a check is done to see if the broker app is installed on the device. On iOS this is the Azure Authenticator app and on Android this is the Company Portal app. When the broker app is not installed on the device, the end-user will be prompted to install the app;
- AAD Registered?: When the broker app is installed, and the end-user is signed in, a check is done to see if the device is registered in Azure AD. When the device is not registered in Azure AD, the end-user will be prompted to register the device.
- Approved: When the device is registered in Azure AD, the end-user can access Exchange Online via the managed app.
Note: The device registration in Azure AD will create a device record and certificate against which tokens are issued. There is no management profile installed on the device and there are no policies applied to the device. The device record in Azure AD only contains the alternativeSecurityIds, the deviceOSType, the deviceOSVersion and the displayName properties.
After knowing what MAM CA is and knowing how MAM CA works, it’s time to look at the perquisites and the configuration.
Before starting looking at the configuration, it’s good to be aware of the following prerequisites/ requirements/ limitation.
- The end-user must be licensed for Enterprise Mobility + Security or Azure Active Directory premium;
- At this moment MAM CA is only available for Exchange Online;
- The end-user must install the broker app on their device;
- MAM CA relies on modern authentication.
Now let’s have a look at the configuration options for MAM CA. The MAM CA polices contain three different configuration sections. These three sections together are the targeted MAM CA policy. Let’s go through these three section and see how they can be used.
An additional consideration for MAM CA is to close the gap for apps that don’t support modern authentication. Without closing that gap, apps that don’t support conditional access might still be able to connect. Let’s go through a method to close that gap.
After configuring MAM CA, it’s time to have a look at the end-user experience. I’m going to show the end-user experience of an end-user signing in to an approved app. However, before showing that experience it’s good to mention a few important facts about the end-user experience.
- Every Exchange Active Sync mail client, including the built-in mail clients on iOS and Android, will be blocked. Instead end-users receive an email informing them that they need to use the Outlook mail app (see also this post);
- If an end-user is targeted with MAM CA and “normal” conditional access (Device CA) policies, the end-user must meet one of the two requirements:
- The used app is allowed by MAM CA;
- The used device is managed by Microsoft Intune (hybrid or standalone) and compliant, or it’s a domain-joined PC.
Now let’s have a look at the Microsoft Outlook app and the flow that I described earlier. The end-user signs in to the Microsoft Outlook app and is prompted to install the Azure Authenticator app (see first screenshot). Once the end-user signs in to the Microsoft Outlook app and the Azure Authenticator app is installed, the end-user is prompted to open the Azure Authenticator app (see second screenshot).
|Azure Authenticator app not installed||Azure Authenticator app is installed|
After switching to, and signing in to, the Azure Authenticator app, and the device is not registered, the end-user is prompted to register the device (see first screenshot). Once the device is successfully registered, and the end-user is successfully signed in, the end-user will be allowed access and receive the configured MAM policies (see second screenshot).
|Device is not registered||Device is registered|
Fore more information about MAM CA and related components, please refer to:
- Allow only mobile apps that support Intune MAM policies to access Office 365 services: https://docs.microsoft.com/en-us/intune/deploy-use/allow-policy-managed-apps-access-to-o365
- What to expect when using an app with MAM CA: https://docs.microsoft.com/en-us/intune/deploy-use/use-apps-with-mam-ca
- Create an Exchange Online conditional access to only allow apps supported by MAM: https://docs.microsoft.com/en-us/intune/deploy-use/mam-ca-for-exchange-online
- Block apps that do not use modern authentication (ADAL): https://docs.microsoft.com/en-us/intune/deploy-use/block-apps-with-no-modern-authentication
10 thoughts on “Conditional access for managed apps”
we have ADFS with internal IP restrictions; but with claims to support mobile devices. Skype for Business ios Client can connect to on-prem lync ok – but S4B clients connection to 365 for EWS to support calendar sync stops. could we place the S4B client in a MAM policy to make this work? btw – we cannot switch on modern auth yet.
You kind of answered your own question. You need modern authentication for MAM to work. Without modern authentication, MAM is not an option.
I had a couple of questions:
1. When you say registered in this statement: “After switching to, and signing in to, the Azure Authenticator app, and the device is not registered, the end-user is prompted to register the device (see first screenshot). Once the device is successfully registered” is that different that enrolling the device with MDM? Is that just registering in MAM CA through Azure?
2. Does this currently only affect iOS and Android devices? So if I set this policy, it should NOT affect laptops currently using O365?
3. If a user on iOS tries to navigate to portal.office.com and click Mail or Onedrive after turning on CA, will they be blocked there as well? Or just Mail?
1. As mentioned in a note, it does something like a mini-device registration. The device record in Azure AD only contains the alternativeSecurityIds, the deviceOSType, the deviceOSVersion and the displayName properties;
2. This functionality is currently only available for iOS and Android;
3. The browser is something you could block with Device CA. This is currently not part of MAM CA.
If I am having the Intune check for the PC as domain joined and we enable this,
do I also need a MAM policy for office 365 Pro Plus ?
If so would the machines need to be intune controlled or just
have used workplace join to make ADFS be able to check if they are wokplace joined?
Not that we have a ton of them would I need a mac osx office 365 thick client policy as well?
What exactly are you referring to? This post is about MAM-WE/MAM CA, which is currently only available for iOS and Android.
As explained in this post MAM CA can work next to Device CA.
We are using sccm and in hybrid mode, and we are about to try to get our devices – a mix of Windows 7 and 10 – registered into AzureAD so we can check the box for all platforms in Intune and I just wanted to better understand if, once we said on the device side to look at PCs and require them to be “domain joined” ,then the MAM CA would care about PCs at all , and where I would set it if we are SCCM integrated, is this setting through the AzureAD CA controls and no different.
We are just starting our on Conditional Access and migration from OKTA to ADFS ( installing it this weekend ) . And between azure CA, MAM CA, Intune CA, ADFS claims rules, Exchange CA and controls, and Modern Auth having the side effect of our owa, outlook(thick) and outlook app calls all looking similar we are a bit confused on what to set where and how they interact with each other.
PS I really appreciate your website, it is always helpful and well done
Once you’ve configured SCCM as the MDM authority, you’re all set. For configuring Conditional Access (CA) I would start looking at the Azure Portal. Configure Device CA via Azure Active Directory > Conditional Access and MAM CA via Intune Mobile Application Management > Conditional Access.
Note: Keep in mind that officially Azure Active Directory is still in preview via the Azure portal, but it gives you a lot better control over Device CA.
Hi Peter, we have just moved our Device CA policies from the classic AAD portal to the Azure portal and it seems that MAM-CA no longer takes precedence over DEVICE-CA. When a user is targeted with both policies they are prompted to enrol. If we exclude the user from DEVICE-CA then they are prompted to register. However we don’t want to have to exclude them from DEVICE-CA completely, just enable MAM-WE/MAM-CA to work for Outlook on iOS/Android.
Do we now have to build complex DEVICE-CA rules with exclusions to try and get this to work? I am just wondering if the behaviour has changed or if there is a bug somewhere…
I’ve heard that one before. Please contact Microsoft about that issue.