Microsoft AZ-104: Hybrid Identity for Azure Admins

Hybrid identity connects on-premises Active Directory with Microsoft Entra ID so users, groups, devices, applications, and authentication can span datacenter and cloud environments. For Azure administrators, the architecture is no longer simply “install Entra Connect.” Microsoft now positions Microsoft Entra Cloud Sync as the strategic direction for most directory-synchronization scenarios, while Connect Sync remains necessary for capabilities that Cloud Sync does not yet support. Authentication choice—password hash synchronization, pass-through authentication, or federation—is a separate decision from object synchronization.

Microsoft’s current 2026 guidance explicitly recommends evaluating Cloud Sync for eligible organizations and states that new synchronization features are being developed primarily on Cloud Sync. Current comparison guidance also documents scenarios where Connect Sync remains required, including some device and complex topology capabilities. Administrators should therefore choose the synchronization tool from the supported-scenario matrix rather than migrate solely because one service is newer.

Hybrid identity belongs inside Azure Architecture in Practice and has a natural security relationship with Microsoft Identity & Security.

Separate synchronization from authentication

Directory synchronization copies or provisions identity objects and selected attributes between Active Directory and Microsoft Entra ID.

Authentication determines how a user proves identity during cloud sign-in.

Hybrid identity is easier to design when these two decisions are evaluated separately rather than treating Connect/Cloud Sync as the authentication method.

Prefer Cloud Sync for eligible new scenarios

Microsoft Entra Cloud Sync uses lightweight provisioning agents and cloud-managed configuration.

Microsoft currently describes Cloud Sync as its strategic direction and recommends it for most organizations where feature requirements are supported.

Multiple agents can provide resilience without one on-premises sync server holding all configuration.

Keep Connect Sync where required

Cloud Sync does not yet support every scenario that Connect Sync supports.

Current Microsoft comparison guidance lists capabilities such as some hybrid device scenarios and complex object/topology features that can still require Connect Sync.

Use the current decision guide and supported-topology matrix before migration, and do not remove Connect scope prematurely during coexistence.

Use password hash synchronization for resilience

Microsoft recommends password hash synchronization where possible for resilient hybrid authentication because cloud sign-in does not depend on an on-premises authentication service after the hash-of-hash is synchronized.

Even organizations that use pass-through authentication or federation can consider PHS as a backup according to Microsoft’s resilience guidance.

Design sign-in continuity as a business requirement, not simply as a preference for one identity technology.

Use pass-through authentication deliberately

PTA validates passwords against on-premises Active Directory through agents.

This can satisfy requirements that depend on on-premises account state or policies at authentication time, but it creates dependencies on agents, network connectivity, and domain controllers.

Deploy multiple agents and test on-premises failure if PTA is the primary cloud authentication method.

Use federation only for a real requirement

Federation introduces an external identity provider or federation service into the sign-in path.

It can support specialized authentication requirements, but it adds certificates, endpoints, servers, network dependencies, and operational complexity.

Microsoft’s current decision guidance favors simpler cloud authentication where it can satisfy the requirement.

Design source authority and lifecycle

Hybrid identity needs clear rules for which directory is authoritative for user, group, and attribute lifecycle.

Provisioning, HR-driven identity, group management, writeback, and mergers can complicate that ownership.

Identity architecture should make joiner, mover, leaver, and emergency-disable behavior explicit.

Monitor synchronization and sign-in separately

Cloud Sync or Connect health does not prove users can authenticate, and successful sign-in does not prove new directory changes are synchronizing.

Monitor agent health, sync errors, object quarantine or provisioning failures, password-hash status, authentication failures, and directory-connectivity dependencies as separate signals.

This separation speeds incident diagnosis.

Plan migration as coexistence and validation

Microsoft’s current migration guidance supports staged movement from Connect Sync toward Cloud Sync for eligible configurations.

Use mutually exclusive scope during coexistence where required, validate object and attribute outcomes, preserve rollback, and move only after the current feature matrix supports the organization’s dependencies.

For Azure administrators, durable hybrid identity is supported scenario → synchronization tool → authentication method → authority/lifecycle → resilience → monitoring → tested migration.

Disconnected forests and mergers are areas where Cloud Sync can simplify architecture because agents can synchronize separate forests into one tenant without consolidating them first. This can reduce the infrastructure complexity traditionally associated with multi-forest synchronization.

Device identity deserves separate design because hybrid join, cloud join, Windows Hello for Business, and device writeback can have tool-specific prerequisites. Do not select the synchronization platform only from user-object needs and then discover later that device requirements depend on Connect Sync or another supported path.

Administrative roles for hybrid identity should be limited. Sync agents and service accounts are high-value infrastructure because compromised synchronization can create or modify cloud identities. Protect installation accounts, gMSAs, connectors, and configuration access with the same rigor as other identity infrastructure.

Hybrid identity is mature when cloud services can continue through reasonable on-premises disruption, identity changes propagate predictably, administrators know which system is authoritative, and migration toward Microsoft’s newer synchronization platform happens through evidence rather than deadline panic.

Cloud Sync architecture uses lightweight on-premises provisioning agents with configuration managed in Microsoft Entra ID. Multiple agents can provide resilience and geographic distribution, and Microsoft manages agent updates. This reduces the operational footprint compared with a traditional Connect Sync server whose configuration is stored and managed on-premises.

Cloud Sync also supports disconnected forests, which can simplify mergers and acquisitions where domains cannot or should not be connected directly. Each forest can run provisioning agents while the cloud service provides centralized configuration and object synchronization.

Connect Sync remains important because Cloud Sync has not reached complete feature parity. Current Microsoft guidance lists device synchronization/hybrid join and some complex large-domain or filtering scenarios among the areas that can still require Connect Sync. Review the latest comparison rather than assuming a migration is possible for every tenant.

Cloud Sync and Connect Sync can coexist when scopes are designed carefully. Microsoft supports migration patterns where a subset of objects moves first while the remaining scope stays on Connect Sync. Avoid overlapping authority that causes the same object or attribute to be synchronized inconsistently by both systems.

Password hash synchronization should be understood precisely: Microsoft Entra receives a derived hash-of-a-hash, not the user’s clear-text password. Because sign-in occurs in the cloud, PHS reduces dependence on on-premises agents during authentication and is Microsoft’s preferred resilience pattern where business requirements allow it.

Pass-through authentication keeps password validation against on-premises Active Directory. This can satisfy policies that require immediate on-premises account-state enforcement, but it introduces agents, network connectivity, and domain controllers into the cloud sign-in path. Deploy multiple agents and monitor them as authentication infrastructure.

Federation should be reserved for requirements that cloud authentication cannot meet. AD FS or third-party federation introduces token-signing certificates, endpoints, proxies, servers, and failover. Those dependencies must be patched, monitored, and tested like any other externally facing identity service.

Seamless single sign-on, password writeback, group writeback/provisioning, device identity, and Exchange hybrid can all introduce additional requirements beyond basic user synchronization. Build a capability matrix before choosing the synchronization platform so one missing feature does not appear late in the migration.

Hybrid identity security should protect agent servers and service accounts. The provisioning agents, Connect server, gMSAs, connector accounts, and administrators can influence cloud identity state. Restrict interactive logon, use appropriate tiering, monitor changes, and keep software current.

Source-of-authority migration is another lifecycle concern. Organizations increasingly create cloud-native users, groups, and access packages while retaining on-premises AD for legacy applications. Define which system owns each object type and how a future cloud-first transition will be handled rather than assuming AD remains authoritative forever.

Monitoring should correlate synchronization incidents with user-impact symptoms. A failed sync can delay a new hire or group change while existing users continue signing in normally; an authentication-agent outage can block sign-in even when directory sync is healthy. Separate dashboards and runbooks reduce diagnosis time.

Disaster recovery should include the hybrid identity tooling itself. Cloud Sync’s multiple agents can reduce single-server dependency, while Connect Sync requires staging-server or recovery design according to current guidance. Back up configuration and practice replacement before identity synchronization becomes a critical incident.

Migration to Cloud Sync should use Microsoft’s readiness and eligibility guidance. Preserve the existing Connect configuration, use staging/coexistence, validate users and attributes, and keep rollback until the cloud-sync path has proven stable for the required scenarios.

For Azure administrators, hybrid identity is successful when directory changes, authentication, device state, and access remain predictable across cloud and on-premises failure—without carrying unnecessary legacy identity infrastructure after newer supported patterns can replace it.

Hybrid administrators should also review synchronization feature changes regularly because Microsoft’s strategic shift toward Cloud Sync is active. New Cloud Sync capabilities can remove old reasons to retain Connect Sync, while unsupported scenarios still justify staying on Connect until the migration path is ready.

The target architecture should become simpler over time: fewer on-premises synchronization dependencies, resilient cloud authentication where possible, explicit exceptions for legacy requirements, and a tested path to retire old identity infrastructure safely.

Review continuously.