I recently had a situation I hadn’t encountered before while moving a client to Hybrid Device Join + Intune (or Entra ID Join, HAADJ, EIDJ, or whatever you want to call it these days). This involved both firewall settings and configuration manager blocking device registration (see Ben’s post here for more on that Co-management Series “Merging the Perimeter” – Part 4: Configuring Hybrid Azure AD (byteben.com). After the experience, I figured it was a good opportunity to make a post about what is really happening on the backend when we hybrid join devices. Why do devices need to see a domain controller, and how does AAD Connect “sync” device objects? Do devices have a role in this process, or is it all on ADD Connect? We will find the answers to all these questions and describe the process of what is happening.
First, I will admit that I strongly dislike Hybrid Join. It’s not necessary in the long term for most organizations. For more on why you shouldn’t hybrid join (unless TRULY necessary), see these two posts here and here. But, the reality is that Hybrid is still going to be around for a while, and even if organizations don’t require it in the long run, it’s a gateway for organizations to use Intune and Conditional Access while they work to get rid of reliance on AD and other on-prem solutions that require AD or Domain Joined devices.
So, what is Hybrid Entra ID join (or maybe this will remain Hybrid Azure AD Join, but I’m sure this name won’t go away)? It’s not much different than the device being joined to Active Directory. The device is still Joined to AD and users authenticate with Active Directory identities. The device is also Registered with Entra ID. So, Hybrid Entra ID/Azure AD Joined is really just AD Joined + Device registration. We can still apply GPOs to the devices, but we also get access to Intune management and Conditional Access. Hybrid devices can easily be enrolled in Intune via GPO using this method: Enroll a Windows device automatically using Group Policy – Windows Client Management | Microsoft Learn
This post is going to look purely at the Hybrid Join process, not how to set it up or how Intune enrollment works. The Hybrid Join process is misunderstood by many people and it’s important to understand the moving parts, especially when troubleshooting issues.
How Hybrid Join Works – The Process
This is usually very simple. You configure Azure AD Connect to Hybrid Join devices, and everything magically works. You start seeing devices populate in Entra ID as Hybrid Joined. But there are several steps and two pre-reqs for devices before they can be hybrid-joined. Let’s take a look at the steps and then go into detail:
- A SCP needs to be created in Active Directory. This is usually performed by Azure AD Connect when going through the wizard for Hybrid Device join. You can also manually create the SCP, but I don’t suggest that since AD Connect can do it for us.
- AD Joined devices automatically read the SCP and try registering with the tenant information located in the SCP. This will fail until Azure AD Connect syncs the device to Entra. However, AAD Connect Cannot sync devices without a value for the userCertificate attribute on the device object in AD.
- The automatic-device-join scheduled task runs on devices. This task will try registering with the Entra tenant and also generates the userCertificate value, which is sent to Active Directory.
- Once the userCertificate value exists on the device object in AD, Azure AD Connect and syncs the Device information up to Entra. However, the registration is not complete and will show as “pending” until the device completes the registration.
- The next time the automatic-device-join task runs after AAD Connect syncs the device info to Entra, the device registration is complete, and the device will show properly registered and Hybrid Azure AD Joined.
Here is a high-level flow of the order of events to achieve a hybrid-joined device state:
Azure AD Connect and the CSP
The first component to hybrid joining devices is to Install & Configure Azure AD Connect (or modify your existing configuration). This is very straightforward, and the instructions from Microsoft are here – Configure hybrid Azure Active Directory join – Microsoft Entra | Microsoft Learn. When we configure Azure AD Connect to Sync devices, it does two things. First, it creates a Service Connection Point (SCP). The SCP is added to Active Directory and contains the tenant ID and domain for your Entra ID tenancy. This is what devices will read so they can properly identify which tenant to register with. We can view the SCP on a domain controller by opening ADSI edit, and connecting to the configuration Naming Context:
To view the SCP, expand the top-level configuration container, then expand Services and Device Registration Configuration. You’ll see a container named “62a0ff2e-97b9-4513-943f-0d221bd30080”. This is the same for all organizations and contains the details devices need to register with Entra ID.
If we right-click the SCP and select properties. In the attribute editor tab, you’ll see a field for “keywords” with your tenant domain and tenant ID. This is what the devices read so they know which AAD tenant to register with:
The second thing Azure AD Connect does after it’s configured for hybrid device join, is sync device information up to Azure AD. However, it doesn’t do this until a device attribute, userCertificate, contains a value on a device object. More on that attribute and how it is populated a little later.
So, configuring AD Connect to Sync devices is usually all you need to do for Hybrid device join to work, but there is more to what actually happens in the background. Let’s see what the device’s role is in all of this. After all, you need to remember that devices require line-of-sight to a domain controller to properly hybrid join.
What’s happening on the device and why does it need to see a domain controller?
Azure AD Connect is a requirement and configures the SCP for us, but the devices also play a role in this. Devices need to see a domain controller to Hybrid-Join for two reasons:
- They need to read the SCP so they know which tenant to register with
- They need to write the userCertificate attribute back to their computer object in AD. Remember from above, this attribute value is required for AAD Connect to sync computer objects to AAD.
Devices will automatically look for an SCP from a DC as long as they’re domain joined. Once an SCP exists and they have tenant information, they’ll try registering with Entra ID. They do this using a scheduled task that’s baked into Windows 10/11. The task is under Microsoft > Windows > Workplace Join. However, the device won’t be able to complete its hybrid registration until AAD Connect has synced information about the computer Entra. Confusing, right? So, the task on its own can’t complete a Hybrid registration, but AAD Connect on its own can’t complete the Hybrid Join without the device automatic-device-join task.
We can see under the description of the task that the purpose is to Entra/Azure register the computer as long as its domain-joined:
The triggers will fire at the logon of any user, or event ID 4096 in the Microsoft > Windows > User Device Registration Log and repeats every hour.
And the actions of the task are to run dsregcmd:
This task is disabled on devices until they’re domain joined:
As soon as you join a device to the domain, the task will be enabled:
When this task triggers, the device reaches out to Entra ID and tries to register, but in order to properly hybrid-join, AAD Connect must have synced device information up to AAD about that device. For AAD connect to do that, the device needs to have a populated value for the userCertificate attribute in AD. This value is generated by the computer when the task runs, and is written to AD (as long as the device has line of sight to a DC):
AAD Connect + Automatic-Device-Join Task = A Happy Hybrid-Joined Device
Remember, the automatic-device-join task on its own can’t complete the hybrid registration. We need an assist from AAD Connect. Now that the user certificate field is populated, AAD Connect can sync the computer information up to Entra. If we re-run the workplace join task after the userCertificate attribute is populated, but before AAD Connect runs its sync, we will see events 204 and 304 in the Windows > User Device Registration log, indicating that the device is not found. It’s referring to the device not being found in Entra when it tries to complete its registration since AAD Connect has not run a sync yet:
We need AAD Connect to complete a sync cycle before the device can complete registration. Technically, the automatic-device-join task needs to run twice to complete the entire hybrid join process. Every time the task runs, it tries to register with Entra ID, but if there is no userCertificate attribute value on the AD device object, it will generate one and send it to AD, which we already went over. The next time the task runs AFTER AAD Connect has finished a sync, it will complete the Hybrid registration process. After AD Connect runs a sync cycle, but BEFORE the automatic-device-join task runs again, you’ll see the device appear in Entra ID with a status of “pending”. AAD Connect has synced information about the device up to Entra, but the automatic-device-join task needs to run again for the device to complete registration:
Very soon after the automatic-device-join task runs again, the device will show up with a registered timestamp in Azure AD or Entra, and you’ll see event 306 appear in the User Device Registration event log, indicating registration was successful.
Now you know what is actually happening on the backend when configuring Hybrid Azure AD / Entra ID Join. If you’re in a situation where none of your devices are hybrid-joining, you can start at the top and work your way down.
- Make sure an SCP exists
- Make sure the automatic-device-join task is enabled on the endpoints.
- Make sure the device userCertificate attribute is populated on the device Objects in AD
- We didn’t go over this in the post, but make sure your devices are in an OU that is targeted to sync in AAD Connect
If all of the above checks out, you’re in good shape and can reference event log errors if you need to do additional troubleshooting. If your devices are stuck in a pending state, I’ve made a previous post about how to troubleshoot that situation here – HAADJ devices stuck with pending registration state – SMBtotheCloud