Windows 10

Digging into Hybrid Azure AD Join

By on • ( 49 Comments )

I’m sure most of you are aware that Windows Autopilot supports a user-driven Hybrid Azure AD Join scenario.  That’s not what I’m talking about here.  I want to talk about Hybrid Azure AD Join itself, which seems to be surprisingly misunderstood by a lot of IT pros.  And there’s probably good reason for that.  Let’s start off with the official definition from the Azure AD documentation:

Hybrid Azure AD Join : Joined to on-premises AD and Azure AD requiring organizational account to sign in to the device

What exactly does that mean?  Well, it means the device behaves exactly like any other Active Directory-joined computer:  You need to sign in using an Active Directory account.  User credentials are validated against an Active Directory domain controller.  User and computer group policy objects (read from the domain controller) are applied automatically.  And that all makes sense, because the device *is* an Active Directory-joined computer.

But after that Active Directory join process is completed, additional steps are taken in the background, asynchronously, to get the device registered to Azure AD as well.  (The documentation and tools such as DSREGCMD show this as “Azure AD-joined” but I don’t really agree with that – if the device were truly Azure AD-joined, you’d be able to sign in with Azure AD credentials.  And that’s definitely not possible, you always need to sign in with Active Directory credentials, validated against a domain controller.  But that’s splitting hairs.)  Once the device is registered with Azure AD, then subsequent user sign-ins will get an additional benefit: Not only will they get a Kerberos ticket from Active Directory (used to authenticate with Active Directory-protected resources), they’ll also get an Azure AD user token that can be used to access Azure AD-protected resources like Intune, Teams, Office 365, etc.

Let’s also talk about co-management while we’re at it, mainly to clear-up what it is or isn’t.  Too many people use “co-management” and “hybrid” as interchangeable terms, but they aren’t.  You can have a co-managed device that isn’t Hybrid Azure AD joined, and you can have a Hybrid Azure AD joined device that isn’t co-managed.  But if you have an Active Directory-joined device that you want to co-manage, the device needs to be Hybrid Azure AD joined for that to work.  Got that?  Let me define it explicitly:

Co-management : A device that is managed by both ConfigMgr and Intune working together, cooperatively.  A co-managed device can be joined to Active Directory (requiring Hybrid Azure AD Join) or to Azure Active Directory.

Hybrid Azure AD joined : A device that is joined to Active Directory and also registered with Azure AD.

One more item to note:  A ConfigMgr Cloud Management Gateway (CMG) is not required for Hybrid Azure AD Join or co-management.  But it’s always a good idea, even if you aren’t doing co-management or Hybrid Azure AD join.  The CMG is needed to enable any ConfigMgr-managed device to communicate with ConfigMgr (e.g. to determine what apps, patches, or task sequences need to be processed) even when it isn’t on the corporate network.

To make this abundantly clear:

Co-management != Hybrid Azure AD joined != CMG

Let’s look at some examples:

  • A device is joined to Active Directory and managed by ConfigMgr.  If you want to co-manage the device, you must get it into a Hybrid Azure AD joined state.  Once that happens, the device will auto-enroll in Intune using the Azure AD auto-enrollment configuration.
  • A device is joined to Azure AD and managed by Intune.  If you want to co-manage the device, you should deploy the ConfigMgr agent bootstrapper (ccmsetup.msi) via Intune.
  • A device is joined to Active Directory and you want it to be managed by Intune, and you aren’t using ConfigMgr.  As with the first example, you must get the device into a Hybrid Azure AD joined state, so that it will then auto-enroll in Intune using the Azure AD auto-enrollment configuration.

Notice that I didn’t mention Windows Autopilot in any of these scenarios, because it doesn’t directly impact any of those scenarios.  But there can be some indirect impacts.  We’ll talk about those later.  First, we need to dive in deeper to how Hybrid Azure AD join works.

One strange question that I have been asked multiple times in the past few weeks:  Is there any risk that a user signing onto a device after completing the Hybrid Azure AD join process will get a new user profile?  This goes back to misunderstandings about what Hybrid Azure AD join is:  It’s still an AD-joined device, users still sign on with their AD credentials validated against a domain controller.  So no, there is zero risk that this will impact their existing user profile.  In fact, the overall Hybrid Azure AD Join process is fairly low-risk, because it just adds to what the device can do, it doesn’t take anything away.  So if you’ve disabled it via GPO out of fear, you should reconsider that decision.

Hybrid Azure AD Join without ADFS

The Azure AD team recommends organizations move away from using federation (e.g. ADFS or third-party federation providers) and instead use Password Hash or Passthrough Authentication.  Given that (and the overall pain of setting up ADFS servers), that’s the configuration I used and that’s what we’ll talk about first.  A key piece of this setup is AAD Connect.  That’s described in the Hybrid Azure AD join configuration tutorial documentation.  The first thing this talks about is a service connection point (SCP), and it mentions that AAD Connect will set one up for you. 

But what is an SCP?  It’s the first piece in the puzzle.  Let’s say you have an Active Directory-joined computer that needs to be Hybrid Azure AD Joined.  How does that computer know what Azure AD tenant it needs to register with?  That’s where the SCP comes in.  The computer needs to read the SCP object in Active Directory, using LDAP, so that it can find the details of the Azure AD tenant that it needs.

So where is this SCP in Active Directory?  Let’s look.  First, run ADSIEDIT.MSC and then right-click on the “ADSI Edit” root node and choose “Connect to…”.  Change to the “Configuration” naming context:

image

Expand out the resulting tree to find the “Device Registration Configuration” container inside the “Services” container.

image

That GUID (62a0ff2e-97b9-4513-943f-0d221bd30080) is what the Windows 10 device knows to search for.  But there are no items in the container, so where is the configuration?  There are properties on the container.  Right-click on the CN=62a0… container and choose “Properties.”  Scroll down to the “keywords” attribute to see the Azure AD tenant info:

image

You can double-click on that item to see the details:

image

Nothing special, just the tenant ID (GUID) and tenant name for the Azure AD tenant linked to my Active Directory domain.  Once the Windows 10 device sees that, it will start trying to complete the device registration process.  But that device registration process won’t complete until the computer’s Active Directory object is synchronized into Azure AD by AAD Connect.  This sounds like a simple enough process:  After the computer is joined to AD, sync the computer object into Azure AD.  As long as the OU containing that computer object is in the scope for AAD Connect, that should “just happen.”  But there are a couple of complications here.

First, AAD Connect only synchronizes every 30 minutes.  If you’re unlucky, that introduces a 30-minute delay in the whole process.  On average, it will add 15 minutes.  Some customers have tried to speed this along by setting up a scheduled task to force the sync to run more frequently, e.g. using a PowerShell script that looks something like this:

image

But there is another complication:  AAD Connect won’t sync the object until a particular attribute on the computer object has been populated.  This attribute, named userCertificate, needs to be updated by the computer itself with a self-signed certificate that the computer generates itself.  Once the computer object is updated in AD, then the next AAD Connect sync will push the object into Azure AD.

During this whole time (starting when the computer is able to read the SCP settings), the device has been polling Azure AD to try to register itself.  Each time that happens unsuccessfully (because the device hasn’t synced from AD to Azure AD, e.g. because the userCertificate property hasn’t been updated yet or because AAD Connect hasn’t done a sync after that), you’ll see an entry in the device’s AAD event log:

image

You can also see similar events in the “User Device Registration” event log:

image

Eventually, you should see an event that indicates the whole process succeeded:

image

After this point, any AD user that signs into the device will get an Azure AD user token (a primary refresh token, or PRT) that can be used to authenticate with Azure AD-based services.  If the user signed in before the registration completed, then they either need to sign out and back in again, or they need to lock and unlock the device – either of those will ensure the user gets a token.

If anything were to go wrong during this process (e.g. some of the required endpoints aren’t accessible), you can check out the published troubleshooting documentation. 

For those of you who are more visually-oriented, here’s the overall flow:

image

And a summary of those labeled, numbered steps:

  1. The device queries AD to find the SCP, in order to obtain AAD tenant details.
  2. The AAD tenant details are returned.
  3. The device creates a self-signed certificate and updates the userCertificate property on its own computer object with that info.
  4. AAD Connect after the userCertificate has been populated, up to 30 minutes later) syncs the AD computer object into Azure AD.
  5. The device (repeatedly) tries to register with AAD.
  6. When AAD can find a matching device (synced by AAD Connect), the registration will succeed and AAD will provide a device certificate back to the device.

Hybrid Azure AD Join with ADFS

If you are using ADFS, the process will behave a little differently.  The device will still get the SCP information it needs, but then it can talk directly to ADFS.  When it does this, there is no need for the userCertificate property to be updated, and no need for AAD Connect to synchronize the object from AD to AAD right away.  Instead, ADFS will directly create the device object representing the AD device in AAD.  That enables the overall device registration process to complete quickly, returning a device certificate back to the device.  Typically this happens well before the user could ever attempt to sign into the device, so the initial user sign-in should always get an Azure AD user token.

There are some specific requirements for Hybrid Azure AD Join with ADFS, as described in the documentation.  For most ADFS customers, you need to make sure that the necessary endpoints (especially for WS-Trust) are enabled and accessible from the internet.

But just because ADFS works better for Hybrid Azure AD Join, that doesn’t mean you should implement ADFS just for this.  The Azure AD team is looking at ways to improve the process for non-ADFS customers.

But what about Windows Autopilot?

I said this wasn’t directly about Windows Autopilot, but it certainly has implications for those that are performing Hybrid Azure AD Join scenarios using Windows Autopilot (which you should understand from above really means “joining the device to AD, and then later in the background completing the Hybrid Azure AD Join device registration process so the user can get an AAD user token”).  Let’s look at a few of those, assuming in all of these cases that ADFS is not being used.

User-driven Hybrid Azure AD Join on the corporate network

In the typical Windows Autopilot user-driven Hybrid Azure AD Join scenario with the device on the corporate network, the device will quickly discover the SCP, generate a self-signed certificate, and update its userCertificate property on the AD computer object.  After that, it’s the luck of the timing – will it take 1 minute or 30 minutes for AAD Connect to sync the device from AD to AAD.  If the user signs in before that has happened, they won’t get an AAD user token, and without that, they won’t be able to sync with Intune.  That would cause an ESP timeout, hence why we say to disable user ESP if you are running into this.

But assume a slightly different variation on that:  Still on the corporate network, but with a device ESP process that takes at least 30 minutes (e.g. installing 20 apps).  In that case, AAD Connect would likely finish syncing the device from AD to AAD, and the device registration process could finish before the user signs on.  So the process would then be smooth.

White glove Hybrid Azure AD Join on the corporate network

If you pre-provision the device using a Windows Autopilot white glove process while on the corporate network, the device should have time to find the SCP and update its userCertificate so that AAD Connect can sync the device to AAD.  Assuming that completes while the apps and policies are being applied, that makes it very likely that the device registration process will complete before the user tries to sign in, so everything works out well here.

White glove Hybrid Azure AD Join off the corporate network

Some people don’t know that this scenario is supported, but is certainly is.  The technician process can be done completely over the internet, with the offline domain join blob provided by Intune to complete the join process.  But when the user gets the device, they will need connectivity to a domain controller.  That could be direct connectivity from being on the corporate network, or via VPN if you deployed a VPN connection or client to the device during the technician phase.

But since the device is off the corporate network, it won’t immediately be able to talk to AD to find the SCP or to update the userCertificate property.  That means the device won’t sync from AD to AAD until after the user gets the device and makes a VPN connection.  So it almost guarantees that the first user sign-on won’t result in an AAD user token (so user ESP would need to be turned off to keep it from timing out).

That is unless you have some sort of “auto-connecting” VPN that make a connection to the corporate network even during the white glove technician phase.  In that case, it’s just like being on the corporate network.

User-driven Hybrid Azure AD Join off the corporate network

This is a scenario we are still working on.  It’s currently in private preview and should be in public preview soon.  This would work similarly to the white glove process described in the previous section:  As long as you deploy a VPN configuration or client to the device during device ESP so that the device automatically connects to the corporate network or so that the user can manually initiate a VPN connection before trying to sign on, the process will work and the user can sign on.

From a Hybrid Azure AD join perspective, an auto-connecting VPN would again behave like a device on the corporate network: the SCP is quickly located, the userCertificate property is updated, and then there’s a wait for AAD Connect to sync the device.  If that happens before the user signs in, great.

But if there is a manually-connecting VPN profile that the user initiates before signing in, the SCP won’t be found and the userCertificate won’t be updated until after the user starts the VPN connection, so there’s no chance the user will get an AAD user token on that first sign-in.  That’s not necessarily fatal, but it certainly has an impact (beyond user ESP), e.g. with conditional access compliance or any user-targeted Intune policies.

Summary

This is all so much easier with Azure AD join, which is designed to work with a simple internet connection.  Staying with Active Directory is going to involve some complexity, especially for devices that are always off the corporate network.  The Hybrid Azure AD Join process, combined with an automatically-connecting VPN client, can smooth out these complexities.  A manually-connecting VPN client works too, but has some complications as I described above.

Categories: Windows 10

49 replies »

  1. I would love to be involved with the preview of User-driven Hybrid Azure AD Join off the corporate network – we are being asked to implement this as a recovery measure for our government client – I’ve read as long as your VPN can connect before log in ( which we can) this should work. We also need to maintain our HostNames as we deploy our software via ad groups.

    Liked by 1 person

  2. A great article 👍, I’ve been trying to explain the process to my colleagues but it sometimes doesn’t sync in as there is so much too it. I will definately be pointing them at this article going forward.

    Our organisation is struggling with the ADFS registration however and it always seems to fall back to the AAD connect. Causing what can be long delays to the provisioning process.

    Liked by 1 person

  4. We have been flighted for the SkipDomainConnectivity check for around a month now, and have been using it alongside Cisco VPN client, it works pretty well, although we do have a bug currently that keeps switching the value back to 0 when a profile change is made. MS have manually set it for us currently so we leave it alone until the fix is in place. Hopefully someday we’ll have an always on VPN but Cisco SBL module is working pretty well for us.

    Like

  5. Best article ever , Have always made me confused aswell.
    Dropped you a note too let me know as well if you need any help in testing.

    Like

  6. Hi Mike. I’m (unfortunately) relatively new to Azure AD and Hybrid Join. Is it possible for us to deploy our standard build initially using Azure AD Join and then allow our regional offices to hybrid join them later?

    The idea here being that we expect most users will survive just fine on a purely Azure AD Joined device, but in some of our less mature regional offices they will need to keep legacy AD support. The idea being access to SMB servers using a seamless token (e.g. Kerberos token) so the users are not constantly prompted for a credential.

    Really though I see some conflicting problems here, in that we really want to push hard for going passwordless with Windows Hello for Business, but it feels like Active Directory is a ball and chain that is going to drag us back into a legacy world.

    Like

    • No, an Azure AD joined device cannot be converted to an AD-joined device. The recommended path for doing that is a full OS reset. You can access SMB shares (any pretty much any other AD-protected resource) even from an AAD-joined device, so it’s worth some effort to validate that all users would be fine using only Azure AD join.

      Like

      • Thanks Michael, I got confirmation from the business that pure Azure AD Join was the preference.

        Do you know if there are any decent articles on SMB shares access (seamlessly without having cred requests popping all the time), as I can only really find a decent article on “Cloud Print” for that topic.

        Like

      • I cover that in one of my posts about “trying out Azure AD.” The main requirement: Make sure you have Kerberos set up properly (you need a Kerberos cert on each DC) and that you have properly set up a CRL for your cert infrastructure (so the client can verify the cert provided by the server). If using Hello for Business, there are some additional requirements.

        Like

  8. We are very close to going prod with AP + Hybrid Join. Didn’t see mention of an duplicate AAD device object, which we are seeing. Is this unexpected?

    One thing we are running into is multiple Azure AD device objects. As mentioned in your article “Group tags with spaces?” the initial first AP run works as expected. The AP Azure AD object (named with serial) is there and updated with the new random device name and Hybrid AAD object also created/used etc. Ok odd would assume the hybrid object would eventually be tied to the intune object, but this doesn’t appear to be the case.

    Wonkyness starts to occur if we do a default wipe.

    It properly goes through the user-driven hybrid join AP, new Hybrid object is created with the new random name, also another AAD object is created with same new random name. Intune/AP object successfully updates to the new name but the intune associated AAD object doesn’t get updated and continues to use the original AAD object which doesn’t appear to be updated after that very first AP. Also notice the intune associated object doesn’t ever use hybrid object only AAD?

    Like

  10. Michael,

    We use ADFS in our environment, from what I’m reading here it seems as though as soon as the AAD connect wizard is run (and all pre-reqs are met) all devices on the domain/forest will start to register themselves in AAD (via the ADFS server) with AAD Connect acting merely as backup source for device registration.

    I want to roll out Hybrid AAD join very gradually,probably at an OU level is this possible?

    Cheers
    C

    Like

  11. Just wondering, is there any more detail about exactly what’s happening during step 3 of this process, “The device creates a self-signed certificate and updates the userCertificate property on its own computer object with that info”?

    Unless there’s something particularly unusual going on, this seems like something that we could achieve at my workplace without having line-of-sight from the client to our on-premise AD domain controllers (which is unfortunately the position we are in due to COVID-19) using, say, a PowerShell script on the client end to capture the certificate, and then another one on the server end to insert this into the on-premise AD.

    Like

      • I mean, I would guess that it will be in the Local Machine certificate store under Personal, like where other machine certificates would live, I’m just wondering if we can replicate that process using, say, New-SelfSignedCertificate in PowerShell, then extract that certificate and inject it into userCertificate on the computer account in our on premise AD. Though, it does seem like we may be able to get a VPN soon, in which case it will be a moot point.

        Like

  12. Michael, thanks for putting these resources together. I’m learning more from your blog than the MS Docs on this topic. We’ve got hybrid Azure AD join deployed in production. Quick question. Today, my laptop’s motherboard was replaced, resetting the TPM info. So now the system can’t authenticate to Azure because “The verification of the target computer’s SID signature failed.” That’s expected. Can I reset the Azure hybrid join process without taking the machine out of our AADConnect sync scope? I’ve found plenty of info on troubleshooting various failures that can happen, but I haven’t found info on this type of situation, which I’m sure others have run into as well.

    Like

  13. Hi Michael, Thank You for the extensive detail around Hybrid Azure AD join. We’re working to achieve the scenario ‘User-driven Hybrid Azure AD Join off the corporate network’ and we’re stuck at the point where the remote client computer looks for On-Prem Domain Controller. As you mentioned this scenario is still in public preview can we receive any useful info or be included as part of the preview to be able to determine the recommended way further? Thank You.

    Liked by 1 person

  14. Regarding the SCP, if that is in place in your domain, this will cause any Win10 / Server 2016 and higher device to hybrid join, correct? Which people may not want — right? If you want a targeted rollout of hybrid join, say, just to your productivity Win10 devices, you can use group policy to deploy the tenant ID and name, and leave servers and process devices alone. We are using GPO to target Win10 end-user devices only. Perhaps we will do servers at some point in the future…..if there is a need.

    Like

  15. Hello
    This is a great article! I have a question: assumed you do white glove hybrid join on the corporate network, does the odjb still affect or does the device recognize its on corporate network and detects the scp as soon as Intune domain join configuration reaches the device? I did this on corporate network with autopilot and the device is working successfully, so I assume it’s not offline domain join 😉 Would be very appreciated due I’m planing to do a visual concept on Microsoft Tech Community to get a better understanding.

    Like

  16. Hi Michael, thanks for the post. We are actually testing this preview, and we have the whole process tested except the last part, when we do login with domain credentials, then the device starts AAD registration, this process fails, it´s an federated environment, and from vpn there are conectivity with DCs but not with the internal IP of the ADFS, only with the external IP, it´s necessary have connectivity with internal address of ADFS to obtain the authentication token?

    Like

    • I’m not sure on that as I don’t use ADFS. There are specific WS-Trust endpoint requirements to make federated device registration work though, covered in the Hybrid AADJ docs.

      Like

  17. Hi Michael. We are using ADFS but we also have enabled PHS as we intend to convert the domains from federated to managed. In current state with federation and PHS enabled, can I configure AAD Connect for hybrid join and select Azure AD for authentication instead of ADFS option?

    Also, once we enable SCP, would the device registration apply only to the devices that are part of sync scope of AAD Connect ot it will apply to all devices regardless if the OU is outside the sync scope?

    Like

  18. Hi Michael, I am trying to get my devices to auto-enroll with Intune after achieving hybrid status. In your example scenario’s you mention the “Azure AD auto-enrollment configuration”. Can you explain what that is? Are you refering to this method: https://docs.microsoft.com/en-us/windows/client-management/mdm/enroll-a-windows-10-device-automatically-using-group-policy#configure-the-auto-enrollment-for-a-group-of-devices

    I have done all the Azure side configs but seems strange that a GPO is necessary. Maybe that is my next step though.

    Also we had found most all of our devices had already populated in Azure as Azure AD Registered, and they would pop up as duplicates ending in a “$” for Hybrid Join with a pending status, and they wouldn’t finish the hybrid join until the registered device was removed.

    Thanks!

    Like

  19. Trying to get Hybrid AAD Join to work.. On a VM it works as it should, but not on a physical computer.

    I extract the hash, add a group tag, and import the csv to Intune and see that my profiles are “Assigned”. Then I boot up the physical computer, get to the ADFS login page, and then it sits at the spinning dots for ~45 minutes before giving me a “Something went wrong, 80004005” error.
    Diving into the logs I can see that the ODJ connector gets the domain join blob after just a couple of minutes from the start of the computer, and there’s a computer object created in the local AD. I can see the computer object in AAD and in Intune as well.
    Meanwhile, on the physical computers event log, it says “Offline Domain Join: Attempting to get the DC Name. Result:(The specified domain either does not exist or could be contacted)” every second…
    The funny thing is that if I then reboot the computer, I get to select keyboard again, log in to ADFS again, and then everything rolls on smoothly from there…
    The physical computer is not on the same network as the DC, but can ping the DC, can access internet, can do name resolution for “dc01.mydomain.com” without issues.

    Like

    • Strange. If the ODJ blob is generated and successfully sent back to Intune, all that’s left is for the client to do another MDM sync to pull down the blob and apply it. What version of Windows 10 and what cumulative update is applied?

      Like