Hybrid identity on Azure Local is not one sign-in system stretched across cloud and datacenter. It is a set of related identity planes that must be designed together without being confused with one another.
Microsoft Entra ID can authenticate access to Azure resources and supported applications. Active Directory Domain Services can continue to authenticate Windows workloads and legacy applications. Microsoft Entra Connect Sync or cloud sync can synchronize selected directory objects. Azure role-based access control authorizes management-plane actions. Guest operating systems and applications still require their own supported identity and authorization paths.
The architecture becomes safer when every sign-in is mapped to the plane that actually validates it.
TL;DR
- Decide which directory is authoritative for each identity and attribute.
- Choose Microsoft Entra Cloud Sync or Connect Sync from current capability requirements—not from a generic “new versus old” rule.
- Choose password hash synchronization, pass-through authentication, or federation from resilience, security, and operational constraints. Microsoft recommends password hash synchronization for most organizations.
- Use Microsoft Entra ID and Azure RBAC for supported Azure management actions on Azure Local resources.
- Keep workload authentication separate: many guest VMs and applications still use AD DS, local identity, or their own identity provider.
- Apply Conditional Access only to supported Microsoft Entra sign-in paths. It is not a network firewall and does not inspect NSG traffic.
- Separate administrative identities from everyday accounts and minimize standing privilege.
The five identity planes
| Plane | Primary question | Typical control |
|---|---|---|
| Source identity | Where is the authoritative person, device, service, group, and attribute record? | AD DS, Microsoft Entra ID, HR source, workload directory |
| Synchronization | Which objects and attributes move between directories, in which direction, and with what failover? | Microsoft Entra Cloud Sync or Connect Sync |
| Authentication | Which system validates the credential for this sign-in? | Entra cloud authentication, PTA, federation, AD DS, workload identity provider |
| Authorization | What may the authenticated identity do at this scope? | Azure RBAC, Entra roles, AD groups, local groups, application roles |
| Privileged access | How are sensitive roles activated, isolated, monitored, and recovered? | PIM, dedicated admin accounts, secure workstations, break-glass process, logging |
A diagram should show all five. A line labeled “Entra” without a resource, protocol, and authorization point is not enough.
Step 1: define source authority
For each object and important attribute, record the system of record. Include users, administrators, service identities, devices, groups, user principal names, email addresses, lifecycle state, and privileged-role eligibility.
Avoid bidirectional ownership ambiguity. If AD DS owns a synchronized user’s display name and department, changing those attributes only in Entra may be overwritten. If an application requires a cloud-only service principal or managed identity, do not invent an unnecessary on-premises account.
The design should state:
- who creates and disables identities;
- which identities are synchronized and which remain cloud-only or on-premises-only;
- how contractors, partners, and emergency accounts are handled;
- how duplicate identities are matched;
- which team approves group membership and privileged roles;
- how deletion, restore, and accidental changes are recovered.
Step 2: clean domains and sign-in names
Before synchronization, inventory forests, domains, trusts, UPN suffixes, proxy addresses, duplicate attributes, unsupported characters, stale accounts, and shared administrative identities.
Use a verified Microsoft Entra domain for the intended sign-in name. Do not assume an internal AD DNS suffix automatically produces a usable cloud UPN. Test identity matching and application behavior with a pilot group before broad synchronization.
Step 3: choose the synchronization engine
Microsoft’s current Cloud Sync decision guide compares capabilities rather than declaring one engine universally correct.
Consider Microsoft Entra Cloud Sync when
- lightweight agents and multiple active agents simplify availability;
- disconnected forests or merger-and-acquisition scenarios must synchronize without one server reaching every forest;
- the required object types, attributes, transformations, scale, and device scenarios are supported;
- cloud-managed configuration aligns with the operating model.
Consider Microsoft Entra Connect Sync when
- the topology or feature set requires capabilities not yet available in cloud sync;
- device synchronization or hybrid-join requirements depend on Connect Sync;
- existing transformations, Exchange hybrid requirements, or supported custom rules are still necessary;
- a staged server and established operational process already meet resilience requirements.
Document the exact feature dependency and revisit it periodically. Do not write that cloud sync has already replaced Connect Sync for every environment.
Step 4: choose the authentication method
Microsoft’s sign-in guidance recommends password hash synchronization for most organizations that need Microsoft Entra-based access to Microsoft 365, SaaS, and other cloud resources. The choice still depends on requirements.
| Method | Where credential validation occurs | Operational consideration |
|---|---|---|
| Password hash synchronization (PHS) | Microsoft Entra ID validates a derived password hash synchronized from AD DS | Lowest on-premises sign-in dependency; can also provide backup authentication for federated designs |
| Pass-through authentication (PTA) | Microsoft Entra ID brokers validation through on-premises agents to AD DS | Requires resilient agents and domain-controller connectivity; no inbound internet port is required for the agents |
| Federation | Microsoft Entra ID redirects authentication to a trusted federation system | Supports specific advanced requirements but adds highly available identity infrastructure and certificate/lifecycle dependencies |
Record outage behavior. If WAN connectivity, sync agents, domain controllers, or federation services fail, which users can still authenticate to which resources? Test the answer.
Step 5: separate Azure Local management from workload sign-in
Azure Local VMs enabled by Azure Arc are represented through Azure Resource Manager. Azure Local VM management supports Azure RBAC for authorized lifecycle actions such as creating or managing VMs and related resources.
That Azure authorization does not automatically sign a user into the guest operating system. Separate the paths:
Azure management plane
- Authenticated by Microsoft Entra ID.
- Authorized through Azure RBAC at management-group, subscription, resource-group, custom-location, or resource scope as supported.
- Logged through Azure control-plane activity and relevant platform diagnostics.
Azure Local host and fabric administration
- Uses the supported Azure Local, Windows Admin Center, PowerShell, or local management path for the operation.
- Requires platform-specific roles and credentials.
- Must remain available according to the site’s connected or disconnected operating model.
Guest and application access
- Uses AD DS domain accounts, local accounts, SSH keys, certificates, workload identity, Microsoft Entra integration, or application-specific identity according to what the guest and application support.
- Requires guest firewall, network segmentation, endpoint security, and application authorization.
Avoid phrases such as “Entra secures every Azure Local VM” unless the article names the exact supported sign-in integration.
Step 6: apply Conditional Access at the correct point
Conditional Access evaluates signals during supported Microsoft Entra access to a resource and applies decisions such as requiring stronger authentication or a compliant device.
Use it to protect Azure portal access, supported Microsoft Entra applications, administrative activation workflows, and other documented Entra-integrated entry points. Do not claim that Conditional Access:
- filters packets between VMs;
- is evaluated by an NSG or physical firewall;
- protects a local RDP or SSH listener that does not authenticate through Entra;
- replaces AD DS group policy, endpoint controls, or network segmentation.
Identity policy and network policy should reinforce each other while remaining distinct.
The companion Zero Trust architecture with Entra and Azure Local SDN guide shows how those layers can reinforce each other without blurring their enforcement points. For a deeper treatment of supported sign-in paths, see Conditional Access architecture for Azure Local.
Step 7: design privileged access separately
Microsoft’s privileged-access guidance recommends dedicated administrative accounts, least privilege, stronger authentication, and controlled activation of sensitive roles.
The companion guide to secure administrative access on Azure Local turns this identity model into a controlled device, gateway, network, and audit path.
For Azure Local and hybrid identity:
- Use normal accounts for email and daily work.
- Use separate accounts for Azure, Entra, AD DS, and platform administration as the privilege model requires.
- Prefer group-based Azure RBAC assignments at the narrowest practical scope.
- Use Privileged Identity Management where licensing and role support permit just-in-time activation.
- Require phishing-resistant authentication and secure administrative devices for high-impact roles.
- Maintain tested emergency accounts and a documented recovery process.
- Monitor role changes, group membership, failed activations, risky sign-ins, and direct local access.
Do not synchronize highly privileged on-premises identities merely for convenience. Define tier boundaries and prevent one compromised account from controlling both cloud and on-premises identity systems.
Step 8: monitor the whole identity path
A useful operations view includes:
- directory synchronization status and latency;
- connector or agent health;
- export errors, duplicate attributes, and quarantine conditions;
- authentication success, failure, and fallback state;
- Conditional Access results for supported Entra sign-ins;
- Azure RBAC and Entra role changes;
- privileged-role activations and emergency-account tests;
- AD DS replication, domain-controller health, and guest authentication;
- Azure Local resource bridge and management-plane health where relevant.
Green sync status does not prove that a user can reach and authenticate to an application. Test complete user journeys.
Modernize old identity scripts
The Azure AD, Azure AD Preview, and MSOnline PowerShell modules are deprecated. Microsoft’s migration guidance maps Get-AzureADUser to Microsoft Graph PowerShell cmdlets such as Get-MgUser.
For a read-only inventory example:
Connect-MgGraph -Scopes 'User.Read.All'
Get-MgUser -All -Property Id,DisplayName,UserPrincipalName,AccountEnabled |
Select-Object Id, DisplayName, UserPrincipalName, AccountEnabledUse least-privilege scopes, approved administrator identities, secure output handling, and change control. Treat sample code as a starting point and verify the current Graph module and permissions before production use.
Validation checklist
- Every identity and key attribute has one documented source of authority.
- Sync scope, filters, transformations, and deletion behavior are approved.
- Cloud Sync versus Connect Sync is supported by an explicit capability matrix.
- PHS, PTA, or federation has a tested outage and fallback design.
- Azure RBAC roles are group-based and narrowly scoped where practical.
- Guest and application authentication are documented separately from Azure management.
- Conditional Access claims name the exact protected resource and sign-in path.
- Privileged accounts, devices, activation, logging, and emergency access are tested.
- A pilot proves join, sync, sign-in, authorization, disablement, and recovery flows.
Final architecture principle
Hybrid identity succeeds when synchronization, authentication, authorization, and network access are deliberately connected—but never conflated. Use Microsoft Entra ID to protect supported cloud and management-plane access, AD DS or another supported provider for workload sign-in, Azure RBAC for Azure resource actions, and a hardened access path for administration.
That model makes both outages and security incidents easier to reason about because every control has an owner and an enforcement point.
1 thought on “Hybrid Identity for Azure Local: AD DS, Microsoft Entra, Sync, and Access Boundaries”