Omnissa Identity Services with Azure AD

What's the Problem?

For a long time, Workspace ONE UEM has had a dependency on-premise Active Directory. We traditionally would deploy an AirWatch Cloud Connector to pull user information from an on-premise AD infrastructure and authenticate with a user's existing identity there. Over time, customers have moved from deploying on-premise infrastructure to favoring cloud-based directories like Azure AD or Okta. With cloud-based identity providers, we would leverage something like SAML for authentication. Key there is leveraging for authentication, but what about the users in the directory? Traditionally, we'd JIT (or just-in-time) provision those users. When the user signs in, the SP (service provider or WS1 in this case) would provision users with the attributes passed as part of the SAML assertion (so it wouldn't show all user objects nor show group entitlements). This would only happen at login time - so the SP's directory was always an incomplete picture of the source of truth directory. This didn't break anything for Workspace ONE UEM, but just was something to be aware of when using JIT provisioning for a SAML IdP (identity provider). 

One minor hiccup here is for Windows management, is using the "Use Azure AD For Identity Services" option (particularly if you want to leverage Azure AD to push Workspace ONE management). If you use JIT provisioning for a pure AAD environment in this scenario, you can run into issues with user identity in your UEM environment. This is acknowledged in this VMware KB that mentions at least a hybrid setup for AD being required. This is the situation that VMware Identity Services aims to solve - to facilitate SCIM provisioning from AAD to Workspace ONE, and provide an option for customers relying solely on Azure AD with no on-prem AD. 

What's the Solution?

The solution to the aforementioned problem is going to be leveraging VMware Identity Services for a pure Azure AD environment. This will SCIM provision all users assigned in AAD, and automatically setup both Workspace ONE UEM and Workspace ONE Access for authentication through your AAD tenant. Access to Workspace ONE is still managed via an entitlement to an application in AAD, which can be done individually or (ideally) based on groups. 

Acknowledgements/Assumptions

• Identities in AAD are not hybrid, and are created in AAD

• Azure AD P1 or P2 licenses are in use to push Workspace ONE MDM to AAD-joined devices 

• This is being done in a brand new Workspace ONE environment. As of writing, VMware Identity Services is not supported in brownfield (existing) WS1 tenants, or if any configuration changes have been made to directory configurations in WS1 UEM or Access

Setup 

Part 1: VMware Identity Services

The first step is to follow the documentation here to setup VMware Identity Services in your environment. See the sub-pages on the left-hand navigation bar. Be sure to acknowledge the key considerations for using the service listed here. 

Note: In my testing I did SCIM for AAD using the OAuth 2.0 method. It's important to follow the documentation carefully, as one value that isn't copied correctly can prevent the solution from working. It is also recommended to copy all of the requested values (ex. secret from VIS, OAuth 2.0 metadata, etc) to a notepad or textedit document until you verify the integration is working. 

Once the configuration is completed, you may need to hasten the provisioning process in Azure AD. You can do this by going to the VMware Identity Services Enterprise Application in AAD, going to provisioning, and selecting the "provision on demand" option. This will validate user attributes and push the user to be provisioned into Workspace ONE and downstream applications (like UEM and Access). 

Now, in Workspace ONE Cloud, under the "End User Management" section, you should see (1) your AAD configuration and (2) provisioned users and their appropriate attributes

Further, by clicking on the "Events" tab for the user, you should see successful provisioning events for UEM and Access 

Part 2: Integration with Azure AD in UEM via "Use Azure AD for Identity Services"

We're already using AAD for identity through VMware Identity Services, so what gives for the second integration? Good question. The setting in question, "Use Azure AD for Identity Services" allows Azure AD to pass a token to UEM to facilitate AAD joining machines and Windows OOBE. We will still be leveraging VMware Identity Services for population of the directories and authentication directly with AAD. The two will work together in this scenario. Below is a figure that explains what this integration does (mind you it is a little dated and contains an on prem AD and AD Connect. We will get around this with the VIS config we did above). 

To complete the integration, follow the published VMware documentation here. In short, you will need to add an enterprise application to your AAD ("AirWatch by VMware") and supply it with URL's from your Workspace ONE UEM console (located in Groups and Settings - All Settings - System - Enterprise Integration - Directory Services) in addition to supplying UEM with your tenant name and directory ID. Then, in AAD, go to Mobility and MDM and enter the TOU and MDM URL for your tenant (this will push all AAD-joined machines to be enrolled into Workspace ONE). This operational tutorial from TechZone also goes through this integration, though is a little dated. Once the above is complete, the settings page in the UEM console should look something like this: 

Note: Certain settings on this page are greyed out due to the VIS integration. This is okay - the config changes we need to make are below those greyed out settings. 

Three additional changes that need to be made. First, at the bottom of this page, set the Immutable ID Mapping Attribute to be "objectGUID", as shown in the below screenshot: 

Next, in Settings - All Settings - Devices & Users - General - Enrollment. Select the "override" radio button. Make sure that Directory is checked for "Authentication Mode(s)" and that "Source of Authentication for Intelligent Hub" is set to be Workspace ONE Access. Click save when done. 

The last change we need to make is going to be in Settings - All Settings - Devices & Users - Windows - Windows Desktop - Intelligent Hub application. Make sure all boxes are checked on this screen. This setting will push Intelligent Hub to devices joined via AAD. 

That's It!

At this point, configuration should be completed and a device should become MDM enrolled in Workspace ONE via AAD domain join / AAD sign in during OOBE. It may take a minute for Intelligent Hub to download. At this point, it is expected that the user may have to sign in again to Intelligent Hub with their AAD credentials. You can push a SCEP profile to Windows devices using the built-in AirWatch CA to push user certificates, and use Workspace ONE Access to authenticate with AAD auth as a fallback authentication method. Details on this can be found on this blog post.