Choosing a sourceAnchor for Multi-Forest Sync with AAD Connect – Part 7, Migrating Users


This blog post series is based upon and tested with AAD Connect, December 2016 release, version 1.1.380.0. Future AAD Connect releases may alter behaviour or expose new features that render this series redundant. Test all deployment designs before production implementation.

Table of Contents

Part 1, Introduction

Part 2, Lab Setup

Part 3, An Aside on EmployeeID

Part 4, Using msDS-SourceAnchor

Part 5, Using mS-DS-ConsistencyGuid

Part 6, Moving off objectGuid

Part 7, Migrating Users

Changing Issuance Transform Rules for O365

If your Azure Active Directory tenant is federated with an on-premises federation service (AD FS for example), you’ll need to make one last configuration change before you migrate users. This final step is to ensure your O365 Relying Party Trust Issuance Transform Rule for ImmutableID uses the attribute you’ve chosen (msDS-SourceAnchor or mS-DS-ConsistencyGuid) instead of objectGuid.

I’ll provide an example using AD FS on Windows Server 2016 –

Open the AD FS Management console

In the left-hand pane, select Relying Party Trusts

In the central pane, right-click Microsoft Office 365 Identity Platform and select Edit Claim Issuance Policy

sa34

Edit the transform rule replacing objectguid with msds-sourceanchor or ms-ds-consistencyguid depending on the attribute you’re using –

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
 => issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/claims/UPN", "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"), query = "samAccountName={0};userPrincipalName,objectguid;{1}", param = regexreplace(c.Value, "(?<domain>[^\\]+)\\(?<user>.+)", "${user}"), param = c.Value);

Save the rule changes

Tools

I’m going to assume you’re using the Active Directory Migration Toolkit (ADMT). This is what I’ve tested with and can confirm works.

Migration Process

Here, I won’t be stepping through the use of ADMT. That’s not what I want to discuss. I just want to make the migration process clear so that you don’t lose any objects. Here we go –

  1. Keep the user objects you want to migrate between Forests in scope for AAD Connect synchronisation. By this I mean, leave it in an OU that AAD Connect is synchronising
  2. Migrate the users so that they are also in scope for AAD Connect synchronisation in the destination Forest – they should land in an OU that AAD Connect is synchronising
  3. Make an edit to a replicated attribute on the destination user object and validate that this shows up in the Azure Active Directory tenant after the next sync cycle (Description attribute for example)
  4. Move the object out of scope for AAD Connect synchronisation in the source Forest (and potentially delete/decommission it)

Example

I start with my synchronised users. I’m going to migrate forest2user over to forest1.com

sa29

Source user is in a synchronised OU –

sa30

After migration, the user object is in a synchronised OU –

sa31

At this point, both objects are synchronising into a merged object in the AAD Connect Metaverse. An attribute change on either object will propagate to the Azure Active Directory tenant. I make an edit to the Department attribute on the destination user object –

sa32

And now I see this after a sync in the Azure Active Directory tenant –

sa33

I am now able to decommission the user object in the source Forest.

Conclusion

This series has covered the proper use of a sourceAnchor for an AAD Connect deployment synchronising multiple Forests to an Azure Active Directory tenant. With the right configuration, user migration between Forests is successful without object duplication in the tenant.

Comments (0)

Skip to main content