Azure AD Conditional Access with 3rd-Party MDM solutions

Leverage the Microsoft Partner Device Compliance APIs for iOS and Android devices. How to setup Workspace ONE UEM (AirWatch) to signal it’s own device compliance status to Microsoft Azure AD (AAD) to secure end-user application access using MEM / Intune Conditional Access (CA).


You may like it or not: For various reasons many companies decide to use Microsoft Azure AD as their primary identity provider (IDP). In addition they choose Microsoft Conditional Access to secure the end-user access to “modern Auth applications“ like Office 365, Salesforce or ServiceNow. The user typically signs into Azure AD once per day and benefits from Single Sign-On (SSO) experience to access all his applications. In addition Microsoft Conditional Access enables IT to control granularly the security level each time the end-user requests access to a corporate application.

When Microsoft Azure AD Conditional Access comes into the play, it’s typically a decision of the customer’s “Security & Compliance” and/or “Identity Management & Access” department. Most of the times this decision gets enforced top-down and will finally hit the endpoint management team. For some reasons companies start to believe that this approach requires the mandatory usage of Microsoft Endpoint Manager (MEM) / Intune as their primary device management tool. But this is wrong.

And this is the main idea of this article: Clear the dust and show how a 3rd-party endpoint management solution like VMware Workspace ONE UEM (AirWatch) nicely integrates into Azure AD Conditional Access. But of course the solution approach is available for other endpoint management solutions as well. But let’s have a closer look at this …

Index & Version Info
### Index
The Why - What's the business and technology challenge at all?
Why do I need to use Workspace ONE Intelligence
Interconnect-3rd-party-MDM-endpoint-solution-with-Azure-AD - Hands-on starts
Enable Partner Device Compliance Policy for Android
Azure AD - register your device - iOS
Azure AD - register your device - Android
Cross check - trigger non-compliance scenario
Cross check - deletion of device
Dos and don'ts
Helpful URLs

### Version Info
# 2020-01-23: Added section: Azure AD - register your device - Android
# 2020-01-23: Added section: Cross check - deletion of device
# 2020-01-29: Added sub-section: Enable Partner Device Compliance Policy for Android
# 2021-01-29: Added sub-section: How to re-test all processes end-to-end using the same test device
# 2021-02-08: Updated requirements for on-premise UEM consoles 

### About the Author
Oliver Kluenter - Vita URL here - Contact me to discuss on LinkedIn here

The Why – What’s the business and technology challenge at all?

When a users request access to an application (e.g. Office 365), Microsoft Conditional Access checks different conditions / signals if the access is okay (user, location, device state, risk-based score, …). Most of the time IT Security wants a policy to check the device “is compliant” status before granting the user access to an application.

If you use MEM / Intune MDM-managed devices, then the device states like “isManaged” or “isCompliant” are automatically set in Azure AD. As a next step you now create a “Jailbreak/root compliance rule” in MEM / Intune. The correspondent device property “isCompliant” get immediately updated in Azure AD once a compromised device is detected. As a result a company can use the device state “isCompliant” in their Conditional Access policies to grant or block access to corporate applications.

But especially in the mobile iOS and Android world a large part of the market share for MDM / endpoint solutions is still with competitors like VMware, MobileIron, Citrix, MaaS 360 and others. In this case the main problem during the user authentication process for Microsoft Conditional Access is: How can it be proved that the device requesting access to an app, is really the device it claims to be? And how can the non-Microsoft => Partner managed device become a registered device in Azure AD including the latest “isManaged” and “isComplaint” status? This is why Microsoft implemented the “Device Compliance Partner” interface to provide a solution to their customers.

How it works in a nutshell: The Microsoft Partner Device Compliance interface allows 3rd party MDM / endpoint solutions to register their devices in Azure AD, and to constantly update the correspondent Azure AD properties like “icManaged” and “isCompliant”. As a result a company can use the device state “isCompliant” in their Microsoft Conditional Access policies in order to secure the access to corporate applications even though not using MEM / Intune as their primary endpoint management solution.

VMware specific: Why do I need to use Workspace ONE Intelligence

This content is a bit specific for VMware customers, but the overall process flow should be the same for other endpoint solutions like MobileIron and others.

Workspace ONE (WS1) Intelligence is a must have if you want to integrate into Microsoft Partner Compliance interface – no way around. For a lot of VMware customers operating Workspace ONE UEM on-premise this requirement is a pain because Workspace ONE Intelligence is a pure SaaS service. The reason behind is that Microsoft wants a central service interface from a Device Compliance Partner that is interacting with Azure AD. We see the same kind of requirement from Google for specific Android Enterprise features, e.g. the App Feedback Channel. So this looks like a modern requirement that endpoint management solutions will see more often in the future.

The good news is that every on-premise customer with Workspace ONE “Standard” + “Advanced” license is privileged to use Intelligence for free with is standard/basic feature. No special add-on is required.

The effort for customers is to get Workspace ONE Intelligence through their internal security and compliance process. As you already use Azure AD to cover this blog’s use case, this should be not too complicated. The Endpoint Management team should reach out to the “ID & Access Management” guys: They know the process pretty well. Please finde below default public documents and URLs for Workspace ONE Intelligence that are usually required.

Once done WS1 UEM on-premise customers need to install and operate the Intelligence Connector service that interconnects the on-premise UEM database with the correspondent Workspace ONE Intelligence tenant – see details here.

### Helpful VMware URLs for companies SaaS security & compliance Processes
# VMware Cloud Trust Center - Compliance

# Workspace ONE Intelligence - Sub-Processors => VMware Workspace ONE / Select Sub-processors / Search for “Intelligence"

# List of all WS1 UEM data that gets synchronized into WS1 Intelligence

Interconnect 3rd party MDM endpoint solution with Azure AD

Scenario & requirements
### Scenario
- Typical VMware customer scenario
- Workspace ONE UEM for iOS and Android endpoint management
- No usage of Workspace ONE Access 
- No usage of Intelligent Hub Services
- Use Azure AD as primary IDP with AAD Conditional Access

### Requirements
# Microsoft
- Microsoft Azure AD Premium + Intune subscriptions 
- I used EMS E5 plan €14,50 per user - EMS E3 plan is sufficient

# VMware
- VMware Workspace ONE UEM 20.08 with feature flag or 20.10+
- Update 2021-02-08: Currently requires Azure Conditional Access for On-prem customers needs public Console URL (KB 82555)
- UEM Integration MUST happen in a tenant with OG type = Customer
- For test purposes it’s not required to connect your local AD with the WS1 UEM tenant

# On the device
- VMware Workspace ONE Intelligent Hub (Agent) 20.03+
- VMware Workspace ONE Intelligence - Standard/Basic
- iOS/Android: Deploy Microsoft Authenticator app as the "broker app"
- Android Enterprise devices: Msft Authenticator MUST be an MDM-managed app

This hands-on part should be useful for everybody who touches this topic first time, and will focus on the generic integration setup and device AAD registration process. If you are a “experienced high flyer” in this area, then I strongly suggest to jump to the follow blog post:

# Sascha Warno – Workspace One UEM 3rd party compliance integration – Microsoft Graph API
– Additional iOS + Android Conditional Access app testing including Videos – great!!!
– Different scenario using Workspace ONE Access + Hub services

Step 1: Add VMware Workspace ONE mobile compliance app – iOS

In general you follow the VMware documentation “Use compliance data in Azure AD Conditional Access policies by integrating Workspace ONE UEM with Microsoft“.

For each supported Microsoft OS (as of 2021-01: iOS, Android, macOS – macOS not yet released by VMware) you need to go through this process. By doing this Microsoft offers the flexibility to add different Compliance Partners (VMware, MobileIron, Citrix, …) for different OS. For each OS you currently can add a single Device Compliance Partner interface. But from my perspetive the way Microsoft set this up would allow them in the future to add multiple Device Compliance Partners for a single OS. Think about a large company with a heterogeneous device management landscape or doing an acquisition. For my first hands-on I decided to use Apple iOS.

The interesting fact is that the VMware Compliance app gets enabled within MEM / Intune – see URL here. So from a process point of view all device related processes towards Azure AD seems to pass MEM / Intune. You will see this later in the Azure AD audit logs when an iOS device gets registered into Azure AD.

At the end of this process you have created your first Partner Compliance Policy for your first OS, in my case iOS. Important: Don’t forget to add your Partner Compliance Policy for other OSes like Android. Otherwise there will be problems when you AAD register your first Android device and wonder, why the “isCompliant” device property will not get updated immediately, and user fail to login into applications. So do it right now, before you forget … like I did first time 😉

Step 2,3,4,5,6,7: Setup WS1 UEM Directory Services
# Have your Azure AD tenant / directory ID at hand. 
# Be aware: VMware supports mapping one Azure tenant to one Workspace ONE UEM that must type = Customer OG.
# For test purposes it’s not required to connect your local AD with the WS1 UEM tenant
Step 8: Create your Conditional Access policies

In a normal customer scenario this is usually already done. If you test first time you must:

1st: Create in MEM / Intune a device compliance policy – even if you don’t use Intune for device management

2nd: You need to disable the the Azure AD security defaults, so that you can switch to Conditional Access – see URL here .

3rd: Create your first Conditional Access policy – example here. Be sure you ENABLE the policy. Be sure that you don’t lock yourself out into Microsoft Management Applications like Azure AD, MEM / Intune or others. I created a policy based on Office 365 application just for iOS devices.

Enable Partner Device Compliance Policy for Android

If you haven’t already done it, you need to do the following two steps:

  • In Intune add a Partner Device Compliance policy for Android. Same process like for iOS, so jump here
  • In WS1 UEM Console re-sync the Azure with UEM. Once triggered UEM will fetch the new partner policy.

Azure AD – register your device – iOS

### Azure AD register your first iOS device

### Deploy WS1 Hub + Microsoft Authenticator App
- Device must be already WS1 UEM MDM-managed
- Device can be AAD registered at any time after device is MDM-enrolled

### AAD Registration - Option 1: Stand-alone AAD Device Registration process
- Manual trigger registration process via UEM "web clip / link" profile
- iOS Web Link: airwatch://conditionalaccess?partner=microsoft
- Android Web Link: awagent://com.airwatch.androidagent?component=conditionalaccess&partnertype=microsoft 
- After registration process the user can access the apps managed with Azure AD Conditional Access.

### AAD Registration - Option 2: Combined - AAD Register during App access
- AAD registration process get automatically triggered when user accesses an AAD CA protected app first time
- User may find this complex or irritating of not aware what happens and why.

Deploy Workspace ONE Hub + Microsoft Authenticator apps

For better user + admin experience less tickets in help desk, I propose the following best practice for iOS to deploy WS1 Hub + Microsoft Authenticator app:

  • Deploy as MDM-managed Apps with automatic deployment
  • Deploy via device-based VPP if possible => better app update options + user does not require Apple ID / iTunes account
  • Make them MDM-managed if apps are already installed by user – no user prompt if device = supervised
  • Set as “non-removable by user” – new with iOS14+ for non- + supervised devices

Trigger the AAD device registration process

There are pros and cons which option above you use for a roll-out scenario for all users in a company. You probably will implement both options. For option #1 the next step is to deploy a Webclip on the iOS device, so the user can manually trigger the AAD device registration process.

And now you should be able to AAD register your first WS1 UEM-managed iOS device.

WS1 UEM-managed device gets AAD registered
Cross check in device in Azure AD audit logs
### Cross check in device in Azure AD audit logs
- You may want to filter your device with the "Target" option

Here comes the interesting part when you have a closer look at initial logs for a AAD registerd device:

  • The first three records come from the “Device Registration Service”. In these steps the device gets AAD registered, and the Azure AD ID gets transfered to the endpoint management solution via the mobile device management agent (Screenshot #2 below)
  • Records 4+5 are triggered from the endpoint management solution and update AAD properties like isCompliant. And this process is “tunneled” through Microsoft MEM-Intune – this is why in the AAD audit logs states “Initiated by” Microsoft Intune. (Screenshots #3/4 below)

Azure AD – register your device – Android

The process for Android is pretty much the same as for iOS – so no need to fill up this blog. If you decide to trigger the AAD registration process by using the Option #1 “Webclip” approach, there is a slight difference in the UEM admin console how you create the webclip. This is because for Android Enterprise devices you can’t use anymore the “old Android legacy” method within an Android profile. So in the console the console you move to the Apps / Web / Weblinks area.

In case the webclip icon does not show up in the Homescreen area on your Android Enterprise device, you can trigger the webclip from within the VMware Intelligent Hub app in the “Websites” area.

Cross check – trigger non-compliance scenario

### Cross check and trigger non-compliance scenario
- Create a compliance rule in WS1 UEM, e.g. iOS app "File Master - document manager" with bundle ID com.filemanger.filemastor
- Trigger the device to be non-compliant in WS1 UEM
- Cross check in Azure AD audit logs if the device isCompliant flag get set to false

### Good to know
- WS1 UEM only updates the AAD properties isCompliant or IsManaged at the point of time when the status changes. No regular update process.

Typically after 5 minutes max, the Workspace ONE compliance engine detects the non-compliant device. So the good news is that when VMware Workspace ONE detects a non-compliant device, it will immediatly reach out to Azure AD / Intune to update the corespondent “isCompliant” device property. Again it’s the Intune process that acts as the entry door for Workspace ONE to change the “isCompliant” property in the Azure AD (screenshot #4/5)

Cross check – deletion of device

If you trigger an “Enterprise Wipe” or “Device Wipe” to the device, the correspondent AAD ID device properties “isCompliant” and “isManaged” gets updated to “false”. As a result the correct status is applied and conforms to the security policies.

Dos and Don’ts

How to re-test all processes end-to-end using the same test device

Delete or Enterprise wipe the device in WS1 UEM. There is no need to additionally delete the device from UEM database required wether for iOS or Android. Delete the correspondent Azure AD device object.

iOS Observations

If you deploy the iOS SSO profile before the user triggers AAD registration process, you sometimes might fail with the registration process. Investigation is on-going.

Enable + Disable Partner Device Compliance Integration

Warning: You cannot disable or re-enable the integration under the following circumstances:
– If you remove VMware Workspace ONE mobile compliance partner from the partner compliance management in the Azure Active Directory.
– If you remove Workspace ONE Conditional Access app in the enterprise applications from Azure Active Directory.

If you want to disable the integration, complete the following:
– Disable conditional access settings in Workspace ONE UEM console.
– Look up for the security group and manually remove the existing device records in the Azure Active Directory.

If you are making changes on the Azure device partner compliance, complete the following:
– Navigate to Groups & Settings > All Settings > System > Enterprise Integration > Directory Service > Sync Azure Services to sync the latest information from the Azure portal.

Helpful URLs

### Great complementary blog articles
# Sascha Warno - Workspace One UEM 3rd party compliance integration – Microsoft Graph API
- Additional iOS + Android Conditional Access app testing including Videos - great!!!
- Different scenario using Workspace ONE Access + Hub services 

# Mobile John - Workspace ONE and Intune Integration is FINALLY Coming

### Microsoft URLs
# What is Conditional Access?

# Support third-party device compliance partners in Intune

### VMware URLs
# Use compliance data in Azure AD Conditional Access policies by integrating Workspace ONE UEM with Microsoft 

# Install the Workspace ONE Intelligence Connector Service for On-Premises