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:
- The preview build of the AAD connector that was available on connect.microsoft.com was build 1.0.6438.3. This version had a dependency on build 4.1.3441.0 of FIM 2010 R2 (the ECMA 2.2 build).
- The release version of the connector is build 1.0.6567.2 and has a dependency on build 4.1.3493.0 which to you and I actually means 4.1.3496.0 (as 3493 was a private build).
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:
- Typical, i.e. one forest, next, next, next, job done.
- 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.
- 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.
- 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.
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:
- 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).
- 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.
- 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:
- Flexibility. A customised set of in-scope containers, object types, connector filters, join and projection rules.
- Alternate immutable ID. For many customers the GUID is simply not immutable across the lifetime of an identity. A single identity might transition between several AD accounts, i.e. move between forests or be deleted and recreated within the same forest.
- Other identity systems. DirSync basically works with AD. You might want to use another directory, or actually aggregate multiple identity stores.
- Additional functionality. You might want to also provision and manage license assignment in O365 or write more data back to the on-premises infrastructure.
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…
- You might choose FIM over DirSync because you want to connect to a different identity system, e.g. you are not using Active Directory and instead plan on using Shibboleth as the IdP to your non-Microsoft directory service. In this case FIM can provision the LDAP identities into the cloud as synchronized objects ready for SSO.
- You might want to include more functionality into your solution, e.g. also use FIM to manage license assignment via a custom connector (I used the PowerShell connector preview to manage licenses for one multi-forest customer).
- You have horrific processes that result in cross-organisational moves resulting in object deletions and creations (I’ve not seen this myself but colleagues working in education have – interdepartmental moves within the same domain resulting in a deletion and recreation due to the administrative model and the added benefit of no lingering access post-move).
For a multiple forest environment…
- There’s not really much choice – you have to use FIM. The reason being immutable ID, scope, custom rules, etc.
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.
- If DirSync works, use it. Seriously. It’s easy and cheap.
- If you have a user estate that spans multiple forests, and you want accounts from more than one forest to SSO to Office 365 or other services that depend on the AAD backend, you have to use FIM.
- If you want to synchronise a non-AD source you need to use FIM.
- If you want to perform coded flows for the purpose of data integrity or remediation cowardice (your crazy, but you can do it) you need FIM.
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).