Compliance Integration with MS Office 365 using Workspace ONE Access

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 1 of a 3-part series. Part 1 will walk you through the first scenario; using VMware Workspace ONE® Access™ as an IDP to authenticate all users and devices by federating it to Azure AD.

This guide covers setting up authentication-based compliance integration with Microsoft Office 365 in VMware Workspace ONE® Unified Endpoint Management (UEM), Workspace ONE Access, VMware Workspace ONE® Intelligence™, and Azure AD.

The following topics will be covered:

• Overview components required for Zero Trust during authentication
• Setting up single sign-on
• Federating Azure AD to Workspace ONE Access as an IDP
• Compliance, monitoring, and automation

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 and Postman, 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 during Authentication - Architecture

With Workspace ONE Access, we can integrate with Workspace ONE UEM which manages the users’ devices and leverage that compliance status during authentication into any application using SAML or OIDC federated to Workspace ONE Access. Microsoft Office 365 is authorized through Azure AD which can be federated to Workspace ONE Access for users synced from an external source like an on-premises AD or another identity source. A benefit of this solution is that it does not require advanced Microsoft licenses to be enabled.

The Zero Trust during Authentication video explains the flow of components involved to create this solution.

To recap, Azure AD is federated with Workspace ONE Access as an IDP, and whenever a user signs into a service integrated with Azure AD, the authentication passes through Workspace ONE Access and uses a certificate that includes user and device information in the form of the Device UDID. Workspace ONE Access is configured to use this certificate-based authentication method in Workspace ONE UEM. This allows Workspace ONE Access to not only check the validity of the certificate and the user it is created for but also the device’s management and compliance state before authenticating the user to Azure AD. One caveat with this; we authenticate to Azure AD and not the service itself, without knowing which specific service (Teams, Exchange Online, SharePoint) we authenticate for. Only blanket conditional access policies can be applied, with no granular policies per service.

Further, this works during initial authentication but when authorizing the user to the specific service, Azure AD uses ID, OAuth2 Access, and Refresh tokens. The Access token is a short-lived authorization by default valid for a random value between 60-90 minutes and the refresh token is also constantly renewed and has a maximum inactive time of 90 days. So, any time the Access token runs out, the Refresh token is used with the token auth endpoint to receive a new token. No new authentication is required in this flow and during that time no check on compliance would happen and non-compliant devices would still have access to resources and services.

To mitigate this, we can revoke the Refresh token used by the application by revoking all sign-in sessions for a specific user. This will require the user to sign in again as soon as the Access token time-to-live ends. Because we use seamless sign-on with certificates, the reauthentication on compliant devices is transparent to the user. Azure AD also has a feature called Continuous Access Evaluation (CAE) which allows applications that support it, like Exchange Online and SharePoint, to subscribe to an event feed and near instantly revoke access after receiving the API call to revoke the user sessions.

This process is automated and triggered on compliance changes to the users’ devices by leveraging Workspace ONE Intelligence’s Custom Workflow Connectors and Automations.

Figure 1: Compliance using Authentication based integration

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

Requirements for Workspace ONE UEM and Workspace ONE Access

The Basic Requirements and Seamless SSO video provides an overview of basic requirements and also walks through single sign-on (SSO) setup.

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

• An existing Workspace ONE environment
• Completed integration of Workspace ONE UEM and Workspace ONE Access
• Set up Certificate Authority in Workspace ONE UEM

If you have a new environment that automatically comes with UEM, Access, and Hub Services set up and connected, you must complete the integration between Workspace ONE UEM and Workspace ONE Access.

See the documentation on integrating Workspace ONE Access and UEM and setting up Certificate Authorities in UEM.

• Workspace ONE UEM Integration with Workspace ONE Access
• Certificate Authority Integrations

If you have already completed the integration, this means that Workspace ONE Access can make the required API calls to UEM for the device’s compliance state. Workspace ONE Access acts as an identity broker and connects your identity source enabling enhanced Hub Services inside Intelligent Hub.

Devices are enrolled into Workspace ONE UEM, and UEM sets the configuration and tracks the compliance state during the lifecycle. UEM has a built-in certificate authority that provides the certificates used for SSO on all device types as well as integrations into all common enterprise certificate authorities and templates to use internal certificates for the use case.

Setting Up Seamless Single Sign-On

As mentioned in the Requirements section, the SSO configuration is discussed in the following video:

On every device platform, we support a targeted SSO method that uses certificates and can be set up in a seamless way. For iOS, we set up certificate authentication in an Apple Single Sign-On profile targeting a cloud KDC. See the VMware documentation, Implementing Mobile Single Sign-On Authentication for Workspace ONE UEM-Managed iOS Devices.

On Android, we leverage the Tunnel app and configuration to proxy the Workspace ONE Access authentication requests through the CertProxy service. We leverage the authentication certificate set up for the tunnel service. See the VMware documentation, Implementing Mobile Single Sign-On Authentication for Workspace ONE UEM Managed Android Devices.

For both Windows and macOS, system certificates are directly used for authentication. Those certificates are delivered through the credential or SCEP payload for each platform.

To automate the process of selecting the certificate on macOS you can send further configurations down to the device. See the Tech Zone blog post, Managing Identity Preferences to Streamline Single Sign-On for macOS.

On Windows, we can use ADMX policies to manage all kinds of browsers. See Certificate picker for SSO on Windows browsers for more information.

Federating Azure AD to Workspace ONE Access as IDP

The Federate Azure to Workspace ONE Access video demonstrates how to federate Azure AD with Access and set up conditional access policies.

For full details, see the VMware Documentation, Workspace ONE Access Integration with Office 365.

In Workspace ONE Access, select the Office 365 application from the catalog to start the integration. Specify your tenant domain and the issuer which you require when enabling or changing the federation settings in Azure AD. This is usually done using PowerShell and the MSolservice API. Figure 2 depicts a sample PowerShell script that can be run in PowerShell ISE line by line.

Figure 2: Code PowerShell sample Azurefederation.ps1

If you want to copy the sample Azurefederation.ps1 file, we have included the text:

#Connect to microsoft online service
connect-msolservice
 
#Set all variables for federation
#Metadata endpoint
$Metadata = 'https://tenant.vidmpreview.com/SAAS/auth/wsfed/services/mex'
 
#Brand
$Brand = 'customer'
 
#domain for which to switch to federated auth
$Domain = 'customer.com'
 
#Active flow login, required for Win10 logins AAD joined and Hybrid AAD
$ActiveSO = 'https://tenant.vidmpreview.com/SAAS/auth/wsfed/active/logon'
 
#Passive flow aka Modern Auth
$PLUri = 'https://tenant.vidmpreview.com/SAAS/API/1.0/POST/sso'
 
#issuer URI for auth request specified in Access O365 Webapp
$IssuerUri = "Issuer"
 
#Access signing cert from IDP xml or admin GUI
$Cert = "MIIFFzCC....9WzKWYp9t+2l5OWic="
 
#Get MS online domains
Get-MsolDomain -DomainName $Domain
Get-MsolDomainFederationSettings -DomainName $Domain
#onmicrosoft.com or other domain needs to be default to set federation
Set-MsolDomain -Name 'customer.onmicrosoft.com' -IsDefault
 
#switching from Managed Authentication
Set-MsolDomainAuthentication –DomainName $Domain -Authentication Federated -FederationBrandName $Brand -PassiveLogOnUri $PLUri -SigningCertificate $Cert -IssuerUri $IssuerUri -ActiveLogOnUri $ActiveSO -LogOffUri $PLUri -MetadataExchangeUri $Metadata
 
#switching from existing other Federation like ADFS to Access
Set-MsolDomainFederationSettings –DomainName $Domain -FederationBrandName $Brand -PassiveLogOnUri $PLUri -SigningCertificate $Cert -IssuerUri $IssuerUri -ActiveLogOnUri $ActiveSO -LogOffUri $PLUri -MetadataExchangeUri $Metadata
 
#Turn on MFA support through federation > need to make sure to send Authnmethodreference attribute in SAML assertion
Set-MsolDomainFederationSettings -SupportsMfa $True -DomainName $Domain
 
#check Federation settings
Get-MsolDomainFederationSettings -DomainName $Domain
 
#switch back to Managed Authentication
Set-MsolDomainAuthentication -DomainName $Domain -Authentication Managed 

Whilst we are setting up the integration, we must add another attribute to the Office 365 Web app within Workspace ONE Access. For certain actions, Azure AD requires a higher level of authentication verification like multi-factor authentication (MFA) or certificate authentication. This includes setting up Hello for Business during OOBE enrollments. To avoid additional prompts, we send information in the SAML assertion to Azure AD letting it know we have completed further forms of authentication.

Figure 3: Office365 Web App configuration

In the Custom Attribute Mapping under Advanced Properties, we add the following values:

• Name – authnmethodsreferences
• Namespace – http://schemas.microsoft.com/claims
• Value - http://schemas.microsoft.com/claims/multipleauthn

Finally, we must set up the specific Workspace ONE Access policy for Office 365 authentication requests specifying the seamless authentication methods before combining it with the compliance check against UEM.

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

Rules must be set up for the different device types, with Web Browser covering macOS and Windows 10. Some older applications (particularly older dot Net apps) will use user agents that are not covered (in the rules listed above Any device type), but the Any device type should catch those user agents if required. The only rule that does not use the certificate-based authentication and compliance check is the Windows 10 Enrollment as this covers OOBE or Azure AD join events during which the device is not yet enrolled, configured with certificates, and compliant. It is important to require authentication with strong MFA in this case.

Figure 5: Office 365 Access policy rules list

Compliance, Monitoring, and Automation in Workspace ONE Intelligence

The following video covers the setup in Workspace ONE Intelligence for Compliance and Automation.

Now that everything is in place to initially authenticate with compliance into Office 365 (or more accurately, all apps that are federated to Azure AD), we must set up the rules to control the compliant state of the device and react to changes of that state. In UEM, there are a set of parameters from basics like the device passcode to compromised state or encryption, that are reported back by the device and evaluated by the compliance engine. See Managing Devices - Compliance Policies in the VMware Documentation to configure these policies.

If a device is marked as non-compliant by a policy, the authentication through Workspace ONE Access will be blocked. But as we previously discussed, this only happens during authentication, and devices might already use authorization tokens to access Office 365 resources. This is where Workspace ONE Intelligence comes into play, which has enhanced capabilities to bring together all kinds of data sources besides UEM and Workspace ONE Access, integrating Trust Network partners like Carbon Black or MTD to create dashboards and reports to stay on top of all the relevant security information. But more importantly, Intelligence allows for integration with other tools and the creation of workflows to automatically react to issues in the environment.

Our goal is to invalidate the OAuth refresh token on a non-compliant device. Azure AD keeps track of all refresh tokens and their validity and although we cannot target one specific OAuth token, we can revoke all active Refresh/session tokens of a specific user using the revokeSignInSessions API.

See Microsoft documentation for details, Graph API user: revokeSignInSessions.

The user will have to sign in again to all services to receive a new set of OAuth Access and Refresh tokens. On a non-compliant device, this authentication will fail. Using the revokeSignInSessions API, we must set up Intelligence to automatically call that API with the right user. First, we need to create an app that Intelligence can call in our Azure AD tenant. We must register an app that allows us to give it the required API permissions and create client secrets for Intelligence to request an OAuth token to call the Graph API.

Figure 6: Add an App registration - single tenant

Figure 7: Provide API permissions and grant admin consent

Figure 8: Create the client secret, specify validity of token, and copy value, not accessible afterward

In Intelligence, you can set up custom connectors that leverage REST API endpoints like this Graph API. For more details, see Intelligence - Custom Connectors in the VMware documentation.

A requirement to set up the custom connector is to prepare the set of APIs to call in a Postman collection. To learn about the Postman tool, see the following Tech Zone posts:

• Introduction to using Postman - Part 1
• Introduction to Using Postman - Part 2

In this specific case, we need to create a small collection with just one POST request. The :UPN specifying a path variable will be replaced by Intelligence and {{baseUrl}} will also be replaced by a value configured in Intelligence.

Figure 9: Specify the POST request

After you specify the POST request, you can set up the custom connector in Intelligence. Under Integrations > Workflow Connectors, add a custom connector, which will guide us initially through the authorization part. We use the Azure AD tenant information, the App ID, and the client secret.

Figure 10: Set up Custom Connector Authorization

The following table describes the values required when setting up the authorization details for the custom connector.

Then, we import our postman collection.

Figure 11: Import Actions, select saved postman file

Under Automations > Workflows, we can now create a custom workflow in the Workspace ONE UEM > Devices category. In the workflow, we specify the filter to find all devices for which the compliance status changed to NonCompliant, and the Enrollment Status is Enrolled. This will trigger the automation to send a Hub notification informing the user of the compliance violation and the revocation of all session tokens as well as trigger our Graph API custom connector with the user principal name variable.

Figure 12: Intelligence Automation configuration Filter and Action part 1

Figure 13: Intelligence Automation Revoke Session action

Because of the available integrations for Trust Network, more automation options are possible, which is the benefit of having a flexible solution for monitoring and automation.

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 at all, then we follow up with managed devices and finally check if the automation is working as expected and block the user on a non-compliant device.

The Workspace ONE Conditional Access – Device Demos video covers the end-user experience.

Summary and Additional Resources

As you can see, together with the Workspace ONE suite you can achieve Zero Trust access to your Office 365 suite of apps. But what if you want to build granular access across the applications inside of Office 365 and Azure AD, securing access to specific services only from managed devices whilst allowing access to uncritical services from any type of device? Next, we will use Zero Trust Network Access (ZTNA) with VMware Tunnel integrated with Azure Conditional Access policies for more granular access.

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 Tunnel [part 2]
• 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.