AAD Connect: The Three Forests Story.

I am writing on a grey area that I recently encountered while working on a AAD Connect project for a customer. The customer had one primary forest(forest A) and a secondary forest(Forest B) which essentially had same users represented twice (both in enabled state). In addition a third forest (Forest C) which is an extranet users forest having a disparate set of users.  A quick look at AAD Connect Supported topologies yields that this is a supported topology.(https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-topologies/)

My topology would look something like this. 

The some users would match (between Forests A and B) while some wont (Forest C).

I ended up choosing the following settings for matching users, Source Anchor and UPN.

Now, if both user objects(matched by UPN) are enabled in Forests A and B, by default AAD Connect can project from either of the objects and join the left over one. This wasn’t acceptable as ADFS is based on Forest A hence, AAD user objects must have the value of objectGUID of Forest A in sourceAnchor.

The solution to this problem is if you allow explicitly only Forest A to project and Forest B to join alone. This can be done by tweaking the default AAD Connect config as follows

1. Open Synchronization rules editor:

2. Open the User Join Inbound Sync Rule for ForestB.com and edit it.

Note: Normally we create a custom rule and should avoid editing the OOTB rules. However, in this case we must edit the default rule.

3. Change the link type to Join instead of provision.

Now Forest B objects will only join to Forest A objects that are project already. Voila, we have everything working as expected now. No other changes are needed to Forest A or Forest B join rules.