Office 365 and multi forest

I had numerous great chats at TechEd Australia about enterprise identity management and Office 365. This is a particular subject of interest to me, after the big, complex BPOS project I worked on for the last 18 months. I don’t believe there’s any official guidance on how to prepare identities for Office 365 in a complex enterprise environment that includes multiple AD forests, or multiple non-AD directories for that matter├é┬á– so here’s the way I approach it.

Use FIM Sync to populate a dedicated “DirSync domain”

DirSync, despite├é┬áit’s faults, is still the best way for enterprises to├é┬áprovision,├é┬áupdate and delete user accounts, contacts and groups in Office 365. While we have more alternatives now than we did with BPOS (in particular the vastly improved powershell coverage)├é┬áDirSync is an official prerequisite for ADFS – so if you think you may be using ADFS for O365, you should plan to use DirSync.

However DirSync only works with a single forest. As well as that, it replicates everything it finds in the forest├é┬á – including service, test and contractor accounts, and all your groups. They are then given a default email address in O365 (even if they didn’t have one locally) and they will appear in your GAL unless you explicitly, and individually, hide them.

So my recommendation, and what I have implemented in the past, is to create a dedicated DirSync domain and use the FIM 2010 Synchronization Service to populate this domain based on objects sourced from your other directories. You can then produce a nice, clean data source for DirSync, with only the objects you actually want to see in O365.

But what about ADFS?

At the moment ADFS with O365 is also single forest only. Plus, if you have multiple user principal name domain suffixes in use, you need a seperate ADFS infrastructure for each one.

However you could attach ADFS to your DirSync domain. You may just need one ADFS infrastructure in this case -it depends on how many UPN domains you’re using. While users won’t be logging in with their actual working account, you still get the advantages of being able to control password complexity, or implement two-factor authentication, or use Forefront UAG.

You’d probably still want to implement internal password sync between the DirSync domain and the various home forests (or other directories), so it’s good to know that the FIM Sync service also supports password sync, including to non-AD domains.

The full solution

In my big BPOS project I added a few more pieces to the solution:

  • In any identity management project it is ideal to get a direct data feed from HR so we know who’s coming and who’s leaving. This allows new starter accounts to be created in time for their start day, leavers’ accounts to be correctly handled (important for security but also when you’re paying by the account!), and for the GAL to be kept up to date with cortect names, job titles, locations etc.
  • DirSync├é┬áis one way only – to the cloud. So if you want to get info back for reporting purposes – such as activation status and which licenses are being used – you can use the O365 powershell interface to pull all sorts of great data back into FIM Sync.
  • I also use the FIM Portal as a management console for Office 365. Any changes that can be made through powershell can be triggered from FIM Portal workflows, while all the user has to do is tick a box or select something from a drop-down. Some advantages of this approach:
    • Portal users don’t need access to the 0365 admin site, and they don’t need to know how to use powershell,
    • I can set my permissions structure in a very targeted and detailed way. In O365 someone with password reset rights can├é┬áchange everyone’s password. Using the FIM Portal in this way allows me to restrict their password reset abilities to, say, just their department.
    • I can offer some self-service options – like allowing a user to control, or at least view,├é┬átheir own mailbox delegations.
    • I can log and report on all actions – something else you don get in O365.
    • I can add extra business requirements such as “no activation without a cost code”.


Microsoft are promising a management agent for FIM Sync as the eventual solution for multi-directory environments that want to move to O365. All this really does is remove the need for the DirSync domain and allows a direct connection to O365. The management agent should also support direct password sync to O365, so that’s a possible├é┬áalternative to ADFS.

My understanding is that it will be possible to migrate from DirSync to the direct connection via the management agent. If we already have FIM Sync in place as pictured above then we’re just replacing once connector with another.

Sounds nice – but how much work is it?

I’m not going to tell you this type of solution is easy to set up, because it’s not easy, though it is definitely both achievable and supportable.

  • In multi-directory environments you’ll often find different naming conventions (or a complete lack of them), people who have accounts in more than one place, and conflicts on mail aliases and distribution list names. Identification and data cleanup can be trickier and more time consuming than you expect.
  • Taking data from multiple sources, filtering, matching and applying rules to it, before finally provisioning it to the DirSync domain will require extension code to be developed for the FIM Sync service. This is the standard and supported approach with FIM Sync, but should not be attempted without training or the help of experienced consultants.
  • If you want to use the FIM Portal then you will definitely need to go through a proper design process with good quality assistance on the policies, forms and custom workflows required.

8 Replies to “Office 365 and multi forest”

  1. Hi Carol,

    Great article. I have also work on this kind of scenario with Office 365. Have a look on my blog : . I have also find a way to provide full SSO on the MicrosoftOnline portal with an account in an account forest. But this part is not supported, so use it with caution. It will be a pleasure to exchange with you about this multi forest scenario and the future of Multi Forest with Office 365.



  2. Hi Olivier and thanks for your comment.
    We discussed a similar idea with ADFS for when my major BPOS customer upgrades to O365, but my concern is that it adds too much extra risk to something as important as authentication. I will be recommending that complex environments stay with cloud-based passwords until it gets easier to implement ADFS. I was unsure from your blog whether you have this working in production? You only mention a lab. I’d be interested to see how it works in prod.

  3. Yes, you are right Carol. ADFS is a very critical part in the authentication process. We have only deployed this solution in a lab environment, with O365 test accounts, and it is working very well for SSO with the MicrosoftOnline Portal. With Outlook client, we don’t have yet tested, and I am not very sure it is working. If you want more informations about the configuration of ADFS, don’t hesitate to contact me by mail.

  4. Great article, but i don’t understand how the mailboxs will be migrated from the multiple source forest?

    Thank you

  5. This article is not about mailbox migration, just about getting the user accounts created and other objects like groups and contacts sync’d to the cloud. Once the user account exists in O365 you will be able to migrate the mailbox but there are other tools you will use for that.

  6. Great article Carol.
    I have a question, with the AAD MA we can do the Future Scenario that you Explain in the article? In that case, how it Works with ADFS.

    Thanks in Advance,

  7. Hi Rodrigo. This article was written a few years ago and things have moved on since then. I haven’t actually used the AAD connector yet myself, though I understand there are some points to be aware of (such as needing a dedicated FIM server for it) that mean it’s not necessarily the right solution for everyone.

Leave a Reply

Your email address will not be published. Required fields are marked *