Workspace ONE and Azure AD: Part 3


Part 2 of this series stepped through how we render a unified app catalog experience for our end users to “one stop shop” their enterprise, productivity, and collaboration service applications in web, mobile-native, and virtual form factor. It also covered how Workspace ONE Hub Services layers in a unified directory with People Search, and how Notifications can provide a comprehensive approach to keeping your variety of personas up-to-date for all things enterprise. In part 3, we’re going to focus on how we can secure these applications, specifically virtual apps delivered from VMware Horizon, with Azure MFA. This is particularly useful for securing “known” forms of credentials, and provides a consistent experience for what our users are accustomed to leveraging in the course of consuming Office 365.


As always, let’s start with a review of the architecture that we defined in Part 1:

Note: What is not depicted in the above is that just as Azure AD is the exclusive claims provider for Office 365 (and other Azure based services), Workspace ONE Access (formerly VMware Identity Manager) is the exclusive claims provider for Workspace ONE Intelligent Hub and VMware Horizon pods operating in Workspace ONE Mode.

The Why

Deploying Workspace ONE for hundreds of enterprise/global customers has exposed me to a number of MFA architectures. With each one, I’m typically asked two questions:

  1. “Which MFA provider should we consider?”, or “Should we remain with [insert name] provider or consider a new provider?”
  2. “Is [insert name] MFA supported by Workspace ONE, and if so, should we integrate it with Workspace ONE Access?”

My answer is usually some rendition of user experience being the forefront requirement for introducing, or maintaining, MFA for your enterprise. Lead with a provider that enables push notifications with fallback to phone-based TOTP, such as VMware Verify, Okta Verify or Azure MFA. Regulation or certification requirements might override that guiding principle, but no worries, it’s likely your hard-token solution can also be integrated with Workspace ONE. Whichever you choose, stay away from SMS!

Answering the second question is a bit more circumstantial than the first. In most cases, namely to secure Workspace ONE UEM device registration and Horizon virtual app consumption, there is always a heavy requirement to integrate your MFA provider with Workspace ONE Access. Keep in mind, unless your enterprise is prepared to enforce MFA for all known-credential authentication requests, it’s best to colocate your MFA enforcement point with your source of authorization. This is the point where you will have the most visibility into what the user is attempting to consume.

To bring us full circle, the architecture we outlined in Part 1 defined our source of authorization as Azure AD, and thus, provides us with an opportunity to introduce Azure MFA as an integral part of the authentication flow for services that are authorized directly from Workspace ONE: Unified Endpoint Management and Horizon.

The How

Extending Azure MFA to on-premises resources is achieved by deploying Windows NPS servers with a special Azure NPS Extension. Clients, such as Workspace ONE Access, are then pointed to the NPS server over a RADIUS protocol for authentication requests in which the Extension will intercept, authenticate with Active Directory, redirect to Azure for MFA push, then respond with RADIUS-Accept messages (assuming success). The flow is further documented here.


  1. A functional, fully integrated Workspace ONE environment. Specifically,
    • Workspace ONE Access and associated Connectors (v1903)
    • Workspace ONE UEM (for testing device registration)
    • VMware Horizon (for testing published apps and desktops)
  2. A functional Azure MFA On-premises server:
  3. RADIUS connectivity from the Workspace ONE Connectors to the NPS server
  4. Azure MFA registered device (for receiving push notifications)

NPS Configuration

There are three configuration items that we need to define in NPS in order for the Workspace ONE Access Connectors to send RADIUS requests:

  1. RADIUS client configuration
  2. Connection Policy
  3. Network Policy

First up, let’s define the client as the IP of the connector(s) and exchange a shared secret:

Second, we define under what conditions the Workspace ONE Access Connectors can communicate with the NPS server (referred to as Connection Policies). I tend to keep these fairly vague, as most controls are managed in step 3:

In order to limit the policy to Workspace ONE Access Connectors, it’s useful to define a condition based on the client friendly name you would’ve created in step one. “?” is the equivalent of a wildcard in this case:

Lastly, we create the Network Policy. This is where we define encryption methods, what constitutes successful authentication, and any special attributes if necessary. Let’s first state that this policy will ‘Grant Access’ if fulfilled:

Then, just as previously stated, we limit the policy to the WS1 Connectors with a condition on friendly name:

Lastly, we define the encryption methods required between client and NPS server. As documented here and here, PAP authentication is required if you want to support mobile app push notification and mobile app verification code. I have enabled the four supported encryption methods from Microsoft (MS-CHAPv2, PAP, EAP-MS-CHAPv2, PEAP):

Restart the NPS service for good measure, then head over to the Workspace ONE Access management console for next steps.

Workspace ONE Connector Configuration

To establish on-premises connectivity with NPS for your WS1 Access tenant, we need to configure the Connectors to point to the NPS server(s) over RADIUS. In the Workspace ONE Access management console:

1. Navigate to Identity & Access Management -> Setup -> Connectors, then select your first connector from the list:

2. Select the ‘Auth Adapters’ tab, then select the ‘RadiusAuthAdapter’ hyperlink from the list. Note: you will want to select this option from a workstation that has inbound TCP 8443 connectivity to the local connector (i.e. management host):

3. On the following screen, fill out the required information that was defined earlier in NPS to establish RADIUS connectivity from the Connector to the NPS server. A few callouts: consider using custom text to breadcrumb your users through the prompts they will be presented with. You’ll see the outcome of this configuration in a later section below. Also, remember to enable the adapter and select PAP authentication:

Save the configuration, repeat steps 1-3 for each of your connectors (for high availability), then return to the Connector list to confirm RADIUS has been enabled on each:

Cloud Deployment AuthN Overview

Before finalizing the Workspace ONE Access RADIUS authentication method in the access policy, it’s a good time to define what selecting a ‘Cloud Deployment’ authentication method within the Built-In IdP means i.e. RADIUS (Cloud Deployment).

The WS1 Access Built-In IdP is a special configuration object that enables unique SSO functions such as Mobile SSO. Moreover, it is also responsible for commanding which connectors, based on your configuration, should be placed into a special mode we call “Outbound-Only“. This is a bit of a misnomer if you ask me since the connector can operate in both “outbound-only” and “inbound” modes simultaneously. Nonetheless, “outbound-only” mode is what labels “inbound” authentication methods as “(Cloud Deployment)” and is an indicator of the direction of communication between your SaaS tenant and the corresponding connectors.

In the context of this post, just know that the main takeaway for “RADIUS (Cloud Deployment)” is that rather than redirect the user to the on-premises connector for RADIUS authentication, the connector will pull down an AuthN request from the SaaS service through a persistent outbound connection. Note: this outbound flow is natively conducive to high availability, but does require that every connector added to the Built-In IdP has identical authentication method configuration.

Workspace ONE Access Policy

With the context around “Outbound-Only” mode, let’s enable that function and introduce Azure MFA to the default access policy. Head back over to the WS1 Access management console:

1. Navigate to Identity & Access Management -> Identity Providers -> Built-In:

2. Scroll down to the ‘Connector Authentication Methods’ section. If the previous steps and connector association are configured correctly, you’ll notice a new AuthN method: “RADIUS (Cloud Deployment)”. Check that box to enable the method:

3. With the method now enabled, select the ‘Policies’ tab, then ‘default_access_policy_set’ -> Edit:

What you configure in the next step is circumstantial, but for the sake of this post, we will configure the last rule in the default access policy to use username, password, and Azure MFA. This rule would fire in the event that all other “managed” forms of authentication (i.e. Mobile SSO, Kerberos, etc) aren’t satisfied.

4. Select ‘2 Configuration’ -> Add Policy Rule:

5. On the Edit Policy Rule page, configure the following settings:

  • Network Range – ALL RANGES
  • Accessing Content From – All Device Types
  • Perform this Action – Authenticate Using
  • Authenticate Using – RADIUS (Cloud Deployment)

Press ‘Save’, ensure that the rule is at the bottom of the list (again, circumstantial), then press ‘Next’ and ‘Save’ again.

Testing Authentication with Azure MFA

As mentioned in the prerequisites, you’ll want to test with an account and device that have been registered with Azure MFA. Let’s head over to the Workspace ONE Unified App Catalog to launch an application (in my case, I’m launching a Horizon published app):

Upon launch, the user is presented with an authentication dialog to provide their password. After selecting ‘Sign In’, the screen will hold for the defined timeout period, or until the user approves the push notification sent to their device (whichever occurs first):

An example of the push notification to approve on iOS MS Authenticator:

If you’re having trouble receiving a push notification to Microsoft Authenticator, you might want to navigate to and confirm that your default sign-in method is set to ‘Microsoft Authenticator’:

The Outcome: Part 3

The great news about Azure MFA (or any other MFA provider) integration with Workspace ONE is that it is pluggable. With this function, you can selectively introduce MFA through the conditional access engine for any apps you deliver through the Unified App Catalog created in part 2, including and especially VMware Horizon and Workspace ONE UEM.

With the Hub Services experience in place and fully equipped, part 4 will begin to fold in endpoint consumption with Windows 10. Stay tuned!

Tags: , , , , ,