Faster Hybrid Windows Autopilot with Microsoft Entra Kerberos
Microsoft wants us to move toward cloud-native Microsoft Entra joined devices, and I agree with that direction. But many organizations aren’t there yet. During Hybrid Windows Autopilot deployments, I’ve repeatedly run into one particularly frustrating situation: The device has joined Active Directory, the user is ready to work, but Microsoft Entra hybrid join is still waiting for the computer object to synchronize. Microsoft Entra Kerberos introduces another path.
What if we could complete Microsoft Entra hybrid join without waiting for that device synchronization at all?
Let’s Understand the Hybrid Join Process First
Several processes are involved in a hybrid Windows Autopilot deployment, and they are easy to mix together.
To understand what Microsoft Entra Kerberos changes, we must first separate four distinct jobs.
1. AD Domain Join
In a Windows Autopilot Microsoft Entra hybrid join deployment, the Intune Connector for Active Directory, also known as the Offline Domain Join connector, processes the Offline Domain Join request.
The connector creates the computer object in the configured organizational unit and provides the information required for Windows to join the on-premises Active Directory domain. It does not synchronize the computer object to Microsoft Entra ID.
That distinction is important:
The Intune Connector handles the AD domain-join operation. It does not complete Microsoft Entra hybrid join.
2. Tenant Discovery (SCP)
After joining the domain, Windows must discover the Microsoft Entra tenant where the device should register.
This is normally handled through the Service Connection Point, or SCP, stored in the Configuration partition of Active Directory Domain Services.
Think of the SCP as a signpost: “This is the Microsoft Entra tenant where this device should register.”
The SCP provides tenant-discovery information. It does not synchronize the computer object and does not complete device registration by itself.
We can configure SCP in two different ways depending on deployment strategy.
- Forest-Wide Configuration (Standard): The SCP is written directly into the Configuration Naming Context partition of your Active Directory forest. Because there is only one Configuration partition per forest, this setting automatically applies forest-wide to all domain-joined Windows 10/11 devices.
- Targeted deployments: tenant-discovery values can instead be deployed to selected devices through client-side registry settings, commonly distributed using Group Policy.
When local client-side values are present, Windows uses those values. Otherwise, Windows queries Active Directory for the forest-wide SCP. Microsoft’s targeted deployment guidance recommends removing the forest-wide SCP if only selected devices should attempt Microsoft Entra hybrid join.
3. Device Synchronization
In the traditional managed-domain hybrid-join flow, information from the AD computer object must reach Microsoft Entra ID before the device can complete registration.
That information can be synchronized using:
- Microsoft Entra Connect Sync, or
- Microsoft Entra Cloud Sync
The two technologies use different architectures, but both provide a synchronization-based device path.
4. Microsoft Entra Device Registration
Windows then authenticates with the Microsoft Entra Device Registration Service and completes device registration.
Once that process succeeds, the device becomes Microsoft Entra hybrid joined.
The interesting part is that Microsoft Entra hybrid join using Microsoft Entra Kerberos changes the authentication path used during this registration process.
It does not remove:
- AD domain join
- Tenant discovery
- The requirement for a valid Microsoft Entra configuration
- Domain-controller connectivity
- Microsoft Entra Device Registration Service connectivity
It removes the requirement to synchronize the AD computer object to Microsoft Entra ID before the device can complete hybrid join through this new path.
Three Hybrid-Join Architectures
Microsoft Entra Connect Sync
The traditional architecture consists of two important elements:
Tenant discovery through the SCP + device-object synchronization through Microsoft Entra Connect Sync
Conceptually, the process looks like this:
Microsoft Entra Cloud Sync
Cloud Sync uses a different synchronization architecture, but the overall device-registration dependency is similar: Tenant discovery through the SCP + device-object synchronization through Microsoft Entra Cloud Sync Device Sync
Conceptually, the process looks like this:
Microsoft Entra Hybrid Join Using Microsoft Entra Kerberos
The Kerberos-based architecture is different: Tenant discovery through the SCP + a Microsoft Entra Kerberos-based device-registration authentication path
Conceptually, the process looks like this:
Microsoft describes the preview feature as allowing devices to perform Microsoft Entra hybrid join without requiring AD FS or Microsoft Entra Cloud Sync. Microsoft also describes the result as providing Microsoft Entra hybrid join behavior without waiting for the traditional synchronization-based path.
Microsoft Entra Kerberos provides a different authentication path through which the device can complete Microsoft Entra hybrid join without first synchronizing its AD computer object.
Back to Windows Autopilot
For this discussion, I am referring to the Classic Windows Autopilot deployment workflows, not Windows Autopilot device preparation. “Autopilot 1.0” is sometimes used as a community shorthand, but it is not an official Microsoft product name. The distinction matters because Windows Autopilot device preparation supports Microsoft Entra join, not Microsoft Entra hybrid join. When hybrid join is required, the Classic Windows Autopilot hybrid-join workflow remains the relevant deployment model. I want to focus on one particular part of the experience:
The device may already be domain joined and usable by the user while Microsoft Entra hybrid join is still pending. During that period, cloud experiences that depend on completed Microsoft Entra device registration, device identity, or a Primary Refresh Token (PRT) may not yet behave as expected.
What Actually Changes?
After AD domain join, the device must register with Microsoft Entra ID.
In the traditional managed-domain path, the required computer information must first be synchronized to Microsoft Entra ID by Microsoft Entra Connect Sync or Cloud Sync Device Sync.
This is the main reason I started investigating Microsoft Entra hybrid join using Microsoft Entra Kerberos.
With the traditional managed-domain flow, the device authenticates using computer information that must first be synchronized from AD DS.
With the Microsoft Entra Kerberos-based path, the architecture uses:
- A Microsoft Entra Kerberos Trusted Domain Object
- A supported Windows Server 2025 domain controller
- Configuration of the Microsoft Entra Device Registration service principal
- A supported Windows 11 client
- Tenant discovery through the SCP or supported client-side configuration
- Connectivity between the client and the supported domain controller
Together, these components provide an alternative device-registration authentication path. The device does not have to wait for its AD computer object to be synchronized to Microsoft Entra ID before completing Microsoft Entra hybrid join through this path.
What Does Not Change?
Microsoft Entra Kerberos does not eliminate the entire hybrid architecture.
The device still requires:
- AD domain membership
- A supported domain controller
- Microsoft Entra tenant discovery
- Connectivity to the relevant Microsoft services
- A correctly configured Microsoft Entra environment
- A supported Windows client build
- Correct Kerberos and service-principal configuration
For a Windows Autopilot hybrid deployment, the Intune Connector for Active Directory still performs its Offline Domain Join role.
The Kerberos method changes the Microsoft Entra registration authentication path. It does not replace the Offline Domain Join connector.
Kerberos removes a device-registration dependency. It does not remove the hybrid architecture.
The Conceptual Kerberos Flow
The exact internal ticket and token exchanges are beyond the scope of this article. The following represents the conceptual flow described by the preview architecture.
1. The Computer Joins AD DS
During a hybrid Windows Autopilot deployment, the Intune Connector for Active Directory supports creating the AD computer account and completing Offline Domain Join.
2. The Device Discovers the Microsoft Entra Tenant
The domain-joined computer uses the forest-wide SCP or supported client-side tenant-discovery configuration to determine which Microsoft Entra tenant it should register with.
3. The Device Uses the Microsoft Entra Kerberos Authentication Path
The client communicates with a supported Windows Server 2025 domain controller and uses the configured Microsoft Entra Kerberos architecture.
This includes the Microsoft Entra Kerberos Trusted Domain Object and the required Microsoft Entra Device Registration service-principal configuration.
4. The Device Completes Registration
The device authenticates through the Kerberos-based path and completes Microsoft Entra device registration.
5. The Device Becomes Microsoft Entra Hybrid Joined
Microsoft Entra hybrid join completes without waiting for the AD computer object to be synchronized through Microsoft Entra Connect Sync or Cloud Sync Device Sync.
Why This Could Matter for Hybrid Windows Autopilot
The goal is not to claim that Microsoft Entra Kerberos makes every part of Windows Autopilot faster.
Application installation, configuration policies, scripts, certificate deployment, security baselines, and Enrollment Status Page processing still take time.
Microsoft Entra Kerberos removes one asynchronous dependency that can delay the completion of Microsoft Entra hybrid join. With the Microsoft Entra Kerberos-based path, the device no longer has to wait for its AD computer object to be synchronized before completing Microsoft Entra hybrid join.
This removes an asynchronous synchronization dependency from the registration process. It does not mean that every hybrid Windows Autopilot deployment completes instantly.
What Does the Microsoft Entra Kerberos Method Require?
The preview method requires more than an SCP and a generic trust relationship.
At the time of writing, Microsoft documents requirements including:
- Domain Controller (At least one domain controller running Windows Server 2025 build 26100.6905 or later in the participating AD domain.)
- Windows Client (A client running Windows 11 build 26100.6584 or later.)
- Microsoft Entra Kerberos Trusted Domain Object
- Microsoft Entra Device Registration Service Principal (The Microsoft Entra Device Registration service principal must be configured to support the Kerberos-based registration path.)
- Tenant Discovery (The device must have a valid tenant-discovery configuration through an SCP or supported client-side configuration.)
- Connectivity (The client must have unimpeded network connectivity to the supported Windows Server 2025 domain controller during the join process.)
- Permissions (Creating and configuring the Microsoft Entra Kerberos Trusted Domain Object requires the documented AD DS and Microsoft Entra permissions. Microsoft currently identifies Domain Admins and Enterprise Admins permissions in AD DS and the Hybrid Identity Administrator role in Microsoft Entra ID for the relevant configuration process.Configuration of the Device Registration service principal requires the relevant Microsoft Entra application-administration permission.)
- KDC Proxy Configuration (The KDC proxy server Group Policy configuration is optional. Microsoft states that this prerequisite applies when a KDC Proxy Server GPO has been deployed to the client computer.)
These requirements reflect the Microsoft preview documentation available when this article was written. Because the feature is in preview, verify the current supported builds, prerequisites, and limitations before implementation.
Can Device Sync and Microsoft Entra Kerberos Coexist?
In my testing, I enabled the Microsoft Entra Kerberos-based configuration while leaving the same device in scope for Cloud Sync Device Sync.
The device completed Microsoft Entra hybrid join without waiting for a device synchronization cycle, and I did not observe an immediate issue.
I have not found a detailed statement in the reviewed Microsoft documentation describing every aspect of same-device behavior when both mechanisms overlap, including:
- Mechanism precedence
- Matching behavior
- Retry logic
- Automatic fallback
- Device-object lifecycle
- Deletion and recreation
- Behavior after disabling one method
- Behavior on unsupported Windows builds
- Long-term coexistence
A client that does not meet the Microsoft Entra Kerberos prerequisites cannot use the preview path.
A correctly configured synchronization-based environment remains a separate hybrid-join path, but I would not promise automatic and seamless fallback between the two methods without validating the precise design.
This is another area that should be tested before production use.
Why Use Microsoft Entra Kerberos alongside Microsoft Entra Cloud Sync?
Because the two technologies solve different problems.
Microsoft Entra Cloud Sync
provides a modern way to synchronize AD computer information to Microsoft Entra ID.
Its benefits include:
- Cloud-managed configuration and orchestration
- Lightweight on-premises provisioning agents
- Multiple-agent availability
- No traditional local Connect Sync engine architecture
- A supported device-synchronization path for Microsoft Entra hybrid join
But the architecture still requires device information to be synchronized before the synchronization-based registration path completes.
Microsoft Entra Kerberos
Microsoft Entra Kerberos provides an alternative authentication path through which the device does not have to wait for that device synchronization.
Its key benefit is not “better synchronization.”
Its key benefit is: No prerequisite device synchronization for Microsoft Entra hybrid join through this path.
For an existing domain-joined computer, that is an architectural difference.
Microsoft explicitly lists the following preview use cases:
- Non-persistent VDI with Microsoft Entra hybrid join
- Customers using or planning to use Microsoft Entra Cloud Sync (this was the case before Microsoft Entra Cloud Sync added support for Hybrid Joined devices)
- Improved hybrid provisioning for Azure Virtual Desktop and Windows 365
- Disconnected forests where Microsoft Entra Connect Sync cannot be used .
Important: Microsoft currently documents Microsoft Entra Kerberos hybrid join as a preview feature, but Windows Autopilot hybrid join is not explicitly listed as one of the documented preview use cases. The Autopilot scenario presented here should therefore be treated as a scenario that requires testing and validation rather than as a Microsoft-documented Windows Autopilot reference architecture.
Also: “No device synchronization required” does not mean “no identity synchronization required anywhere.”
This feature addresses the device-registration and hybrid-join operation.
User and group synchronization remain separate architecture decisions. An organization will still require Microsoft Entra Connect Sync or Microsoft Entra Cloud Sync for users, groups, attributes, and other identity requirements.
See ya in next blog post 🙂
