In case you’ve ever had to register Windows devices in Workspace ONE UEM on behalf of other users, you’re probably familiar with the following command line. For the most part this command is self-explicatory and well documented on TechZone.
As you can see, you’re enrolling on behalf of other users using a staging account. Obviously, you don’t want all these devices to be assigned to that staging account in the console, but you want them to be linked to the actual end user working on the system. So you set ASSIGNTOLOGGEDINUSER to Y. Piece of cake…
But….
- How does this actually work behind the scenes?
- What are the pre-requisites to make this magic happen?
- How do I troubleshoot this if things don’t work out as expected?
There’s not a lot of public documentation available, so let me try to answer these questions for you…
What does it do and how does it do that?
Let’s take a look at the command line and leave the optional ASSIGNTOLOGGEDINUSER switch out of the equation for now:
Msiexec /I <path_to_AirwatchAgent.msi> Enroll=Y server=dsXXX.awmdm.com LGNAME=<groupID> USERNAME=<staginguser> PASSWORD=<staginguserpassword>
With this command, you as an admin are installing the MDM agent on the Windows client and you’re telling it to enroll the device in your Workspace ONE environment using a staging account.
That’s exactly how these devices are going to show up in your UEM console, as if they are in use by the staging account.
You’re probably going to need to publish specific apps, profiles and configurations based on the user working on the machine, so we need a mechanism to silently reassign the devices from that staging user to the actual users.
Back in the stone age, the only way to achieve this was to upload a spreadsheet to the UEM console that mapped the serial number of the device to the end user. No need to explain this doesn’t work very well in environments with tens of thousands of devices. At the time you enroll the device, you may not even know yet who’ll be using the device.
Instead of using a spreadsheet to do the mapping, adding ASSIGNTOLOGGEDINUSER=Y to the equation instructs the Intelligent Hub to attempt to link the device in the UEM console to the user currently logged in to the system. In case it worked well, the UEM shows the correct user:
The Troubleshooting tab should contain these logs in case of success:
Here’s the magic formula:
- The Intelligent Hub locally checks what user (SID) is currently active on the system.
- It queries Active Directory to obtain the objectGUID attribute for that user.
- Hub sends a “checkout” API call containing this objectGUID value to the Device Services server.
- The Device Services server tries to find a matching user by comparing the objectGUID to the externalID attribute of the user objects it knows
- If it finds a match, the magic happens and the device is seamlessly reassigned to that end user
Note: Today Intelligent Hub uses the AD attribute objectGUID to try to match the user. This is hard coded so can’t be changed. VMware is working on making this configurable for customers where objectGUID can’t be used (think of SCIM provisioned accounts coming from OKTA or any other IdP)
under the hood
Let’s dig a little deeper and try to find proof for all this. First, let’s run a simple command to obtain my account’s SID:
In the Intelligent Hub DeviceEnrollment logs (as well as the Taskscheduler logs), we can clearly see the Hub is checking for this value for the purpose of the reassignment to the end user:
Right after that, a Wireshark trace shows the client device is exchanging a bunch of LDAP packets with the domain controller. I didn’t want to go through the effort of decrypting these packets, so I’ll just have to believe my sources when they claim the Hub is trying to obtain the objectGUID attribute for this user.
To verify the third step of the process, we can use the Fiddler tool to sniff for the API call (here’s how to configure Fiddler). As you can see, Hub is indeed sending that objectGUID to Workspace ONE.
The user tab in the UEM console doesn’t show that objectGUID, but you can use the Directory Services Test Connection button to query AD and verify if this is indeed the correct value that’s being used.
In case you are using SCIM provisioning and don’t have Directory Services configured, use an API call:
Lastly, the Device Enrollment log should show you these logs in case of a successful attempt:
What are the pre-requisites to make this work?
The information in the previous section disclosed a couple of these pre-requisites already:
- The device needs to be domain joined
- It needs line of sight with that domain controller during the process (cfr Wireshark trace)
- The logged on user needs to by known in UEM
- The end user’s objectGUID should match the externalID attribute in Workspace ONE UEM.
When to use ASSIGNTOLOGGEDINUSER=N?
In case you wonder, setting the switch to No is the same as omitting it entirely.
Now to answer the question:
- When you’re certain you can’t meet all of the requirements. The only workaround you have today is to use that spreadsheet…
- In case you’re preparing the machine upfront and they’re not yet in use by anyone. When you set the switch to No, the Hub will try to reassign the device to the next domain user that logs in to the machine.
What if it’s not working?
If any of the requirements is not fulfilled at the time the Hub tries to check-out the device to the end user, the silent reassignment will fail and Intelligent Hub will prompt the end user for manual authentication.
Note: The screenshot below shows an environment where Hub authentication is set to UEM, so this might very well be an authentication screen of your IdP (WS1 Access, okta, Ping,…).
Many things can (and will) go wrong from time to time, so there’s a built-in logic to retry the assignment.
The flow is triggered again in following occasions (as far as I was able to confirm):
- Immediately upon enrollment if ASSIGNTOLOGGEDINUSER=Y
- 24 hours after the last failed attempt
- A device query initiated from the UEM console
- When the user logs off / logs on again (Windows session)
- When the user clicks the toast notification to complete enrollment (only shown when the auto-reassignment failed of course)
