MIM/AADConnect: Working With Multi Forest & Resource Forest Model
Introduction
In this article we will be configuring Azure AD Connect's underlying synchronisation engine MIM (Microsoft Identity Manager, used to be FIM - Forefront Identity Manager) to read from two separate active directory forests and merge the matching user accounts to create one logical representation of each user in Azure Active Directory.
The image below shows a logical representation of a situation where users are replicated from one forest to another to use services (Exchange in this case) in the resource forest.
https://msdnshared.blob.core.windows.net/media/2016/07/kerb1.png
Scenario
We are putting the “Resource Forest” in air quotes here because this particular customer we have engaged with has an Exchange “Resource Forest” with around 20,000 mailboxes but around 2,000 of the linked mailbox accounts are enabled and in use for some legacy applications!
This causes all sorts of headaches for us trying to get a single source of truth for each user and selecting the correct attributes from each forest (as multiple matching accounts are both enabled so how does MIM know which object is authoritative for which attributes?).
Normal Operation
Usually in an Account/Resource model we would have a simple 1-1 relationship between all disabled user accounts in the resource forest and all users in the account forest and would match them up in Azure AD Connect by using the msExchMasterAccountSid attribute.
AAD Connect would automatically pick the user attributes from where the account is enabled i.e. the Account Forest and the Exchange attributes as they are cumulative to what we already have from the resource forest.
Current Issue
As some of the customer’s users are enabled in both forests we now have a big problem, AAD Connect has found a match for an account using msExchMasterAccountSid but both accounts are enabled, which UPN and Password should it select? which GUID should form the cloud anchor?
Another issue that causes further complications is that the objects in the account forest are replicated from the resource forest, so “mail” and “proxy address” attributes exist within the account forest but are not updated and are not classed as the source of truth for the current Exchange attributes as this information needs to come from the resource forest.
Is everyone confused? good…
Solution
Azure AD Connect “Synchronization Rules Editor” and “Precedence”
Ensure Account Forest user attributes are selected ahead of resource forest attributes (UPN, GUID, Password etc)
So Azure AD Connect runs a cut down version of MIM in the background, part of this application is the “Syncronization Rules Editor” found on the start menu.
By default the Azure AD Connect wizard will generate a default precedence depending on what you entered into the wizard but there are not too many options there so we use this interface instead.
Ensure Resource forest Exchange attributes are selected ahead of Account forest
On the inbound from on-premises rules we need to change the precedence for the account forest to be higher than the resource forest as shown in the image below, however we want the “User Exchange” rule to take higher priority for the resource forest objects as this is where our Exchange is deployed.
Red = Account Forest
Blue = Resource Forest
https://365guy.co.uk/wp-content/uploads/2018/03/AAD1.png
Ensure “Mail” & “ProxyAddresses” attributes come from Resource Forest
Finally as Mail and ProxyAddresses attributes are not part of the Exchange import rules (they are in the “User Common” rule) and the Account Forest “User Common” rule has a higher precedence we would end up with the incorrect Mail and ProxyAddresses in our metaverse.
So we need to alter the “User Common” rule for the Account Forest to stop the Mail & ProxyAddresses attributes from being overwritten.
In this version of MIM the removal of any transformation rule is blocked or greyed out so we need to edit the 2 x transformations for Mail and Proxy…
We use a direct mapping of the Manager attribute to replace Mail and Telephone Assistant to replace ProxyAddresses.
Now when this rule is fired neither of the Mail or ProxyAddresses attributes overwrite or take precedence in the MIM metaverse.
https://365guy.co.uk/wp-content/uploads/2018/03/AAD2.png
