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

Future

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.