Hybrid Identity

Windows Azure Active Directory Connector part 1: when, where and why


As per my earlier post Microsoft shipped the Windows Azure Active Directory (AAD) connector at the end of November 2013.  The connector has been around a while, in preview (beta/release candidate) form since the beginning of the summer and has been part of the newer builds of the DirSync appliance since early Summer too.  I’ve been very busy with this connector.  Last year I implemented four multi-forest Office 365 deployments, from an identity perspective, and have more planned for this year (and I mean implemented, I’ve been involved with scoping and troubleshooting other customers too, but have actually designed, configured and developed four).  Of those four three have been deployed using the AAD connector (preview, but I’m updating them now).  I feel I have some experience in this particular area at the moment so am probably going to dedicate a few posts to this topic.  I’ll start by discussing the kind of topologies I’ve been working in and how I think the landscape looks today.

But first, let’s quickly talk about the builds:

So, if you’re doing a clean install of FIM install the slipstreamed SP1 build (4.1.3419.0 which is available on MSDN and VL sites) and patch to 4.1.3496.0 and then install the RTW connector.

NOTE.  It is very important that you deploy the RTW connector bits and FIM build 4.1.3496.0.  If you don’t you will likely hit a bug where the connector goes into a continuous export loop which never stops, causes so much error mails from AAD that spam filters will block the traffic and also skews the export stats so that you have no idea what happened!

Why use the AAD connector?

First and foremost, don’t. 

Seriously.  If you’re deploying Office 365 and you can use the Directory Synchronization (DirSync) appliance then please do so.  It is operationally cheaper – it is cheaper to buy (there is no separate licensing cost); it is cheaper to run (it schedules itself and just works); it is cheaper to support (when there’s an issue you just reinstall it); it is cheaper to upgrade (you just run an EXE).  That being said, DirSync doesn’t work for everyone.  And this is why we have the connector (although I think more use-cases will become supported above and beyond enabling Microsoft Online services in the future).

Flavours of directory synchronization

To really answer the question of why use it, we have to take a step back and consider the different types of Directory Synchronisation topologies that are required today.  There are, in my opinion, four flavours of directory synchronisation:

  1. DirSync
    1. Typical, i.e. one forest, next, next, next, job done.
    2. Multiple-forest.  Not broadly communicated originally and now deprecated, this configuration supports multiple AD DS forests that can utilise either objectGUID or extensionAttribute4 as the immutable ID, i.e. one or more account forests where objects generally do not move between forests.
  2. FIM
    1. Multiple-forest, multiple-Exchange organisation.  One or more forests with or without Exchange organisations that require advanced filtering, rules extensions, or more complex immutable ID requirements.
    2. Account forest, resource forest model.  Linked mailboxes, i.e. one resource forest hosting Exchange and one or more account forests.

There is of course an additional flavour not easily categorised into the above.  I call this the nasty hybrid scenario, and I’ve seen three of these too: There are multiple account forests, multiple Exchange organisations, normal mailboxes (i.e. the account forest has an Exchange organisation) and there are linked mailboxes.  There’s usually an AD and/or Exchange migration thrown into the mix too.

Directory synchronization

I’m going to gloss over this as I only get involved with the complex synchronisation projects.  DirSync is the recommended tool for the job of enabling Office 365, InTune or CRM Online.  If you can use it, do so.  Otherwise, read on.

Multiple forest directory synchronisation

The DirSync appliance did actually ship with some PowerShell cmdlets to configure multiple source forest connectors (instances of the Active Directory Management Agent or ADMA).  It was largely unknown and very rarely deployed.  The primary reasons it was largely unused was because you were still tied to the configuration and weren’t allowed to configure it differently, which left you with an immutable ID of either objectGUID (default) or extensionAttribute4 (via permitted IAF rename).  Coupled with the allowed changes to connector filters and containers you could use this for some limited scenarios but in the end it got canned because it wasn’t flexible enough.  So this is just a memory.  Now, if you can’t use DirSync you have to use FIM.

Directory synchronisation with FIM

Here we have, again in my opinion only, three core scenarios:

  1. Multiple account forests, with or without Exchange, that need to be synchronised into AAD for the purpose of SharePoint Online, CRM Online, InTune (no real requirement for Exchange Online and/or Lync Online).
  2. Multiple account forests with multiple Exchange organisations that need to be synchronised into AAD for the purpose of O365, InTune or CRM.  For O365 this includes Exchange Online and/or Lync Online.
  3. Multiple account forests with one resource forest for Exchange and/or Lync.

Then there’s the nasty hybrid scenario that takes bits from each or all of the above.

So why use the connector?

Well, given the above, the core reasons to use FIM are:

Note.  Don’t be mistaken into thinking that you need to use FIM for basic flexibility, such as configuring what OUs and/or containers are in-scope or utilising connector filters.  The selection of containers and the configuration of connector filters is a supported modification to DirSync:

When, where and why

The AAD connector, in its current form with the current state of the service, is intended for customers that cannot use DirSync.  Customers that can use DirSync should do so.  I know I’m repeating myself here however it is an important message.  There’s little to no benefit in choosing FIM and the AAD connector over DirSync if DirSync meets your requirements.

Where does FIM work when DirSync cannot?

For a single forest environment…

For a multiple forest environment…


Hopefully I’ve now described the when, where and why of the AAD connector.  To be sure, I’ll wrap this post up with a summary.

It’s worth stating too, that…if you don’t have a resource forest and account forest model the OOB example code won’t work for you.  You’ll need to develop your own solution.

I’m intending on posting several posts on the subject of the AAD connector.  In my next post I’ll discuss multi-forest synchronisation (focussing on two or more account forests, each with their own messaging infrastructure, i.e. no single resource forest housing Exchange).