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 1.
As these users need to retain the same UPN, the first thing we need to do is to add the UPN suffix to the new domain. If you have already done this, you can skip this step.
Log into the new domain and launch the Active Directory Domains and Trusts console
Step 2.
Right click on the AD Domains and trusts and select properties
Step 3.
Enter the name of the UPN you need to add.
Click Add and then OK.
Step 4.
Now what we need to do, is remove the users from the sync cycle. The easiest way to do this is to move them into an OU that is not being synced. Below is our test user in AD.
Step 5.
Here is the user in Azure AD
Step 6.
Now let’s move him into an OU that is not being synced.
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 8.
Open a PowerShell console and enter: Start-ADSyncSyncCycle -PolicyType delta
This will initiate a delta sync to Azure AD
Step 9.
Log into the Azure portal and open the Active Directory panel
Select the Deleted Users option on the left hand blade
In here we should find our “deleted” user
Step 10.
Select the tick box next to the user and click on Restore User
Step 11.
Once the user is restored, click on the All Users blade on the left and search for the restored user.
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 “john.smith@smikar.com.au” -ImmutableId $ImmID
Step 14.
Move the user into an OU that is flagged to sync
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.
Leave a Reply
You must be logged in to post a comment.