Lesson 31 — Microsoft Entra Hybrid Identity Best Practices

Learning objectives

After completing this lesson, you should be able to assess and improve a Microsoft Entra hybrid identity design.

• Define the source of authority for each identity and attribute.
• Select an appropriate synchronisation and authentication model.
• Design high availability without creating conflicting writers.
• Protect synchronisation infrastructure and privileged access.
• Control scope, mappings and identity lifecycle changes.
• Monitor hybrid identity health and security indicators.
• Plan safe changes, migrations and rollback.
• Maintain a tested recovery and continuity plan.

The problem this solves

Many hybrid identity environments begin as a small synchronisation project and gradually become critical infrastructure without receiving the same architectural discipline as domain controllers, networks or authentication systems.

Best practices reduce hidden dependencies, conflicting ownership, single points of failure and emergency changes during incidents.

Principle 1 — Define authority

Every identity and important attribute should have one recognised source of authority. Administrators must know where a name, department, manager, UPN, mail address and enabled state should be changed.

Unclear ownership creates overwritten values, conflicting updates and slow incident response.

Authority questions

• Who creates the identity?
• Which system owns employment status?
• Where are names and departments corrected?
• Who owns UPN and mail-address standards?
• Which system disables leavers?
• Which attributes may be cloud-managed?

Principle 2 — Choose the right sync tool

Use Microsoft Entra Cloud Sync when its cloud-managed configuration, lightweight agents and multi-agent resilience fit the organisation's requirements.

Use Microsoft Entra Connect Sync when required features or complex synchronisation scenarios are not supported by Cloud Sync.

Avoid tool selection by habit

The correct decision should be based on supported topology, object types, writeback needs, filtering, transformation, operational model and migration constraints.

Document why the selected platform exists and review the decision as Microsoft Entra capabilities evolve.

Principle 3 — Simplify authentication

Select the least complex authentication method that satisfies business and regulatory requirements.

Password hash synchronization provides cloud authentication and strong service continuity because Microsoft Entra can authenticate users without contacting the on-premises environment during each sign-in.

Authentication dependencies

Pass-through Authentication validates passwords against on-premises Active Directory and therefore requires healthy authentication agents and connectivity.

Federation introduces additional infrastructure and should be retained only where there is a clear requirement that cannot be met with cloud authentication.

Principle 4 — Design for failure

Hybrid identity must continue operating when one server, agent, network path or administrator is unavailable.

Cloud Sync supports multiple active agents. Connect Sync environments should maintain a tested staging-mode server and a documented activation process.

Resilience is more than quantity

Redundant components should not share every dependency. Place agents or servers so one maintenance event, proxy failure or host problem does not remove the entire service.

Test failover rather than assuming that a second installation is usable.

Principle 5 — Protect the sync tier

Synchronisation servers and agents bridge two identity systems and should be treated as sensitive infrastructure.

Use dedicated supported hosts, restrict interactive access, minimise installed software and monitor administrative activity.

Administrative protection

• Use separate privileged accounts.
• Require MFA for cloud administration.
• Use Privileged Identity Management where available.
• Restrict local administrator membership.
• Protect service credentials and secrets.
• Record emergency access procedures.

Principle 6 — Control scope

Synchronise only the objects and attributes required by the approved design. Broad scope increases the blast radius of mistakes and can expose unnecessary directory information.

OU, group and attribute filters should have an owner, purpose and review date.

Scope-change discipline

• Measure expected object impact.
• Identify creates, updates and removals.
• Test with representative identities.
• Review privileged and service accounts.
• Record rollback steps.
• Monitor the first processing cycles.

Principle 7 — Use stable identifiers

Display names, departments and email addresses can change. Matching and investigation should rely on stable, unique identifiers wherever the supported design permits.

Duplicate or recycled values can create incorrect joins, duplicate cloud identities and difficult recoveries.

Naming and uniqueness

• Define a UPN naming standard.
• Validate mail and proxy-address uniqueness.
• Plan rename and rehire scenarios.
• Check active and deleted cloud objects.
• Avoid manual cloud repairs that conflict with sync.
• Retain object identifiers in incident evidence.

Principle 8 — Minimise customisation

Custom rules and transformations should exist only where a documented business requirement cannot be met by standard behaviour.

Every customisation increases testing, upgrade and troubleshooting complexity.

Customisation register

For each custom rule, record its owner, purpose, source and target attributes, test cases, dependencies, approval date and rollback method.

Remove obsolete rules rather than allowing years of undocumented logic to accumulate.

Principle 9 — Monitor continuously

Monitor agent health, configuration status, provisioning failures, skipped objects, duplicate values and unusual bulk changes.

Healthy infrastructure should produce expected recent activity—not merely show a green status at one point in time.

Correlate evidence

• Provisioning Logs
• Microsoft Entra Audit Logs
• Sign-in Logs
• Connect Health or agent status
• Windows and service logs
• Source Active Directory changes

Principle 10 — Govern the lifecycle

Joiner, mover and leaver processes must operate consistently across Active Directory and Microsoft Entra ID.

Disabling a source account, removing access, revoking sessions and managing retained data are related but separate controls.

Lifecycle evidence

• Approved employment event
• Source account creation or disablement
• Provisioning event and target result
• Group and role changes
• Session or token revocation
• Ticket closure and owner approval

Principle 11 — Use staged change

Authentication and synchronisation migrations should use controlled populations, measurable success criteria and a rollback plan.

A staged rollout allows the organisation to validate cloud authentication before changing the whole domain.

Migration controls

• Inventory current dependencies.
• Confirm feature compatibility.
• Select representative pilot users.
• Synchronise required password data first.
• Measure sign-in and provisioning outcomes.
• Remove old infrastructure only after validation.

Principle 12 — Prepare recovery

Document how to restore synchronisation, activate standby capacity, replace an agent, recover credentials and validate the target after an incident.

Recovery documentation should be usable by another authorised administrator under pressure.

Recovery package

• Architecture and data-flow diagram
• Server, agent and configuration inventory
• Secure credential recovery process
• Standby or replacement procedure
• Known custom rules and dependencies
• Post-recovery validation checklist

Security indicators

• Unexpected changes to synchronisation scope or rules.
• New privileged accounts entering scope.
• Unapproved agent or connector registration.
• Bulk mail, UPN or ownership changes.
• Administrative access from standard workstations.
• Removal of monitoring or loss of log activity.

Operational indicators

• Only one functioning agent or sync server.
• No tested failover procedure.
• Undocumented custom rules.
• Stale or unsupported components.
• Recurring duplicate-value failures.
• Unclear ownership for source attributes.

Common mistakes

• Treating synchronisation as a set-and-forget service.
• Allowing multiple systems to own the same attribute.
• Keeping federation without a current requirement.
• Calling an untested server a standby.
• Synchronising more objects and attributes than necessary.
• Using permanent privileged access for routine support.
• Retiring old infrastructure before proving the replacement.

Best practices

• Prefer simple, supportable architecture.
• Document authority, scope and matching.
• Use redundant and independently tested components.
• Protect the synchronisation tier as identity infrastructure.
• Baseline normal provisioning behaviour.
• Stage high-impact changes and migrations.
• Exercise recovery before an outage.