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:
Expand out the resulting tree to find the “Device Registration Configuration” container inside the “Services” container.
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:
You can double-click on that item to see the details:
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:
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:
You can also see similar events in the “User Device Registration” event log:
Eventually, you should see an event that indicates the whole process succeeded:
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:
And a summary of those labeled, numbered steps:
- The device queries AD to find the SCP, in order to obtain AAD tenant details.
- The AAD tenant details are returned.
- The device creates a self-signed certificate and updates the userCertificate property on its own computer object with that info.
- AAD Connect after the userCertificate has been populated, up to 30 minutes later) syncs the AD computer object into Azure AD.
- The device (repeatedly) tries to register with AAD.
- 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.
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