In the last week, I did Hybrid Device Join configuration and have to say that configuration is a bit smoother with Azure AD Connect than the last time (couple years ago) I was working with it. I’m an old school man and I like to perform tasks manually, to see what’s really happening underneath the hood. Naturally, I faced immediately a problem with it and this blog is a short version of findings.

The Problem

During AAD HDJ configuration the following error appeared:

  • Client ErrorCode: 0x801c03f2
  • Server Message: The device object by the given id is not found

This event was found from Windows logs. Both messages clearly indicate that the device join phase failed because the computer object was not found.

Finding The Solution

Error code is always extremely useful and with it, you can most probably find a solution. With an error code, I made some googling and found two excellent blogs around this topic.

It was found that workstations were not in Azure AD Connect sync scope which was causing this error. Workstations were added to sync scope and in the next sync cycle, devices are synced and created to Azure AD.

What Happens Underneath The Hood

In initial sync, the devices are synced (and matched to managed later on) to Azure AD by AAD Connect and during the registration process, a device certificate will be created. This certificate is needed for authentication and to get Primary Refresh Token (PRT). To really dig deep underneath the hood read these Jairo Caneira blogs:

In some cases, I have found that there is some latency in certificate creation. When a certificate is created it can be found from the cloud with PowerShell and in the portal device state is changed.

Dsregcmd /status shows outcome which is much better than after initial sync.

Azure AD and will generate the certificate and send it back to the device. The API, in turn, will install the certificate into the LocalMachine\MY store.

dir Cert:\LocalMachine\My\ | where { $_.Issuer -match "CN=MS-Organization-Access" } | fl

A few things to highlight (from Jairo’s blog):

  • DeviceId is a GUID generated by Azure DRS. Note that this is the same value in the Subject field of the certificate.
  • AlternativeSecurityIds contains the certificate thumbprint with a specific scheme format (i.e. “X509:<SHA1-TP-PUBKEY>:” + thumbprint). This is how Azure AD will find the device object when the device presents the certificate upon authentication.
  • The storage/transport key is stored in the device object in an attribute non-visible through Graph API.

This was a quick post of the Azure AD HDJ problem I faced. Happy and Successful New Year 🙂