question

benk avatar image
0 Votes"
benk asked ·

Azure AD Connect source anchor in cross forest migration

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






azure-active-directory
10 |1000 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

FrankHuMSFT-3200 avatar image
0 Votes"
FrankHuMSFT-3200 answered ·

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://docs.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

· Share
10 |1000 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

benk avatar image
0 Votes"
benk answered ·

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

· Share
10 |1000 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

SanderBerkouwer avatar image
0 Votes"
SanderBerkouwer answered ·

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.

· Share
10 |1000 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

benk avatar image
0 Votes"
benk answered ·

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

· Share
10 |1000 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

AmayacittaGill avatar image
0 Votes"
AmayacittaGill answered ·

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.



· Share
10 |1000 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

benk avatar image
0 Votes"
benk answered ·

Hi,

thanks for your reply!

We did some testing in the meantime (deleting user in the source forest/disconnected source forest/etc.) and have come to the conclusion that the issue was somehow related to the duplicate proxy addresses, because we did not have this issue with any other user during testing.

We assume that the following happened:
- Office 365 reported duplicated proxy addresses (in this case, soft match will not work)
- We removed sync from the user and added it again - soft match did not work
- Hard match compared immutable ID and objectGUID from target user which is not matching - new user was created
- Manually modified immutable ID to match objectGUID of target user - sync works again

Maybe this has something to do with rule priority in Azure AD Connect (target AD is synced last so source objects do not count anymore).



· Share
10 |1000 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

BocarFofana-0865 avatar image
0 Votes"
BocarFofana-0865 answered ·

Hello Benk,

I'm facing the same kind of migration you described.
I have to consolidate several AADC-synchronized forests into one single forest.

Is that you can share with me the different ways you followed to migrate users to the new forest and make the match with AADC.

I'm available if you want to talk privately.

Thank you in advance.

Regards

· Share
10 |1000 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

benk avatar image
0 Votes"
benk answered ·

Hi BocarFofana-0865,

the process is pretty straight-forward:
1. Configure Azure AD Connect to sync user from source forest
2. Migrate Exchange mailbox via HCW or 3rd party tool, if existing
3. Migrate user from source to target forest via ADMT or 3rd party tool - user object in target forest should have the same ms-DS-Consistency-GUID as the source user
4. Depends on the environment (i.e. migrate client from source to target forest so that user must login with new user, etc.)
5. Remove user from source environment (or disable it but removing will show if the migration was successful and AADC only takes the target account for syncing now)


Regards
Ben






· Share
10 |1000 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.