Recently, I wrote a great article about leveraging Azure AD Domain Services and Workspace ONE to build a fully cloud UEM environment. This was a pet project of mine to build something special for small businesses that are primarily remote workers using Azure AD, but you could have a few people that are also hybrid.

The next phase of this concept was to leverage Azure AD Premium and the automated MDM enrollment via Azure AD Join, which is a brilliant idea. Essentially, when someone logs into a PC with your company credentials, it will enroll their device and deploy policies courtesy of Workspace ONE. Let’s talk about how to do it, the main challenge with AAD-DS, and my impressions working within Azure AD Join.

Setting up Azure AD Join for Workspace ONE UEM

Let’s cover the basics first. You must own some Azure AD Premium licenses or have Office 365 Business Premium to leverage this feature as Microsoft shows you in this graph: (The checkmarks signify Azure AD Premium)

Now that we have that behind us, let’s cover the configuration needed in Workspace ONE. You can see below the configuration needed inside of System > Enterprise Integration > Directory Services with the main keys that the “Directory ID” is the Azure AD Directory ID found in Azure AD Properties called “Tenant ID” and the Tenant Name is your Primary Domain Name found under “Custom Domain Names”

Configuring the Azure AD Side for Azure AD Join

Setting up this portion of things can be confusing mainly because the VMware documentation is inconsistent. I’m here to set things straight. You will be doing a few things: (1) Adding and configuring the AirWatch MDM app and (2) adding and configuring the On-premises MDM application. To make it easy, you can access the mobility section of the Azure Portal here.

Configuring the AirWatch by VMware Mobility Application

After you click “Add Application” and add the AirWatch app, you just basically click “None” for the user scope, accept the default values, and click “Save”. I’m honestly not sure why it’s required by it is. Nothing is actually done with it:

Configuring the On-Premises MDM Application

This one is a bit trickier, so we will be showing you a video on how to do it because it can trip some people up. The good news is it only takes a few minutes and is simplistic once that is done.

Why Azure AD Join?

Azure AD Join is a great technology. The idea is that people can seamlessly self-enroll their PCs without even realizing they’re enrolling PCs. A few of the other benefits are:

• Essentially a cloud version of domain join
• Eliminates the need for personal Microsoft accounts on the device
• Automated MDM enrollment as mentioned above
• Seamless SSO on all browsers (Chrome requires an add-in) leveraging Azure credentials
• Settings are synchronized across devices e.g. Wi-Fi credentials, websites, accessibility settings and more
• Windows Store integration

How Azure AD Join Works with Workspace ONE

When you configure the On-Premise application as we mentioned earlier, those URLs are published to the cloud and picked up instantly. Once you input your email address and password, it will seamlessly enroll your device. There’s a catch however!

The way the code is implemented for Workspace ONE, it expects your directory account is a normal AD account. They map enrollments to users based on the immutable ID mapping attribute. In layman terms, they look at the immutable ID that Azure passes to Workspace ONE to see if it matches an ObjectGUID for a Directory account to map that device to the right user.

What’s the Catch?

So that seems like no biggie right? Totally should just work and shouldn’t be an issue right? Wrong! As you recall, we are using Azure AD Domain Services, which does things a little bit differently. As you can read about here, Azure AD-DS uses a different SID namespaces than your on-premise Active Directory. This is a problem because when someone enrolls, you will basically end up with a brand new user account and nothing is linked to it whatsoever.

Luckily, I am here to say that I found a few ways to fix the issue. Let’s cover them next!

Option 1: Leveraging LDAP Synchronization in Workspace ONE UEM

You will notice now, there is a field for mapping the AD attribute in the user account:

I found that you can use the user attribute synchronization in Workspace ONE to populate this and easily fix the issue:

Option 2: Running a Translation Script from Azure AD DS to Azure AD

There is a script that you run when a new employee starts (potentially something to add to your onboarding script). It will take the Azure AD-DS ObjectGUID and convert it/write it to the Immutable ID:

$guids = Import-CSV .\guidimport.csv | Select-Object UPN, @{Name = 'ImmutableID'; Expression = { [system.convert]::ToBase64String(([GUID]$_.guid).ToByteArray()) } }
 $guids | foreach {Set-AzureADUser -ObjectId $_.upn -ImmutableId $_.ImmutableID}

This script will simply take your list of ObjectIDs out of Azure AD-DS and convert them up to Azure AD since Microsoft does not provide an easier way currently. It’s not the most ideal situation, but it’s a workable solution if you would prefer to leverage the Azure side of the house.

Final Thoughts

I have to admit that I thought this was going to be a major issue to achieve. Once I leveraged the user attribute synchronization I found an enterprise-grade solution to an annoying issue. Beyond that, it works like a charm! I am really enjoying how clean the solution is functioning overall. I’m lucky enough that a good friend (Josue Negron) helped me understand how this flows at the Workspace ONE side. By sharing this information, we can build a solution that solves real business issues. I implore all of you to try it because it’s something special!