Azure Hybrid AD joined windows 10 ( please help)

Question

Hi

We are a large organization 10K plus and have on-premise AD syncing to Azure with AAD Connect.
I read many articles online and needs some clarity on joining windows 10 Hybrid AD join computers.

Do I simply just configure Hybrid join computers in Azure AD connect and then setup the GPO as mentioned in this article?
I only want to test a group of machines on a certain OU. I was afraid if I enabled Auzre Hybrid join in Azure AD connect, all the 10K computers will become Azure Hybrid AD joined.

Answer 1

If you only want to test a small amount of devices, then you can use the controlled rollout by creating reg keys on the devices that you want to test. See https://learn.microsoft.com/en-us/azure/active-directory/devices/hybrid-azuread-join-control

Answer 2

Thank you. I think the goal is to eventually have all the windows 10 machines Azure Hybrid Joined. In a scenario if I want to target a specific OU with computers. What is the best method? How about the entire organization? Can you please share the process? Any user intervention required?

Another side question, if I configure Azure Hybrid AD joined in AAD, will that trigger all the machines to become Hybrid AD joined? or will I still need the GPO

Answer 3

@Virtual Tech , If we only want the devices in one OU to do Hybrid Azure AD join with managed domain , based on my test in my lab, we can consider to only sync the selected OU in your environment. Then configure Hybrid Azure AD join. It will only do Hybrid Azure AD join for the devices in that OU in my test. Here are the screenshot of the steps for the reference:


For your another question, If we configure Hybrid Azure AD join, it will do Hybrid Azure AD join to AAD. If these devices are also needed to be managed by Intune, then the GPO enrollment is needed.
https://learn.microsoft.com/en-us/mem/intune/fundamentals/what-is-intune

Here is a link about enrolling a Windows 10 device automatically using Group Policy for the reference:
https://learn.microsoft.com/en-us/windows/client-management/mdm/enroll-a-windows-10-device-automatically-using-group-policy

Hope it can help.

---

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 4

That post is going in many directions :) I will chime in hoping it will not lead to more confusion...

For the following message, let’s consider Windows 10 and higher and put aside Windows 7 (as it can also be Hybrid Azure AD Joined but the process and the results are quite different).

When a user signs into a domain joined Windows 10/Windows Server 2016 (and higher), the following scheduled task will start:

• \Microsoft\Windows\Workplace Join\Automatic-Device-Join

This will run the following command in the SYSTEM context (the context of the computer account):

• %SystemRoot%\System32\dsregcmd.exe

Then the machine will look into its registry to see if there is an Azure AD tenant it should register to. These are the two values it looks for:

• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD\TenantName
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD\TenantId

IF those values aren’t there, then it will query Active Directory to look for that info. It is called a Service Connection Point object (or SCP) located at this path:

• CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=<your domain>,DC=com

This object has a multi-value attribute named keywords that contains the azureADId and the azureADName.
If the registry isn’t set and the SCP not created. Then nothing happens. And the machine will try again later…
Now why is it doing that? Because it wants to exist in Azure AD. And it wants to exist in Azure AD for the same reason an on-prem machine wants to exist in AD DS on-prem: Single Sign-On. When a machine is Hybrid Azure AD Joined, if a user that exists in Azure AD signs into it, it will get an Azure AD PRT. The PRT is that give the user an SSO experience each time they want to access a service protected by Azure AD (like any of the Office 365 services). The Azure AD PRT is to Azure AD what the Kerberos TGT is to AD DS.

So, is that a problem that your machine wants to do that? Not really. It could be an issue if you have hundred of thousands of machines as you might hit some quota limits in Azure AD. But otherwise, the fact you have machine who want to be Hybrid Azure AD Joined and are Hybrid Azure AD Joined isn’t really a problem. It’s even an advantage if you expect to use Azure AD users in them and expect a SSO experience when accessing apps protected by AAD.

Now, if you are in a federated environment (which seems to be the case as you mentioned AD FS), the TenantName or the azureADName values can point to your federated domain name. As a result, the computer account will try to register in Azure AD by contacting AD FS and ask for a token to go to the Device Registration Service of Azure AD. If that works, then the machine is instantaneously Hybrid Azure AD joined. No need to do anything on Azure AD Connect. As a matter of fact, Azure AD Connect isn’t leverage at all in this process (well you can use it to set the CSP, but you don’t have to use a CSP and the recommended approach is to use the registry that you control through group policies: https://learn.microsoft.com/en-us/azure/active-directory/devices/hybrid-azuread-join-control).

BUT that implies that AD FS is configured correctly. Meaning that you have configured the right claim rules and enabled the right endpoints (see that section for the endpoint: https://learn.microsoft.com/en-us/azure/active-directory/devices/howto-hybrid-azure-ad-join#federated-domains and use that tool to generate the right claim rules: https://adfshelp.microsoft.com/AadTrustClaims/ClaimsGenerator).

So in a nutshell, to do Hybrid Azure AD Joined on a federated environment, you don’t need to add the computer accounts in the scope of the sync. It will work regardless. BUT you want to put the computer in scope of the sync to make sure that if you deleted a computer account on-prem, it will sync that deletion in Azure AD and delete the device object in Azure AD.

If AD FS is not configured properly, or you are no using a federated domain, then the machine will still try to do Hybrid Azure AD Join but the process is very different. The machine account will write an attribute into its own object in AD DS on-prem (the userCertificate attribute, I know it is odd because it is a computer, but the attribute is called userCertificate attribute). And as long as the computer account is in the scope of synchronization of Azure AD Connect, the object is going to be synchronized to Azure AD. So it is not instantaneous like with AD FS. To be fully Hybrid Azure AD Joined, the machine will have to wait until the Azure AD Connect synch cycle finishes. In that situation, if the computer account is not in the scope of sync, it will not work at all. So, make sure that you have updated your Azure AD Connect sync server to look for the userCertificate attribute (very old version of Azure AD Connect were not) and that you include the OU where your computers are in the scope of the sync.