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.
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.
Now you technically can brute force a fix by either manually putting in literally anything for that attribute (I tried, it accepts a junk value) or changing the rule in AAD Connect to sync the object anyways. Either way I would not recommend as something else is most likely the actual root issue and wont fix the problem.
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.
This has been super super helpful - thank you so much for taking the time to write this. You answered something which was missing from the MS documentation and the MS support guys were scratching their heads over. Thank you.ReplyDelete
Thank you very much for your post.
I want to clarify, that do I need to set "userCertificate" attribute value in AzureAD Connect server empty in synchronization rules or set ISNOTNULL=FALSE
You shouldnt have to set it to anything. Populating this by hand is more of a test. Once the machine reaches out to Azure AD it will populate this attribute itself.
If this is not occuring that means there is a communication issue happening somewhere in the process.
Thank you for reply!ReplyDelete
Hi, i get this issue after Azure AD Sync is updated. Suddenly some computers deleted from azure AD because usercertificate value is null. But this had little weird actions because only some computer did had valid user certificate. Computers are deployed on same image only some had this issue. I resolve to drop computer out of domain and then join again. Then computer gets valid certificate after next sync. But this had too much work to do about 100-200 computers.ReplyDelete
Hello, sorry for the delay my comments were not turned on for a moment.Delete
As far as why the 'User Certificate' attribute would drop off after an AAD Connect upgrade I have no idea.
The value comes after the machines communicates with Azure AD. Im not sure why a domain rejoin would solve this issue
Thanks for this! Helped me to better understand what is happening behind the scenes. My issue ended up just being basic internet connectivity after a profile migration but my computers finally picked up the usercertificate attribute upon login.ReplyDelete
A late addition here, but when SCCM is involved we ran into this because of the SCCM client settings. Check Cloud Services and ensure "Automatically register new Windows 10 domain joined devices with Azure Active Directory" is set to Yes. This will enable the required scheduled tasks for the hybrid domain joined devices and the userCertificate will update a short while later and the devices will sync properly.ReplyDelete
Found the rule 2nd to last: Out to AAD - Device Join SOAInADReplyDelete
Took way too long to find this article, appreciate you posting this. 3 devices did not sync out of hundreds, and this was why.ReplyDelete