Hybrid Identity Models in Entra ID (Azure AD) and On‑Prem AD

Hybrid identity is the set of patterns used to connect an on‑premises identity system—most commonly Active Directory Domain Services (AD DS)—with Microsoft Entra ID (formerly Azure Active Directory, often still referenced as Azure AD). The goal is straightforward: users sign in to Microsoft 365, Azure, and SaaS apps using an identity that is consistent with their corporate directory, while administrators keep control over lifecycle, security, and access.

In practice, “hybrid identity” is not one architecture. It is a spectrum of models that differ mainly in where authentication happens, how identities are synchronized, and which systems are authoritative for attributes like passwords, group membership, and device state. The right model depends on constraints such as network reliability, regulatory requirements, legacy app dependencies, and how quickly you need to move workloads to the cloud.

This article walks through the major hybrid identity models used with Entra ID and on‑prem AD DS. It explains the mechanics (how sign-in is processed), the operational tradeoffs, and the security controls that matter in real environments. Along the way, you’ll see realistic scenarios that mirror common enterprise transitions—because hybrid identity decisions are rarely made in a vacuum.

Core building blocks of hybrid identity

Most hybrid designs use the same underlying components, even if the authentication model differs. Establishing the vocabulary early makes later tradeoffs easier to evaluate.

AD DS is the on‑premises directory service that stores users, groups, computers, and Kerberos/NTLM credentials for Windows-integrated authentication. In many environments it is still the authoritative source for employee identities.

Microsoft Entra ID is the cloud identity provider (IdP) used for Microsoft 365, Azure, and thousands of SaaS applications via modern protocols (OAuth 2.0, OpenID Connect, SAML). Entra ID is where Conditional Access and many cloud security controls are enforced.

Directory synchronization is the process of copying identity objects and selected attributes from AD DS to Entra ID so that cloud services can recognize your users. Historically this is done via Microsoft Entra Connect (formerly Azure AD Connect), and increasingly via Entra Cloud Sync for specific scenarios.

Authentication is the process of validating credentials at sign-in. In hybrid identity, authentication can be performed:

In the cloud (Entra ID validates the password hash or uses cloud-only credentials).
Against on‑prem AD DS (password validation is delegated back to your domain controllers).
Through a federation service (Entra ID redirects sign-in to an on‑prem identity provider like AD FS).

Single sign-on (SSO) means users don’t repeatedly type passwords. In hybrid identity, SSO might be:

Integrated Windows authentication to on‑prem apps using Kerberos.
“Seamless SSO” to Entra ID from domain-joined machines on the corporate network.
Token-based SSO to SaaS apps using Entra ID.

Device identity ties access decisions to device state. In Microsoft terminology you’ll encounter:

Entra registered (formerly Azure AD registered) for bring-your-own devices.
Entra joined (cloud-joined) devices.
Hybrid Entra joined (domain joined and registered in Entra ID).

These building blocks combine into a few well-established models, which you’ll evaluate in the next sections.

Identity authority and what “source of truth” really means

A critical design decision is which system is authoritative for user objects and attributes. In most hybrid deployments, AD DS remains the source of truth for core attributes (sAMAccountName, userPrincipalName, group membership, password), while Entra ID becomes the control plane for access policies and app assignments.

In this arrangement, user accounts are created and managed on-prem, then synchronized to the cloud. Entra ID does not “own” those objects; it receives a synchronized representation. This has operational consequences. For example, if a synchronized user’s display name or UPN is edited in Entra ID, that change may be overwritten by the next sync cycle unless the attribute is defined as cloud-managed.

It is also common to transition authority over time. Organizations migrating to cloud-native endpoints and HR-driven provisioning may move toward cloud-only identities or authoritative sources like Entra ID Governance and HR provisioning connectors. However, as long as AD DS remains central for Windows authentication, Group Policy, and legacy line-of-business applications, hybrid identity is usually the pragmatic middle state.

A useful way to validate the “source of truth” is to ask two questions:

Where is the account created and disabled as part of joiner/mover/leaver processes?
Where is the password verified at sign-in?

Directory synchronization answers the first question; the authentication model answers the second.

The main hybrid identity models

Hybrid identity models are often described by the method Entra ID uses to validate user credentials. The three most common are Password Hash Synchronization, Pass-through Authentication, and Federation. Each can be combined with SSO and multi-factor authentication (MFA), and each can be operated securely if implemented correctly.

As you read through them, note that the differences are not merely technical. They change your operational dependencies: uptime requirements for on‑prem components, incident response patterns, and how quickly you can adopt modern security features.

Password Hash Synchronization (PHS)

Password Hash Synchronization is the simplest and most widely recommended hybrid authentication method. With PHS, a hash of the user’s on‑prem AD DS password hash is synchronized to Entra ID. Entra ID then validates credentials during sign-in without having to contact your on‑prem environment.

Two clarifications matter here:

First, Entra Connect does not synchronize the plaintext password. It synchronizes a hash derived from the AD DS password hash, with additional hashing and salting applied so the value stored in Entra ID is not the same as the on‑prem hash.

Second, PHS changes the dependency chain. If your VPN is down or your datacenter is unreachable, users can still authenticate to cloud services because Entra ID has what it needs. That resiliency is often the decisive factor.

PHS pairs well with Conditional Access and modern MFA because authentication happens in Entra ID, where those policies are natively enforced.

Pass-through Authentication (PTA)

Pass-through Authentication keeps password validation on-prem. When a user signs in to Entra ID, the cloud service securely queues the authentication request to one of your PTA agents installed on domain-joined servers. The agent validates the credentials against AD DS (via standard Windows authentication APIs) and returns the result.

PTA appeals to organizations that cannot or do not want to store password-derived material in the cloud, even in hashed form, and to environments that need immediate enforcement of on‑prem password policies without waiting for a password hash sync event.

The tradeoff is operational dependency: if your PTA agents or connectivity to Entra ID are unavailable, users may not be able to sign in to cloud services. You can mitigate this by deploying multiple agents across sites and ensuring outbound connectivity is stable, but the dependency remains.

PTA still allows Conditional Access and cloud MFA because Entra ID remains the primary sign-in endpoint; it is just delegating password validation.

Federation (commonly AD FS)

Federation means Entra ID does not validate credentials itself. Instead, it redirects sign-in to a trusted identity provider (IdP), most historically Active Directory Federation Services (AD FS), though third-party federation products exist.

In a federated model, the on‑prem federation service authenticates the user (often using AD DS) and then issues a token that Entra ID accepts. Entra ID becomes a relying party (RP) for authentication, and your federation service becomes a critical path dependency.

Federation is typically justified by specific requirements:

Legacy authentication patterns or smartcard/certificate requirements tightly integrated with AD FS.
Complex sign-in constraints that predate Conditional Access.
Existing federation investments and operational maturity.

However, federation increases complexity significantly. You operate additional infrastructure (federation servers, Web Application Proxy, load balancers, TLS certificates), and you must secure it as an internet-facing authentication tier. Many organizations have moved from federation to PHS or PTA to reduce that complexity while improving resiliency.

Cloud-only identities (not hybrid, but often adjacent)

Cloud-only identities live solely in Entra ID without synchronization from AD DS. They are relevant because many hybrid environments gradually introduce cloud-only accounts for new SaaS apps, contractor access, or separate administrative identities.

When cloud-only identities are mixed with synchronized identities, you must be clear about naming conventions, MFA requirements, and privileged access processes. Inconsistent policy between the two populations is a common gap.

How directory synchronization works in practice

Authentication choices are only half the picture. Hybrid identity nearly always begins with directory synchronization—getting identities into Entra ID in a controlled and predictable way.

Entra Connect vs Entra Cloud Sync

Microsoft Entra Connect is the traditional synchronization tool installed on a Windows Server in your environment. It supports a broad set of features, including:

Synchronizing users, groups, and contacts.
Password hash synchronization.
Hybrid device registration (depending on configuration and environment).
Custom synchronization rules for attribute flows.

Entra Connect is mature and flexible, but it’s also a stateful server role you must maintain: patching, monitoring, backups, and managing changes carefully.

Entra Cloud Sync uses lightweight provisioning agents and a cloud-managed configuration model. It is designed to simplify some sync scenarios and reduce on‑prem complexity, but it does not replicate every Entra Connect feature. In particular, complex attribute transformations and some advanced hybrid scenarios still commonly rely on Entra Connect.

Choosing between them is less about “new vs old” and more about whether your requirements fit within Cloud Sync’s supported scope.

Attribute design: UPN, mail, and immutable identifiers

The userPrincipalName (UPN) is often used as the sign-in name in Entra ID. Ensuring users have a routable UPN suffix (for example, user@company.com rather than user@corp.local) reduces friction.

In many organizations, the UPN is updated as part of hybrid identity deployment. That change has ripple effects: Outlook profiles, Teams sign-in, and application mappings may depend on UPN. Planning and staging the change is safer than bulk updates without validation.

Entra ID also uses an immutable identifier to maintain object linkage between AD DS and Entra ID. In Entra Connect, this is often based on the AD object’s source anchor (commonly the objectGUID converted to a Base64 value). Treat this as a foundational identity mapping. Changing it incorrectly can result in duplicate cloud accounts, broken permissions, and mailbox mismatches.

Sync scope and filtering

Scope is your control mechanism. You can limit what gets synchronized by:

Organizational unit (OU) filtering.
Attribute-based filtering.
Group-based filtering.

Start small in pilot phases. Syncing all users and groups immediately can create security exposure (unexpected accounts available for cloud authentication) and administrative overhead (cleaning up stale objects). A well-defined scope makes the rollout auditable.

Operational cadence and change control

Synchronization is not a one-time event. It is an ongoing pipeline.

If you rely on sync for lifecycle events, you need to understand how long it takes for changes to appear in Entra ID, especially for critical actions like account disablement. Even when sync runs frequently, there is still a window where a user might authenticate to cloud apps based on cached tokens. That’s why hybrid identity design must include Conditional Access session controls and token lifetime strategies where appropriate.

Single sign-on patterns in hybrid identity

Once users are synchronized and can authenticate, the next expectation is SSO. Users rarely care which model you chose; they care whether sign-in is consistent across networks and devices.

Seamless SSO with PHS or PTA

“Seamless SSO” is a Microsoft capability that allows domain-joined devices on the corporate network to sign in to Entra ID without entering credentials, using integrated Windows authentication. It typically relies on a computer account in AD DS (often named AZUREADSSOACC) and Kerberos to obtain a ticket used during sign-in.

This capability is often paired with PHS or PTA. It reduces password prompts for users on managed endpoints in the office, while still supporting modern authentication and Conditional Access.

Seamless SSO is not a replacement for MFA. It simply reduces friction for primary authentication on trusted networks; you still apply MFA based on risk and policy.

Federation SSO behavior

With federation, SSO can be very smooth on domain-joined corporate devices because AD FS can use Windows Integrated Authentication (WIA) to silently authenticate users and issue tokens. But this depends on network pathing, WIA configuration, and browser behavior.

If your workforce is increasingly remote and mobile, federation SSO can become less predictable due to reliance on the federation endpoint and potential pre-auth steps. Modern Conditional Access and browser-based token flows tend to be more consistent across devices when using cloud authentication models.

SSO to on‑prem applications and the double-hop reality

Many organizations expect hybrid identity to provide seamless access to on‑prem web apps from cloud-managed devices. This is achievable, but the mechanism differs. On‑prem integrated authentication (Kerberos/NTLM) relies on domain trust and device join state. Cloud SSO relies on tokens.

If you are publishing on‑prem apps to remote users, consider architectures like Entra Application Proxy for token-based access rather than exposing internal apps directly. Hybrid identity is the foundation, but app access architecture determines the user experience.

MFA and Conditional Access in hybrid models

Multi-factor authentication and Conditional Access are usually the primary security drivers behind hybrid identity modernization. Conditional Access is Entra ID’s policy engine for controlling access based on identity, device state, location, risk, and application.

Where MFA is enforced

In PHS and PTA models, primary authentication occurs at Entra ID, so MFA is naturally enforced in the cloud. This aligns well with modern authentication to Microsoft 365 and SaaS apps.

In a federated model, MFA can be enforced either:

At the federation provider (for example, AD FS with an MFA adapter), or
In Entra ID depending on configuration and token claims.

Federation MFA design can become complex, particularly when trying to blend legacy on‑prem requirements with modern Conditional Access. Many organizations simplify by moving toward cloud MFA enforcement, but that requires careful planning of claims, conditional access evaluation, and legacy app behavior.

Device-based access controls

Conditional Access policies frequently depend on device signals such as “compliant device” (from Microsoft Intune) or “hybrid Entra joined.” This is where device identity becomes a core part of the hybrid story.

If you require compliant devices, you’re implicitly requiring a device management and registration strategy. Without it, Conditional Access policies become blunt instruments that create user friction.

Token lifetime and session controls

Hybrid identity administrators often focus on sign-in success and forget sessions. Even after a user is disabled on-prem, they may still have valid refresh tokens and active sessions in cloud apps.

Conditional Access includes controls such as sign-in frequency and continuous access evaluation (where supported) that can reduce exposure. These are not “fixes” for poor deprovisioning, but they are important layers that work with your synchronization cadence.

Device identity: Entra join, hybrid join, and why it changes access

Hybrid identity is not only about users. Devices provide critical context for access decisions and for end-user SSO.

Hybrid Entra join (domain joined + registered in Entra ID)

Hybrid Entra joined devices are joined to AD DS and also registered with Entra ID. This is common in organizations that still rely heavily on Group Policy and on‑prem management but want Conditional Access and SSO benefits.

Hybrid join is especially useful during transitions: you can keep your traditional imaging and domain-join processes while enabling device-based policies in the cloud.

Entra join (cloud-joined)

Entra joined devices are joined directly to Entra ID. This model aligns well with cloud-first management (Intune) and remote provisioning (Windows Autopilot). It reduces dependency on line-of-sight to domain controllers for day-to-day authentication, but it requires a plan for accessing on‑prem resources.

Many organizations adopt Entra join for new devices while maintaining hybrid join for existing fleets, resulting in a mixed device population. Hybrid identity design should anticipate this coexistence.

Entra registered devices

Registration is common for BYOD and mobile devices. Registered devices can provide some device identity signals but are usually less trusted than joined devices for high-privilege access.

How device join interacts with SSO and Kerberos

On-prem Kerberos depends on domain membership and connectivity to domain controllers. Cloud SSO depends on Entra tokens. When you introduce cloud-joined devices, users may still need access to on‑prem file shares or apps. In those cases, you must plan for how Kerberos tickets are obtained and whether you use VPN, modern solutions for on‑prem access, or app publishing.

The point is not that one join state is “better,” but that device identity choices directly affect authentication pathways and therefore user experience and support load.

Model selection criteria that actually matter

Organizations often choose a model based on what they’ve heard is “best,” but the best model is the one that fits your operational realities. The following criteria drive durable decisions.

Resiliency and dependency chains

If your on‑prem environment experiences frequent outages, or if you cannot guarantee stable outbound connectivity from all sites, PHS often provides the best user experience because cloud authentication remains available.

PTA and federation introduce stronger dependencies on on‑prem components. You can make them highly available, but doing so requires more engineering and testing.

Security posture and attack surface

Federation infrastructure is internet-facing and therefore expands attack surface. It must be patched aggressively, monitored closely, and protected with strong TLS and network controls.

PHS reduces the amount of critical authentication infrastructure exposed on-prem for cloud sign-ins, but it does store password-derived material in the cloud (in a secure, hashed form). For some regulatory environments, that alone may drive a PTA or federation decision.

Legacy application constraints

If you have applications that depend on AD FS claims rules, smartcard authentication via federation, or very specific sign-in flows, federation may be required in the short term.

However, it’s worth quantifying how many apps truly require federation. In many environments, federation remains because it was implemented years ago and never reevaluated.

Administrative overhead

PHS typically has the lowest ongoing overhead. PTA adds agent management and monitoring. Federation adds the most: certificate management, proxies, load balancing, WAP, and complex incident response when sign-in breaks.

This overhead matters not only for cost, but for security. Complex systems are harder to patch and harder to observe.

User experience across locations

Remote work changes the calculus. If users are often off-network, models that depend on on‑prem integrated auth for “smooth SSO” may provide diminishing returns.

Modern Entra ID sign-in with MFA and device-based Conditional Access tends to be consistent regardless of location, which is one reason many organizations move from federation to PHS/PTA.

Real-world scenario 1: Moving from AD FS to PHS for resiliency

Consider an enterprise that implemented AD FS years ago to support SSO for Microsoft 365. Over time, the organization adopted Conditional Access and started enforcing MFA for most users. The federation stack remained, but it became a single point of failure: if AD FS or the Web Application Proxy had issues, users could not access email or Teams.

In this scenario, the identity team decided to migrate to Password Hash Synchronization while keeping the same synchronized identities and UPNs. The primary driver was operational resiliency: cloud services should remain accessible during planned maintenance or unexpected outages in the datacenter.

The migration typically involves verifying that password hash sync is operational, validating sign-in behavior in a pilot group, and then switching the domain from federated to managed in Entra ID. Because this is a sensitive change with broad impact, teams usually schedule it during a maintenance window and ensure they have a rollback plan.

A simplified illustration of checking the domain authentication type and switching from federated to managed uses the Microsoft Graph PowerShell module (exact commands depend on your tenant state and should be validated against current Microsoft documentation). The key operational takeaway is that this is not merely a toggle—communications, pilot testing, and Conditional Access review matter as much as the technical change.


# Connect to Microsoft Graph (requires appropriate permissions)

Connect-MgGraph -Scopes "Domain.ReadWrite.All"

# List domains and authentication types

Get-MgDomain | Select-Object Id, AuthenticationType, IsDefault

# Example: update a domain to managed authentication (illustrative)

# Update-MgDomain -DomainId "company.com" -AuthenticationType "Managed"

After the move, the organization reduced its internet-facing authentication footprint and shifted MFA enforcement entirely into Entra ID Conditional Access. AD FS was retained temporarily for a small set of legacy apps, but Microsoft 365 sign-ins no longer depended on it.

Real-world scenario 2: Choosing PTA for strict password policy requirements

A financial services organization wanted hybrid identity but had strict internal controls about password verification. While they understood that PHS does not sync plaintext passwords, their compliance team preferred that all password checks remain on-prem.

They selected Pass-through Authentication with multiple agents deployed across two datacenters. They paired PTA with Seamless SSO to keep in-office sign-ins smooth, and they used Conditional Access for MFA and device compliance.

Operationally, the team treated PTA agents like critical infrastructure. They monitored agent health, ensured outbound firewall rules were stable, and documented failover behavior. They also tested what happens during a datacenter outage: cloud sign-ins should continue as long as at least one agent remains reachable.

A common administrative task is to validate that PTA is enabled and that agents are healthy. Exact steps vary by tooling and portal views, but the discipline is consistent: treat hybrid authentication dependencies as production services, not “set and forget.”

Real-world scenario 3: Hybrid join for a phased Windows 11 rollout

A mid-sized manufacturer had a large fleet of domain-joined Windows 10 PCs managed primarily with Group Policy and Configuration Manager. They wanted to roll out Windows 11 with Autopilot and Intune but could not migrate everything at once.

They adopted a mixed device strategy:

Existing PCs remained domain joined but were configured for hybrid Entra join to enable Conditional Access based on device state.
New Windows 11 devices were Entra joined and Intune-managed.

This created a practical hybrid identity outcome: users could access Microsoft 365 with modern authentication across both device types, while administrators gradually shifted management workloads to the cloud. The identity team coordinated with endpoint management to ensure that device registration and compliance reporting worked consistently, because Conditional Access policies depended on those signals.

The lesson from this scenario is that hybrid identity planning must include endpoint realities. If device state is used for access control, the device join and management approach is not an afterthought—it is a prerequisite.

Planning a hybrid identity deployment step by step

Hybrid identity projects fail most often due to incomplete inventory and unclear ownership boundaries, not because the sync tool misbehaves. A structured approach reduces risk.

Start by standardizing UPNs and ensuring they align with email addresses where appropriate. If users currently sign in with corp.local UPNs, plan a controlled migration to a verified public domain suffix.

At the same time, define how privileged accounts will be handled. Many organizations use separate admin accounts that are cloud-only or synchronized but subject to stricter Conditional Access and MFA requirements. Mixing end-user and admin access patterns creates avoidable risk.

2) Clean up AD DS before syncing

Directory synchronization is unforgiving: it will replicate your mess into the cloud.

Before syncing, identify and remediate:

Stale accounts that should be disabled.
Duplicate or conflicting proxyAddresses.
Inconsistent UPN formats.
Groups with unclear ownership.

Doing this upfront reduces support incidents later when users cannot sign in or when mail attributes collide.

3) Choose the authentication model with operational input

Authentication model selection should include identity, security, and infrastructure teams. If your chosen model requires on‑prem highly available components, confirm you can meet those uptime requirements.

If you select PHS, confirm that compliance stakeholders understand what is synchronized and what is not. If you select PTA or federation, confirm you have the monitoring and incident response maturity to handle an authentication dependency.

4) Implement sync in a scoped pilot

Begin with a limited OU or group-based scope. Pilot users should represent different profiles: office users, remote users, mobile-heavy staff, and at least a few IT administrators.

During the pilot, validate not only sign-in but also:

Group-based access to apps.
Mailbox and Teams behavior.
Self-service password reset (if planned).
Device registration and Conditional Access outcomes.

5) Roll out Conditional Access deliberately

Conditional Access can lock out users quickly if rolled out aggressively. Build policies incrementally, starting with report-only mode where possible, then applying to controlled groups.

A common pattern is:

Require MFA for admins immediately.
Require MFA for all users with exclusions for break-glass accounts.
Introduce device compliance requirements for sensitive apps.

The details depend on your environment, but the sequencing matters.

6) Prepare for lifecycle events (joiner/mover/leaver)

Hybrid identity must handle the full account lifecycle. Confirm how quickly disablement or termination actions must take effect in cloud apps and whether your sync cadence and session controls meet that requirement.

Also validate how role changes (movers) are reflected in group membership and app assignments. Many organizations use group-based licensing and access, which makes group accuracy critical.

Operational considerations: monitoring, change management, and recovery

Hybrid identity adds moving parts, and those parts must be operated as a service.

Monitoring the sync pipeline

At minimum, you need visibility into:

Sync success/failure and last run time.
Export errors (for example, attribute conflicts).
Password hash sync status (if using PHS).

Centralize logs where possible so identity incidents can be triaged quickly. Even if you don’t build a full SIEM pipeline on day one, make sure the team knows where to look when sync does not behave as expected.

Monitoring authentication dependencies

For PTA and federation, monitor the health of agents and federation endpoints and test authentication paths from multiple networks.

Even with PHS, you should monitor sign-in logs in Entra ID, because many access issues come from Conditional Access and client behavior rather than password validation.

Change management and staged rollouts

Identity changes can have tenant-wide impact. Treat changes to:

Authentication model (federated vs managed).
Conditional Access policies.
Sync rules and scoping filters.
UPN formats and domains.

…as controlled changes with validation steps.

A recurring theme in successful deployments is staged rollout with clear rollback conditions. Hybrid identity is foundational; outages affect nearly every cloud workload.

Security architecture: hardening hybrid identity

Hybrid identity expands your security boundary. The goal is to reduce the chance that compromise of one layer leads to compromise of everything.

Protect the sync and authentication servers

Servers running Entra Connect, Cloud Sync agents, PTA agents, or federation services are high-value targets. Apply strong controls:

Tiering model (limit admin access; avoid logging on with highly privileged accounts).
Patching and vulnerability management.
Endpoint protection and tamper protection.
Restrictive outbound access to only required endpoints.

Even if a server is not internet-facing, it can be used to manipulate identity data flows if compromised.

Privileged access strategy

Use a dedicated privileged access model. In Microsoft ecosystems, this typically includes:

Separate admin accounts.
MFA enforced for all privileged roles.
Just-in-time role activation where available (Privileged Identity Management).

Hybrid identity often fails from a security perspective when legacy “Domain Admin everywhere” habits leak into cloud administration. Treat Entra ID roles as distinct privileged surfaces.

Break-glass accounts

Maintain at least one (often two) emergency access accounts that are not dependent on the hybrid pipeline. These accounts should be cloud-only, strongly protected, and excluded from Conditional Access policies that could block access during outages.

Document storage and access procedures for credentials. The goal is not routine use; it is tenant recovery when identity policies or dependencies fail.

If AD DS remains authoritative for passwords, ensure on‑prem password policies are strong and consider password protection mechanisms that reduce common and breached passwords.

In Entra ID, monitor sign-in risk and suspicious activity. Hybrid identity centralizes access, which makes the sign-in logs a valuable detection source—if you operationalize them.

Coexistence with legacy authentication and protocols

Hybrid identity deployments often stumble when older protocols are still in use.

Legacy authentication in Microsoft 365

Protocols like IMAP, POP, and older Office clients may use basic authentication, which bypasses modern controls and is increasingly blocked in Microsoft 365. Hybrid identity modernization is a good opportunity to inventory and retire legacy auth.

If you must support older clients temporarily, isolate them and use compensating controls, but treat it as technical debt with a retirement plan.

NTLM, Kerberos, and on‑prem dependencies

Even in cloud-forward organizations, NTLM and Kerberos remain in use for on‑prem resources. Hybrid identity does not eliminate that. What it can do is reduce how often users must interactively authenticate and provide a pathway to modernize app access.

Be explicit about which apps remain on-prem and which will move to SaaS or Azure-native services. Identity architecture should reflect application architecture, not fight it.

Practical validation commands and checks

Hybrid identity administrators often want concrete ways to verify state without relying solely on portals. The following examples are intended as operational starting points; adapt them to your standards and validate against your environment.

Sign-in logs are invaluable for understanding Conditional Access outcomes and authentication failures.

powershell
Connect-MgGraph -Scopes "AuditLog.Read.All"

# Get recent sign-ins (limited example; paginate for real usage)

Get-MgAuditLogSignIn -Top 20 | Select-Object UserDisplayName, UserPrincipalName, AppDisplayName, CreatedDateTime, Status

In real operations, you’ll filter by user, app, status code, or Conditional Access result, and export to a log system for correlation.

Inspect AD user UPNs and common readiness issues (on-prem PowerShell)

UPN cleanup is a frequent prerequisite. This snippet helps you find non-routable suffixes.

powershell

# Requires RSAT ActiveDirectory module

Import-Module ActiveDirectory

Get-ADUser -Filter * -Properties UserPrincipalName | 
  Where-Object { $_.UserPrincipalName -match "@corp\.local$" } | 
  Select-Object SamAccountName, UserPrincipalName

Before changing UPNs at scale, confirm you’ve added and verified the corresponding domain in Entra ID and validated impacts on dependent systems.

Validate domain join state on Windows endpoints

Device join state affects Conditional Access and SSO expectations.

powershell

# Run on a Windows endpoint

dsregcmd /status

Review the output for AzureAdJoined/DomainJoined status (terminology may reflect Entra/Azure naming), and confirm that the device is in the expected state for your chosen access policies.

Common migration paths and coexistence strategies

Hybrid identity is often a journey rather than a one-time switch. Understanding common migration paths helps you avoid dead ends.

Federation to managed (PHS/PTA)

A frequent modernization move is migrating from AD FS to PHS or PTA. The coexistence period may include:

Some domains still federated while others are managed.
A subset of apps still using AD FS while Microsoft 365 uses managed auth.

The critical risk here is inconsistent user experience and policy enforcement if Conditional Access and federation rules diverge. Plan policy alignment early.

Hybrid join to Entra join

Endpoint modernization often starts with hybrid join, then moves to Entra join for new devices. This staged approach reduces risk, but it demands clear documentation so support teams know what “expected behavior” is for each device class.

AD DS authoritative to cloud authoritative

Some organizations eventually reduce reliance on AD DS for identity management. This is feasible, but it is constrained by:

On‑prem app dependencies.
Windows authentication needs.
Organizational readiness for cloud-based lifecycle and access governance.

If this is on your horizon, treat hybrid identity as an intermediate architecture and avoid over-investing in complexity that you intend to retire.

Designing for scale: multi-domain, multi-forest, and mergers

Real environments are messy. Hybrid identity solutions must accommodate organizational complexity.

Multiple domains and UPN alignment

Multiple AD domains can synchronize into a single Entra tenant. The key is consistent UPN strategy and avoidance of attribute conflicts (especially proxyAddresses for email).

When merging organizations, you may need temporary coexistence where two directories sync into one tenant or where two tenants are consolidated. These projects require careful identity mapping to prevent duplicate accounts and access issues.

Multiple forests

Entra Connect can support multiple forests, but design decisions matter: do you represent users from multiple forests as separate identities, or do you implement a resource forest/user forest model where a single user identity is represented?

These questions affect mailbox mapping, access control, and lifecycle processes. They also affect how you standardize naming and how you implement consistent Conditional Access policies across the population.

Latency and site considerations

For PTA and federation, site design impacts user experience. Placing agents close to domain controllers and ensuring resilient outbound connectivity reduces sign-in latency.

For PHS, sign-in latency is mostly a cloud concern, but user provisioning and attribute updates still depend on sync performance and on-prem directory health.

Putting it all together: choosing a sustainable hybrid identity model

By this point, the differences between models should be clearer:

PHS optimizes for simplicity and resiliency. PTA optimizes for on‑prem password validation with cloud policy enforcement but introduces on‑prem dependencies. Federation optimizes for legacy and specialized requirements at the cost of complexity and a larger exposed surface.

The practical recommendation in many modern deployments is to use PHS (often with Seamless SSO) unless you have a defined requirement that PHS cannot meet. If you do, PTA is commonly the next choice. Federation is usually reserved for specific constraints and ideally treated as transitional rather than permanent.

What matters most is that your chosen model aligns with how your organization operates: how you manage endpoints, how you handle outages, how you monitor identity services, and how you enforce privileged access. Hybrid identity is not just a connectivity project—it is the authentication backbone for your cloud estate.

Hybrid Identity Models in Microsoft Entra ID (Azure AD) and On‑Premises AD DS