Device Posture in Entra ID using Workspace ONE Tunnel

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.

This tutorial is part 2 of a 3-part series. Part 2 will walk you through the second scenario; using Omnissa Workspace ONE® Tunnel™ as a compliance enforcement point for resources in Entra ID.

This guide covers setting up a network access-based compliance integration with Microsoft Office 365 in Omnissa Workspace ONE® Unified Endpoint Management (UEM), Workspace ONE Tunnel service, and Entra ID.

The following topics will be covered:

• Overview of components required for Zero Trust during authentication and authorization
• Setting up the Tunnel configuration
• Configuring the Entra ID Conditional Access policy rules

Audience

This tutorial is intended for IT professionals and Omnissa 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 Omnissa Workspace ONE® Access™.

Zero Trust through Controlled Network Access - Architecture

  One solution we offer with Workspace ONE is the Workspace ONE Tunnel Service, built to allow managed compliant devices access to internal resources through a client application, a per-app or full device VPN configuration, and the Tunnel Service as a VPN gateway controlling the sessions. Workspace ONE Tunnel offers more than just plain VPN or split tunneling—we can configure Device Traffic Rules (DTR) which further control what traffic is tunneled, proxied, or bypassed. This allows us to detect very specific endpoints that an app communicated with and not bottleneck the rest of the application traffic.

Tunnel service can be deployed in your data center (VMware vSphere®, Hyper-V), cloud (Azure, AWS) or can run as hosted service (Secure Access Service Edge) offering. Tunnel clients are available for the most common device platforms: Android, iOS, macOS, and Windows.

Let’s see how we can use these features to enable granular conditional access to Office 365.

The Device Posture in Entra ID using WS ONE Tunnel - Architecture video explains the flow of components involved to create this solution.

To recap, in this scenario we built on the Workspace ONE Access configuration from part 1, but only use it for the benefit of seamless single sign-on. The solution works as well with any other forms of authentication into Office 365, be it managed accounts using password hash sync or accounts federated with any other IdP. Our devices are again enrolled into Workspace ONE UEM which controls the configuration and compromised/compliance state of the device. We also push the Tunnel app and configuration which includes the rule to tunnel the authentication traffic of applications. This part allows us to block non-compliant devices from authenticating.

To finish the configuration and target non-managed devices, we configure the egress IP address of the Tunnel service as Named Location in Entra ID Conditional Access and block access to all or a select choice of apps. Because the authentication request of our managed compliant device now comes from the egress IP of the Tunnel Service, the authentication is successful on the Entra ID side and the application receives the authorization for the web services in form of the already discussed OAuth Access and Refresh tokens.

Now this network access-based solution also covers the ongoing authorization scenario; whenever the Refresh token is used to request a new Access token, Entra ID Conditional Access evaluates its ruleset and requires the same configured Named Location as the source of the request. Because Entra ID Conditional Access covers the authorization part, we now can target specific applications and set up granular rules to allow access to sensitive apps only from managed devices and grant access to the remaining apps from all device types.

Figure 1: Compliance using Authentication based integration

Now, we will walk through the required steps to set up the solution in UEM, Workspace ONE Intelligence, and Entra ID.

Requirements for Workspace ONE UEM and Workspace ONE Tunnel

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

• An existing Workspace ONE environment
• A Omnissa Unified Access Gateway™ (UAG) with Tunnel Edge Service deployed or

Devices are enrolled into Workspace ONE UEM, and UEM sets the configuration and tracks the compliance state during the lifecycle. In UEM, we also configure the Tunnel service, setting up authentication, architecture, and device profiles. UEM has a built-in certificate authority that provides the certificates to authenticate with Tunnel as well as integrations into all common enterprise certificate authorities and templates to use internal certificates for the use case.

Setting Up Device Traffic Rules

The Device Posture in Entra ID using WS1 Tunnel - Setup Tunnel video discusses the required configuration in Workspace ONE UEM.

We focus on the required settings to configure Tunnel Edge Service for our compliance integration use case. For detailed instructions on how to set up Tunnel Edge Service in general and other use cases, see the following comprehensive guides on Tech Zone.

• Configuring the Omnissa Tunnel Edge Service: Workspace ONE Operational Tutorial
• Deploying Omnissa Workspace ONE Tunnel: Workspace ONE Operational Tutorial

Our goal is to send all authentication traffic for Office 365 applications on managed devices through Tunnel Edge services. Besides any other configuration you might use for internal resources, you must add the Microsoft destinations given in the table below to your DTR.

Warning: This works only for applications that can be tunneled. Native email on iOS/iPadOS uses the settings app to request the OAuth token; not the Safari WebView. Because of that, Omnissa Tunnel cannot apply the DTR. So, for email you can only apply this solution for 3^rd party apps, like Omnissa Boxer, that can be tunneled.

Figure 2: Device Traffic Rules

For Android and iOS we specify Per Application rules adding the given URL, and we wildcard them to catch any subdomains. Later, we will require the egress IP address of the Tunnel Edge service itself, i.e., the gateway address that the Tunnel uses to communicate to the Internet. If you don’t know the egress IP, include a service like myip or whatismyipaddress to find it. If you use Secure Access, you must check the egress IP addresses for each of the global instances you might have deployed. The final rule is a Bypass rule for wildcards (*) which allows application traffic to bypass the Tunnel and access their destination directly.

Figure 3: Per Application - Device Traffic Rules

In our example, we used All Applications, which will apply the rule to all applications that have the VPN profile with this specific DTR configured even if you add more applications later. Quite often, authentication is going through Microsoft Authenticator (iOS) or Company Portal (Android), it is not enough to only tunnel those apps as the authorization is happening from the application itself and the IP address is evaluated at that point as well.

For macOS and Windows, specify a Full Device rule which applies the rules to all applications running the managed device.

Figure 4: Full Device - Device Traffic Rules

The DTR rules are then applied to the VPN profiles configured for the respective platforms. For example, the iOS VPN profile as shown in Figure 5.

Figure 5: iOS VPN profile

To make sure users don’t accidentally remove the Tunnel client application and block themselves from accessing Office 365 services, you might want to add an Automation to Workspace ONE Intelligence to re-push the application in case it is removed by the user. Workspace ONE Freestyle can be considered as another option to enforce this desired state when it comes out of Preview for mobile platforms.

Figure 6: Workspace ONE Intelligence Automation example – reinstalling uninstalled app

Update: Create Compliance Policies in UEM

To avoid seeing network timeouts when the user tries to authenticate on a non-compliant device, set an action inside the compliance rules to remove the VPN profile from the device, or if you have reasons to still have it connected somewhere, install a compliance VPN profile which does not include DTR rules to tunnel authentication traffic with Entra ID.

Figure 7: UEM Compliance policy remove profile

In case you have an integration with Entra ID set up in UEM you can also revoke the Azure Tokens from compliance policies for iOS and Android to trigger Microsoft’s Continuous Access Evaluation (CAE) and force a re-authentication.

If you have completed the previous setup with Workspace ONE Access for Mobile SSO and compliance (see part 1 of this series), the next step is to enable a Fallback in the access policies for Office 365 to allow unmanaged devices access to applications that we will later configure in Entra ID conditional access.

Figure 8: Workspace ONE Access – Office 365 policy changes

With that, configuration is complete on the Workspace ONE side, and we can now change our configuration on Entra ID.

Setting Up Entra ID Conditional Access Rules

    The Device Posture in Entra ID using WS1 Tunnel - Setup Tunnel video demonstrates how to set up conditional access policies in Entra ID.

In Entra ID under Security, we find the Conditional Access section. The Entra ID Conditional Access policies are a step up from the security defaults that come with Entra ID in the basic offerings and require at least Entra ID Premium P1/P2, Microsoft 365 Business Premium or E3/E5 or Enterprise Mobility and Security E3/E5.

Potentially, there are already a lot of policies available in the Conditional Access section, at least a policy to require MFA to access resources. Initially, we will configure the Named locations feature.

Figure 9: Entra ID Conditional Access portal

The Named locations feature allows us to specify network ranges or even country locations that we can use later within conditional access policies. We add a new IP range location that will include the Tunnel Edge services egress IP addresses.

Figure 10: Conditional Access – Named locations

A new location is created with a unique name and marked as a trusted location. The IP addresses or ranges can be uploaded as a text file separated by line breaks. The addresses must be formatted in the CIDR standard, so if you add single IP addresses, use /32 at the end of each.

Figure 11: Conditional Access – Newly named location

Back in the policies section, we have our best practice base policy requiring MFA for all cloud apps for all targeted users or groups. This could also be a policy only targeting our specific applications with the authentication strength we require, be it password, certificates, MFA or phishing resistant authentication methods, you can think of that as our whitelist. We add a new policy that specifically targets all applications that require higher security and should only be accessed by managed and compliant devices which really is a blacklist policy for the non-managed and non-compliant devices.

Update : Some of the configuration done here under Locations where moved under its own Network section in the policy. Microsoft also describes the setup of this Block policy in their global secure access guidance.

https://learn.microsoft.com/en-us/entra/global-secure-access/how-to-compliant-network#protect-your-resources-behind-the-compliant-network

Figure 12: Office 365 Access policy using Android SSO and Compliance

First, we specify all apps that should be included in this policy in the Cloud apps or actions section. In this example, we target all Teams, SharePoint Online, and Exchange Online. Note that it will affect all other Office services that try to access SharePoint files or calendar data for example.

Figure 13: Office 365 Access policy using Android SSO and Compliance

Under Conditions, we configure the Locations settings. Under Include, we leave the Any location option but under Exclude we configure our Workspace ONE Tunnel named location. So, all further settings will not apply to authentication and authorization requests coming from managed devices using the Tunnel service.

Update: In Entra ID the configuration of Locations moved into its own Networks section and works together with Global

Figure 14: Office 365 Access policy using Android SSO and Compliance

In the Grant section, we configure Block access, which blocks all access to the configured applications unless you come from a managed device which coming from the Tunnel Egress IP is excluded from this setting and policy.

Figure 15: Office 365 Access policy using Android SSO and Compliance

We can initially only target a subsection of users or even enable the Report-only mode to check the functionality of our configuration before activating it for production.

Workspace ONE Conditional Access Device Demos

Now that the setup is complete from the administrator side, let’s review the experience for the end user.

Starting with an unmanaged device, we should have no access to everything related to Teams, SharePoint, and Exchange Online but should be able to use Yammer. Then we follow up with managed devices using the Tunnel connection and finally, check how the Tunnel Edge service blocks a non-compliant device and informs the user.

The Device Posture in Entra ID using WS1 Tunnel - Demos video covers the end-user experience.

Summary and Additional Resources

  With this setup, we achieve more granular access to Office 365, allowing access from managed and unmanaged devices based on the sensitivity of data in specific apps of the Office 365 suite. We do not interfere with the application traffic in general but only with authentication and authorization traffic. With Hub Notifications, we can inform the user about the compliance issued, but as it is not a direct integration, we cannot control the behavior of the application itself and the network timeout that occurs in it.

In the final part of the series, we will look at an API-based integration between Workspace ONE UEM and Entra ID to directly share device compliance information with Entra ID and leverage it in Entra ID Conditional Access policies.

Additional Resources

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

• Device Posture in Entra ID using WS1 Access [part 1]
• Device Posture in Entra ID using API [part 3]
• 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.