In part 3a, we explained how ADFS can be used in cross-forest migrations to ensure all users (migrated or not) can still authenticate. In part 3B we will be looking at Pass-Through authentication and how it affects migrated/non-migrated users. First of all, we need to make sure we have pass-through authentication agents deployed. In my […]
To continue our coverage of ADMT and AAD, part three of the series. I know I promised 3 articles, but given the amount of data, I’ll split part 3 (authentication) in a few more posts.. We have 1 AAD and 2 AD’s; FORESTOOT.local as the source and TARGET.local is still the target AD forest. There […]
Paul Williams talked in his blog about using another attribute from on-premises Ad’s to act as the ImmutableID for Azure Active Directory (http://blog.msresource.net/2014/03/10/windows-azure-active-directory-connector-part-3-immutable-id/)
While making a very detailed blog entry on why and which attribute to choose, there wasn’t a guide on how to make this work in AADSync.
[update 21-Aug-2017: The latest version of Azure AD Connect have the functionality built-in to select the ImmutableID. There is no need to hack the rules manually anymore.. read more about it at: http://blog.azureinfra.com/2017/08/21/immutableid-ms-ds-consistencyguid-adconnect-final-part/]
So a recent project got me thinking about this. In this particular scenario there is already a forest (1 domain) using DirSync to replicate their users to AAD, and the requirement is to prepare for an AD migration, while also adding other users to the same AAD tenant. As usual, user objects might be duplicate between the two forests and we want to use the mS-DS-ConsistencyGuid attribute to be the immutableID.