VMware Workspace ONE – Fixing the “Unable to find user in Active Directory” issue
This blog post describes the issue and misconfiguration I had that caused the “Unable to find user in Active Directory” message during the Out-Of-Box-Experience (OOBE) enrollment phase of a Windows 10 device with Azure AD, including the fix for my setup.
My Setup
My setup looks like this:
- Azure AD / Office 365 federated to Workspace ONE Access (Reference)
- Workspace ONE Access and UEM are connected using API’s (Reference)
- Workspace ONE UEM and Azure AD are configured to use Workspace ONE UEM as the Mobile Device Management (MDM) platform (Reference)
Account Creation Workflow
My working account creation and provisioning flow looks like this:
(1) Users are created in a local directory in Workspace ONE Access using PowerShell and automatically added to a group (Azure-AD-Users) in the System Domain.
(2) The Office365 with Provisioning app in Workspace ONE Access is used to automatically provision the users in Azure AD / Office 365, based on Azure-AD-Users group membership.
(3) The AirWatch Provisioning app in Workspace ONE Access is used to automatically provision the users in Workspace ONE UEM, based on Azure-AD-Users group membership.
Windows 10 Enrollment
So, with all the previous stuff configured, I believed I was ready to enroll a Windows 10 device. I started spinning up my “new device” (VM) and started signing in using my e-mail address.
Since Azure AD / Office 365 is federated to Workspace ONE Access, I receive the Workspace ONE sign in prompt. Here I sign in using my e-mail address and password.
It is after this sign in that I get the error “Unable to find user in Active Directory“.
After clicking Exit, I got another message “Something went wrong. It looks like we can’t connect to the URL for your organisation’s MDM terms of use.“.
After clicking Try again, I was again presented with the Microsoft sign in screen.
Workspace ONE Access Sign In Validation
I started looking at the Workspace ONE Access audit events for my specific sign in.
The username and local password LOGIN event was successful.
The WSFed LAUNCH event was also succesful.
With this being validated, I started focussing on the Workspace ONE UEM configuration part.
Workspace ONE UEM
I started investigating my user account in Workspace ONE UEM and compared the account properties with the lab configuration of my colleague Jesper Alberts. This is where we found out that his accounts, synced from an on-prem Active Directory and synced with Azure AD, contained a GUID value for the Azure Active Directory Mapping Attribute. This was empty for my user account in Workspace ONE UEM.
So I looked up the objectGUID value for my user account in Workspace ONE Access, which is the same for the ImmutableId (converted from base64) value for my account in Azure AD / Office 365, and used that for the Azure Active Directory Mapping Attribute for my user account in Workspace ONE UEM.
Once I started re-enrolling my Windows 10 device, I didn’t receive the error message anymore. Every step after signing in went as expected.
Adjusting the AirWatch Provisioning App Configuration
I was glad to find out what the issue was, but I wanted to automatically have the Azure Active Directory Mapping Attribute for my user accounts in Workspace ONE UEM configured with the correct GUID value. Therefore, I opened up the AirWatch Provisioning app configuration in Workspace ONE Access and headed to the User Provisioning section. Since I wanted to create a new mapping, I clicked ADD MAPPING.
This is where I can add the AAD Mapping Attribute and give it the value of the user’s objectGUID.
Once the configuration is saved, you can (re-)provision new or existing accounts, which now have the objectGUID filled in for the user’s Azure Active Directory Mapping Attribute in Workspace ONE UEM.
Conclusion
I hope this blog post helps you understanding and solving this or similar issues in your environment.
If you have any questions or comments, please reach out on Twitter or LinkedIn.
