Today I want to talk about an issue I ran into recently with trying to setup Hybrid Azure AD Join.
First lets do a little background on the process. Microsoft has a decent guide on how to do it which can be found here.
https://docs.microsoft.com/en-us/azure/active-directory/device-management-hybrid-azuread-joined-devices-setup
The exact situation I ran into, or at least that I thought I ran into, was the fact that the device object was not syncing into Azure AD.
In order for a Hybrid Join to occur you have to sync the device object with AAD Connect. Inside of AAD Connect there are certain sync rules and settings. One of those rules states if the userCertificate attribute on a machine is $null then do not sync it.
For awhile I chased down the idea that this attribute was generated upon domain join (due to a tip from an MS rep), spoiler alert, this is not when the attribute is generated on the Active Directory Object. This attribute is generated AFTER the Win10 device probes the SCP you setup in your AD and actually finds something.
So, at a basic level, this meant that my issue was one of communication. For whatever reason my device was not communicating with Azure AD. This issue was solved two different ways for me when I ran into it across a few customers.
1.) ADFS. If you have ADFS in place you need to place the claims rules in ADFS correctly. In my specific case the users UPN and the domain that they had federated with O365 was user@domainA.com but the real domain name on prem and the name that all the devices used was computer.domainB.com. The fix in this scenario was to federate domainB.com with ADFS as well and include domainB in our claims rules.
2.) Scheduled Task. At two of my clients we ran into this without ADFS being in the mix. We were using AAD Connect with SSSO. The fix in this situation came in the form of enabling the scheduled task built into Win10 devices that attempts to do the Hybrid Join. This task can be found at Microsoft>Windows>WorkPlace Join. For some reason this was disabled, it should be enabled by default. I suspect something to do with SCCM but can not verify.
Once this was actually enabled the device was able to probe the Azure AD Join service, generate its specific userCertificate attribute and then complete its join after a login or two. If this does not happen for you this task can also be controlled by a GPO that can block the device enrollment. As a test I would move a device into an OU with no policies on it and work off it from there.
So, to recap, usually not having a value in the userCertificate attribute is not the actual issue. Something is stopping the communication between your machine and Azure AD.
Event Viewer is also pretty helpful in tracking down some of these issues as well. You can view the logs at Microsoft>Windows>User Device Registration. If the above does not help you I would check here for further info.
Hope this can help some of you, see ya around.
