Building a Resource Forest for Cross-Organization SharePoint Collaboration
Using a Resource Forest for Cross-Organization SharePoint Collaboration
Sometimes the most interesting SharePoint riddle is figuring out how to make it work across the boundaries that exist between organizations.
Consider a scenario where several large organizations need a common SharePoint environment for collaboration.
Each organization already has its own internal Active Directory environment. Each has its own SharePoint farm supporting internal collaboration. From an infrastructure perspective, they're completely independent organizations, and establishing traditional domain trusts between all of them simply isn't an option.
They still need a way to work together.
This is one of the situations where a resource forest can provide an interesting solution.
The Problem
Internally, the model is straightforward. Users authenticate against their organization's Active Directory environment and access resources within that environment, including their internal MOSS 2007 farm.
It gets trickier when several organizations need to participate in the same collaboration environment.
Putting the shared SharePoint farm inside any one organization's internal network immediately raises questions about authentication, network access and security boundaries.
Creating trusts between all of the participating organizations may solve some of those problems technically, but in a large enterprise environment that may not be politically, administratively or operationally possible.
Instead of trying to force those environments together, another option is to create a separate environment specifically for the shared resources.
A forest for the collaboration environment
The basic concept is to establish a dedicated Active Directory forest whose purpose is to support the shared-collaboration environment.
In this case, the central organization can deploy a MOSS 2007 farm into its DMZ along with a separate Active Directory resource forest.
That gives the collaboration environment its own security boundary rather than making it a direct extension of the organization's internal domain.
For users belonging to the central organization, a one-way Active Directory trust can be established between the resource forest and the internal corporate domain.
The direction of that trust is important. The collaboration environment needs to be able to authenticate the organization's internal users without requiring the internal environment to place the same level of trust in systems operating within the DMZ.
From the user's perspective, the result can be relatively seamless. They continue using their existing corporate credentials while accessing the shared SharePoint environment.
External organizations are handled differently. Rather than creating trusts back into each participating company's Active Directory environment, accounts for those users can be maintained directly within the collaboration resource forest.
The end result is a SharePoint environment capable of supporting users from several organizations without requiring those organizations to combine, redesign or establish trusts between their internal identity infrastructures.
Keeping the shared environment separate
The important part of the design isn't necessarily the mechanics of creating the forest or configuring the trust, rather it is the separation it provides.
The organizations can continue operating their existing environments exactly as they already do.
Their internal SharePoint farms remain responsible for internal collaboration.
Their internal Active Directory environments remain under their own administrative control.
The shared MOSS farm exists specifically for information and activities that cross those organizational boundaries.
Why not just build more trusts?
Technically, there are plenty of ways to connect Active Directory environments. That doesn't necessarily mean you should. When you're dealing with different enterprises, establishing a domain trust isn't simply an Active Directory decision. It can involve security policies, firewall requirements, administrative ownership, change control, legal agreements and entirely different approaches to identity management.
Multiply that across several organizations and a technically simple solution can become organizationally impossible. The concept of a resource forest changes the question.
Instead of asking every participating organization to trust every other organization, you establish an environment whose entire purpose is providing the shared resource. That is a much easier architectural boundary to understand.
SharePoint as the common ground
There is also something particularly appropriate about applying this model to SharePoint. Each participating organization may already have a perfectly good SharePoint environment. The goal isn't to replace any of them. The shared MOSS farm becomes the place where the organizations overlap.
Internal projects & documents stay internal.
When a project, team or activity requires participation from multiple organizations, that work can move into the collaboration environment. You're essentially creating a neutral collaboration space without requiring the underlying enterprises to become part of the same infrastructure.
It doesn't solve every problem
Obviously, introducing a resource forest creates its own administrative responsibilities. Accounts maintained within the resource forest still need to be provisioned, managed and eventually removed.
Password policies have to be established, ownership needs to be clearly defined, the DMZ architecture needs to be designed appropriately and SharePoint permissions still need to be managed.
None of those things disappear. But those are problems contained within the collaboration environment rather than problems that require fundamental changes to every participating enterprise.
That's really the value of the model.
Think beyond the farm
Sometimes we spend so much time thinking about SharePoint architecture in terms of Web Front Ends, application servers, SQL Servers and site collections that it's easy to overlook the identity architecture surrounding the farm.
In a cross-organizational environment, identity may be the more important architectural problem and a resource forest gives you another tool for solving it.
It allows you to create a SharePoint environment specifically designed to sit between organizations rather than attempting to force several independent organizations into a single identity model.
If you find yourself looking at a collaboration requirement involving multiple enterprises, separate Active Directory environments and little appetite for establishing trusts between them, don't assume those boundaries prevent SharePoint from becoming the common collaboration platform.
Sometimes the better solution is to leave those boundaries exactly where they are and build something new between them.