
We were recently asked for help by one of our clients that needed to separate a number of users from their existing domain by moving them into their own Active Directory forest. This can happen for all sorts of reasons, including divestments, security, geographical or division separation.
Whatever the reason, they needed to move these users across into an entirely new AD domain.
Now, although they were going to be moved into this new AD domain, they were still part of the same parent company and were going to remain within the same Azure AD tenant.
OK, doesn’t seem too hard, what’s the catch? Build the new domain, create a trust, move the users and resync them, job done.
Well, that was the plan until we looked into the configuration of AD Connect and discovered that the source anchor was set to the OBJECTGUID.
If you aren’t familiar with this, AD Connect uses the source anchor as a mechanism to “match” on-premises users with Azure AD users. In the newer versions of AD Connect the source anchor is usually set to the mS-DS-ConsistencyGuid which makes life easier.
However, older versions of AD Connect used the OBJECTGUID.
Now comes the problem. When a user is moved from domain1 to domain2, a new OBJECTGUID is created so when you try and sync them up again AD Connect will not recognise them as the same user and will create a new user account for that user. Even though technically it’s the same user, AD Connect does not see it that way because the ImmutableID is different.
The ImmutableID is the OBJECTGUID converted to Base64.
OK, so how do we get these users moved from domain1 into domain2 and have them sync with their existing Azure AD user?
You have to delete them…kind of.
Before we begin, I am assuming you have:
AD Trust in place between the original domain and the new domain
AD Connect has been configured to sync across both domains (if you don’t know how to do this, check out our other post explaining the process: https://www.smikar.com/second-domain-using-ad-connect)
Step 7.
If you are syncing the entire domain then you will need to change some settings in AD Connect so you have at least one OU that is not being synced.
If you don’t know how to do that, open up AD Connect, click on Connectors, right click on the domain and select properties. Under the Configure Directory Partitions you will find a Containers button. That is where you can select which OUs to sync.
Step 12.
Migrate the user from the original domain to the new domain.
We used ADMT to perform this task but I won’t go into detail on this. If you need help on how to set this up and use it, here is a good guide.
https://www.pelegit.co.il/admt-active-directory-migration-tool/
Here is the user we migrated into the new domain.
Step 13.
Now we need get the OBJECTUID of the migrated user, convert it to an ImmutableID and apply that to the restored user in Azure AD.
The below command will get the OBJECTGUID and convert it to an ImmutableID for a single user but can be converted to run against multiple users (you will need the ActiveDirectory and MSonline modules installed).
$ImmID = Get-ADUser -identity john.smith -Properties ObjectGUID | select ObjectGUID | foreach {[system.convert]::ToBase64String(([GUID]($_.ObjectGUID)).tobytearray())}
Now let’s set that ImmutableID to the restored user.
set-msoluser -UserPrincipalName “[email protected]” -ImmutableId $ImmID
Step 15.
Now let’s kick off another sync
Start-ADSyncSyncCycle -PolicyType delta
Job done
The user will now be matched with the restored user account as the ImmutableID will match the migrated user.
1 thought on “Move users to another domain and retain AD Connect sync”
-
Pingback: Head-to-Head: Active Directory vs. Azure Active Directory - Which One Wins?
Leave a Reply Cancel reply
You must be logged in to post a comment.