Compliance Integration with MS Office 365 using Graph APIs

Zero Trust for MS Office 365 Overview

The concept of Zero Trust assumes that any connection to sensitive data is untrusted even coming from a corporate device and requires further checks during authentication and access. The concept specifies 5 pillars that need to be addressed when implementing Zero Trust. For an overview of those five pillars and matching VMware solutions, see Introduction to VMware Zero Trust on Tech Zone.

There are different possibilities to achieve Zero Trust and secure access to sensitive data in productivity suites like Office 365, some of which are discussed in the Tech Zone blog post Exploring Workspace ONE Compliance Integrations into Microsoft Office 365 and Azure AD.

This tutorial is part 3 of a 3-part series. Parts 1 and 2 walked you through the setup of Authentication and ZTNA-based compliance integrations with Office 365.

This part explores how Graph API integrations with Azure AD can be leveraged to update the compliance state of a linked device record in Azure AD and how to use that state within Azure AD conditional access policies.

The following topics will be covered:

• Overview components required for Zero Trust leveraging the Graph API integration.
• Setting up the Integration in Workspace ONE UEM and Azure AD
• Configuring the Azure AD Conditional Access policy rules

Audience

This tutorial is intended for IT professionals and Workspace ONE administrators of existing production environments. Familiarity with Active Directory, identity management, and directory services is assumed. Knowledge of other technologies, such as Azure AD, is also helpful.

If you are new to Workspace ONE, review the Evaluation Guide: Managing Apps and Devices with Cloud-Based VMware Workspace ONE which has step-by-step exercises implementing features like mobile single sign-on (SSO) in UEM and Workspace ONE Access.

Zero Trust through Graph API Integration - Architecture

In today's world, where remote work is becoming the norm, securing access to company resources has become crucial. Workspace ONE Compliance with Azure AD and Office 365 integration can help enterprises achieve this by providing a seamless and secure experience to their employees across various devices.

In the final part of this series, we will explore the Graph API-based integration between Workspace ONE Compliance, Azure AD, and Office 365. We will discuss two integrations—one for mobile devices like iOS and Android, as well as macOS, and the other for Windows devices.

The Graph API-based Zero Trust – Architecture video explains the flow of components involved to create this solution.

Let's start with the partner compliance integration for mobile devices, which was introduced in 2021. In this scenario, backend services are set up to handle the communication between Workspace ONE and Azure AD through endpoint management integration and Intune APIs. To leverage the API, an Intune license must be applied to the affected users. The process involves enrolling devices into Workspace ONE to receive the data and configuring them securely. This can be part of the normal rollout or a remediation step on previously unmanaged devices accessing Office 365 resources.

Once the device is enrolled, the registration process is triggered inside Azure AD, which creates and tracks device assets. On mobile devices, the registration process happens through the Microsoft Authenticator app, and the user must sign in to their Azure AD account in the app. Federation to Workspace ONE Access and Mobile SSO can be used for the best user experience. On the callback, the Azure AD Device ID is provided to Intelligent Hub and saved alongside the device record in Workspace ONE UEM. Then, backend services send API calls to Azure AD to signal device management and the current compliance state.

Any authentication or authorization request from the device to Azure must go through Authenticator, the broker, and use MSAL (MS Authentication Library) or certificates installed during registration to identify the user and the device ID from which the request originates. This allows Azure AD conditional access to look up the device record in management and the compliance status before granting access.

On iOS, the SSO extensions are leveraged, while on Android, a certificate needs to be installed or the Edge browser needs to be used for all authentication traffic. Mobile sandboxing requires more configurations to transfer the device identifier during authentication processes of applications not sharing the Microsoft secure authentication library.

Figure 1: Compliance using Graph API-based integration for iOS, Android, and macOS

Figure 1b: Partner Compliance Device registration flow

Now, let's move on to the Windows integration. The process is similar, but different in the way that the OS already includes the tools to Azure AD Join or hybrid Azure AD Join the device and allow integration with the Azure AD MDM application. The process starts with joining the device to Azure AD, and the device ID is saved in the Workspace ONE UEM device object. Then, the device ID is used to update the compliance status of the device in Azure AD and Windows. The PRT or the primary refresh token can be leveraged to achieve a single sign-on into Microsoft or other applications federated with Azure AD.

To set conditional access rules and enroll the device with the MDM application, at a minimum, the Azure AD Premium P1 license is required on the Azure AD side. The microservice on the Workspace ONE side for both scenarios is located on the Intelligence tenant with your Workspace ONE environment. It requires you to opt-in to the free tier of Intelligence, also known as custom reports.

Figure 2: Compliance using Graph API-based integration for Windows 10/11

Let's run through a quick comparison of all the solutions that we reviewed. It mainly comes down to the trade-offs and flexibility, licensing costs, and the support for certain use cases like BYOD.

With Tunnel or ZTNA, it offers some flexibility on granular policies for applications, allowing secure access on BYOD devices when using the Tunnel SDK with applications like Boxer for email access, VMware Web, or using the standalone Tunnel. The graph API-based solutions work well when you install management—even with light management—or the whole device fleet is managed already.

Figure 3: Comparison of Authentication, ZTNA, and Graph API method

Setting Up the Partner Compliance Integration

Next, we will walk through the required steps to set up the solution in Workspace ONE UEM, Workspace ONE Intelligence, and Azure AD.

Requirements for Workspace ONE UEM and the Partner Compliance API

Before you can proceed, you must have the following components installed and configured:

• An existing Workspace ONE environment
• Access to Azure AD Conditional Access Policies
• Intune/Endpoint management portal access
• Azure AD Premium P1 license, Intune license

Let’s go through the main steps required to set up this solution. The brief documentation for it can be found in VMware Docs: Use Compliance Data in Azure AD Conditional Access Policies.

Watch the Partner Compliance Integration Setup video:

We begin in the Workspace ONE UEM console by opting into the Intelligence service if not done already. On new SaaS tenants, that step is already completed, and you can see the Launch button.

Figure 4: Check Intelligence Opt-in

We confirm that the Azure AD Integration is set and that we added the correct Directory ID from Azure AD. We pause here in UEM and move over to Azure AD.

Figure 5: Check Directory Settings in UEM

In Azure AD, we navigate to the Endpoint Management/Intune portal and navigate to the Partner Compliance settings in the tenant administration.

Figure 6: Microsoft Endpoint management partner compliance setup

We add a compliance partner, VMware Workspace ONE mobile compliance, for all the platforms we want to cover from the available Android, iOS, and macOS.

Figure 7: Microsoft Endpoint management partner compliance setup – add Platform

In the next step, target the group of users for the integration. This can be achieved by including groups, all users, or excluding a set of users. Whenever you change the users here or add new platforms, you must sync the Azure Services in the UEM Directory settings.

Figure 8: Microsoft Endpoint management partner compliance setup – assign User group

With the Azure side prepared, enable the integration. This will send a request for registration to the microservice hosted in Intelligence which in turn redirects to Azure AD to add the Workspace ONE conditional access enterprise app.

Figure 9: Enable integration in UEM

Sign in to Azure AD with an administrator that can accept the app registration.

Figure 10: Sign in to Azure AD with administrator account

The permissions for the app to be added are displayed and need to be accepted.

Figure 11: Accept and add Workspace ONE Conditional Access app

After closing the previous window, complete the integration setup on the Workspace ONE UEM side.

Figure 12: Complete setup in UEM

In Azure, we will now see the status of the integration as Active, allowing us to register and update device statuses.

Figure 13: Check integration in the Endpoint management portal

In the next step of preparing our environment, we set up SSO extension profiles for macOS and iOS to allow all apps to benefit from the integration and SSO through the broker application (Authenticator or Company Portal).

Setting up the SSO extension is very briefly discussed in Configure MS Conditional Access For Workspace ONE Boxer and iOS Native Mail in VMware Docs. For more details on the various optional settings in the Custom XML, check out Microsoft Enterprise SSO plug-in for Apple devices. The basic settings you require for the SSO extension are as follows:

Figure 14: SSO extension iOS example

On the Android side, it is not as easy to let other apps benefit from the compliance integration as there is no equivalent for the SSO extension. Apps need to support MSAL to leverage the broker. If that is not the case the end user can install a certificate from inside the Authenticator app to enable certificate-based auth identifying the device in Chrome and apps leveraging Chrome custom tabs during authentication. The other alternative would be switching to Microsoft Edge browser as the default browser for Android. Boxer can be configured to leverage MSAL and the broker app for conditional access by setting a KVP (Key Value Pair) in the assignment. For more details, see Configure Support for Azure Conditional Access Policies in Workspace ONE Boxer in VMware Docs.

Figure 15: Android Boxer conditional access KVP

To ease the onboarding, it is suggested to first register the users into the integration before enforcing the conditional access policy and requiring the user to follow the many steps of the remediation flow.

One can send out weblinks or notifications to inform the user of the requirement to register in Authenticator first based on the installation of the prerequisites. Ideally, you would trigger them with an Intelligence Freestyle Workflow and leverage rich Hub notifications. (At the time of writing, there is a bug that prevents you from adding the custom URI links).

Android

Required broker app – Microsoft Authenticator - com.azure.authenticator

awagent://com.airwatch.androidagent?component=conditionalaccess&partnertype=microsoft

iOS

Required broker app – Microsoft Authenticator - com.microsoft.azureauthenticator

airwatch://conditionalaccess?partner=microsoft

macOS

Required broker app – Microsoft Company Portal - com.vmw.macos.CompanyPortal-Installer (only required for SSO extension, not registration)
wsonehub://conditionalaccess?partner=Microsoft

Figure 16: Sample Hub notification with custom URI link

Figure 17: Sample Intelligence Freestyle Workflow

With everything set up and in place, you can finally create an Azure AD conditional access policy to enforce the device compliance for required apps. We add our application and user group, and in the grant section, specify Require device to be marked as compliant. In the previous part of the series on ZTNA compliance, I covered the conditional access policies in greater detail. Check Setting Up Azure Conditional Access Rules in Part 2 if you need further guidance.

Figure 18: Azure AD conditional access policy

Setting Up the Azure MDM App for Windows Device Compliance

In this section, we walk through the setup for Azure MDM app for Windows device compliance.

Requirements for Workspace ONE UEM and Graph API

Before you can proceed, you must have the following components installed and configured:

• An existing Workspace ONE environment
• Access to Azure AD Conditional Access Policies
• Azure AD Premium P1 license

To report device compliance for Windows devices, we need to perform the Azure AD as Identity Service integration in UEM. This is already covered in detail on Tech Zone, so we will review the high-level configuration steps.

For an in-depth review, read the following:

Watch the Windows Azure AD MDM Setup video for an overview of the steps.

We must enable Azure AD for Identity Service in the UEM Directory settings and enable the AirWatch by VMware MDM app in Azure AD.

Figure 19: Setting up Azure AD for Identity Services in UEM

Make sure the Immutable is configured correctly to match the user authenticating to Azure AD during Azure AD join with the user in UEM. To send the compliance information for Windows devices, enable the option as well.

Figure 20: Specify the Tenant Name or Tenant ID (both work the same) and Immutable ID Mapping attribute

Add the AirWatch by VMware app in your Azure AD tenant under the Mobility (MDM and MAM) section.

Figure 21: Add the AirWatch by VMware MDM app in Azure AD

You can target a subset of users when setting up the solution by specifying the scope when migrating from other solutions.

Figure 22: Configure the scope and redirect URLs used during Azure AD join

If you are On-Premises, you must set up a custom MDM application with the correct discovery and terms of use links. The domain of your On-Premises UEM installation must be registered in Azure AD as a custom domain to do so. The conditional access policy we set up earlier for partner compliance was set up for all device types, so it will secure Windows devices as well.

That concludes the basic setup of the compliance integration for Windows devices. On the device itself, the PRT created during enrolment, and built-in tools like the Cloud AP and WAM, handle the single sign-on into applications.

Workspace ONE Conditional Access Device Demos

Now that the setup is complete, let’s review the experience on the different device types.

The video Partner Compliance Integration – Device Demos walks through the registration process for the user and how compliance changes affect the access to apps.

And for Windows, the Windows MDM App – Device Demos video checks how a change in compliance is sent to Azure AD through the integration and what the expected behavior is.

Troubleshooting the Graph API Integration

Finally, we review where you can get details on the service communication, device audit, and sign-in logs to troubleshoot if the integration does not work as intended.

The Integration Troubleshooting video covers these steps.

In the Device details in UEM, check the Conditional Access log which pulls in information from the microservice and allows you to check the API calls sent in the direction of Azure AD.

Figure 23: Compliance API communication in Device Details

Figure 24: Compliance API communication in Device Details

On the Azure AD side, follow the received API calls and device commands in the Device audit logs. We can follow the flow for device registration and setting the managed state until lastly updating the compliance state.

Figure 25: Device Audit logs in Azure AD

If the device shows up correctly but sign-in into applications does not work as expected, have a look at the Azure Sign-in logs. You can follow the authentication (interactive sign-ins—user needs to sign in with SSO or password) and authorization (non-interactive sign-ins—application requests Access tokens) in these logs. If the setup is working, the application will use the broker and saved token which includes the device ID to request an Access token. Logs in Azure AD have a delay—don’t expect real-time updates when testing—usually it takes around 15 minutes for the logs to populate.

Figure 26: Azure AD Sign-in logs

For events using the token and device information, you will see the device and status linked in the Device info section. Further, you can check the applied Conditional Access policies in the respective tab.

Figure 27: Sign-in logs device details

Several times I have seen customers activate the compliance conditional access for all applications in Azure AD Conditional Access and then exclude applications as needed. Only with this configuration can you apply the policy to all apps including apps that are not available in the conditional access configuration. That includes the Workspace ONE conditional access (which can be excluded) and the AirWatch by VMware MDM (which is not available in GUI) applications required to register the devices in the first place. If you plan to use that configuration and still would like to Azure AD join your devices, your only option is leveraging the custom security attributes feature and tagging the AirWatch by VMware MDM app with it.

Figure 28: Custom security attributes setup

Add the newly created tag to the AirWatch by VMware app.

Figure 29: Enterprise App custom security attribute settings

Finally, in the conditional access policy, under exclude cloud apps, edit the filter and add the mdmapp security tag.

Figure 30: Conditional Access cloud apps exclusion using filter and custom security attributes

With this, the environment can have conditional access for all apps while still allowing the enrollment and registration of devices for compliance.

If you run into issues with the SSO extension, have a look at the Microsoft page, Troubleshooting the Microsoft Enterprise SSO Extension plugin on Apple devices which goes into lots of details about how the extension works and how to troubleshoot it.

Summary and Additional Resources

This concludes our series on Workspace ONE compliance integrations into Azure AD and Office 365, giving you an overview of available options and required steps of configuration.

It now depends on the specific use case, available licensing, and security requirements to decide which of the 3 options will be implemented.

Additional Resources

For more information about Zero Trust, you can explore the following resources:

• Understand Zero Trust [Tech Zone Activity Path]
• Workspace ONE Compliance Integrations with Azure AD [video]
• Compliance Integration with MS Office 365 using Workspace ONE Access [part 1] 
• Compliance Integration with MS Office 365 using Workspace ONE Tunnel [part 2]

Changelog

The following updates were made to this guide:

About the Author

This document was written by:

• Sascha Warno, Staff Architect Identity & Security Solutions, EUC Technical Marketing, VMware

Feedback

Your feedback is valuable.

To comment on this paper, contact VMware End-User-Computing Technical Marketing at euc_tech_content_feedback@vmware.com.