Topology and Deployment

Before installing Connect Sync, you need two decisions: which topology matches your AD environment, and which authentication method to use. Getting these wrong is expensive to fix later because topology changes typically require rebuilding the sync server from scratch.

Supported Topologies

Single Forest, Single Tenant

The most common deployment. One AD forest (with one or multiple domains) syncs to one Entra ID tenant. Express install handles this automatically with password hash sync enabled.

When to use: Most organizations with a single AD forest and a single Entra tenant.

Multiple Forests, Single Tenant

Multiple AD forests sync to one Entra tenant through a single Connect Sync server. The server must be able to reach all forests (domain-joined to one, with trust or credential-based access to the others).

Common variants:

• Separate topologies - each forest has unique users; no overlap between forests.
• Full mesh with GALSync - users exist in one forest, contacts representing them exist in others. Identity matching uses the mail attribute.
• Account-resource forest - user accounts live in one forest, Exchange/Lync resources in another. Matching uses objectSID and msExchMasterAccountSID.

When to use: Post-merger environments, organizations with dedicated resource forests, or multi-region AD deployments.

Staging Server

A second Connect Sync server installed in staging mode. It imports and syncs data but never exports. This gives you:

• Disaster recovery - promote the staging server to active if the primary fails.
• Configuration testing - preview the effect of rule changes before they hit production.
• Server replacement - prepare a new server, verify its sync output, then swap.

You can have more than one staging server, but only one active server should export to a given Entra tenant at any time.

Multiple Tenants

Each Entra tenant requires its own Connect Sync server. A single AD forest can sync to multiple tenants, but each server runs independently with its own scope and rule set. Only one tenant can receive writeback for a given object.

Unsupported Topologies

• Multiple active sync servers to one tenant (except staging). Two active servers writing to the same tenant causes conflicts and data corruption.
• Split-forest sync where two servers each handle a subset of objects from the same forest. Not supported even with mutually exclusive filters.

Topology Decision Guidance

flowchart TD
    A[How many AD forests?] -->|One| B[How many Entra tenants?]
    A -->|Multiple| C[Can one server reach all forests?]
    B -->|One| D[Single forest, single tenant]
    B -->|Multiple| E[One Connect Sync server per tenant]
    C -->|Yes| F[Multi-forest, single server]
    C -->|No| G[Review network or consider Cloud Sync]
    D --> H{Need disaster recovery?}
    F --> H
    H -->|Yes| I[Add staging server]
    H -->|No| J[Done]
    I --> J

The key constraint is that one Entra tenant gets one active sync server. Everything else follows from that.

Authentication Mode Choices

The authentication method determines how users prove their identity when signing into cloud resources. Connect Sync handles object synchronization regardless of which method you pick, but your choice affects what gets installed alongside it.

Password Hash Sync (PHS)

Connect Sync extracts password hashes from AD and syncs them to Entra ID. Users authenticate directly against the cloud with the same password they use on-premises.

Pros:

• Simplest to deploy - no additional infrastructure.
• Highest availability - cloud authentication scales automatically.
• Enables Entra ID Protection features (leaked credential detection).
• Works as a fallback if you later switch to PTA or federation.

Cons:

• Password changes take up to 2 minutes to sync (delta cycle timing).
• On-premises account states (locked, expired, disabled) do not take immediate effect in the cloud until the next sync cycle.

Best for: Most organizations, especially those without regulatory requirements mandating on-premises password validation.

Pass-Through Authentication (PTA)

Lightweight agents installed on-premises receive authentication requests from Entra ID and validate them against the local AD domain controller. Passwords never leave the on-premises environment.

Pros:

• Passwords stay on-premises - addresses some compliance concerns.
• On-premises account policies (lockout, sign-in hours, password expiry) apply immediately.

Cons:

• Requires at least one (ideally multiple) PTA agents with network access to domain controllers.
• If all PTA agents are unreachable, cloud sign-in fails (unless PHS is enabled as fallback).
• Does not support Entra ID Protection leaked-credential reports without also enabling PHS.

Best for: Organizations with strict requirements around password residency or immediate enforcement of on-premises account states.

Federation (AD FS or Third-Party)

Authentication is redirected entirely to an on-premises federation server (AD FS, PingFederate, or another SAML/WS-Fed provider). Entra ID trusts tokens from the federation server.

Pros:

• Full control over the authentication flow - supports smartcard auth, third-party MFA, and complex claim rules.
• Required for some legacy scenarios (certain third-party MFA solutions, on-premises MFA servers).

Cons:

• Highest infrastructure cost - requires federation servers, WAP proxies, TLS certificates, and monitoring.
• Operational complexity - certificate rotation, server patching, and capacity planning.
• Microsoft is actively steering customers away from AD FS toward cloud-native alternatives.

Best for: Organizations with existing AD FS investments that require features only federation provides, or those using third-party federation providers.

Authentication Decision Summary

Recommendation: Start with PHS unless you have a specific requirement for PTA or federation. You can layer PTA or Seamless SSO on top of PHS later. Always enable PHS as a fallback even when using PTA or federation.

Deployment Planning Checklist

Before installing Connect Sync:

1. Identify your topology using the flowchart above.
2. Choose your authentication method and confirm any infrastructure prerequisites (PTA agents, AD FS servers).
3. Verify network connectivity - the sync server needs LDAP access to all AD forests and HTTPS outbound to Entra ID endpoints.
4. Decide on a source anchor - ms-DS-ConsistencyGuid is the default and recommended choice. Changing the source anchor after initial sync is painful.
5. Plan service accounts - the installer creates the AD DS connector account and the Entra connector account. Understand their permission requirements.
6. Plan staging server if you need disaster recovery or want safe configuration testing.
7. Review hardware requirements - CPU, RAM, and disk depend on the number of objects. The built-in SQL Express supports up to 100,000 objects; larger environments need full SQL Server.