For a long time, when we talked about Microsoft Entra hybrid join, the conversation usually came back to the same building blocks: device sync, tenant configuration, SCP, and in some environments, federation dependencies. That model worked, but it also introduced limitations, especially for customers trying to modernize identity while keeping parts of on-premises Active Directory.
Now Microsoft is introducing a new approach: Microsoft Entra hybrid join using Microsoft Entra Kerberos.
What makes this interesting is not just the feature itself, but the type of customer scenarios it can unlock. This approach is designed for environments where the traditional hybrid join path is not always ideal — especially where customers are using Microsoft Entra Cloud Sync, deploying non-persistent VDI, improving Azure Virtual Desktop or Windows 365 provisioning, or working with disconnected forest designs.
In this Blog post, I want to walk through what this new model means, where it fits, and how to prepare the technical implementation steps.
Why this matters
Traditional hybrid join has often depended on the broader synchronization path to make the device object available in Microsoft Entra ID before registration is fully completed. In many production environments, that dependency is manageable. But in some designs, it adds delay, complexity, or architecture constraints.
This new Entra Kerberos-based model changes that conversation.
Microsoft describes this approach as a way to achieve Microsoft Entra hybrid join behavior without requiring AD FS or Microsoft Entra Connect sync for the join flow itself. That is a significant shift for organizations that want hybrid joined device behavior but do not want to depend on the classic setup path for every scenario.
From an architectural point of view, this feels especially relevant in environments where:
- device provisioning speed matters,
- traditional sync dependency is difficult,
- cloud-first identity patterns are already in progress,
- or the organization wants to support hybrid join in more isolated or complex AD designs.
| Capability | Traditional Hybrid Join | Entra Kerberos Hybrid Join |
|---|---|---|
| Sync Dependency | Yes | No |
| AD FS Dependency | Yes (in many cases) | No |
| Deployment Complexity | Higher | Lower |
| Authentication Type | Federation / Sync | Cloud Kerberos Trust |
| Kerberos Issuer | Domain Controller | Microsoft Entra |
Where this fits best
This is not something I would describe as a universal replacement for every existing hybrid join deployment. Instead, it looks more like a targeted modern option for specific scenarios.
The strongest use cases currently called out are:
1. Environments using Microsoft Entra Cloud Sync
This is probably one of the most interesting use cases. In many customer conversations, Cloud Sync comes up as a simpler or more flexible alternative for identity synchronization, but customers also discover that some traditional device-related expectations are different. Entra Kerberos for hybrid join helps close part of that gap.
2. Non-persistent VDI
This is another strong fit. If devices are short-lived or rebuilt frequently, waiting on traditional synchronization behavior can become painful. Microsoft specifically calls out non-persistent VDI as a preview use case.
3. Azure Virtual Desktop and Windows 365 provisioning improvement
The value here is operational. If the join behavior becomes available more quickly and with fewer traditional dependencies, provisioning cloud desktops becomes smoother.
4. Disconnected forest scenarios
This is where many architects will pause and pay attention. Microsoft explicitly mentions disconnected forest setups where Microsoft Entra Connect Sync cannot be used. That opens interesting possibilities for customers with segmented or unusual directory designs.
What is happening behind the scenes
At a high level, this model uses Microsoft Entra Kerberos as part of the join flow so the device can achieve hybrid join behavior in a different way than the traditional dependency chain many of us are used to.
A key part of the design is the trust relationship created between the on-premises Active Directory side and Microsoft Entra. Once that trust is in place, Microsoft Entra can participate in the Kerberos-based flow needed for device registration. The Microsoft Entra Device Registration service principal also needs to be prepared with the required Kerberos-related entries.
Key takeaway is : This is not “hybrid join with fewer clicks.” It is a different implementation path with specific prerequisites and configuration elements.
Prerequisites you should check first
Required roles
The implementation requires:
- Domain Admins and Enterprise Admins in on-premises AD DS for the trusted domain object side
- Hybrid Identity Administrator in Microsoft Entra ID
- Application Administrator for the Microsoft Entra device registration service principal configuration
License Requirements
There is no specific license required to enable this feature. However, if you want to manage and control devices effectively, Microsoft Entra ID P1 and Intune Plan 1 licenses are required.
Domain controller requirement
At least one Windows Server 2025 domain controller, on build 26100.6905 or later, must exist in each domain where you want to use this method
Client requirement
The client device must run Windows 11 build 26100.6584 or later
Network requirement
During join, the client must have unimpeded network connectivity to the Windows Server 2025 domain controller.
SCP requirement
You still need to configure the Service Connection Point (SCP). This can be done either by setting the SCP through client-side registry configuration or by writing it directly to AD DS using PowerShell ,without installing Entra Connect. As of today, Entra Cloud Sync does not support SCP configuration via its configuration.
Technical implementation Steps
Step 1 Create and configure Microsoft Entra Kerberos Trusted Domain Object
This is the foundational step. Before devices can use this model, the trust relationship between on-premises Active Directory and Microsoft Entra must be established properly.
This trusted domain object is what enables the Entra Kerberos-based flow to work as part of the hybrid join process. Without this trust layer, the rest of the configuration will not come together correctly.
To configure the Trusted Domain Object, begin by installing the Azure AD Hybrid Authentication Management PowerShell module.
Open a Windows PowerShell session with administrative privileges, and run the installation script. This script performs the following actions:
- Enables TLS 1.2 to ensure secure communication
- Installs the NuGet package provider
- Registers the PowerShell Gallery (PSGallery) repository
- Installs the PowerShellGet module
- Installs the Azure AD Hybrid Authentication Management module
The following PowerShell will help to achieve the same.
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Install-PackageProvider -Name NuGet -Force
if (@(Get-PSRepository | Where-Object { $_.Name -eq "PSGallery" }).Count -eq -1) {
Register-PSRepository -Default
Set-PSRepository -Name "PSGallery" -InstallationPolicy Trusted
}
Install-Module -Name PowerShellGet -Force
Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber
To create the Trusted Domain Object, ensure the module is already installed, then follow these steps:
- Open Windows PowerShell as Administrator.
- Run the following commands:
$domainCred = Get-Credential
$cloudUserName = "your Microsoft Entra Global Admin UPN (e.g., admin@tenantname.onmicrosoft.com)"
- Set the $domain value to your on-premises Active Directory domain name.
- When prompted by Get-Credential, enter credentials of an on-premises AD administrator.
- Set the $cloudUserName value to a Global Administrator account in Microsoft Entra ID.
If a Microsoft Entra service account does not already exist, this command will create one. The Trusted Domain Object will be created only when a Microsoft Entra service account is present or successfully provisioned during this step.
The CloudTrustDisplay field will return Microsoft.AzureAD.Kdc.Service.TrustDisplay, as shown in the sample output below:
- First, run the command on the root domain and include the -SetupCloudTrust parameter.
-
Then, run the same command on the child domain, but omit the
-SetupCloudTrustparameter.
Step 2 Configure the KDC proxy server GPO (if applicable)
- The user configuring this policy must be a Domain Admin or have delegated permissions to manage Group Policy.
- If you haven’t deployed the KDC proxy server GPO, you can skip this section.
Configure the KDC Proxy Server Policy
Deploy the following Group Policy setting to client devices using the incoming trust-based flow:
Open GPMC.msc on your Domain Controller and follow these steps:
- Create a new Group Policy Object (GPO) and link it to the target Computer OU.
- Edit the newly created GPO.
- Navigate to:
Configure the Policy
- If the policy is Not Configured, proceed to Enabled
- If the policy is Disabled, change it to Enabled
- Under Options, click Show… to open the Show Contents dialog box.
- Define the KDC proxy server mapping (replace with your tenant ID):
Step 3 Configure the Microsoft Entra Device Registration Service Principal
The next step is to configure the Microsoft Entra device registration service principal. This process adds a Kerberos key to the service principal, enabling it to participate in Kerberos-based authentication.
This configuration is essential, as it allows Microsoft Entra ID to securely issue Kerberos tickets during device registration. The device registration service must have a valid Kerberos identity to establish trusted communication with your on-premises Active Directory.
Once this service principal is properly created and updated in Microsoft Entra ID, hybrid device registration can function as expected.
First, ensure that the Microsoft Entra PowerShell module for Windows is installed (refer to the official Microsoft documentation for installation steps). It’s recommended to use PowerShell 7 for better compatibility and performance.
Next, open PowerShell and connect to Microsoft Entra using an account with the Application Administrator role:
After successful authentication, run the following command to verify the device registration service principal configuration:
$drsSP.ServicePrincipalNames
Following commands Preparing both updates with variables and Configuring Kerberos SPN
$spns = [System.Collections.Generic.List[string]]::new($drsSP.ServicePrincipalNames)
$tags = [System.Collections.Generic.List[string]]::new($drsSP.Tags)
if ($drsSP.ServicePrincipalNames -notcontains $kerbSpn) {
Write-Host "Kerberos SPN needs to be added"
$spns.Add($kerbSpn)
$needsUpdate = $true
}
Following Command can be used to Configure Kerberos policy Tag
if ($drsSP.Tags -notcontains $kerberosTag) {
Write-Host "Kerberos policy tag needs to be added"
$tags.Add($kerberosTag)
$needsUpdate = $true
}
To finally update the Service Principal configuration, below command can be used
Write-Host "Updating service principal configuration..."
Set-EntraServicePrincipal -ObjectId $drsSP.Id -ServicePrincipalNames $spns -Tags $tags
Write-Host "Service principal configuration updated successfully"
} else {
Write-Host "Service principal already configured correctly"
}
To validate and get the Final configuration, Below command can be used
Write-Host "`nFinal Configuration:"
Write-Host "SPNs:"
$drsSP.ServicePrincipalNames | ForEach-Object { Write-Host " $_" }
Write-Host "Tags:"
$drsSP.Tags | ForEach-Object { Write-Host " $_" }
Step 4 Configure SCP for device discovery
Even with this new join path, the device still needs to know which tenant it belongs to. That is where the Service Connection Point comes in. The SCP object stores tenant discovery information for the device registration process.
The SCP contains keyword values such as:
- azureADid:<TenantID>
- azureADName:<verified domain>
The same can also be verified using the following PowerShell command:
To configure the SCP object for your endpoints, there are two supported approaches:
- Option 1: Create the SCP object directly in Active Directory using PowerShell
- Option 2: Configure the SCP settings through Group Policy and target the required computer objects
Let’s walk through both options.
Option 1: Create the SCP Object using PowerShell in Active Directory Configuration
Option 2: Configure an AD GPO to deploy the Tenant Name and Tenant ID to domain-joined computers
If you prefer not to modify the Active Directory configuration directly, you can use a GPO-based approach to push the tenant details to endpoint registry settings by following the steps below.- Open the Group Policy Management Console (GPMC) and create a new GPO in your domain.
- Provide a meaningful name (for example, ClientSideSCP).
- Edit the GPO and navigate to:
- Right-click Registry → New → Registry Item
- On the General tab, configure:
- Action: Update
- Hive: HKEY_LOCAL_MACHINE
- Key Path:
SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD - Value Name: TenantId
- Value Type: REG_SZ
- Value Data: Your Microsoft Entra Tenant ID (GUID)(Entra ID → Overview → Properties → Tenant ID)
- Right-click Registry → New → Registry Item
- On the General tab, configure:
- Action: Update
- Hive: HKEY_LOCAL_MACHINE
- Key Path:
SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD - Value Name: TenantName
- Value Type: REG_SZ
- Value Data:
- Your verified domain name (for federated environments like AD FS), or
- Your onmicrosoft.com domain (for managed environments, e.g., contoso.onmicrosoft.com)
Step 5 Install and Configure Entra ID Cloud Sync
Once the installation is complete, the Entra Provisioning Agent Configuration Wizard will appear.
Enter your Microsoft Entra Administrator account and click Authenticate.
In the Configure Service Account step, select Create gMSA account, then enter the Domain Admin credentials and click Next.
On the next screen, connect to Active Directory by providing the required AD credentials, then click Next.
Once the Cloud Sync agent is successfully provisioned, it will appear under the Agents tab in the Cloud Sync configuration page in Microsoft Entra ID.
Now let’s configure Cloud Sync from the Microsoft Entra ID portal.
Navigate to Entra Cloud Sync, click New Configuration, and select AD to Entra ID Sync.
Select the installed active agent, enable Password Hash Sync, and then click Create.
Now, go to the Scoping Filter tab, select the required OU you want to sync to Microsoft Entra ID, enter the OU distinguished name, and click Add.
Finally, go to the Review section and click Enable to activate the Entra ID Cloud Sync configuration.
If you want to trigger it immediately, you can use Provision on demand to sync a specific on-premises identity to the cloud.
Now your on-premises users have been successfully provisioned to Microsoft Entra ID.
Step 6: Configure Intune Auto Enrollment GPO (Optional – for Validation)
This step is optional and can be used to validate Intune auto-enrollment on your devices.
This ensures that when a hybrid user signs in, the device will automatically enroll into Intune.
Note: This step is optional and only required if you want to enable automatic enrollment of Windows 10/11 devices into Intune.
Navigate to:
Computer Configuration → Policies → Administrative Templates → Windows Components → MDM
Locate “Enable automatic MDM enrollment using default Azure AD credentials”, set it to Enabled, and select the credential type as User credentials.
Step 7: Prepare Windows 11 Device and Validate Hybrid Device Join
Now let’s prepare a Windows 11 device, join it to the on-premises Active Directory, and validate the configuration.
Before proceeding, ensure the device meets the prerequisites for Windows 11 that were mentioned earlier.
Now you can see the newly joined device appearing in on-premises Active Directory.
Now, sign in using your hybrid user account and verify the device status from the command line.
Open Command Prompt as a normal user and run:
SSO Status as follows
Now, if you navigate to the Microsoft Entra ID → Devices page, you will notice that the device has successfully completed Intune enrollment.
The device will show:
- MDM: Microsoft Intune
- Ownership: Updated correctly
- Compliance status: Successfully evaluated and reflected
Conclusion
Microsoft Entra hybrid join using Microsoft Entra Kerberos introduces a new path for customers who need hybrid-joined device behavior without relying on the older join dependency model.
It is especially relevant for modern identity architectures where Cloud Sync, VDI, Azure Virtual Desktop, Windows 365, or disconnected forests are part of the design. With the right prerequisites in place, this approach can simplify some long-standing challenges in hybrid device onboarding.
If you are planning to test this, start with a pilot, document your SCP strategy carefully, and validate every prerequisite before rollout.
0 Comments