Compliance Integration with MS Office 365 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. 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 2 of a 3-part series. Part 2 will walk you through the second scenario; using VMware Workspace ONE® Tunnel™ as a compliance enforcement point for authenticating to Azure AD.

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

The following topics will be covered:

• Overview of components required for Zero Trust during authentication
• Setting up the Tunnel configuration
• Configuring the Azure AD Conditional Access policy rules

Audience

This tutorial is intended for IT professionals and VMware 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 VMware 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 for Secure Access in VMware’s SASE™ (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 Zero Trust through Controlled Network Access – 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 Azure AD 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 Azure AD 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, Azure AD Conditional Access evaluates its ruleset and requires the same configured Named Location as the source of the request. Because Azure AD 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 Azure AD.

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 VMware Unified Access Gateway™ (UAG) with Tunnel Edge Service deployed or
• SASE with Secure Access configured

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 ZTNA Setup in Workspace ONE and Azure AD 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 VMware Tunnel Edge Service: Workspace ONE Operational Tutorial
• Deploying VMware 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, VMware Tunnel cannot apply the DTR. So, for email you can only apply this solution for 3^rd party apps, like VMware Boxer, that can be tunneled.

Figure 2: Device Traffic Rules

For Android, iOS, and macOS, 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.

Note: This setting does not work for macOS—for macOS, you must add all the relevant applications under Manage Applications and add them in a separate rule to the All Applications rule.

For 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

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 Azure AD conditional access.

Figure 7: 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 Azure AD.

Setting Up Azure Conditional Access Rules

The ZTNA Setup in Workspace ONE and Azure AD video demonstrates how to set up conditional access policies in Azure AD.

In Azure AD (AAD) under Security, we find the Conditional Access section. The Azure AD Conditional Access policies are a step up from the security defaults that come with Azure AD in the basic offerings and require at least Azure AD 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 8: Azure AD 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 9: 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 10: Conditional Access – Newly named location

Back in the policies section, we have our base policy requiring MFA for all cloud apps for all targeted users or groups. We add a new policy that specifically targets all applications that require higher security and should only be accessed by managed and compliant devices.

Figure 11: 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 12: 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.

Figure 13: 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 excludes you from this setting.

Figure 14: 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 Zero Trust Network Access – Device 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 Azure AD to directly share device compliance information with Azure AD and leverage it in Azure AD Conditional Access policies.

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 Graph APIs [part 3]

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.