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:

  • The preview build of the AAD connector that was available on 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).

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.  Smile

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:

  • 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).


About Paul Williams

IT consultant working for Microsoft specialising in Identity Management and Directory Services.
This entry was posted in Azure Active Directory, DirSync, FIM, FIM 2010 R2, Office 365 and tagged , , , , , , , , . Bookmark the permalink.

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

  1. Michael Cassidy says:

    Hi Paul, thanks for this article, it was very helpful.

  2. Pingback: Windows Azure Active Directory Connector part 2: multi-forest directory synchronization | Yet another identity management blog

  3. Jon says:

    Paul, some great stuff here. In the article you advocate dirsync where possible.

    I would be really interested to hear if you have ever deployed Dirsync in an environment where a FIM implementation already exists in parallel, which manages on premise exchange (an associated attributes such as proxy address).

    We will be single forest/single exchange, but already have FIM, and are trying to work out some of the issues around precedence when hybrid write back is enabled in dirsync and our separate existing FIM environment is also controlling some of those attributes…

    EG dirsync adds proxy addresses into AD from O365 then on premise FIM comes along and reverts attributes to what it thinks they should be….

    • Hi Jon. The closest I’ve come to your scenario is implementing DirSync in a customer that had FIM Synchronization Service 2010 R2 for GALSync. This customer had two core environments (one a single forest, with DirSync to its tenant; the other multiple forests with FIM SYNC to its tenant) with GALSYNC running between them (well, sort of, I put GALSYNC in for them and then DirSync and then FIM for DirSync). In this environment DirSync was enabled for the hybrid write-back and would add the cloudLegacyExchangeDN as an X500 address to all contact objects. Next time GALSync ran it would remove the offending proxyAddresses value. And so it would go. I describe this issue and my solution in this post:

      For your scenario I see merit in looking at implementing a similar solution. DirSync is only adding the cloudLegacyExchangeDN into proxyAddresses as an X500 value. The cloudLegacyExchangeDN is known to you and contains some reasonably unique strings that you can easily match. So consider modifying your existing proxyAddresses code to ignore “X500:/o=ExchangeLabs/” using a starts-with clause.

      I’ll be interested to know if this works for you.

      • Jon says:

        I had spotted that post this evening whilst reading through your blogs. Definitely sounds promising, some really useful information there.

        Thanks for sharing, blogging to this level of detail must be time consuming, but is really appreciated.

        I will let you know how we get on, although it may be a while before this gets to our live environment..

      • Benoit Boudeville says:

        My customer syncs 90K contacts from an external source (the group they belong to, being themselves a group in the group :)). I choosed another approach to flow the cloudLegacyExchangeDN to the sync’ed contact: I flow the cloudLegDN to an available AD attribute and then the AD flow rebuilds the proxyAddresses by flowing the external proxyAddressCollection computed from this source with merging this attribute, if present.

        Probably not the best approach although I just wanted to avoid merging proxyAddresses from the AD forest to the external source by adding one more complity in the proxyAddress management code (it’s a nightmare, by design :)).

  4. Benoit Boudeville says:

    Hehehe, we implemented a “nasty scenario” last year for a medium-large customer:
    Exchange 2013 Resource Forest, (Hybrid with ExO) + multiple Ex2007-2010 Orgs + regular orgs with non-Exchange MailSystems (Domino, GroupWise, pure IMAP hosted externally). And in the middle of this ability to support mutation scenarios and forest migration WITHOUT loosing the O365 Identity! We used FRIM+Portal to provision the RF properly and handle hybrid objects with care, generate our own “ImmutableId” (a self-managed GUID) and a FIM 2010 R2 acting as DirSync, but at this date was recoded from scratch using the original MA + over custom code. There were no offical doc at this stage (we had some internal MS doc available since we were on may TAPs).

    Oh and yes, we extended the “DirSync” with Remote PS capabilities to handle extra stuff, such as automatic license option assignment and mutations between E1-3 plans. Also serves to rename a user when moving from one forest to another and UPN suffix rename… This avoids manual actions and being spammed by Azure because the change isn’t allowed on a one-step action!

    • Utilising WF for federated-to-managed-to-federated (I call that F2M2F) is cool. I wish I had the luxury on a current project. 🙂

      I’m about to post a follow-up post around immutable ID. Will be happy to get your feedback. I’ve used a self-managed GUID, i.e. copied the original objectGUID and persisted it elsewhere; copied the original MVObjectID and persisted it elsewhere; and generated a random. My favourite however is a customer who actually have a system that generates an immutable ID as part of a separate FIM implementation…nice. 🙂

      • Benoit Boudeville says:

        Hi Paul,
        We are using a radom generated GUID because the MVGUID is unapplicate to me (imagine the mess you get in a DR scenario if you need to rebuild your metaVerse). I didn’t want to use the ObjectGUID as well, using a home-made immutable ID is safer IMHO.

        Here’s the code: we use the “uid” if present from the User Forest. Otherwise generate a new and write-back to the User Forest. In a mutation scenario, we’d need to create a new user in another User Forest, then copy the UID in the mutation process. I also have a custom join rule on objectSid sidHistory for the biggest forest which is the only potential target for cross-forest AD migrations. This is in saftey if they forget to copy the UID… 🙂 – and if the objectGUID was to be used, then this would require to retireve it from somewhere (eg: the original object) and copy as its text form to the target. That’d make the import flow / joins a bit harder.

        Then this UID is flowed to the Resource Forest in a specific attribute (msDS-cloudExtenstionAttribute1) and then used to convert the GUID as sourceAnchor/ImmutableId to its base64 form for cloud-federated auth with ADFS.

        case “cd.user:sAMAccountName,uid->mv.person:uid”:
        if (csentry[“uid”].IsPresent)
        mventry[“uid”].StringValue = GetStringValue(csentry, “uid”);
        if (!mventry[“uid”].IsPresent)
        mventry[“uid”].StringValue = Guid.NewGuid().ToString();

        In the mutation scenarion, when the two AD accounts are connected to the one Identity in the MV, only one will be the “master” (determined by precedence). The other changes such as the UPN are changed when the “master” object changes, eg: when precendence says it or when the precedence #1 connector is disconnected (eg: deleted, moved out fo sync or just made an explicit disconnector).

        On an UPN change, the custom DirSync sees the change (esp int he SUffix) and takes necessary Msol actions (thought a PowerShell MA) to rename the MsolUserPrincipalName to the default Tenant’s domain using the logic, then back to the new UPN right after. The Azure MA then doesn’t complain on the UPN change (export to PS MA is done _before_).

        Yes, it’s fun 🙂
        Let me know when your article is posted, I’ll be happy to read.

  5. Pingback: Windows Azure Active Directory Connector part 3: immutable ID | Yet another identity management blog

  6. Pingback: (2014-03-21) GALSync, DIRSync And SSO With Office 365 Blog Posts From MSResource.NET « Jorge's Quest For Knowledge!

  7. Pingback: (2014-10-01) TroubleShooting Federation/SSO To Windows Azure AD And Office 365 « Jorge's Quest For Knowledge!

  8. Rick says:

    Hi Paul,

    Have you had any experience of using FIM for a single AD to multiple 365 tenants scenario? We have a single AD we use for multiple clients that each have their own tenant. We currently have multiple servers running dirsync but having one dirsync server per tenant is becoming quite a drain. I know FIM can do many things but I can’t find any specifics on whether or not it can replace the need for multiple dirsync servers in this scenario.


    • Firstly, sorry for the delay – I take time off over the Christmas and New Year and was laid up in bed for more than a week ill prior to that!

      I’ve briefly looked into this, but have not implemented it myself, although might be doing something similar later in the year assuming contracts can be agreed. It is technically possible using both FIM and AADSync, but last I checked only supported using FIM (a future scenario for AADSync that may or may not become something). That support statement requires, unless I’m mistaken, a Premier contract too.

      There is no example code set for this scenario though. Although it won’t be complex to implement. I’d decompile DirSync using something like Telerik JustDecompile and then beef up the Provisioning method to accommodate the required filtering logic to determine which AAD MA you actually provision into.

      FYI, all of my multi-forest deployments have been based on a code set that I wrote from scratch (as opposed to modifying the example that ships with the connector) that is very much based on simple direct flows and the DirSync codebase. 🙂

      (In other words some blatant plagiarisation, but for a good cause)

  9. Rick says:

    Thanks for the reply Paul. I think I follow. I have played around with multiple AD agents in DirSync but the issue is not having the functionality to link different AD agents with different Azure agents, which is the logic I think you are referring to. I don’t have the expertise when it comes to code, none at all in fact. Do you know of any 3rd parties that offer such services?

    • If you want third parties it depends where you’re located. Microsoft Services are obviously one option. 🙂 In the UK and US you have Oxford Computer Group (OCG). In the US you also have Edgile and Insight/EnSynch. In Australia you have UNIFY solutions. All experts and all of us can help.

      Your details suggest you’re in the UK. So here’s my biased order of preference:

      Microsoft Consulting Services (that’s where I work)
      Oxford Computer Group (awesome team of folks)
      Salford Software (not worked directly with them, but have used/worked with subcons who used to work here)

  10. Vanna says:

    This article is very helpful! Could you please tell us how can I assign O365 license using this connector?.The MA to AAD exports the users from FIM. We are manually assigning the license in O365. How can we assign license? Thanks.

    • You can’t using this connector. You need to write your own. I’ve done this using the PowerShell connector. You can also obviously write a .NET based connector that talks to the Azure AD Graph API. Be warned, it’s not a five minute job either way.

Leave a Reply

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

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

Google photo

You are commenting using your Google 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 )

Connecting to %s