Partager via

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

  • Article

Update 25th May 2017:- As of AAD Connect May 2017 release, version 1.1.524, the default sourceAnchor used by the setup wizard is mS-DS-ConsistencyGuid. This renders most of this blog post series moot but it will be maintained for reference.

 

This blog post series is based upon and tested with AAD Connect, December 2016 release, version 1.1.380.0. 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 == "https://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
 => issue(store = "Active Directory", types = ("https://schemas.xmlsoap.org/claims/UPN", "https://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

  • Anonymous
    April 10, 2017
    Your information is based upon a multi-forest scenario. What about a single forest wanting to use the Pass-Through Authentication in connection with Modern Auth.?
    • Anonymous
      April 10, 2017
      Hi SvenPass-Through Authentication has its own set of requirements. I'm sure you've looked at it but the documentation is here - https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-pass-through-authentication.As far as the sourceAnchor is concerned, the role it plays is matching an identity object in your on-premises Active Directory with an identity object in your Azure Active Directory for the purpose of synchronisation.When it comes to authentication using Pass-Through, the UPN is the important attribute. AAD will look at the UPN being presented by the user and choose the Pass-Through connector matching the UPN suffix. The connector then attempts to authenticate the user against the on-premises Domain Controller using that same UPN. The on-premises DC needs to be able to match that UPN to the user object in the on-premises Active Directory for authentication to succeed.So the short story is that the on-premises UPN has to match the AAD UPN (and this is separate to sourceAnchor).HTHMark