Azure-docs: userCertificate required on AD Computer account for AAD Connect to sync

[jeremyhagan]

In its default configuration from version 1.1.553 Azure AD Connect wont synchronise Computer objects unless the userCertificate attibute is populated. Is this attribute required for implementing hybrid domain join? Can I safely disable this Scoping Filter on the Out to AAD - Device Join SOAInAD rule in AAD Connect? This isn't documented above (or anywhere else that I can find).

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 72cdc251-618a-e84e-f40d-960b0ac69f99
• Version Independent ID: 8cbaba3c-e883-2c71-28fb-f88db3fcaf7d
• Content: How to configure hybrid Azure Active Directory joined devices
• Content Source: articles/active-directory/device-management-hybrid-azuread-joined-devices-setup.md
• Service: active-directory
• GitHub Login: @MarkusVi
• Microsoft Alias: markvi

[Mike-Ubezzi-MSFT]

@jeremyhagan Thanks for the feedback! We are currently investigating and will update you shortly.

[MohitGargMSFT]

@jeremyhagan Hi, Please note as per below document regarding Azure AD Connect version 1.1.553 below -
https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-version-history#new-features-and-improvements-10

Specific to userCertificate attribute on Device objects, Azure AD Connect now looks for certificates values required for Connecting domain-joined devices to Azure AD for Windows 10 experience and filters out the rest before synchronizing to Azure AD. To enable this behavior, the out-of-box sync rule “Out to AAD - Device Join SOAInAD” has been updated.

[jeremyhagan]

This is self referential. What user certificates are required and why?
Where do they come from? If they aren't there what is the behaviour?

On 20 March 2018 at 11:06, Mohit Garg [e-mail] wrote:

@jeremyhagan https://github.com/jeremyhagan Hi, Please note as per
below document regarding Azure AD Connect version 1.1.553 below -
https://docs.microsoft.com/en-us/azure/active-directory/
connect/active-directory-aadconnect-version-history#
new-features-and-improvements-10

Specific to userCertificate attribute on Device objects, Azure AD Connect
now looks for certificates values required for Connecting domain-joined
devices to Azure AD for Windows 10 experience and filters out the rest
before synchronizing to Azure AD. To enable this behavior, the out-of-box
sync rule “Out to AAD - Device Join SOAInAD” has been updated.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/azure-docs/issues/5872#issuecomment-374427472,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AWnfbTIjPoISXgqrIlrD0lvC1qrSwkV0ks5tgEgjgaJpZM4StSsS
.

[MohitGargMSFT]

@jeremyhagan Out to AAD - Device Join SOAInAD sync rule is used to implement Hybrid Azure ad join / Domain Join in a managed domain. In a federated domain this rule is not used as the STS / AD FS would authenticate the device. In a managed domain the certificate for the device would be used to authenticate the device in AAD.

You can disable the sync rule as long as you are using a federated environment.

[MohitGargMSFT]

@jeremyhagan We will now proceed to close this thread. If there are further questions regarding this matter, please open a new MSDN forum post and community will help address your query. Please refer to below link to MSDN forum to ask new question -
https://social.msdn.microsoft.com/Forums/azure/en-US/newthread?category=windowsazureplatform

[jlbeasley]

I know this case closed, but I am looking at the same situation where the device objects do not have a userCertificate attribute populated so are being filtered out and not joined to AAD. We are using PTA with SSO. Any recommendation on populating this attribute?

[jeremyhagan]

The computers require internet access via WinHTTP in order to probe the device registration service. Once they successfully probe the service they create a self-signed certificate which they then use to populate the userCertificate attribute. Check the User Device Registration event log. If you see errors saying winhttp call back failed it is because the machines can't find a proxy or access the internet.

[AJRus]

I had a similar issue where some devices had a UserCertificate and others did not, a full sync resolved the issue.

[toanyonebutyou]

I stumbled across this when facing the same issue. Hybrid Azure AD is already setup in the environment and can confirm it is working for most machines. I have a couple problem computer objects that upon domain join did not receive the userCertificate attribute. These machines of course are not being synced up.

I have tried Initial Syncs, confirmed connectivity, even removed the machine from the domain and rejoined it and still no userCert attribute. Completely at a loss right now.

Any ideas anyone?

Thanks,

[jeremyhagan]

Check the User Device Registration Event Log. The errors will be indicated in there. The machine wont generate the userCertificate until it is sure it can reach the device registration endpoint. Obviously the computer account has to be within the scope of replication (i.e. not in the wrong OU if you aren't syncing the whole domain) and the GPO telling it to join need to be not configured or enabled (win10) or enabled (win81).

[toanyonebutyou]

@jeremyhagan The machine is within the scope and I do see a warning under the event viewer > apps and services > Microsoft > User Device Registration, but no errors. The warning states it can not be joined the process must run as NT authority.

I am not trying to get it to join right now though, I just need the object to sync,

[jeremyhagan]

The object wont sync until the user certificate is created. The workstation
wont create the user certificate and push it to AD until it decides it want
to do the hybrid join. It is just the way it works.

On 29 May 2018 at 23:04, toanyonebutyou [e-mail] wrote:

@jeremyhagan https://github.com/jeremyhagan The machine is within the
scope and I do see a warning under the event viewer > apps and services >
Microsoft > User Device Registration, but no errors. The warning states it
can not be joined the process must run as NT authority.

I am not trying to get it to join right now though, I just need the object
to sync,

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/azure-docs/issues/5872#issuecomment-392767984,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AWnfbXauCZaAtLbHeJYjCN74rwwrg4zVks5t3UdLgaJpZM4StSsS
.

[toanyonebutyou]

@jeremyhagan First off, thank you for your time in replying to me. Secondly I must apologize as there is something that I am not understanding, it is not clicking for me.

I did a test in my lab, I disabled AAD Connect and joined a new machine and that new machine recieved the usercertificate if that sheds any light.

Can you describe the process a little more for me? At least the flow of events? I am not sure what you mean by

'The workstation wont create the user certificate and push it to AD until it decides it want
to do the hybrid join.'

Thank you for your time.

[jeremyhagan]

Sure @toanyonebutyou There are a couple of disjoint processes in play.

AAD Connect has a sync rule which prevents a computer account from syncing unless the userCertificate attribute is populated. It has no involvement in populating that attribute on the computer account. It is just a simple sync rule. The question is: How does this attribute get populated? I'm going to stick to describing the process for Windows 10 since that is where I did all my testing and implementation work.

The userCertificate attribute on the computer account in your on-premises AD gets populated by the User Device Registration Scheduled Task on the workstation. It generates a self-signed certificate and populates the computer account with the public key of this cert. The next question is, how/when does the workstation decide to do this and why?

Well it does it when it is configured to perform a Hybrid Domain Join. Which it will do if there is a Service Connection Point in AD configured with your Tenant ID and if there is a GPO setting set to Not Configured or Enabled on the workstation (see here for doco on the SCP and GPO https://docs.microsoft.com/en-us/azure/active-directory/device-management-hybrid-azuread-joined-devices-setup). So if you think that these two things are set up properly, then you need to monitor the Microsoft-Windows-User-Device-Registration/Admin Event Log to see the flow of events.

A summary of event (from my memory) is as follows:
1: The workstation finds the SCP and decided to try for a hybrid domain join
2: It probes the Azure Device Registration endpoint to see if it can join, if this is successful it then generates the certificate and populates the userCertificate attribute
3: It tried to hybrid join and fails because there is no synced account in Azure AD
4: Time passes until the next AAD Connect sync interval and now, since the userCertificate attribute is populated
5: Meanwhile, the workstation keep periodically trying to Hybrid Domain join, eventually the computer account exists in Azure AD and it matches up the certificate with the one it generated and the hybrid join is successful

The problem is that the workstation need Internet access for the probe to succeed. If this probe fails, it wont generate the certificate. It would be much better if it generated the certificate regardless of the success of the probe. What's worse, is that the Scheduled Task either needs WPAD to be working of to have the WinHTTP proxy settings set to work behind an proxy. It wont use the proxy settings of the logged in user. These two issues (the timing of the cert generation and the proxy requirements) make this a very confusing issue to troubleshoot, ESPECIALLY since the documentation for this process is virtually non-existent.

I hope this makes it clearer for you.

Cheers,
Jeremy.

[csteelatgburg]

Thanks for this writeup @jeremyhagan. I have found that machines which already have a userCertificate attribute sometimes need to be removed from the domain and then added again before they will perform the Hybrid join successfully. The userCertificate does not seem to change as part of the process, so I'm not entirely sure what is happening. Have you experienced that?

[jeremyhagan]

@csteelatgburg I don't operate the environment where we implemented this. I've put in a question to the sysops people at my customer to see if they have the same issue.