Azure AD Connect source anchor in cross forest migration

Question

Hi @all ,

currently we are migrating users from multiple source AD forests to one target AD forest while already using Office 365. The workflow has been as follows:

1. Configure Azure AD Connect sync rules for filtering objects by extensionattribute15 (contains 'Office365')
2. Set attribute for objects in the source AD forest that should be synced
3. Migrated mailboxes from on-prem Exchange to Exchange Online
4. Migrated user objects from source AD forest to target AD forest via ADMT

The source anchor is ms-DS-ConsistencyGUID which is the same for source AD and target AD user.

So there should be a match between source, target and cloud user.

Then we prepared to shut down the source AD forest and cleared the extensionattribute15 - sync still works.

After that we ran into some minor issues with duplicate proxy addresses with some users and therefore temporarily removed sync for the affected target AD users by clearing the extensionattribute15 and re-added it after a sync.

But then, the cloud user was not matched to the target AD user anymore.

Instead, a new cloud user was created creating more duplicate issues.
We then had to remove the sync again, modify the immutable ID of the cloud user to match the objectGUID of the target AD user (matched the source AD user as the initial sync was done with the source AD forest) and sync again.

Voilà, the match worked again!

But this behaviour is strange because we chose ms-DS-ConsistencyGUID to be the source anchor, not the objectGUID.
ConsistencyGUID is the same for source and target so we wonder now why this happened.

Can anyone give us a hint if we are missing something or have to configure anything else to get this working?
We want to avoid modifying all immutable IDs as this will cause massive downtime for users and extensive work for us.

Best regards
Ben

Answer 1

Can you clarify on what the question is?

It sounds like it's working properly, but instead of using the msd-dsconsistencyguid source anchor, it's using the objectGUID?

By default per the docs here :
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/plan-connect-design-concepts#using-ms-ds-consistencyguid-as-sourceanchor

Azure AD Connect (version 1.1.524.0 and after) now facilitates the use of ms-DS-ConsistencyGuid as sourceAnchor attribute. When using this feature, Azure AD Connect automatically configures the synchronization rules to:

Use ms-DS-ConsistencyGuid as the sourceAnchor attribute for User objects. ObjectGUID is used for other object types.

For any given on-premises AD User object whose ms-DS-ConsistencyGuid attribute isn't populated, Azure AD Connect writes its objectGUID value back to the ms-DS-ConsistencyGuid attribute in on-premises Active Directory. After the ms-DS-ConsistencyGuid attribute is populated, Azure AD Connect then exports the object to Azure AD.

Please remember to mark one of the responses as answer if your question has been answered. If not please let us know if there are anymore questions. Thanks

Answer 2

Hi Frank,

the question is: why does the cloud user lose sync with the target AD user when the source AD user is removed from sync (i.e. by deleting it)?

Azure AD Connect uses ms-DS-ConsistencyGUID to match users and it is the same for source AD and target AD user.

The workaround is to manually reconfigure the cloud user immutable ID with the target AD user's objectGUID, then the sync works again. But this cannot be the solution.

Best regards
Ben

Answer 3

You experience this behavior because of three reasons:

1. Azure AD Connect writes the mS-DS-ConsistencyGUID during provisioning, e.g. when a user object comes into scope of Azure AD Connect the first time.
2. Azure AD Connect writes the Base64 representation of the value in the objectGUID attribute in the mS-DS-ConsistencyGUID attribute.
3. When you move a user object between Active Directory forests, the new user object in the destionation Active Directory forest has a different value for the objectGUID attribute than the user object in the source Active Directory forest.

Because the object falls out of scope of Azure AD Connect, Azure AD Connect will apply provisioning logic to the object when it comes back into scope. (1). It uses the value of the objectGUID attribute (which has changed, 3) to write a new value to the mS-DS-ConsistencyGUID attribute (2).

Because the new user object has a new mS-DS-ConsistencyGUID value, Azure AD Connect cannot hard-match the on-premises object to the cloud object. When you also removed e-mail addresses from the proxyAddresses attribute of the on-premises user object, soft-matching based on this attribute is also not possible, in which case Azure AD Connect creates a new cloud object.

Answer 4

Hi Sander,

the ms-DS-ConsistencyGUID is the same for both AD users (I verified that) but as it had been generated when syncing the source AD user for the first time, it matches the objectGUID of the source AD user - should not be an issue.

Nevertheless, we migrated the ConsistencyGUID with ADMT when moving the user to the target AD.
All other attributes like mail and proxyaddresses have been migrated via PowerShell.

So this is why I cannot understand this behaviour as both soft and hard match should work here.

Best regards
Ben

Answer 5

Not sure of your exact process but the hard match works in my case, the only time it doesnt is when I don't move the object out of sight of Azure AD connect in the source forest, at which point the metaverse gets two objects and creates a duplicate. In my setup we have one Azure AD connect with both forests added.

For this reason I do the following as part of the migration process.

1. Disable Sync scheduler (Set-ADSyncScheduler -SyncCycleEnabled $false)
2. Perform user migration from source to target forest
3. Move the source object out of sight of Azure AD connect
4. Re-enable sync scheduler (Set-ADSyncScheduler -SyncCycleEnabled $true)

In the case where I don't do step 1, sometimes the background sync kicks in whilst both source and target user accounts are in place. The conflict then leads to a duplicate account in the tennant.

If I follow step 1-4 above then the hardmatch of ms-DS-ConsistencyGUID takes place 100% of the time and the same Immutable ID exists in the tennat objects before and after the ADMT user migration.