This is a second blog post in a row about AAD Connect and Hybrid Device Join aka HDJ which explains that I haven’t played with it lately (latest entry in here). I visited one of my customer sites last week and during the day I found that there was a high number of failed sign-ins against Azure AD. I was a bit curious about what’s causing those ones, let’s see what I found.

The Problem

From the internal network, Hybrid Device Join (HDJ) registration was not working as expected in some of the devices and a high number of failed sign-ins events were found from Azure AD sign-in logs. I noticed that my own identity was having 3-4 failed sing-ins multiple times per day on a regular basis. Even, end-users didn’t have a critical problem it’s definitely something that needs to be fixed to make sign-in process much smoother for the end-user.

Approximately 5% of Windows Sign-ins are failed.

Device authentication caused most of the failure sign-ins. For a moment I was scratching my head with my colleague @pitkarantaM until we realized what caused the problem. Application, where failed sign-ins were triggered was “Windows Sign-in”.

This lead us to Windows 10 devices where we found errors from Event Viewer. There are two logs which can be used to find related events (in the picture)

HDJ status can be confirmed with “dsregcmd /status” command. Ran that and found immediately that my device didn’t have a Primary Refresh Token (PRT).

Also, device status in Azure AD portal was “Registered – pending“.

Affect To End-Users

In such a case, the Hybrid Join Devices W10 devices login process SSO part doesn’t work as expected, because Azure AD is not able to issue Primary Refresh Token (PRT) to W10 devices.

The Solution

Found excellent blog from Sergii, which had a solution for a different Hybrid Device Join error – Unregistered status. Followed same process than in here and my device state was successfully changed:

  • dsregcmd /debug /leave
  • Confirmation from Azure AD that device object was removed
  • Reboot machine
  • Confirmation that the device had been trying to register itself again to Azure AD (AAD audit logs)
  • Confirmation of device status from AAD (changed from pending to “registered with timestamp”)
  • dsregcmd /status (which should now have PRT included)

Difference between AAD Join SSO & Seamless SSO

Because people mix these right now and then (including me) here is short description of these solutions (

Q: What is the difference between the single sign-on experience provided by Azure AD Join and Seamless SSO?

Azure AD Join provides SSO to users if their devices are registered with Azure AD. These devices don’t necessarily have to be domain-joined. SSO is provided using primary refresh tokens or PRTs, and not Kerberos. The user experience is most optimal on Windows 10 devices.

Both Azure AD Join and Seamless SSO can be used in one tenant. These two features are complementary. If both features are turned on, then SSO from Azure AD Join takes precedence over Seamless SSO.

How To Prevent This At Future

If you have read the blog post this far you might wonder what might cause such an issue with the device registration? Microsoft FAQ of device troubleshooting highlights the following reasons:

  • Pending indicates that the device is not registered This state indicates that a device has been synchronized using AAD Connect and is ready for device registration
  • If device is deleted from Azure AD first and re-sync from an on-prem AD
  • If a device is removed from a sync scope on Azure AD Connect and added back


Device Registration Deep Dive

What’s a Primary Refresh Token

Hope this helps, until next time!