ADFS in a resource/account forest scenario

Handling identities in a hybrid cloud is often no easy task. Configuring ADFS with Office 365 and Azure should not be difficult. Generally speaking using the cloud is not necessarily rocket science. However, things can get very complicated depending on the on the server infrastructure a company already has in place when deciding to move to the cloud.

A very common scenario is using resource forests and account forests in the same organization. Typically the resource forest is configured for some services, like Exchange or SharePoint and the account forest contains account information for client login. Many larger organizations have opted for such a scenario a while back and probably nowadays they want to move some workloads to the cloud. The big question for identity folks is, how should directory synchronization and identity federation be implemented in a resource/account forest scenario? 

The problem here is that users in the account forest don’t have the service specific AD attributes populated, like the Exchange specific attributes, while in the resource forest we would have linked mailboxes with disabled users. I think we may better understand this with this picture:

resource forest

Assuming that the two way transitive trust between the resource and account forest is already created (as it is a prerequisite for this type of scenario), configuring ADFS should not cause any problem from the authentication perspective. We could run DirSync or Azure AD Sync in the account forest and configure ADFS either in the resource forest or in the account forest. Important is only that the ADFS service account has the necessary permissions to login users that reside the other forest.

However, if we want to run an Exchange Hybrid in such a scenario, things get more difficult. Regarding the synchronization, if we run it against the resource forest, all synced users will be disabled users, and won’t be able to login to Office 365. If we run the synchronization in the account forest, the user accounts will have no Exchange attributes synchronized. If we run Azure AD Sync against both forests we will most probably have user mismatch errors in the synchronization engine.

An acceptable plan in this scenario is to have the AD schema on the account forest extended with the Exchange attributes, set up directory synchronization against the account forest and ADFS against the resource forest. The trick here is that when we run the directory synchronization wizard, we have to check the option to use it in an Exchange hybrid environment. This will allow certain Exchange attributes needed for the hybrid functionality to be written back from Exchange Online into the corresponding local AD attributes. If DNS, firewalls and proxies are configured correctly, basic Exchange hybrid functionality will work smoothly. The hybrid CAS should be placed, obviously, also in the resource forest.

Still in this circumstances we will have limitations in having the mailbox on premises and the archive on Exchange Online. When we will try to connect Outlook and access the online archive we will most probably get an “access denied” error and the Outlook ETL traces would confirm that.

If we really want to benefit from all Exchange hybrid features, including on premises mailboxes and online archives, the recommended way would be to consolidate resource and account forest into a single forest. Again, this is a very painful process since we would have to migrate AD data with tools like ADMT, but also the Exchange infrastructure. The end result will be, on the other hand, rewarding, since we would benefit from all Exchange hybrid features, including online archiving. Of course, when the 2 forests are consolidated to a single forest, we would run DirSync against the new forest, set up ADFS in the new forest and the Exchange Hybrid CAS will also be there.

As I said, things aren’t easy in resource/account forest environments when we want to move to the cloud, but if we have a clear idea on what it will work and what limitations we would face, we could plan accordingly.

I am open to any questions or other ideas.

 

Dan Patrascu-Baba

Partner Technical Consultant at Microsoft
Azure PaaS and dev consultant, working for Microsoft. Mostly dealing with Microsoft Azure services, ASP.Net Core, AngularJS, Javascript. Helping partners and customers to write good code and to architect their cloud and hybrid solutions.

4 thoughts on “ADFS in a resource/account forest scenario

  1. Dave

    Hi,

    We have the same issue. We have a resource forest and login forest combined in forest A. then we have 14 other login forests that we provide email services for only. I was thinking of extending the login forests’ schemas to include exchange attributes, then copy over the pertinent attributes to those accounts. After which time I would convert all distribution group in the resource forest to Cloud only DLs and repopulate them and re permission everything with those groups… I’m just wondering if all this is feasible. Did you have any success with it? We have a MS premier contract so they are helping, but I think I didn’t really convey the premise as well as you did here in the blog. Looking forward to your input.

  2. Dan Patrascu-Baba Post author

    Hi Dave,

    Thank you for your comment. Do you plan to migrate users mailboxes to Office 365? It is difficult to give some useful thoughts without knowing the exact scenario.
    However, I have few cents to spare 🙂 This article was written some fairly long time ago. Right now with Azure AD Connect things are a little bit easier. In this kind of scenario you can merge identities from the two different type of forests into one user in Office 365 based on ObjectSID and MsExchMasterAccountSID. This will basically thake your users from the resource forest and user accounts from account forest and merge this information. The user will be then synced with all attributes, from both account and resource forest. This scenario is also covered here .

    The only problem is when you want to set up ADFS with Office 365. In this case you could use alternate login ID or, provided that each forest has an own UPN suffix, implement ADFS in each account forest.

    I think I would have to write a new article describing the scenarios right now. Hope this helps a little bit.

    1. Alcaudon

      I’m very interested on this scenario. Environment with some account forests+resource forest+AAD Connect+Hybrid migration+ADFS+MFA. I couldn’t find your new articule about that, did you write it?

      1. Dan Patrascu-Baba Post author

        Sorry for the late reply. Unfortunately, I lost the sight of this blog during the last 12 months. I am really sorry.
        I didn’t write a new article since I changed focus around 2 years ago and I am working now more on Azure PaaS and development.

Leave a Reply

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