8.1 Preparing for Identity Synchronization & IdFix
Key Takeaways
Microsoft Entra Connect Sync requires an on-premises AD DS forest, a verified Entra tenant, and a dedicated sync server running Windows Server
The recommended sourceAnchor attribute is ms-DS-ConsistencyGuid rather than objectGUID because it survives user object portability across domain migrations
The on-premises UPN suffix must be a verified custom domain in Entra ID — the default .onmicrosoft.com suffix causes cloud UPNs to mismatch on-prem UPNs
IdFix scans on-premises AD for duplicate UPNs, duplicate proxyAddresses, malformed attributes, and empty required fields before synchronization is enabled
Synchronized identity is the most common model for hybrid shops; cloud-only identity removes on-prem dependency; federated identity adds an STS such as AD FS for authentication
Preparing for Identity Synchronization & IdFix
Quick Answer: Successful hybrid identity starts with preparation: stand up a healthy on-premises AD DS, verify a custom domain in the Entra tenant, pick a stable sourceAnchor (prefer
ms-DS-ConsistencyGuid), decide the sign-in and identity model, and run IdFix to clean duplicate and malformed attributes before you ever install a sync engine.
Prerequisites Checklist
Before installing any sync engine, confirm every prerequisite is in place. Missing one is the most common cause of a stalled deployment.
| Requirement | Why it matters |
|---|---|
| On-premises AD DS forest | The source directory; schema must be at least Windows Server 2012 R2 forest functional level |
| Entra tenant with Global Admin | The target tenant; the install account needs Global Administrator to write objects |
| Verified custom domain | The on-prem UPN suffix must be a verified, custom (non-onmicrosoft.com) domain in Entra |
| Sync server running Windows Server | A dedicated, domain-joined Windows Server 2016+ host (Connect Sync) or a provisioning-agent host (Cloud Sync) |
| Outbound connectivity | HTTPS to *.msappproxy.net, *.servicebus.windows.net, and the Microsoft 365 endpoints over TCP 443 |
| Local AD account for sync | Connector account with read/write permissions on the AD partitions being synchronized |
Choosing the Identity Model
Microsoft supports three identity models in Microsoft 365. The choice drives prerequisites, the sync engine you pick, and how users sign in.
- Cloud-only identity — Users exist only in Entra ID; no on-prem AD, no sync engine. Simplest to operate, but offers no parity with on-prem directories.
- Synchronized identity — On-prem AD is the source of truth; identity objects are provisioned into Entra ID via Entra Connect Sync or Cloud Sync. Passwords can flow with Password Hash Sync (PHS), or sign-in can be delegated via Pass-Through Authentication (PTA) or federation. This is the dominant model for enterprises with existing AD.
- Federated identity — Synchronized identity plus a Security Token Service (typically AD FS or a third-party IdP) that issues tokens. Entra ID trusts the STS for authentication. Choose federation when you need claims-based auth, smartcard/HAADJ sign-in, or on-prem MFA.
The sourceAnchor / immutableId Decision
Every synchronized object in Entra ID carries an immutableId that permanently anchors it to a source AD object. The attribute you map from AD becomes the sourceAnchor. Two are commonly used:
objectGUID— the legacy default. It is unique within a domain but changes when a user object is migrated between domains in the same forest, breaking the anchor.ms-DS-ConsistencyGuid— the recommended anchor. Microsoft documents it as the preferred sourceAnchor because it is portable across domain migrations within the forest, so the cloud link survives a cross-domain move.
Microsoft's guidance: during install, accept the sourceAnchor defaults option, which lets Connect pick ms-DS-ConsistencyGuid when it is populated and fall back to objectGUID otherwise. Once chosen, the sourceAnchor cannot be changed without re-syncing, so decide up front.
UPN Matching and the Verified Domain Rule
The on-premises userPrincipalName is synchronized to Entra ID and, by default, becomes the cloud UPN users type at sign-in. Entra ID will only accept the on-prem UPN suffix if it is configured as a verified custom domain in the tenant.
If the on-prem UPN suffix is contoso.com but only contoso.onmicrosoft.com is verified in Entra, the sync engine falls back to the .onmicrosoft.com UPN for cloud sign-in. Users then see one UPN on-prem and a different one in Microsoft 365 — a common support driver. Always add and verify the custom domain before enabling sync.
IdFix — Clean Before You Sync
IdFix (Microsoft Entra ID Fix) is a free tool you run against on-prem AD to find and fix directory errors before the first sync. Running IdFix early prevents the bulk of object-level sync errors that otherwise show up in Connect Health after sync is enabled.
IdFix scans for:
- Duplicate
userPrincipalNamevalues — two objects with the same UPN; Entra rejects the second - Duplicate
proxyAddresses— two mailboxes sharing an SMTP address - Malformed attribute values — invalid characters, non-RFC-compliant email format, trailing spaces
- Empty required attributes — missing
mail,displayName,sAMAccountNameon objects that sync rules require them on - Formatting issues — leading/trailing whitespace, case problems in UPN/mail
IdFix presents findings in a grid with Action and Update columns. You can accept IdFix's suggested fix (for example, blanking a duplicate proxyAddress) or edit the proposed value. Apply updates in batch, then re-run the tool until the error count is zero. Common remediations:
| IdFix error | Typical remediation |
|---|---|
| DuplicateUPN | Reassign a unique UPN to one of the two objects |
| DuplicateProxyAddress | Remove the duplicate SMTP: value from the object that should not own it |
| InvalidMail | Correct the malformed address or clear it if the object is not mail-enabled |
| EmptyRequiredAttribute | Populate mail, displayName, or sAMAccountName on the source object |
| FormatError | Strip whitespace, fix casing, or correct non-RFC characters |
Cleaning up front is dramatically cheaper than remediating conflicts after sync is live. Make IdFix part of the standard pre-install checklist.
You are planning a hybrid deployment where users may be migrated between domains in the same AD forest. Which sourceAnchor attribute should you choose?
ms-DS-ConsistencyGuid, because it remains stable across domain migrations within the forest
objectGUID, because it is the legacy default
userPrincipalName, because it is what users sign in with
proxyAddresses, because it is unique per mailbox
After enabling synchronization, users report that their Microsoft 365 sign-in UPN is user@contoso.onmicrosoft.com even though their on-prem UPN is user@contoso.com. What was missed during preparation?
Running IdFix before install
Installing the Connect Health agent on the sync server
Choosing Password Hash Sync instead of Pass-Through Authentication
Verifying contoso.com as a custom domain in the Entra tenant before sync
Sections you finish are checked off in the contents.