{"id":1674,"date":"2011-09-02T22:49:09","date_gmt":"2011-09-02T22:49:09","guid":{"rendered":"https:\/\/www.wapshere.com\/missmiis\/?p=1674"},"modified":"2011-09-02T22:49:09","modified_gmt":"2011-09-02T22:49:09","slug":"office-365-and-multi-forest","status":"publish","type":"post","link":"https:\/\/www.wapshere.com\/missmiis\/office-365-and-multi-forest","title":{"rendered":"Office 365 and multi forest"},"content":{"rendered":"

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\u00c2\u00a0– so here’s the way I approach it.<\/p>\n

<\/p>\n

Use FIM Sync to populate a dedicated “DirSync domain”<\/h3>\n

DirSync, despite\u00c2\u00a0it’s faults, is still the best way for enterprises to\u00c2\u00a0provision,\u00c2\u00a0update 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)\u00c2\u00a0DirSync is an official prerequisite for ADFS – so if you think you may be using ADFS for O365, you should plan to use DirSync.<\/p>\n

However DirSync only works with a single forest. As well as that, it replicates everything it finds in the forest<\/em>\u00c2\u00a0 – 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<\/em> unless you explicitly, and individually, hide them.<\/p>\n

So my recommendation, and what I have implemented in the past, is to create a dedicated DirSync domain<\/strong> 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.<\/p>\n

\"\"<\/a><\/p>\n

But what about ADFS?<\/h3>\n

At the moment ADFS\u00c2\u00a0with 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.<\/p>\n

However you could attach ADFS to your DirSync domain. You may<\/em> 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.<\/p>\n

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.<\/p>\n

The full solution<\/h3>\n

In my big BPOS project I added a few more pieces to the solution:<\/p>\n