Disclaimer: During October I spent a few weeks working on this blog posts solution at a customer and had to do the responsible thing and pull the pin on further time as I had hit a glass ceiling. I reached what I thought was possible with Azure AD Connect. In comes Nigel Jones (Identity Consultant @ Kloud) who, through a bit of persuasion from Darren (@darrenjrobinson), took it upon himself to smash through that glass ceiling of Azure AD Connect and figured this solution out. Full credit and a big high five!

***

tl;dr

  • Azure AD Connect multi-forest design
  • Using AADC to sync user/account + resource shared forest with another user/account only forest
  • Why it won’t work out of the box
  • How to get around the issue and leverage precedence to make it work
  • Visio’s on how it all works for easy digestion

***

In true Memento style, after the quick disclaimer above, let me take you back for a quick background of the solution and then (possibly) blow your mind with what we have ended up with.

Back to the future

A while back in the world of directory synchronisation with Azure AD, to have a user and resource forest solution synchronised required the use of Microsoft Forefront Identity Manager (FIM), now Microsoft Identity Manager (MIM). From memory, you needed the former of those products (FIM) whenever you had a multi-forest synchronisation environment with Azure AD.

Just like Marty McFly, Azure AD synchronisation went from relative obscurity to the mainstream. In doing so, there have been many advancements and improvements that negate the need to ever deploy FIM or MIM for ever the more complex environment.

When Azure AD Connect, then Azure AD Sync, introduced the ability to synchronise multiple forests in a user + resource model, it opened the door for a lot of organisations to streamline the federated identity design for Azure and Office 365.

2016-12-02-aadc-design-02

In the beginning…

The following outlines a common real world scenario for numerous enterprise organisations. In this environment we have an existing Active Directory forest which includes an Exchange organisation, SharePoint, Skype for Business and many more common services and infrastructure. The business grows and with the wealth and equity purchases another business to diversity or expand. With that comes integration and the sharing of resources.

We have two companies: Contoso and Fabrikam. A two-way trust is set up between the ADDS forests and users can start to collaboration and share resources.

In order to use Exchange, which is the most common example, we need to start to treat Contoso as a resource forest for Fabrikam.

Over at the Contoso forest, IT creates disabled user objects and linked mailboxes Fabrikam users. When where in on-premises world, this works fine. I won’t go into too much more detail, but, I’m sure that you, mr or mrs reader, understand the particulars.

In summary, Contoso is a user and resource forest for itself, and a resource forest for Fabrikam. Fabrikam is simply a user forest with no deployment of Exchange, SharePoint etc.

How does a resource forest topology work with Azure AD Connect?

For the better part of two years now, since AADConnect was AADSync, Microsoft added in support for multi-forest connectivity. Last year, Jason Atherton (awesome Office 365 consultant @ Kloud) wrote a great blog post summarising this compatibility and usage.

In AADConnect, a user/account and resource forest topology is supported. The supported topology assumes that a customer has that simple, no-nonsense architecture. There’s no room for any shared funny business…

AADConnect is able to select the two forests common identities and merge them before synchronising to Azure AD. This process uses the attributes associated with the user objects: objectSID in the user/account forest and the msExchMasterAccountSID in the resource forest, to join the user account and the resource account.

There is also the option for customers to have multiple user forests and a single resource forest. I’ve personally not tried this with more than two forests, so I’m not confident enough to say how additional user/account forests would work out as well. However, please try it out and be sure to let me know via comments below, via Twitter or email me your results!

Quick note: you can also merge two objects by sAmAccountName and sAmAccountName attribute match, or specifying any ADDS attribute to match between the forests.

Compatibility

aadc-multi-forest

If you’d like to read up on this a little more, here are two articles reference in detail the above mentioned topologies:

Why won’t this work in the example shown?

Generally speaking, the first forest to sync in AADConnect, in a multi-forest implementation, is the user/account forest, which likely is the primary/main forest in an organisation. Lets assume this is the Contoso forest. This will be the first connector to sync in AADConnect. This will have the lowest precedence as well, as with AADConnect, the lower the precedence designated number, the higher the priority.

When the additional user/account forest(s) is added, or the resource forest, these connectors run after the initial Contoso connector due to the default precedence set. From an external perspective, this doesn’t seem like much of a bit deal. AADConnect merges two matching or mirrored user objects by way of the (commonly used) objectSID and msExchMasterAccountSID and away we go. In theory, precedence shouldn’t really matter.

Give me more detail

The issue is that precedence does in deed matter when we go back to our Contoso and Fabrikam example. The reason that this does not work is indeed precedence. Here’s what happens:

2016-12-02-aadc-whathappens-01

  • #1 – Contoso is sync’ed to AADC first as it was the first forest connected to AADC
    • Adding in Fabrikam first over Contoso doesn’t work either
  • #2 – The Fabrikam forest is joined with a second forest connector
  • AADC is configured with user identities exist across multiple directories
  • objectSID and msExchMasterAccountSID is selected to merge identities
  • When the objects are merged, sAmAccountName is taken Contoso forest – #1
    • This happens for Contoso forest users AND Fabrikam forest users
  • When the objects are merged, mail or primarySMTPaddress is taken Contoso forest – #1
    • This happens for Contoso forest users AND Farikam forest users
  • Should the two objects not have a completely identical set of attributes, the attributes that are set are pulled
    • In this case, most of the user object details come from Fabrikam – #2
    • Attributes like the users firstname, lastname, employee ID, branch / office

The result is this standard setup is having Fabrikam users with their resource accounts in Contoso sync’ed, but, have their UPN set with the prefix from the Contoso forest. An example would be a UPN of user@contoso.com rather than the desired user@fabrikam.com. When this happens, there is no SSO as Windows Integrated Authentication in the Fabrikam forest does not recognise the Contoso forest UNP prefix of @contoso.com.

Yes, even with ADDS forest trusts configured correctly and UPN routing etc all working correctly, authentication just does not work. AADC uses the incorrect attributes and sync’s those to Azure AD.

Is there any other way around this?

I’ve touched on and referenced precedence a number of times in this blog post so far. The solution is indeed precedence. The issue that I had experienced was a lack of understanding of precedence in AADConnect. Sure it works on a connector rule level precedence which is set by AADConnect during the configuration process as forests are connected to.

Playing around with precedence was not something I want to do as I didn’t have enough Microsoft Identity Manager or Forefront Identity Manager background to really be certain of the outcome of the joining/merging process of user and resource account objects. I know that FIM/MIM has the option of attribute level precedence, which is what we really wanted here, so my thinking as that we needed FIM/MIM to do the job. Wrong!

In comes Nigel…

Nigel dissected the requirements over the course of a week. He reviewed the configuration in an existing FIM 2010 R2 deployment and found the requirements needed of AADConnect. Having got AADConnect setup, all that was required was tweaking a couple of the inbound rules and moving higher up the precedence order.

Below is the AADConnect Sync Rules editor output from the final configuration of AADConnect:

2016-12-01-syncrules-01

The solution centres around the main precedence rule, rule #1 for Fabrikam (red arrows pointing and yellow highlight) to be above the highest (and default) Contoso rule (originally #1). When this happened, AADConnect was able to pull the correct sAmAccountName and mail attributes from Fabrikam and keep all the other attributes associated with Exchange mailboxes from Contoso. Happy days!

Final words

Tinkering around with AADConnect shows just how powerful the “cut down FIM/MIM” application is. While AADConnect lacks the in-depth configuration and customisation that you find in FIM/MIM, it packs a lot in a small package! #Impressed

Cheers

Category:
FIM, Identity and Access Management, Office 365
Tags:
, , , ,

Join the conversation! 15 Comments

  1. Hi and thanks
    always interesting…
    did same thing twice with no issues weird:)
    only thing I did do was I did not add the domains(all of them) right there at wizard
    I added one
    then other then other(3 domains setup)

    :The Scoping Filter section is used to configure when a Synchronization Rule should apply. Since the name of the Synchronization Rule you are looking at indicates it should only be applied for enabled users, the scope is configured so the AD attribute userAccountControl must not have the bit 2 set. When the sync engine finds a user in AD, it applies this sync rule when userAccountControl is set to the decimal value 512 (enabled normal user). It does not apply the rule when the user has userAccountControl set to 514 (disabled normal user).:

    Reply
    • Hey mate,
      I looked into that UAC as well.
      In my instance, straight out of the box, disabled or enabled, the UPN from the first (Contoso) forest would always sync.
      This happened for members of Contoso forest and Fabrikam forest.

      I didnt try not adding the forests via the wizard. I’ll try that next time and see how it goes.
      Cheers!

      Reply
      • now that I think about it
        I added the user forest first(where upn was)
        then the resource and the other user forest as we progressed.
        I did notice that in older versions of aadsync if the account
        if the account forest had a disabled account it will change the upn to be the resource forest upn because of that rule.
        on adconnect that seem to change(although rule looks the same)
        anyway, interesting and not “casual setup” 🙂
        always interesting stuff btw
        thanks for posting

  2. I have an identical situation to what you described, the only twist being users in both forests use the same primary smtp domain. For ease of logon by users in both domains, it would be ideal to have their username’s be their email address so I would naturally add the primary smtp domain as a UPN suffix. The problem here is that if I add it as a UPN suffix to both forests I believe their would be a UPN conflict. Any thoughts?

    Reply
    • Hi Chris,
      RE your question – if there is a trust between the two, I believe there would be a conflict in that trust config. I don’t recall being able to do what you’re wanting to do.

      Reply
  3. Can you add to the article how to access the “AADConnect Sync Rules editor”

    Reply
    • Hi mate,
      Two options- you should have a start menu shortcut, or via the .exe directly (which generally is accessible via: “C:\Program Files\Microsoft Azure AD Sync\UIShell\SyncRulesEditor.exe”).
      Cheers!

      Reply
  4. I have a unique scenario. I have the secondary forest, with a two way trust, but it Selective Auth. I have no requirements for email in that second forest, in fact at this time I have no need to sync it to azure. Just authentication to another 3rd party place pure ADFS. Other than that the diagram looks the same.

    How do i set that up?

    Reply
    • Hi Jason, I would say then that AADConnect is not your solution. Thats for syncing identities to AzureAD only. If you’re wanting to auth multiple forests to a SaaS app, AD FS alone can do that. If you have that trust in-place, you can use AD FS to authenticate users in either forest. Deploy AD FS in your “primary” or likely main forest, then configure your relying party trust. When you’re thinking about O365 and AzureAD, AADConnect can either sync unique users or merge users between forests if their are duplicates/copies between the two. Hope that helps!?

      Reply
  5. Great article.

    Go Nigel!

    Reply
  6. Can multiple forests be synced to a single Azure AD tenant without trusts being established between the two forests? Can you also have multiple Exchange system in Hybrid mode with Exchange Online? Does SSO and PTA work with the multiple forests without trusts? Apologies for all of the questions. We currently have a client that has a need to do this.

    Reply
    • Joel, you can certainly have multiple forests connected via AADC. Without a trust, i think that would work, but, you would need AADC to be able to talk to a DC in your second forest. You wouldn’t get SSO from a single AD FS deployment, if you used AD FS; you’d need two (one for each forest). Exchange is limited though. Only a single Exchange org can federate via Hybrid connectivity to Exchange Online.

      You’re better off using an IDAM tool to replicate identities between on-prem forests and Exchange orgs. Dell have a tool that does this. Quest Colab Tool and Quest Quick Connect. Or, on-prem Exchange migration and setup a user/resource model that then can be moved to O365. AADC supports user+resource connectivity and merging of accounts for a single cloud identity.

      Reply
  7. Great post Lucian,

    I’m in a process of syncing multiple forests with Azure AD and at this stage just trying to do some tests and see how does things go with an application which is meant to be moved to the cloud as part of a bigger project.
    I have a question for you:
    in the documentations of AD Connect it is said that Multiple Forest Sync using Multiple AD Connect to one Azure AD is not supported. I’m just wondering if this is a ‘not supported and not working’ or a ‘could work but we do not support any issues later on!’ ? I was testing this and it actually works.
    domains are not trusted or even on the same network. they have different domain names and sync users with different UPN to one Azure AD. I’ve this running for almost 10 days with no errors on either side…
    have you got any ideas why it’s working OR why it should not working?

    thanks

    Reply
    • Hey Afshin,
      I suppose there isn’t a true technical reason why it wouldnt work. It’s more to do with validated and supportable reference architecture or design patterns. When things go wrong, you want a consistent set of patterns to work with to be able to troubleshoot and determine any fault. I’d try and work within Microsoft guidelines to ensure that you can get premier support, or partner support.
      On the other hand, there could be some new functionality that is available publicly, but, not ratified that you’ve stumbled upon. It could be a new feature coming soon!? Reach out to your Microsoft AM to confirm?!

      Reply
      • Hi Luclan,
        Thanks for the reply, yes for many reasons (apart from the guideline) I’ll tend to keep them separated.
        thanks again.
        Afshin

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: