Device Posture in Entra ID using API

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.

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 this 3 part tutorial. 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 Entra ID can be leveraged to update the compliance state of a linked device record in Entra ID and how to use that state within Entra ID 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 Entra ID
• Configuring the Entra ID 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 Entra ID, is also helpful.

If you are new to Workspace ONE, review the Evaluation Guide: Managing Apps and Devices with Cloud-Based Omnissa 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 Entra ID 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, Entra ID, 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 Device Posture in Entra ID using API - 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 Entra ID 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 Entra ID, 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 Entra ID account in the app. Federation to Workspace ONE Access and Mobile SSO can be used for the best user experience. On the callback, the Entra ID Device ID is provided to Intelligent Hub and saved alongside the device record in Workspace ONE UEM. Then, backend services send API calls to Entra ID to signal device management and the current compliance state.

Any authentication or authorization request from the device to Entra ID 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 Entra ID 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 Entra ID Join or hybrid Entra ID Join the device and allow integration with the Entra ID MDM application. The process starts with joining the device to Entra ID, 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 Entra ID 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 Entra ID.

To set conditional access rules and enroll the device with the MDM application, at a minimum, the Entra ID Premium P1 license is required on the Entra ID 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, Omnissa 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 Entra ID.

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 Entra ID Conditional Access Policies
• Intune/Endpoint management portal access
• Entra ID 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 Omnissa Docs: Use Compliance Data in Entra ID Conditional Access Policies.

Watch the Device Posture in Entra ID using API - Setup Partner Compliance 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 Entra ID Integration is set and that we added the correct Directory ID from Entra ID. We pause here in UEM and move over to Entra ID.

Figure 5: Check Directory Settings in UEM

In Entra ID, 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, Omnissa 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 Entra ID Services in the UEM Directory settings.

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

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

Figure 9: Enable integration in UEM

Sign in to Entra ID with an administrator that can accept the app registration.

Figure 10: Sign in to Entra ID 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 Entra ID, 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 Omnissa 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 Entra ID Conditional Access Policies in Workspace ONE Boxer in Omnissa 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 Entra ID 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 Entra ID Conditional Access Rules in Part 2 if you need further guidance.

Figure 18: Entra ID conditional access policy

Setting Up the Entra ID MDM App for Windows Device Compliance

In this section, we walk through the setup for the Entra ID MDM app for Windows device compliance for Entra ID joined(OOBE and through settings) and Hybrid Entra ID joined(OOBE) devices.

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 Entra ID Conditional Access Policies
• Entra ID Premium P1 license

To report device compliance for Windows devices, we need to perform the Entra ID 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:

https://techzone.Omnissa.com/enrolling-windows-devices-using-Entra-ID-workspace-one-uem-operational-tutorial#introduction

Watch the Device Posture in Entra ID using API - Setup Windows MDM App video for an overview of the steps.

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

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

Make sure the Immutable is configured correctly to match the user authenticating to Entra ID during Entra ID 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 MDM app in your Entra ID tenant under the Mobility (MDM and MAM) section.

Figure 21: Add the AirWatch MDM app in Entra ID

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 Entra ID 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 Entra ID 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.

Update: Compliance Integration for Hybrid Entra ID joined and Entra ID registered Windows devices

Whilst Omnissa Workspace ONE does not support non OOBE Hybrid AD joined or registered Windows clients natively you can leverage Workspace ONE Intelligence, Sensors and Custom Connectors to transmit the compliance state to Entra ID and leverage it in Entra ID Conditional Access as with the other API based methods. Head over to Compliance Integration for Hybrid Entra ID joined and Entra ID registered Windows devices for more info

Workspace ONE Conditional Access Device Demos

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

The video Device Posture in Entra ID using API - Demos Partner Compliance walks through the registration process for the user and how compliance changes affect the access to apps.

And for Windows, the Device Posture in Entra ID using API - Demo Windows MDM video checks how a change in compliance is sent to Entra ID 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 Device Posture in Entra ID using API - 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 Entra ID.

Figure 23: Compliance API communication in Device Details

Figure 24: Compliance API communication in Device Details

On the Entra ID 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 Entra ID

If the device shows up correctly but sign-in into applications does not work as expected, have a look at the Entra ID 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 Entra ID have a delay—don’t expect real-time updates when testing—usually it takes around 15 minutes for the logs to populate.

Figure 26: Entra ID 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 Entra ID 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 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 Entra ID join your devices, your only option is leveraging the custom security attributes feature and tagging the AirWatch MDM app with it.

Figure 28: Custom security attributes setup

Add the newly created tag to the AirWatch MDM 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 Entra ID 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:

• Compliance Integration with MS Office 365 using Workspace ONE Access [part 1] 
• Compliance Integration with MS Office 365 using Workspace ONE Tunnel [part 2]
• Device Posture in Entra ID using WS1 Intelligence
• Device Posture in Okta

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, Omnissa

Feedback

Your feedback is valuable.

To comment on this paper, contact Omnissa End-User-Computing Technical Marketing at tech_content_feedback@omnissa.com.