Autopilot Hybrid Entra Join via Entra Kerberos (Preview): The Fix We've Been Waiting For? -- iphase.dk

● ... views

Let's Get One Thing Straight: I Hate Hybrid Autopilot

If you've followed my work for a while, you know my stance on device management: Cloud Native devices are far preferred for speed, reliability, and sanity. Hybrid Autopilot has historically been a fragile, timeout-prone mess. Waiting for Entra Connect to sync the device object up to the cloud before the deployment can continue has cost IT admins countless hours of troubleshooting, coffee, and the occasional loss of faith in humanity.

But I have to admit, Microsoft just solved a lot of those problems with the new Autopilot Hybrid Entra Join via Entra Kerberos (Public Preview).

And despite the Autopilot-heavy headline here, this is not just an Autopilot story. If you deal with manual domain join, imaging, or non-persistent VDI, this feature matters there too. Autopilot is simply where the old pain has been loudest.

The important nuance is this: Autopilot Hybrid Join is really two operations. First, the device has to get domain joined. Second, it has to register in Entra ID as a hybrid-joined device. Entra Kerberos only fixes the second part, but that second part is the one that has caused the infamous 30+ minute wait and a lot of the misery.

So no, this does not remove the Offline Domain Join connector from Autopilot. The Intune Connector for Active Directory is still needed to create the computer account and hand the device its ODJ blob during OOBE. What Entra Kerberos removes is the painful wait for Entra Connect to sync that device object before registration completes. Once the device is domain joined and can talk to a Windows Server 2025 DC, it gets a Kerberos TGT, exchanges that for a JWT with Entra ID, and registers directly.

And this is where things get really interesting. For a lot of organizations, the old Entra Connect Sync server has been kept alive partly because Hybrid device registration depended on that device sync step. If that dependency goes away, then a lot of companies suddenly have a much more realistic path toward using Entra Cloud Sync instead. That is a much nicer sentence to say out loud than "please keep the old sync box alive because one weird device workflow still needs it."

Even better, this integrates beautifully with Windows Hello for Business Cloud Kerberos Trust — which I highly recommend because I absolutely love passwordless.

While I still advocate for going Cloud Native wherever possible, if you have legacy on-prem requirements that force you into Hybrid Join, this new Kerberos flow is a massive upgrade. Let's dive into how to set it up.

Last reviewed: April 2026 · Based on Microsoft Learn docs published 2026-02-17 Feature status: Public Preview Scope: This guide covers the path without KDC Proxy. If you previously deployed a KDC Proxy GPO, simply ensure it includes the KERBEROS.MICROSOFTONLINE.COM mapping.

What This Gives You

Before we hit the checklist, let's separate the moving parts properly.

Hybrid Autopilot is two different jobs

Domain Join The device needs a computer object in AD and must join the domain. During Autopilot OOBE, that still means the Intune Connector for Active Directory creates the computer object and generates the Offline Domain Join blob.
Entra Registration After the device is domain joined, it still needs to become a Hybrid Entra Joined device in Entra ID. In the old flow, that meant writing certificate data to AD and then waiting for Entra Connect to sync the computer object. In the new flow, the device can register directly by using Entra Kerberos.

Key differences from traditional Autopilot Hybrid Join:

Traditional Autopilot Hybrid Join	Entra Kerberos-enhanced Autopilot Hybrid Join
Uses Intune Connector for AD to perform Offline Domain Join during OOBE	Still uses Intune Connector for AD for the domain join step
After domain join, waits for Entra Connect device sync (often 30+ min) before registration completes	After domain join, registers directly with Entra ID via Kerberos. No device sync wait
Works with any DC version	Requires at least one Windows Server 2025 DC per domain
Works with any Windows 10/11 build	Requires Windows 11 build 26100.6584+ (24H2)
Optionally uses AD FS in some legacy designs	No AD FS required for the registration flow

If you're not using Autopilot at all, this still matters a lot. The old sync dependency was never just an Autopilot problem. Autopilot simply made the pain impossible to ignore because the user was stuck staring at the Enrollment Status Page while life choices were being reconsidered.

In a traditional manual domain join or imaging scenario, the flow has still been annoyingly dependent on directory sync:

The device joins AD and gets its computer object.
A scheduled task discovers the SCP and finds the Entra tenant.
The device generates a self-signed certificate and writes it to its own userCertificate attribute in AD.
Then everyone waits for Entra Connect to sync that computer object into Entra ID.
Only after that does the device finish hybrid registration.

So the difference was never whether there was a sync wait. The difference was simply whether the user was forced to watch it happen in real time.

That has had very real consequences outside Autopilot too:

Users could domain join a device and still get blocked by Conditional Access policies requiring a hybrid-joined device until sync completed.
Entra Connect delays or outages could leave devices sitting in a pending state for far too long.
Non-persistent VDI scenarios were especially ugly, because the machine could be destroyed before the sync ever happened.
Entra Cloud Sync customers did not get the same hybrid join path, because device object synchronization was the missing piece.

With Entra Kerberos, the domain join can still happen however it normally happens, whether that is manual join, imaging, VDI provisioning, or Autopilot. The improvement is that the registration no longer depends on waiting for device sync. That is the real win, and it applies much more broadly than just Autopilot.

The sleeper benefit: an exit ramp from Entra Connect Sync

This is the part I think a lot of people will miss on first read, probably because their brain is still recovering from years of Hybrid Join diagrams.

For years, some environments have had to keep Entra Connect Sync around not because they loved it, but because Hybrid device registration needed that device object synchronization step. And I don't know about you, but "+1 legacy sync server" has never appeared on my list of favorite architecture decisions.

With Entra Kerberos handling the registration directly, that specific dependency starts to disappear. If the main thing keeping you on Entra Connect Sync was device sync for Hybrid Join, then this feature may be your gateway drug to Entra Cloud Sync.

That matters because Entra Cloud Sync is agent-based, simpler to operate, and generally a lot less dramatic than the old full-fat sync server. Fewer moving parts, less server baggage, less of that "please nobody touch the sync engine on Friday" energy, and fewer opportunities for one sad Windows Server to become the most emotionally fragile part of your identity stack.

To be clear, you still need user sync for hybrid identity scenarios. This feature does not remove that requirement. But it does remove the old requirement to sync the device object just to get the registration done. For many companies, that changes the design conversation completely.

So the bigger strategic takeaway here is not just "Hybrid Autopilot got less awful." It is also this: some organizations may finally be able to retire Entra Connect Sync and move to Entra Cloud Sync, assuming their remaining sync requirements are supported there. That is a pretty big deal.

Prerequisites at a Glance

Requirement	Detail
Windows Server 2025 DC	Build 26100.6905 or later, at least one per AD domain
Client OS	Windows 11 build 26100.6584 or later (24H2 + Sept 2025 CU or newer)
Network	Client must have unimpeded line-of-sight to the WS2025 DC during join
AD roles	Domain Admins + Enterprise Admins (for Trusted Domain Object)
Entra roles	Hybrid Identity Administrator (for TDO), Application Administrator (for DRS SPN)
Licensing	No additional license for this feature. Intune + Entra P1 still apply for Autopilot as usual
Entra Connect / Cloud Sync	Still needed for user sync. Device sync is no longer required for the registration step, which may open the door to Entra Cloud Sync for some environments
SCP	Service Connection Point must exist in AD

Step-by-Step Setup Guide

Step 1: Create the Microsoft Entra Kerberos Trusted Domain Object

Important nuance if you already have Windows Hello for Business Cloud Kerberos Trust: You are often already configured, but do not blindly skip this step. Run the verification command and confirm CloudTrustDisplay is populated. If that field is empty, run the TDO setup again.

This step creates an inbound trust from Entra ID into your on-prem AD, setting up a krbtgt_AzureAD service account. In other words, this is where the magic starts, or at least where the paperwork for the magic starts.

1a. Install the PowerShell module

Run this on a domain-joined machine in an elevated PowerShell. A domain controller is the obvious choice, but in the field I have personally hit issues doing this directly on a DC in some environments, most likely because of security hardening. In those cases I have had better luck running it from the dedicated Entra Connect Sync server instead. A properly managed Privileged Access Workstation (PAW) may also be a perfectly sensible place to run it from:

# Enable TLS 1.2
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

# Install the module
Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

1b. Check current Kerberos settings & Create the TDO

$domain = "yourdomain.com"
$cloudUserName = "[email protected]"
$domainCred = Get-Credential

# Check existing setup
Get-AzureADKerberosServer -Domain $domain -DomainCredential $domainCred -UserPrincipalName $cloudUserName

# If empty, create the Trusted Domain Object
Set-AzureADKerberosServer -Domain $domain `
  -UserPrincipalName $cloudUserName `
  -DomainCredential $domainCred `
  -SetupCloudTrust

(Note for Multi-domain forests: Run on the root domain first with -SetupCloudTrust, then on child domains without it).

1c. Real-world gotcha: WHfB Cloud Trust exists, but `CloudTrustDisplay` is empty

This one is worth calling out because it is easy to miss during validation.

In one deployment, Windows Hello for Business Cloud Trust was already working, so at first glance everything looked fine. But the verification output from:

Get-AzureADKerberosServer -Domain $domain `
    -DomainCredential $domainCred `
    -UserPrincipalName $cloudUserName

looked mostly healthy while CloudTrustDisplay was empty. That turned out to be the blocker.

After running the TDO setup again:

Set-AzureADKerberosServer -Domain $domain `
  -UserPrincipalName $cloudUserName `
  -DomainCredential $domainCred `
  -SetupCloudTrust

the same Get-AzureADKerberosServer check returned:

CloudTrustDisplay   : Microsoft.AzureAD.Kdc.Service.TrustDisplay

If you are troubleshooting a "looks right but still fails" scenario, treat an empty CloudTrustDisplay as a red flag and recreate/reapply the Trusted Domain Object configuration.

Reference workflow (Microsoft Learn): https://learn.microsoft.com/en-us/azure/azure-sql/managed-instance/winauth-azuread-setup-incoming-trust-based-flow?view=azuresql#create-and-configure-the-microsoft-entra-kerberos-trusted-domain-object

Step 2: Configure the Entra Device Registration Service Principal

⏭️ This step is always required, even if you have WHfB Cloud Trust.

We need to configure the Entra device registration service to accept Kerberos-based authentication from your on-prem devices. Connect using the Application Administrator role. Yes, another service principal tweak. No, I don't make the rules, I just develop opinions about them.

Install-Module -Name Microsoft.Entra -Repository PSGallery -Scope CurrentUser -Force -AllowClobber
Connect-Entra -Environment 'Global' -Scopes "Application.ReadWrite.All"

# Get the Device Registration Service principal
$drsSP = Get-EntraServicePrincipal -Filter "AppId eq '01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9'"

$spns = [System.Collections.Generic.List[string]]::new($drsSP.ServicePrincipalNames)
$tags = [System.Collections.Generic.List[string]]::new($drsSP.Tags)

# Add Kerberos SPN & Policy Tag
$spns.Add("adrs/enterpriseregistration.windows.net")
$tags.Add("KerberosPolicy:ExchangeForJwt")

# Apply updates
Set-EntraServicePrincipal -ObjectId $drsSP.Id -ServicePrincipalNames $spns -Tags $tags

Step 3: Deploy a Windows Server 2025 Domain Controller

You need at least one Windows Server 2025 DC per AD domain running build 26100.6905 or later.

If you're already running WS2025 for Cloud Trust, just make sure the October 2025 out-of-band update (KB5070881) or a newer cumulative update is applied. If your only WS2025 DC is still missing the required build, now would be a great time to stop calling it "good enough for now."

Verify the KDC service is running on that DC:

sc query kdc

Step 4: Configure the Service Connection Point (SCP)

⏭️ SKIP THIS STEP if you already have traditional Hybrid Entra Join working. The SCP is already in place.

If you are setting this up from scratch and don't use Entra Connect's device options wizard, create the SCP manually:

$verifiedDomain = "yourdomain.com" 
$tenantId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

$ConfigNC = (Get-ADRootDSE).configurationNamingContext
$de = New-Object System.DirectoryServices.DirectoryEntry
$de.Path = "LDAP://CN=Device Registration Configuration,CN=Services,$ConfigNC"

$scpObj = $de.Children.Add("CN=62a0ff2e-97b9-4513-943f-0d221bd30080", "serviceConnectionPoint")
$scpObj.Properties["keywords"].Add("azureADName:$verifiedDomain")
$scpObj.Properties["keywords"].Add("azureADId:$tenantId")
$scpObj.CommitChanges()

Step 5: Configure Client Computers

Once prerequisites are in place, domain-joining a Windows 11 24H2 client (with the September 2025 CU or later) triggers automatic Entra hybrid registration via Kerberos. This is the point where Hybrid Join briefly stops feeling like a punishment and starts acting like a feature.

For Autopilot: this is the bit that needs to be stated precisely. The ODJ Connector is still used to perform the actual domain join during OOBE. Entra Kerberos does not replace that. What it replaces is the old registration dependency on Entra Connect device sync. In other words: the connector still gets the machine into AD, but Kerberos gets the machine registered in Entra ID without the old wait.

That distinction matters, because the Microsoft Learn article for Entra Kerberos hybrid join is not an Autopilot article. It assumes the client is already being joined to the domain by whatever method you normally use and focuses on what happens after that point.

Step 6: Verify

On the client after the domain join and restart:

dsregcmd /status

You should see:

AzureAdJoined : YES
DomainJoined  : YES

If it didn't work, ensure your client can ping the WS2025 DC, and verify the SCP and DRS tags were applied correctly. And yes, if name resolution is broken, it is probably still DNS. I wish I had a more exciting answer there.

Final Thoughts

This feature is a godsend for environments stuck on Hybrid Join. It does not magically make Hybrid Autopilot cloud-native, and it does not remove the ODJ Connector from the equation. But it does remove the single most annoying part of the flow: waiting for directory sync just so the device can finish registration.

However, my recommendation stands: If you don't strictly need on-prem AD computer objects, go Cloud Native. It's faster, more reliable, and a much cleaner operational model overall.

But if you do have a real on-prem dependency and Hybrid Join is staying for a while, then this preview is the first version of Hybrid Autopilot in a long time that makes me think: fine, I still don't love it, but at least now it makes technical sense.

And beyond Autopilot itself, I think this may end up being the feature that helps many organizations finally kick Entra Connect Sync out of the room. If device sync was the last excuse for keeping that old dependency alive, Entra Kerberos has just made that excuse a lot weaker. No flowers, no sad music, just a polite nod and a migration plan.

And if you're touching this area anyway, do yourself another favor and lean into Windows Hello for Business while you're there. Passwordless plus Cloud Kerberos Trust is still one of the nicest improvements Microsoft has made in this whole identity stack.