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?
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?