Troubleshooting Hybrid AD Join

Hybrid AD Join is often used for Windows devices that are joined to an Active Directory domain, and that also need to be joined to Azure AD to provide a level of trust in the device and its management.

First of all familiarise yourself with these articles

• https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso-quick-start
• https://docs.microsoft.com/en-us/azure/active-directory/devices/hybrid-azuread-join-managed-domains

At a high level they say that getting the environment ready for Hybrid AD Join requires a number of steps:

1. Ensure the OUs that the devices are in are in scope for Azure AD Connect (AADC) to sync them to Office 365
2. Ensure that in AADC you have run the configuration wizard for Configure Device Options to create the device registration service (DRS) service connection point (SCP) in AD
3. If you need to Hybrid Join Windows devices older than Windows 10/Windows Server 2016, then you must also configure Seamless SSO in AADC
4. On pre-Windows 10/Windows Server 2016 devices you have to install the Microsoft Workplace Join software
5. Internet Access must be available for the device in the SYSTEM context. In particular the following URLs need to be accessible
   • https://enterpriseregistration.windows.net
   • https://login.microsoftonline.com
   • https://device.login.microsoftonline.com
   • https://autologin.microsoftazuread-sso.com
6. SSL Inspection must be turned off for
   • https://device.login.microsoftonline.com
7. The following URLs need to be in the Local Intranet zone so that the appropriate default zone settings are applied, including automatic logon using username and password
   • https://device.login.microsoftonline.com
   • https://autologin.microsoftazuread-sso.com
8. The Local Intranet Zone setting ‘Allow updates to status bar via script’ must be enabled

Now we are ready to Hybrid Join a device. The Hybrid AD Join has the following high-level steps, all of them are run as the result of a Workplace Join scheduled task that runs on user login or unlock of the device (within a few mins)

1. The device finds the SCP in AD and generates a Self Signed Certificate. The public key for this certificate is put into the device’s Computer object in AD as a userCertificate attribute value
2. The device contacts Azure AD looking for the Computer object’s ObjectGUID as the deviceid in Azure AD. It signs this request using the private key of the cert from step 1
3. Azure AD checks if it has a device with that deviceid and if so then it verifies the signature using the userCertificate values that were synced from on-premises with AADC
4. If Azure AD validates the request then the device is Hybrid AD Joined, if not then the device is given an HTTP 400 response with deviceid not found

Ok, that’s all well and good when everything works… but sometimes it doesn’t… The key is to understand the process and follow it through.

1. Does the Computer object in AD have the userCertificate attribute populated? Note that for pre-Windows 10/Windows Server 2016 each user logon will generate their own userCertificate entry
   
   If not then the issue is that the device either can’t see the Domain Controller or it isn’t properly joined to the domain. This can be checked using nltest /sc_verify:<domainFQDN>
   
   If this returns ok then run the following and check the userCertificate attribute
   * Windows 10/Windows Server 2016: dsregcmd /join /debug
   * Earlier OS: “%PROGRAMFILES%/Microsoft Workplace Join/AutoWorkplaceJoin.exe” /join
   
2. Does the device appear in Azure AD?
   
   If the device has a userCertificate but does not appear in Azure AD, then check that the OU that the computer object is in is in scope for AADC. If not then either move the computer object, or add the OU to AADC.
   If the OU is in scope for AADC, then run a delta sync and check that it is in the metaverse in AADC
   
3. Does the device show in Azure AD as pending?
   
   If the device is in Azure AD and shows as pending, then run a new Hybrid AD Join:
   * Windows 10/Windows Server 2016: dsregcmd /join /debug
   * Earlier OS: “%PROGRAMFILES%/Microsoft Workplace Join/AutoWorkplaceJoin.exe” /join
   
4. Does the device show in Azure AD as Hybrid AD Joined?
   
   If the device shows as Hybrid AD Joined in AD then confirm if the device itself also thinks it is Hybrid AD Joined
   * Windows 10/Windows Server 2016: dsregcmd /status /debug
   * Earlier OS: “%PROGRAMFILES%/Microsoft Workplace Join/AutoWorkplaceJoin.exe” /status
   
   If the device doesn’t think it is joined but Azure AD does then open regedit.exe and delete the entire subtree HKLM\Software\Microsoft\Enrollments (plural, not singular). You will get some warnings/errors, but it will delete what it needs to. Reboot the device and after a few mins check the Hybrid AD Join status again
   
5. Does the user show it has an AzureADPRT?
   
   If dsregcmd doesn’t show AzureADPRT=YES when running in a regular user’s context, yet it does appear to be fully Hybrid AD joined both on the device and on Azure AD, then simply lock and unlock the device and wait a couple of minutes. The PRT should come down to the machine, as long as
   • the user logs in with their Azure UPN to the device
   • or the UPN in Active Directory matches the Azure UPN and the device has line of sight to the DC to fetch an cache the UPN to the device

We hope this helps people with getting device Hybrid AD Joined, which can then be part of a Conditional Access Policy to provide a level of trust in the device. Not as rigid as Device Compliance, but then also not as hard to get to on an existing estate with mixed hardware.