Enrolling into Workspace One UEM using Okta as the IdP is a great way to leverage your existing identity solution, whilst adding Workspace One to check device trust and add management.
1 -This article presumes the following:
- You’ve connected Workspace One UEM to vIDM. If not, follow this guide.
- You’ve added Okta as a IdP within vIDM. If not, follow this guide.
- Azure has been configured, users have synced, the AirWatch application added and federated to either Okta or vIDM. If not, follow this guide.
The flow for this type of enrollment is as follows:
- User types Azure username
- Azure sends user to organisation sign-in page. In this example, this is Workspace One (vIDM) with Okta added as a 3rd paty IdP
- User logins in with AD username and password that’s synced into Okta
- This then SSO’s into Workspace One UEM (AirWatch) for the enrollment
- User is then prompted with the standard Windows privacy and terms options
- User is then prompted to verify user account, this is done through text message in this example.
- User is then prompted for a PIN
- Workspace One Agent is then pushed to device
- The device is automatically enrolled into Workspace One UEM
- Scripts, applications, Bitlocker and certificates are installed on the machine
Bear in mind, some aspects of this video have been sped up for demoing purposes.
Sales Engineer specialising in Unified Endpoint Management (UEM) and Identity Management.
o Okta – Identity Management – Providing single sign on services to applications
o VMware Workspace ONE – Configuring and managing AirWatch components across all device types.
o Digital Transformation – Helping organisations implement and deploy a modern strategy for UEM
o Networking – VPN, DNS, DHCP
o Device Management – macOS, iOS, Android, Windows and Rugged Devices
o Cloud Solutions – Azure, Office 365, Identity Providers, VMware AirWatch
o Server – Windows Server, Active Directory, Exchange
BryanJune 15, 2020
Love this Chris! Will have to give this a shot! We have been trying to get this to work in our environment. We just moved to Airwatch and this set up looks amazing. Love this blog.
Charlie HodgeJune 16, 2020
Thanks Bryan! I’ve put together a handy guide on how to setup the Windows 10 out of the box configuration: https://blog.eucse.com/windows-10-oobe-and-office-365-federation/ we’ve also got some great documentation on how to do this on techzone: https://techzone.vmware.com/enrolling-windows-10-devices-using-azure-ad-vmware-workspace-one-uem-operational-tutorial#999422
HergitJuly 8, 2020
Thank you sir!
I had a question – Is Windows Auto-Discover Services (WADS) required for this setup?
Charlie HodgeJuly 8, 2020
No need for any WADS for this configuration. When you take the device out of the box, typing the users email or Autopilot is what points the device to the correct Azure instance. A Workspace ONE app will be installed within Azure to point to the relevant Workspace ONE instance ?
Andre NguyenAugust 4, 2020
This is the use case we are trying to implement. Okta as idp for UEM enrollment. Okta as iDP for Workspace ONE Access as well. The problem for us is failing after Step 3 – User logins in with AD username and password that’s synced into Okta
The flow right now is User power on the device brand new out of the box –> going through standard Win10 set up process –> Join Azure, enter in email address –> UEM registration pop –> redirected to Okta –> Authenticate with Okta successful. then error out
User able to authenticate against Okta. However, then error display on the device “unexpected error has occur” …the enrollment fail at this stage.
Do you know if anything I might have miss?
Andre NguyenAugust 4, 2020
Adding – we are using SCIM provisioning to push user account from Okta to WS1 Access –> then from Access to provision users to UEM via AirWatch Provisioning app….I am feeling like the issue is surrounding ObjectGUID attributes.
Andre NguyenAugust 5, 2020
Do you know how I can SCIM this attributes over to Workspace ONE Access? ObjectGUID or any KB would help
Charlie HodgeAugust 5, 2020
Hi Andre, almost got my name right 😀
Have a look at this doc: https://docs.vmware.com/en/VMware-Workspace-ONE/services/workspaceone_okta_scim_provisioning/GUID-000EAC15-207F-4ABC-9887-7F523A767010.html, at the bottom you can pass the domain attribute. You may be able to do the ObjectGUID that way. I haven’t actually tested this though. Maybe it’s time, I might configure this from end-to-end with the Okta Universal directory, SCIM the user into Workspace ONE access and provision the user into O365.
JohnMarch 25, 2022
1. Couple of questions. It sounds like this setup would not require Autopilot/Intune is that right?
2. How are passwords managed? In step 3 when a user logs in with their Azure AD credentials – Can Okta be the source of truth syncing credentials downstream to AD allowing the user to authenticate at this step?