Out of Office Hours

You’ve probably heard someone say it before: Don’t do Hybrid Azure AD Join, move to Azure AD Join. What they are generally referring to is more specifically talking about Windows Autopilot and its user-driven Hybrid Azure AD Join scenario, in which Windows Autopilot joins a device to Active Directory and enrolls it in Intune.

But it’s worth looking at that question more broadly. Let’s start from the top…

What’s wrong with Active Directory?

We should probably be more specific here and say “Active Directory Domain Services” since for a while everything had an Active Directory label on it. For simplicity though, let’s just say AD. What’s wrong with AD? Well, it was originally shipped in the year 2000 and was designed for a different computing reality: Devices that are always (or at least mostly) connected to the corporate network. These days, people work from home; they travel around the world; they primarily use laptops which are certainly not always connected to the corporate network. So what’s wrong with that?

First, there’s always a need for connectivity to do certain tasks. For example, you need connectivity to an AD domain controller to log in initially; to change your password; to apply updated Group Policy objects; to enroll and renew AD Certificate Services certificates; to map network drives to file servers; etc.

Solutions like DirectAccess (which was deprecated and then un-deprecated) solved that challenge, but were difficult to deploy and support. Newer solutions like Always On VPN could also work, but they were also challenging to implement. Many organizations adopted third-party VPN solutions that supported integration with Windows to help (e.g. start before logon [SBL], PLAP, etc.), and with the right instructions you could get it to work. But it typically wasn’t smooth or seamless, and required educating employees on how to use it.

Second, Active Directory assumed good connection speeds, e.g. devices on a LAN, so it can get more challenging when using slower internet/VPN-based connections. This can cause issues with the same sorts of AD capabilities (e.g. GPOs) even when you have solved the connectivity issues. As internet speeds improved, this may not be as big of any issue now.

What’s wrong with Hybrid Azure AD Join (generally)?

Azure Active Directory was designed for internet-connected devices, so it doesn’t have the same challenges. But it also has much less functionality when you look at it from a Windows perspective. It’s just an authentication service, it has no device management capabilities of its own: no policy delivery (so no GPOs); no certificate enrollment features; no drive mapping; etc. Hence you need a separate management solution (e.g. Intune/MDM, ConfigMgr/CMG, or pretty much any other management solution that can support internet-facing clients, which is pretty much all of them at this point). But even with that, you need to rethink things, e.g. no more file servers, logon scripts, mapped drives or anything like that. “All you need to do is move that stuff to OneDrive, SharePoint, Teams, etc.” But that’s more of a “what’s wrong with Azure AD” discussion.

If we look at Hybrid Azure AD Join, it has a more limited purpose: To get devices joined to AD known to Azure AD, and to get users signed into AD to also have Azure AD user tokens. The benefits for doing that include single sign-on to Azure AD-based services, conditional access, etc.

But to get this to work, you need to synchronize AD to Azure AD: all users and devices need to be synchronized. The user part works pretty well, but there are complications with the device part. Here’s an image from a post I did a few years ago:

For organizations not using ADFS (which is likely a lot at this point since Microsoft is trying to push customers away from ADFS), the Hybrid Azure AD device registration process needs for the device to communicate with an AD domain controller, first to find the SCP object that tells the device what AAD tenant it needs to register with, and then again to update the device’s certificate in AD. Only when that certificate is present will AAD Connect synchronize the device into AAD. And if a user signs into the device before that happens, they don’t get an AAD user token, which has some potentially bad side effects, e.g. timeouts from user ESP, an inability to do single sign-on to AAD-based services (e.g. OneDrive, SharePoint, Teams), etc.

There used to also be issues caused by duplicate objects for a single device in Azure AD: you would find the original AAD device created when the device was first registered with Autopilot, and then a second Hybrid Azure AD device that was synchronized from AAD Connect into AAD. This caused havoc with Intune policy targeting because Intune would switch to the new HAADJ device object as soon as it showed up; anything that targeted the original AAD device would fall out of scope. The most noticeable side effect of this was the offline domain join process timing out; you could work around it by either assigning the Domain Join configuration profile to “All users” or to a dynamic group that contained both objects. Interestingly, I haven’t seen this happen recently. Perhaps it’s been fixed so that AAD now merges the two objects together? The docs aren’t particularly clear.

What’s wrong with Windows Autopilot user-driven Hybrid Azure AD Join (HAADJ)?

The user-driven HAADJ process definitely has some shortcomings. While some have been eliminated, others remain.

First, there’s the computer naming. The only thing you can configure for the computer name is the prefix, e.g. “DJ-“. The rest of the name is filled with random characters to create a 15-character name. (You can tell that whoever implemented this initially didn’t realize that Windows computer names were case-insensitive, as they use both upper and lower case letters in the names.) Few organizations are happy with this.

Also, the offline domain join process implemented by Intune that is used to join the device to AD is rather slow as it’s designed to handle a ridiculous scale, even though orgs typically would only deploy a few devices per hour, so the implementation is overkill. The process also doesn’t support the other DirectAccess-related capabilities that are generally useful for offline join scenarios: embedding root certificates; generating a computer-specific cert and including it in the blob; including one or more GPO objects in the blob. I tried to add these at one point (and did add them in the Tanium Provision offline domain join implementation) by modifying the ODJ Connector’s code myself, but it wouldn’t work: the communication channel to send the resulting ODJ blob back to Intune for relaying to the client via MDM wouldn’t accept an ODJ blob that was larger than 16KB.

Related to the AAD Connect synchronization process described above, it’s also highly unlikely that user ESP will work properly since the signed-on user will not have an AAD user token. Unfortunately, the ESP settings in Intune don’t provide a simple way to turn it off (you really don’t need it); you have to use a custom OMA-URI configuration profile to do that. That doesn’t help Intune out any — it still won’t be able to deliver any user policies or apps until the user signs out and back in again, but at least that is a background issue that the user won’t notice.

At least one improvement was made to the original user-driven HAADJ process: the addition of the “Skip AD connectivity check” option. Prior to this, Autopilot would always try to find a domain controller before it would continue the deployment process, but unless you had successfully implemented an Always-On VPN connection (“all you have to do is replace your current VPN with the Windows Always On VPN solution”) that would never work. By saying “skip the check” you are telling Autopilot that you are responsible for establishing connectivity in some way before the user will be able to sign into the device (if they are are off the network — obviously not an issue if you are deploying while on the corporate network).

Enrolling certificate via MDM can also be tricky with the user-driven HAADJ process, since the initial certificate template configuration profiles will be received by the device before it has rebooted to complete the ODJ process; that sets the “real” computer name at the same time. There is a workaround using the {{FullyQualifiedDomainName}} attribute in the profile. That value can’t be obtained until after the ODJ reboot, and the device will keep trying until that happens, so you will eventually end up with a “proper” cert. (Be careful if you are using AD-delivered auto-enroll certificates since those have the same connectivity challenges as previously mentioned.)

So what should I do?

The Microsoft message will always be “move to AAD Join, give up on HAADJ.” But that can be a significant amount of work. There’s nothing wrong with using HAADJ in the near term, you just need to make sure you do some things to increase your chances of success.

1. Implement Always On VPN or a third-party equivalent that supports automatic connections. This will provide the smoothest operation, just like if you were on the corporate network. If that’s not an option (e.g. you’re a Cisco shop and you need to use the Start Before Logon [SBL] feature of AnyConnect), you would need to at least teach your users how to make a VPN connection before logging on (check the box on the logon screen, connect to VPN first). This post is probably a little out-of-date, but it’s a good starting point.
2. Check the “Skip AD Connectivity Check” box in the HAADJ Autopilot profile. Even if you are using Always On VPN from Microsoft, this can still be problematic — by skipping this, connectivity isn’t needed until the user signs in.
3. Turn off user ESP. See the “SkipUserStatusPage” instructions in my post here. (There really should be a checkbox in the ESP settings to make this easier.)
4. Target your Domain Join profile to “All devices.” This avoids issues that can occur with group membership in Azure AD (Entra ID) that can cause ODJ timeouts that occur because Intune couldn’t find any Domain Join profile targeted to the device. This does mean that all devices would need to be put into the same OU, but you can always move them later. (The typical symptom that you’re running into this: a newly-registered device works once, but if you reset it or reimage it and try again it doesn’t work the second time.)
5. Specify the {{FullyQualifiedDomainName}} attribute on certificate templates in Intune so that the certificate does not get enrolled until after the computer name has been set (so after the ODJ reboot). (Note that this only works for AD-joined devices; a certificate profile set up like that won’t work on an AAD-joined device.)

One other item to consider if you really don’t like the random computer names:

• Rename the AD device after the provisioning process completes. See this post for the details around that (AD/VPN connectivity required).