Exploring Hybrid Azure AD Join with a Provisioning Package

In testing a provisioning package deployment, I found out that you can apply the PPKG to a domain-joined device so that it effectively becomes Hybrid Azure AD Joined. Although I’m not exactly sure if the process is actually useful, it is certainly interesting, so I thought I’d write out this blog post. I’d also consider this not really supportable since provisioning packages for Azure Active Directory Joining are meant to be used during OOBE, not a domain joined device.

Let’s start by looking at the device itself, and running dsregcmd /status to verify that it is Domain Joined:

If we scroll further down, you can see that it fails the AD Connectivity Test, so it’s not completing the Hybrid Join process:

And in Azure AD we can verify that it is pending a Hybrid Join, but hasn’t completed it:

Great! So let’s create a provisioning package, using Windows Configuration Designer (which you can download from the Microsoft Store app):

Once that’s downloaded, we’ll create a new project:

The most important step will be going to Account Management, selecting Enroll in Azure AD, and getting a Bulk Token:

Once you have a bulk token, select Finish and then click Switch to advanced editor in the bottom left. We need to switch to the advanced editor to remove any extra settings other than the bulk token.

Here I’ll delete the DNSComputerName:

And then the HideOobe setting:

Once we only see Authority and BPRT under Azure, we’re ready to export the package:

Then we just need to copy the RunTime Provisioning Package (.ppkg) file in the exported directory to our device:

Once the PPKG is on the device, double click it to kick off the process:

Unfortunately PPKGs don’t really report any progress, but you can check under Settings > Accounts > Access work or school > Add or remove a provisioning package to see if it applied:

And we should also now see under Access work or school the ability to check Info and sync with Intune:

So what happens if we run dsregcmd /status again?

Exactly as we’d expect – it’s reporting as Hybrid Azure AD Joined! And we know that because according to the Docs, showing both AzureAdJoined and DomainJoined qualifies the device to be Hybrid Azure AD Joined:

But… if we check Azure AD, we see that the Hybrid Azure AD Join record is actually still pending – and there’s now a new record for the Azure AD Joined device:

If we look at the device in Intune it does show up, but with no primary users since we used the provisioning package:

So what gives? Michael Niehaus has written about Hybrid Azure AD Join a ton – and he describes the process more as Azure AD registering a Domain-joined device, rather than Azure AD joining it (great blog post here). Once of the key points he makes is that you can’t log in to a Hybrid AADJ device with your Azure AD credentials – because it needs to check in to the Domain Controller, because the device is really just domain joined.

If we try to log in with the Azure AD creds of a test user…

…we see that we can’t, because we don’t have line of sight to the domain controller (that’s why it was failing the AD Connectivity check earlier).

So it at least acts like it’s Hybrid Joined, but if Azure Active Directory isn’t reporting it as such, what is it really? Because we forced the client to finish the Hybrid Join via PPKG (instead of AAD Connect syncing it up), does Azure AD refuse to recognize it as Hybrid joined?

I don’t have the answers to those questions yet, so please comment your thoughts below! Until then, happy exploring! 🕵️‍♂️