MSA1.4 Hybrid Identity Architecture

If your tenant has synced users, those identities exist in two systems: on-premises Active Directory and Entra ID. The hybrid identity architecture determines which sync engine replicates those identities, which authentication method validates their credentials, and what security properties each choice provides. A misconfigured hybrid architecture is the most common path for on-premises compromise to reach the cloud. The sync engine and authentication method are not admin choices you make during installation — they're architectural decisions with specific, measurable security consequences documented in an ADR.

Estimated time: 45 minutes.

The two sync engines

Microsoft has two engines for replicating on-premises Active Directory identities to Entra ID. Understanding the architectural difference — not just the feature difference — is the first decision.

Entra Connect Sync — the legacy engine

Entra Connect Sync (formerly Azure AD Connect) has been the standard hybrid identity tool since Azure AD's early years. It runs as a Windows service on a dedicated, domain-joined server in your on-premises environment. The server hosts everything locally: a SQL LocalDB instance storing the metaverse and connector spaces, a sync scheduler, rules engine, and the complete configuration. The server connects outbound to both on-premises AD (to read objects) and Entra ID (to write them).

The architectural properties of this design:

Everything is local. The sync configuration, the rules, the connector spaces, and the scheduling all reside on the server. If the server is lost (hardware failure, compromise, accidental deletion), the entire sync configuration is lost unless you've backed it up. Rebuilding requires reconfiguring from scratch or restoring from a backup that may be outdated.

Single server, single point of failure. Entra Connect Sync runs on exactly one server in active mode (a staging server can exist but doesn't sync actively). If that server fails, sync stops. Identity changes in on-premises AD (new users, password changes, group membership changes, account disables) don't propagate to Entra ID until the server is restored. If Password Hash Sync is the authentication method, this doesn't affect authentication (the hashes are already in Entra ID). But attribute changes, group membership changes, and new user provisioning are delayed.

The server is a Tier 0 asset. The Entra Connect service account has write access to Entra ID and read access to on-premises AD (plus write access if password writeback or group writeback is enabled). Microsoft's own prerequisites documentation states this server "should be a tier 0 server based on the Active Directory administrative tier model." Compromising this server gives an attacker the ability to modify synced identity attributes in Entra ID, trigger password resets via writeback, and potentially take over cloud identities via hard-match manipulation.

Full feature coverage. Legacy Entra Connect supports features that Cloud Sync doesn't yet: hybrid Entra joined device writeback, pass-through authentication (the PTA agents run alongside Entra Connect), Exchange hybrid writeback for full on-premises Exchange coexistence, custom sync rules for complex attribute transformation, and group writeback. If your organization requires any of these features, Entra Connect Sync is currently the only option.

Microsoft's direction is clear. Entra Connect Sync now supports Windows Server 2025 (announced May 2026 after an extended gap). But Microsoft simultaneously announced that beginning July 2026, phased transition notifications will start for tenants whose configurations are supported by Cloud Sync. The message is explicit: Cloud Sync is the future. Entra Connect Sync will enter phased retirement as Cloud Sync's feature coverage expands. New deployments should use Cloud Sync unless a specific feature gap forces Entra Connect Sync.

Entra Connect Cloud Sync — the current architecture

Cloud Sync inverts the architecture. Instead of running the sync engine on-premises, it deploys a lightweight provisioning agent on one or more domain-joined servers. The agent's only job is to read objects from on-premises AD and relay them to the cloud. The sync logic — scheduling, rules evaluation, conflict resolution, configuration management — runs entirely in the cloud, managed through the Entra admin center or the Microsoft Graph API.

The architectural properties:

Configuration is cloud-managed. No local SQL database, no local rules engine, no local configuration files. The agent is a thin relay. If the server hosting the agent fails, you install the agent on another server and it reconnects to the cloud-managed configuration automatically. No reconfiguration needed.

Multiple agents for high availability. Unlike Entra Connect Sync's single-server model, Cloud Sync supports multiple provisioning agents. Deploy agents on two or three servers, and if one fails, the others continue syncing. This eliminates the single point of failure. The sync cycle for Cloud Sync is 2 minutes by default — significantly faster than Entra Connect Sync's 30-minute default.

Reduced on-premises attack surface. The agent has read access to on-premises AD (and write access only for password writeback). It doesn't store the sync configuration locally — compromising the agent server gives the attacker access to on-premises AD (which they likely already have if they can compromise a domain-joined server), but the cloud-side configuration, rules, and scheduling are not accessible from the compromised server. The agent is still a Tier 0 asset (it has directory sync permissions), but its blast radius is smaller than Entra Connect Sync's.

Feature gaps. Cloud Sync does not yet support hybrid Entra joined device writeback (organizations migrating to Entra joined devices don't need this, but organizations with hybrid joined fleets do). Cloud Sync does not support pass-through authentication (PTA agents are an Entra Connect Sync feature). Cloud Sync does not support complex custom sync rules (it uses scoping filters and attribute mappings, but not the custom rule engine that Entra Connect Sync provides). And critically: Cloud Sync has a known issue with Windows Server 2025 — Microsoft's documentation explicitly states that Server 2025 "is NOT supported" for the Cloud Sync agent due to synchronization problems.

Source of Authority management. Cloud Sync supports a "cloud-first" model where Entra ID becomes the authoritative source for identity attributes. This enables scenarios where new users are created in the cloud (not on-premises AD) and their attributes are written back to on-premises AD — the reverse of the traditional sync direction. This capability positions Cloud Sync for organizations moving toward a cloud-primary identity strategy.

Query your hybrid configuration

Before designing the architecture, you need to know exactly what's deployed. These queries produce the evidence for your ADR's Context field:

Connect-MgGraph -Scopes "Directory.Read.All"

# Tenant-level sync status
$org = Get-MgOrganization
Write-Host "OnPremisesSyncEnabled: $($org.OnPremisesSyncEnabled)"
Write-Host "LastSyncDateTime:      $($org.OnPremisesLastSyncDateTime)"

$syncAge = (Get-Date).ToUniversalTime() - $org.OnPremisesLastSyncDateTime
Write-Host "Sync age:              $([int]$syncAge.TotalMinutes) minutes"
Write-Host ""

# Sync features — the detailed configuration
$syncConfig = Invoke-MgGraphRequest -Method GET `
  -Uri "https://graph.microsoft.com/v1.0/directory/onPremisesSynchronization"

$syncConfig.value | ForEach-Object {
  Write-Host "Configuration ID: $($_.id)"
  Write-Host ""
  Write-Host "Feature flags:"
  $features = $_.features
  $features.PSObject.Properties | ForEach-Object {
    $icon = if ($_.Value -eq $true) { "[ON] " } else { "[OFF]" }
    Write-Host "  $icon $($_.Name)"
  }
}

OnPremisesSyncEnabled: True
LastSyncDateTime:      2026-05-05T06:14:22Z
Sync age:              84 minutes

Configuration ID: d4e5f6a7-...

Feature flags:
  [ON]  blockCloudObjectTakeoverThroughHardMatchEnabled
  [OFF] blockSoftMatchEnabled
  [OFF] cloudKerberosTrustEnabled
  [OFF] concurrentCredentialUpdateEnabled
  [OFF] concurrentOrgIdProvisioningEnabled
  [OFF] deviceWritebackEnabled
  [OFF] directoryExtensionsEnabled
  [OFF] fopeConflictResolutionEnabled
  [OFF] groupWriteBackEnabled
  [ON]  passwordSyncEnabled
  [ON]  passwordWritebackEnabled
  [OFF] quarantineUponProxyAddressesConflictEnabled
  [OFF] quarantineUponUpnConflictEnabled
  [ON]  softMatchOnUpnEnabled
  [ON]  synchronizeUpnForManagedUsersEnabled
  [OFF] unifiedGroupWritebackEnabled

Every feature flag is an architectural decision. Here's what each ON flag means for NE:

blockCloudObjectTakeoverThroughHardMatchEnabled: ON — the hard-match takeover protection discussed in MSA1.3 is active. Beginning June 2026, this prevents an attacker from using on-premises AD to take over cloud-only identities that hold Entra roles by matching the sourceAnchor. the tenant has proactively enabled this — a good sign that someone was paying attention to identity security.

passwordSyncEnabled: ON — Password Hash Sync is active. Entra ID receives derived password hashes from on-premises AD. Cloud authentication works without on-premises dependency. Identity Protection can evaluate risk for every synced user sign-in. This is the recommended authentication method for most organizations.

passwordWritebackEnabled: ON — when a user resets their password in the cloud (via SSPR or admin reset), the new password is written back to on-premises AD. This enables a single password change to work in both environments. The security implication: if an attacker compromises a cloud account and resets the password, the reset propagates to on-premises AD. The compensating control is MFA for password reset (MSA2) and monitoring of password writeback events.

softMatchOnUpnEnabled: ON — the sync engine can match on-premises accounts to existing cloud accounts by UPN (if no immutableId match exists). This is useful during initial sync setup but creates a risk: if a cloud-only account exists with a UPN that matches an on-premises account, the sync engine will merge them. After initial sync is complete, consider whether this should remain enabled.

The OFF flags are equally informative:

deviceWritebackEnabled: OFF — no hybrid Entra joined device writeback. This is consistent with Cloud Sync (it doesn't support device writeback). It also means NE is either using Entra joined devices (no writeback needed) or the device join strategy hasn't been architected (a gap for MSA6).

cloudKerberosTrustEnabled: OFF — Cloud Kerberos Trust is not configured. This feature enables passwordless authentication (FIDO2, Windows Hello) for on-premises resources without deploying on-premises PKI. If NE plans to use phishing-resistant authentication (MSA2), enabling this becomes relevant for SSO to on-premises applications.

groupWriteBackEnabled: OFF — cloud-created groups are not written back to on-premises AD. This is typical for organizations that manage groups primarily in on-premises AD and sync them to the cloud (the organization's pattern).

The three authentication methods — security analysis

The sync engine replicates identities. The authentication method determines how those identities prove who they are. The security properties of each method determine what attackers encounter, what Identity Protection can see, and what happens when infrastructure fails.

Password Hash Sync (PHS) — the recommended architecture

With PHS, the sync engine reads NTLM password hashes from on-premises AD, applies an additional layer of hashing (SHA-256 with a per-user salt), and stores the derived hashes in Entra ID. When a synced user signs in to a cloud service, Entra ID validates the password against the stored hash. No on-premises infrastructure is involved in the authentication.

Identity Protection — full coverage. Because authentication happens in Entra ID, the Identity Protection risk engine evaluates every sign-in. It sees the source IP, the device properties, the browser fingerprint, the authentication method, and the behavioral patterns. It compares this sign-in against the user's historical baseline and against known attack patterns. Risk detections — anomalous token, unfamiliar features, impossible travel, leaked credentials — all function because Entra ID is performing the authentication and has full visibility.

This is the decisive architectural advantage. With PTA or federation, authentication is redirected away from Entra ID. Entra ID sees the result (success or failure) but not the authentication itself. Identity Protection's ability to detect subtle anomalies — the kind that distinguish AiTM replay from legitimate sign-in — is reduced because the risk evaluation has less signal to work with.

Cloud resilience. If on-premises infrastructure fails — network outage, domain controller compromise, power failure, ransomware encrypting the server fleet — synced users can still authenticate to cloud services. The password hashes are in Entra ID. Email, Teams, SharePoint, OneDrive — all continue working. The business continues operating. With PTA or federation, on-premises failure means cloud authentication failure. Users can't sign in. Business stops.

For an organization with multiple sites and hundreds of users, cloud resilience is not theoretical. A ransomware attack that takes down the primary site network (where the domain controllers are) would, with PTA, lock every synced user out of M365. With PHS, those users continue working from other sites or from home while the on-premises environment is recovered.

The "passwords in the cloud" objection. Some architects and compliance officers object to PHS because "it puts password hashes in the cloud." The objection sounds reasonable but doesn't survive analysis. The hashes in Entra ID are derived from the on-premises NTLM hashes using SHA-256 with a per-user salt — they're not the raw NTLM hashes. An attacker who obtains the Entra ID hashes can't use them for pass-the-hash against on-premises resources. They'd need to crack the SHA-256 layer first, then the NTLM layer — a computationally expensive process for strong passwords.

More importantly: the alternative (PTA) doesn't eliminate the hash exposure — it just moves the authentication to a different location. The NTLM hashes still exist in on-premises AD. An attacker who compromises a domain controller gets them regardless of whether PHS is enabled. PHS doesn't add a new attack surface — it adds a new copy of credentials that already exist. The security question is not "are the hashes in the cloud?" but "does having them in the cloud enable better detection of their misuse?" With Identity Protection, the answer is yes.

Pass-Through Authentication (PTA) — the on-premises dependency

With PTA, cloud sign-in requests are proxied to on-premises authentication agents. The user submits their password to the Entra ID sign-in page. Entra ID encrypts the password and places it in a queue. The on-premises PTA agent polls the queue, retrieves the encrypted password, decrypts it, validates it against the domain controller, and returns the result. The password is never stored in Entra ID.

The architectural weaknesses:

On-premises dependency for every cloud sign-in. Every authentication event requires the PTA agent to be running and connected to a domain controller. If the agents are down (server failure, network issue, maintenance window), authentication fails for all synced users. Microsoft recommends deploying at least three PTA agents for resilience — each on a separate server, each treated as Tier 0 infrastructure.

Reduced Identity Protection. Entra ID sees the authentication result but not the full authentication context. The risk evaluation engine has less signal. Microsoft's documentation acknowledges that certain risk detections are "not applicable" or have "reduced coverage" with PTA compared to PHS.

Agent servers as attack surface. Each PTA agent server decrypts and processes authentication credentials. An attacker who compromises a PTA agent server can potentially intercept credentials in transit (the password is in memory on the agent server during validation). Microsoft requires PTA agent servers to be "treated with the same level of protection" as domain controllers.

When PTA is architecturally correct: PTA is appropriate when a regulatory or compliance framework explicitly prohibits any form of password storage in the cloud. Some financial services regulators, some government security frameworks, and some contractual obligations have this requirement. If your organization's compliance framework has this restriction, PTA is the compliant alternative. Otherwise, PHS provides stronger security through better Identity Protection coverage, better resilience, and fewer on-premises attack surface components.

Federation (AD FS) — legacy for most organizations

With federation, authentication is entirely delegated to an on-premises Active Directory Federation Services (AD FS) infrastructure. The user's browser is redirected to the AD FS sign-in page, authentication happens on-premises, and AD FS issues a SAML or WS-Federation token that Entra ID trusts.

Federation requires the most complex on-premises infrastructure: AD FS servers (minimum two for redundancy), Web Application Proxy (WAP) servers (minimum two for external access), load balancers, SSL certificates, and ongoing maintenance. It introduces the broadest on-premises dependency — both authentication and the federation trust itself must be maintained. If the federation trust breaks (certificate expiration, configuration drift), all synced users lose cloud access.

Federation was the original hybrid authentication method — before PHS and PTA existed, it was the only option. It's still required for specific scenarios: third-party MFA solutions that don't integrate with Entra ID natively, smart card authentication that requires on-premises PKI, and some government compliance frameworks that mandate on-premises authentication for sovereign data access.

For organizations without these requirements, federation is legacy. Microsoft's guidance explicitly recommends migrating from AD FS to PHS. MSA1.5 covers the migration path.

Assessing your hybrid architecture

Run the sync configuration query against your own tenant. If OnPremisesSyncEnabled is False, you.re cloud-only — the hybrid architecture decisions (sync engine, auth method) don.t apply to your environment directly, but understanding them is essential reference knowledge for assessing other organizations. If True, the output tells you exactly what.s configured.

Check your sync method and configuration. If you recently migrated from legacy Entra Connect to Cloud Sync, verify the migration was complete: are all users syncing correctly? Is PHS active? Is password writeback enabled? Has the legacy sync server been decommissioned? Is hard-match takeover protection enabled? Each unanswered question is a potential risk register entry.

But the legacy Entra Connect server hasn't been decommissioned. It was powered off but not removed from the domain. Its Entra Connect service account still exists in both on-premises AD and Entra ID. The service account's permissions haven't been revoked. If someone powers the server back on — or if an attacker accesses it — the service account could potentially interfere with the Cloud Sync configuration or be used to authenticate to Entra ID with directory sync permissions.

This is a documented risk register entry. The remediation is straightforward: decommission the server, disable the service account in both AD and Entra ID, and verify that no stale sync configuration references it. MSA1.11 documents this.

ADR-MSA1-002: Hybrid identity architecture — Cloud Sync with PHS

Context. the tenant has a single Active Directory forest with 4 domain controllers across 3 AD sites. 723 user accounts synced to Entra ID. Organization migrated from legacy Entra Connect to Cloud Sync in September 2025. Legacy server not yet decommissioned.

Current sync configuration evidence:

(Get-MgOrganization).OnPremisesSyncEnabled            # True
(Get-MgOrganization).OnPremisesLastSyncDateTime        # 2026-05-05T06:14:22Z
# Feature flags (summarized — see full output above):
# passwordSyncEnabled: True
# passwordWritebackEnabled: True
# blockCloudObjectTakeoverThroughHardMatchEnabled: True
# deviceWritebackEnabled: False
# cloudKerberosTrustEnabled: False

Decision. Maintain Cloud Sync with Password Hash Sync as the hybrid identity architecture. Two Cloud Sync agents deployed on separate domain-joined servers at the Manchester site, both treated as Tier 0 infrastructure. Password writeback enabled for SSPR. No PTA agents. No federation. Legacy Entra Connect server to be decommissioned and its service account disabled in both AD and Entra ID (risk register entry MSA1-RISK-003).

Alternatives Considered.

• Revert to legacy Entra Connect Sync — rejected. Microsoft has stated Cloud Sync is "the long-term solution for directory synchronization" and will begin phased transition notifications from July 2026. the organization's topology (single forest, no hybrid Exchange, no device writeback requirement) is fully supported by Cloud Sync. Reverting increases future migration burden without addressing any current gap.
• PTA instead of PHS — rejected. the tenant has no regulatory requirement prohibiting cloud-stored password hashes. PHS provides full Identity Protection coverage for all synced users. PTA would add 2–3 on-premises agent servers as Tier 0 attack surface, introduce on-premises dependency for cloud authentication, and reduce Identity Protection's risk detection effectiveness — with no corresponding security benefit for the organization's compliance requirements (ISO 27001 and Cyber Essentials Plus neither prohibit PHS).
• Federation (AD FS) — rejected. the tenant has no third-party MFA requirement, no smart card authentication, and no compliance framework mandating on-premises authentication. AD FS would add minimum 4 on-premises servers (2 AD FS + 2 WAP), SSL certificate management, and the most complex failure mode of the three options. NE doesn't have the infrastructure team capacity for AD FS operational maintenance.
• Disable password writeback — considered but retained. Writeback enables SSPR, which reduces helpdesk load and improves user experience. The security risk (cloud compromise → on-premises password change) is mitigated by requiring MFA for all password reset operations (MSA2) and monitoring writeback events in the Entra audit log.

Consequences.

• Enables: Full Identity Protection risk evaluation for all synced users. Cloud authentication resilience if on-premises network fails. Simplified sync infrastructure (lightweight agents, cloud-managed configuration). 2-minute sync cycle for near-real-time attribute propagation. High availability via multiple agents. Future alignment with Microsoft's strategic direction.
• Requires: Cloud Sync agent servers treated as Tier 0 (hardened OS, restricted logical and physical access, dedicated admin workstations, security event log monitoring, alerting on service account activity). Password writeback events monitored and alerted on. Legacy Entra Connect server and service account decommissioned.
• Dependencies: PHS requires healthy domain controllers for initial and ongoing hash replication. Cloud Sync agents require network connectivity to at least one DC and outbound HTTPS to Entra ID.

Residual Risk. PHS means the derived password hashes in Entra ID originate from the same NTLM hashes in on-premises AD. An on-premises domain compromise (DCSync, ntdsutil) gives the attacker the source material. If the attacker cracks the NTLM hash, they have the cloud password. Mitigation: phishing-resistant MFA (MSA2) makes the password irrelevant for cloud authentication. Device compliance (MSA3) blocks authentication from unmanaged devices even with a valid password. The password becomes a legacy factor that will eventually be eliminated by passwordless authentication.

Communication. "Our directory sync uses Microsoft's recommended cloud-based engine with passwords validated in the cloud. This gives us the strongest threat detection capability for all synced users and means cloud services stay accessible even if the Manchester office network goes down. We're decommissioning the old sync server that's no longer needed — removing an unnecessary attack surface."

Before moving on, verify your understanding: Run the sync configuration query against your tenant. If no sync is configured (cloud-only tenant), explain what each of the three ON flags in the NE example output means and why they're architecturally significant. Explain why PHS provides stronger Identity Protection coverage than PTA. Be specific — name the risk detection capability that is available with PHS but reduced with PTA, and explain the technical reason for the difference.

Reusable script — the commands from this sub assembled for operational use:

Copy ADR-MSA1-002 into your architecture package at 01-identity/adrs/ADR-MSA1-002-hybrid-identity.md. If you're building a parallel package for your own organization, write the equivalent ADR. The key queries for your Context field:

# Sync status and health
$org = Get-MgOrganization
$org | Select-Object OnPremisesSyncEnabled, OnPremisesLastSyncDateTime

# Feature flags
(Invoke-MgGraphRequest -Method GET `
  -Uri "https://graph.microsoft.com/v1.0/directory/onPremisesSynchronization"
).value.features

# Synced user count
(Get-MgUser -All -Filter "onPremisesSyncEnabled eq true" `
  -ConsistencyLevel eventual -CountVariable c).Count

# Check for PTA agents (indicates legacy Entra Connect)
Get-MgServicePrincipal -Filter "displayName eq 'Microsoft Azure AD Connect'" |
  Select-Object DisplayName, AppId

Your ADR should document: which sync engine, which authentication method, which feature flags are enabled (and why), what alternatives were rejected (with specific constraint-based reasons), and what residual risks are accepted.