I count myself lucky every now and again, for many reasons.  I have my health.  I have my wonderful family.
Today, however, it’s finding out the latest version of AAD Connect (v1.1.524.0) will probably give me back a few more months of my life.
The reason?  My customer’s chosen configuration of their AAD Connect to choose the default value of ‘ObjectGUID’ for their ‘SourceAnchor’ value.
Now, for most organizations with a single AD forest, you’re laughing.  No reason to keep reading.  Log off, go outside, enjoy the sunshine (or have a coffee if you’re in Melbourne).
But no, my customer has TWO AD forests, synchronizing to a single Azure AD tenancy.
OK? What’s the big deal?  That’s been a supported configuration for many years now.
Well…… when they configured their AAD Connect they chose to use ‘ObjectGUID’ as their ‘SourceAnchor’ value:
Why is this an issue? 
I’m trying to MIGRATE a user from one forest to another.   Has the penny dropped yet?
OK, if not, let me extract and BOLD these scary dot points from this Microsoft Support Article (https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-design-concepts#sourceanchor):

  • The sourceAnchor attribute can only be set during initial installation. If you rerun the installation wizard, this option is read-only. If you need to change this setting, then you must uninstall and reinstall.
  • If you install another Azure AD Connect server, then you must select the same sourceAnchor attribute as previously used. If you have earlier been using DirSync and move to Azure AD Connect, then you must use objectGUID since that is the attribute used by DirSync.
  • If the value for sourceAnchor is changed after the object has been exported to Azure AD, then Azure AD Connect sync throws an error and does not allow any more changes on that object before the issue has been fixed and the sourceAnchor is changed back in the source directory.

Ok another link:
By default, Azure AD Connect (version 1.1.486.0 and older) uses objectGUID as the sourceAnchor attribute. ObjectGUID is system-generated. You cannot specify its value when creating on-premises AD objects.
OK, just un-install and re-install AAD Connect.   No big deal.  Change Window over a weekend.  Get it done.
No, no, no.  Keep reading.
If you browse to page 6 of this very helpful (and I’ll admit downright scary migration blog), you’ll see this text:
You need to delete your users from Azure Active Directory and you need to start again.
Come again?!. Ok.  In the word’s of the great ‘Hitchhiker’s Guide to the Galaxy’:  DON’T PANIC.
Yes. So. That is one option (sic) however the MS blog does into detail (albeit not tested by me) of another method, namely changing the ‘SourceAnchor’ value away from ‘objectGUID’ in a new installation of AAD Connect by also changing all your users UPN values to ‘onmicrosoft.com’ values, removing then installing a version of AAD connect, then changing their UPN values back to their original values.
But yeah, scary stuff.  Doing this for all users in a very large organization?  Positively terrifying (hence the start of this article).   With an Azure AD that integrates with Exchange, Skype for Business and a basically 24×7 global user base.  Well….you get my drift.
So good news?  Well, the new version supports the migration of ‘SourceAnchor’ values to the use of the positively joyous: msDS-ConsistencyGuid
So back to my original context, why is this important?  Well, looky here …I can see you msDS-ConsistencyGuid  (using ADSIEdit.msc):
The reason I’m excited – it’s a ‘writeable attribute’.
So forward sailing boys.  Let slip the anchor.  Let’s get sailing while the tide is high.
(In other words):
I’m going to:

  1. I’m going to upgrade my customer’s AAD Connect
  2. Ensure during the upgrade, that I migrate ‘SourceAnchor’ option in the AAD Connect wizard to use the new msDS-ConsistencyGuid  value in AD.
  3. Ensure all users (in both AD forests) have a new & unique  value after AAD connect performs a full sync and export to both domains.
  4. Ensure my Active Directory Migration Tool (or PowerShell migration script) moves the users msDS-ConsistencyGuid value from one forest to another (as well as retaining SIDHistory and passwords)
  5. And always: Test, test, test – to ensure I don’t lose their Azure AD account in the process.

Cross fingers this all works of course.  There’s very little guidance out there that combines ADMT guidance with this latest AAD Connect versioning.  It’s not explicitly stated in the AAD Connect online documentation, but it suggests that Microsoft have made changes on the Azure AAD ‘cloud’ side of the equation to also migrate unique joins to use this new value during the upgrade.
So upgrading AAD Connect and selecting to use msDS-ConsistencyGuid as your new ‘SourceAnchor’ SHOULD also trigger some back end changes to the tenancy as well (I’m hoping).
As you know, There’s nothing worse than a good plan and design spoiled by one little bug in implementation.  So come back for a future blog or two on my perilous journey argh me maties.. (er, customer project friends).

ADFS, Azure Infrastructure, Cloud Infrastructure, Identity and Access Management

Join the conversation! 9 Comments

  1. Hi, do you have a script or solution for setting write (back) access on the msds-ConsistencyGuid attribute for the AD Connect service account if using Custom installation ?

  2. Excellent article and very timely for me.

  3. The latest 1.1.553.0 version supports updating the source anchor from objectguid to ms-ds-consistencyguid, by clicking on the “Update” button in AADConnect. But can you tell me what to change in the claims in ADFS? I cannot seem to find a definitive answer to that.

  4. Nice article. Really appreciate the details you went into.

  5. So Pearny, how did it go ? tell me it was seamless 😉
    We are about to do the same thing (SVH).. guidance looks like it should be a straight forward upgrade of AD Connect.. in theory
    David Frith

  6. My organization currently has one forest. You were saying this shouldn’t affect us, but if we believe we have the possibility to be multi-forest in the future, should we migrate our sourceAnchor?

    • Hi Matt, if you have the possibility of changing forest design in the future, i would recommend exploring source anchor changes then as part of a larger overall identity architecture. You shouldn’t change the design now for the sake of it.

  7. Hi,
    How AAD Connect transforms employeeID(from AD) as SourceAnchor to ImmutableID(to Azure AD)? In case of ObjectGUID as SourceAnchor , it will converts sourceAnchor to base64string and stores in ImmutableID of the corresponding user.

  8. Firstly, This should only be an issue if you are migrating users between forest with the same objectGUID. The GUID address space is quite something the chances of a duplicates “To put these numbers into perspective, one’s annual risk of being hit by a meteorite is estimated to be one chance in 17 billion,[32] that means the probability is about 0.00000000006 (6 × 10−11), equivalent to the odds of creating a few tens of trillions of UUIDs in a year and having one duplicate”
    Secondly, contacts, groups etc still use the objectGUID.
    Thirdly, watchout for the new schema update for Windows Server 2016 attribute called msDS-SourceAnchor has been added.

Comments are closed.