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 (docs.microsoft.com)
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
References
What’s a Primary Refresh Token
Hope this helps, until next time!
Sam's Corner 
Glad my post was helpful in troubleshooting of your issue. The WorkplaceJoin Event log is more useful for Workpla Join troubleshooting scenarios. For Azure AD join and Hybrid Azure AD join we use User Device Registration logs to get information about possible root of the issue before trying to simply re-join the device.
Thanks! And as you guided me last time this is a super useful link for device registration flows in different scenarios:
https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-how-it-works-device-registration?WT.mc_id=twitter#hybrid-azure-ad-joined-in-managed-environments
Thanks Sami to share this topic. I had same issue with about 200 computers. I open MS support case in 3months ago. Still devices are pending. Some computers fix with same steps what you did. Some only fixed to drop of domain and join back at same session. Maybe same day last of computers are get right status on registerations
Hi Sami! Thanks for sharing your experience related to this same issue. It seems that is quite commonly seen but solution for fix it varies a bit. In environment I worked with, the fix provided in blog worked for pilot group of computers. Let’s see what’s the status at the end of the day with the rest ones😊
Hey Sami, thank you for this blog. Its excellent. One question I do have, I know the PRT refreshes every 14days, weather by coming into the corp network or via VPN. We are seeing after 14 days, even on full tunnel VPN the PRT does not refresh and the user is removed from Hybrid Azure Join in the Cloud and locally on there device. Is there a setting would allow this token to refresh? I have had multiple tickets opened with MS on this, but I have gotten no where.
Hi, First of all, thanks for reading:) Yes, you are right, PRT lifetime is 14 days and it’s continuously renewed as long as the user actively uses the device. One question which comes to my mind, is your HDJ properly in place for those machines or are you seeing errors in there?
A PRT is renewed in two different methods:
• Azure AD CloudAP plugin every 4 hours: The CloudAP plugin renews the PRT every 4 hours during Windows sign in. If the user does not have internet connection during that time, CloudAP plugin will renew the PRT after the device is connected to the internet.
• Azure AD WAM plugin during app token requests: The WAM plugin enables SSO on Windows 10 devices by enabling silent token requests for applications. The WAM plugin can renew the PRT during these token requests in two different ways:
○ An app requests WAM for an access token silently but there’s no refresh token available for that app. In this case, WAM uses the PRT to request a token for the app and gets back a new PRT in the response.
○ An app requests WAM for an access token but the PRT is invalid or Azure AD requires additional authorization (for example, Azure Multi-Factor Authentication). In this scenario, WAM initiates an interactive logon requiring the user to reauthenticate or provide additional verification and a new PRT is issued on successful authentication.
I would like to know a bit more about your use cases to give you detailed answer. You can send an email to me samilamppu@hotmail.com and we can continue discussion privately.
Thanks,
Sami
Sami, I will send you an email. Thank you again.
Reblogged this on PV-Views and commented:
Nice Article
Thank you for reading 🙏
The next time I come to this blog I will be sure to make better points.
Microsoft Azure Active Directory Migration Services India
We have several hundred devices pending registration in Azure AD. Those are currently co-managed. We are moving to Azure AD and Intune only.
What would be the best way for fixing a large number of devices like this in the pending state since manually touching each one would be time consuming?
The odd thing is we have hundreds that are co-managed and registered properly. But still have a bunch that are not registering properly.
Thanks!