Companies acquiring other companies as they grow. For IT, it’s a never ending nightmare to bring the systems in-line. Projects that involves setting up new company’s systems according to the mother company and what not.
Among them, Active Directory Domain migration/ have domains in trust mode takes priority.
If you have Office 365 running, that makes things more interesting and challenging.
Most of the implementations takes place of providing the new company’s users with Office 365 services as the step 1. So yes, a migration should take place, but few things to be considered. I mean the bigger picture.
This is where the “Sync now, consolidate later” theme comes in. So when it comes to the consolidation part, it will be a smooth transition and will be less road blocks.
Questions you should ask, according to my experience
I’ll name the Mother company as Company A and the new company as Company B
Company A is already connected to Office 365 tenant and running the AAD Connect Sync tool.
- Do you need to create company B’s AD accounts in Company A’s AD? – Sounds very easy and straight forward.
- If not, if you create the cloud identity by syncing Company B’s AD, what about the connection? One of the Company B’s DCs should see Company A’s AAD Sync Connect server (Port 389 to be opened to the directory server)
- What about the forests? Are they going to be separate forests or will there be a forest migration happening in few months time? – domain consolidation
- Is the Company A running ADFS in it’s environment? (My article will cover an environment without ADFS. I will write a separate article for that later)
I will leave the 1st bullet point as it is very straight forward – Create AD accounts in Company A’s AD, assign licenses, hand over the credentials to the users.
The real discussion will take place around 2nd, 3rd and 4th points.
If you create the cloud identity by syncing Company B’s AD, what about the connection? One of the Company B’s DCs should see Company A’s AAD Sync Connect server (Port 389 to be opened to the directory server)
This simply means Microsoft’s AAD Connect tool’s Multiple forests, single Azure AD tenant scenario
How to add the additional directory in AAD Connect tool?
Azure AD Connect tool has got the option to add an additional directory as long as that server can see the other forest. I will list down some essential things you need to consider for a successful directory lookout.
1 – Proper network connectivity
2 – Hostnames
3 – IP address in the NIC (without register in AD)
4 – Forward lookup zone in DNS
Once you configure above, you can run the “Azure AD Connect” on the Company A’s end and complete below.
Open Microsoft Azure Active Directory Connect > Tasks > Under Additional Tasks, select “Customize Synchronization options” > Connect to Azure AD by providing a Global Admin credentials to Office 365 portal > Under Connect your directories, select Add Directory
> Select “use existing AD account” (note that this account should be from Company B – and this has the access to read/ write/ password reset to the directory users)
The above steps will go through which OUs you need to sync from Company B’s AD.
Once you run this, it will create the Connectors in the tool and will go though a full synchronization which will then sync the B’s users in Office 365.
Guids? Source Anchor?
The On-prem AD is connected to Azure AD via 2 attributes which is immutable at the Azure AD end throughout the object life-cycle
Traditional method –objectGUID
- Unique to a specific domain only
- Was the unique ID that tide up with the ImmutableID in Azure AD when Microsoft 1st introduced Directory Sync and it was a by default selection.
- With Azure AD Connect – now have the option of converting the ObjectGuid to mS-DS-ConsistencyGuid which is more reliable and stable
mS-DS-ConsistencyGuid
- Will not be changed event after a forest migration.
- Hence – After migrating a Domain B user to Domain A forest, AAD Connect will not panic and trying to duplicate or throw errors for the already synced user before migrating the Domain B forest.
- More reliable when it comes to recovering deleted On-Prem AD users from Azure
- Microsoft’s recommended attribute.
objectGUID and mS-DS-ConsistencyGuid in AD
How to convert ObjectGUID to MsDS Consistancy GUID
Few additional steps carrying out in AAD Sync tool will be able to do a conversion of the immutableID to MsDS Consistancy GUID.
View the current configuration for the Source Anchor
Note: If you go with the Express Settings, you will not the the option to select the Source Anchor and it will be defaulted to the Source Anchor according to the AAD Connect version.
AAD Connect Version 1.1.486.0 and older will be defaulting to use ObjectGuid
AAD Connect Version 1.1.524.0 and after will be defaulting to use mS-DS-ConsistencyGuid
If you notice your AAD Connect tool still got the ObjectGuid even you are on a later version, it’s because the tool has been upgraded, but the Source Anchor needs a manual upgrade.
I’ve done this in my environment and it didn’t require any downtime and it was pretty much seamless.
How to convert the Source Anchor?
Note: This is the process if you don’t have ADFS setup in your environment. If you have ADFS setup, it has some additional tasks to be done.
to change the Source Anchor for a non-ADFS enviroment
Open the AAD Connect tool > Go to Tasks > Configure Source Anchor
Press Next
Select the option to start the Synchronization process and press Configure
Once its done, the Source Anchor will be changed to mS-DS-ConsistencyGuid attribute
If you receive the below error
Run the tool with the switch that shown below from a command prompt.
“c:\Program Files\Microsoft Azure Active Directory Connect\AzureADConnect.exe” /SkipLdapSearch
How this will help in ADMT’ing?
Because the mS-DS-ConsistencyGuid attribute is a constant even you move the user via ADMT to a different forest (from Domain B to Domain A in this case) it won’t affect the ImmutableID to look at a different object and to create a duplicate cloud account.
In this case, it will be still bound to the same object when it was 1st synced from the Domain B to the O365 Tenant.
Conclusion
I think this as planning ahead so when it comes to forest or domain consolidation it can be a less work because you have already addressed the road blocks.
EMS Route - Shehan Perera 