Microsoft Entra Hybrid Join Configuration (2026 Guide)

Once you’ve set up synchronization, your users show up in the cloud — good. But one morning a user tries to open Teams and is prompted for their password again and again; Conditional Access says "I don’t recognize this device." Because you synced the user, not the device.

Microsoft Entra Hybrid Join closes exactly this gap: it gives a Windows device that stays joined to the on-prem domain a device identity registered in Microsoft Entra ID (formerly Azure AD) as well. The device can then say "this is me" to both the domain controller and the cloud; SSO flows smoothly, device-based Conditional Access works, and Windows Hello for Business and Intune compliance scenarios fall into place.

In theory it’s as simple as "tick a box in Entra Connect." In practice the thing that trips deployments isn’t the box: it’s a wrong UPN, a missing SCP, image/sysprep mistakes, and the sneakiest one — devices losing line of sight to a domain controller. This guide covers both the correct configuration and these pitfalls, one by one. Our scenario is the most common: managed environment (PHS or PTA + Seamless SSO), no federation.

What does Hybrid Join actually do?

A domain-joined device is already a computer object in AD. Hybrid Join additionally creates a device object in Entra ID and binds the two to the same physical machine. Once registration completes, the device gets a Primary Refresh Token (PRT); cloud-side SSO and Conditional Access work through that token.

The key point: Hybrid Join is not a "move to the cloud," it’s a dual identity. The device stays domain-joined and must periodically see a domain controller. Internalize this up front, because most field failures come from forgetting it.

Prerequisites — before you open the wizard

Identity infrastructure (the most critical condition)

• The environment must be managed: PHS or PTA + Seamless SSO. If Federation (AD FS) is in play the flow differs; this guide covers the managed scenario. We cover which method to pick in the PHS, PTA and Federation comparison.
• The UPN must be routable and verified in Entra. This is non-negotiable: nonroutable UPN + managed environment = NOT SUPPORTED. So users with a company.local UPN can’t do managed Hybrid Join. You must move to a verified domain first.
• If the on-prem UPN differs from the Entra UPN, the on-prem UPN must be synced to the onPremisesUserPrincipalName attribute in Entra; otherwise some scenarios (like Entra SSPR from the lock screen) won’t work.

Devices

• Supported: Windows 11, Windows 10, Windows Server 2016/2019/2022. Getting current is best.
• Not supported: Hybrid Join can’t be done on a server in the Domain Controller role. Server Core supports no device registration. USMT doesn’t work with device registration.
• TPM: TPM 2.0 is ideal. FIPS-compliant TPM 1.2 is not supported (must be disabled); from Windows 10 1903 onward TPM 1.2 is ignored anyway.

Domain controller and network

• Minimum DC version: Windows Server 2008 R2.
• Devices must periodically have line of sight to a domain controller. Without it the device eventually becomes unusable.
• Devices must reach these cloud endpoints (managed): login.microsoftonline.com, device.login.microsoftonline.com, enterpriseregistration.windows.net, and for Seamless SSO autologon.microsoftazuread-sso.com.

Sync tool

• The Hybrid Join wizard ships in Microsoft Entra Connect (1.1.819.0 and later). You must have completed the sync setup first.
• Alternative: Hybrid Join is also supported via device sync on the Microsoft Entra Cloud Sync side (generally available). On that path an SCP is still required and the provisioning agent must be 1.1.1107 or later.

The heart of it: the Service Connection Point (SCP)

The one thing that makes Hybrid Join work automatically is the SCP. The SCP is an object in the AD forest’s configuration naming context that tells domain-joined devices "your tenant is this, go here to register." Without an SCP the device doesn’t know which tenant to register with and nothing happens.

It’s configured one of two ways:

1. Via the Entra Connect wizard (recommended): on the Connect server, open the wizard → Configure device options → Configure Hybrid Microsoft Entra join. Select the target forest, enter Entra credentials, finish. Connect writes the SCP for you.
2. Manually with PowerShell: when you can’t use the wizard, you write the SCP into AD by hand (under Device Registration Configuration in the forest’s configuration partition).

Notes:

• Writing the SCP requires Enterprise Admin; the privilege can be removed afterward.
• In a multi-forest environment, the SCP must be configured separately in every forest that contains domain-joined computers.
• If an SCP already exists, save its values (azureADName, azureADId) before changing them; an SCP pointing to the wrong tenant breaks all registrations.

Step-by-step configuration (managed, with Entra Connect)

1. Verify prerequisites. Routable/verified UPN done? Environment PHS/PTA + Seamless SSO? Can devices see the DC and the cloud endpoints?
2. Open the Entra Connect wizard → Configure device options → Configure Hybrid Microsoft Entra join.
3. Device OS/scenario selection: proceed for Windows 10 and later domain-joined devices.
4. SCP configuration: select the target forest(s). In a managed environment the authentication service is Microsoft Entra ID — the AD FS option is only for federated environments.
5. Entra credentials: sign in as Hybrid Identity Administrator and approve writing the SCP.
6. Finish. At this point the SCP is ready in the forest; devices will start registering themselves.

How and when does registration happen?

After the SCP is written there is no magic "register all" button; registration happens automatically on the device side. Domain-joined Windows devices read the SCP via a scheduled task (Automatic-Device-Join) and sign-in triggers, find the tenant and register themselves with Entra. The device object usually appears shortly in Entra admin center → Devices as "Microsoft Entra hybrid joined."

Two field tips:

• Pilot first (targeted deployment). Don’t enable the whole estate at once. With Microsoft’s targeted method, keep the SCP out of AD and give pilot devices the tenant info via a client-side registry value (TenantId under CDJ\AAD) through GPO. Pick sample users across roles/profiles; seeing a problem on 10 devices beats seeing it on 10,000.
• Be patient but check. If it doesn’t appear immediately, sign out/in and confirm the device reaches the DC and the cloud endpoints.

Verification: the single source of truth, dsregcmd /status

On the device, in an elevated command prompt:

dsregcmd /status

The lines to look at:

• AzureAdJoined : YES
• DomainJoined : YES (both YES = Hybrid Join complete.)
• In the SSO State section, AzureAdPrt : YES — a PRT was obtained; this is the sign that SSO and Conditional Access will work.

Example output (truncated):

+----------------------------------------------------------------------+
| Device State                                                         |
+----------------------------------------------------------------------+
            AzureAdJoined : YES
             DomainJoined : YES
         EnterpriseJoined : NO

+----------------------------------------------------------------------+
| SSO State                                                            |
+----------------------------------------------------------------------+
               AzureAdPrt : YES

If you see AzureAdJoined : NO, the cause is almost always one of four: a missing/wrong SCP, a nonroutable UPN, no access to the cloud endpoints, or dual-state (below).

Field pitfalls (what breaks registration, not setup)

• Trying managed Hybrid Join with a nonroutable UPN. The most common mistake. .local won’t work; verified domain + UPN fix first.
• Losing line of sight to a domain controller. If the device can’t see a DC regularly, password change, cached credentials and TPM reset scenarios break and the device becomes unusable over time. Plan VPN/branch scenarios accordingly.
• The image/Sysprep and VM snapshot trap. Cloning from an image or snapshot of a device that is already Hybrid Joined clones the registered identity and causes conflicts. Always clone from a "clean," unregistered image.
• Turning on Unified Write Filter too early. Technologies that wipe disk changes on every reboot must be applied after Hybrid Join completes; enable one first and the device drops its registration on every reboot.
• Dual state (Entra registered + hybrid joined). Older devices can end up in a dual state. 1803+ builds clean this up automatically on user sign-in; if needed, block the Entra registered state up front with the BlockAADWorkplaceJoin registry value.
• Proceeding with TPM 1.2 (FIPS). Not supported; set the TPM to a suitable mode with the hardware vendor, or disable it.
• Enabling the whole estate at once. Skipping the pilot means experiencing the first problem in production.

Conclusion

Hybrid Join looks like a "tick a box" job, but the real work starts before configuration: routable/verified UPN, managed identity infrastructure (PHS/PTA + SSO), the correct SCP in every forest, and uninterrupted device access to the DC and the cloud. With those in place, the Entra Connect wizard writes the SCP, devices register themselves, and you verify with dsregcmd /status. Pilot first, then the rest — and watch out for the image/snapshot/UWF traps.

After bringing devices into Entra, the next step is to settle how the user authenticates in the cloud. Once the device has an identity, you can tie it to a Conditional Access "require compliant/hybrid-joined device" condition.