Conditional access for managed apps

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.

Introduction

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.

Flow

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.

CA_MAMWE

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.

  1. Start: The end-user signs in to a managed app;
  2. 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;
  3. 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;
  4. 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.
  5. 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.

Configuration

After knowing what MAM CA is and knowing how MAM CA works, it’s time to look at the perquisites and the configuration.

Prerequisites

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.

Configuration options

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.

1

MAMCA_AllAppsThe first configuration section is Allowed apps. The Allowed apps is used to select the mobile apps for iOS and Android that are allowed to access Exchange Online.

MAMCA_ManagedAppsTo allow apps to connect to Exchange Online the administrator can choose between selecting Allow all apps and Allow apps that support Intune app policies. The latter selection currently contains Skype for Business, Excel, PowerPoint, Word, OneNote, Outlook, Microsoft SharePoint and OneDrive for Android and iOS.

2 MAMCA_RestrUsGrThe second configuration section is Restricted user groups. The Restricted user groups section is used as the targeting mechanism for the MAM CA policy. Every available group in Azure AD can be selected. The selected group will be restricted by the MAM CA policy, immediately after saving the MAM CA policy.
3 petervanderwoude.nlThe third configuration part is Exempted user groups. The Targeted apps section is used as an exemption mechanism for the MAM CA policy. Every available group in Azure AD can be selected. The selected group will be exempted from the MAM CA policy, immediately after saving the MAM CA policy.

Additional considerations

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.

4

ADFS_ModernAuthAn additional consideration is to use AD FS to block non-modern authentication. This can be achieved in AD FS 2016 by creating an Access Control Policy and assigning it to the Microsoft Office 365 Identity Platform Relying Party Trust.

That Access Control Policy must contain at least a rule to Permit users with Endpoint Path contains (/adfs/ls)|(/adfs/oauth2) in the request. This will make sure that only apps, using modern authentication, can connect to any cloud services that uses the Microsoft Office 365 Identity Platform Relying Party Trust.

End-user experience

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
IMG_0098 IMG_0099

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
IMG_0100 IMG_0101

More information

Fore more information about MAM CA and related components, please refer to:

Share

10 thoughts on “Conditional access for managed apps

  1. 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.

  2. 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?

  3. 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?

  4. Hi Paul,

    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.

    Regards,
    Peter

  5. 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.

  6. 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

  7. Hi Paul,

    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.

    Regards,
    Peter

  8. 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…

Leave a Comment