In the multiple-forests - Super Admin domain model, as shown in the following figure, the service provider deploys multiple forests. The first forest contains the standard shared or dedicated hosting domain, along with a separate and tighter controlled administration domain. The reason for this separation is that the service provider's administrators require different domain-wide security policies, as compared to the rest of the service provider's organization.
If a reseller demands an additional forest, you must determine where your administrators will be created. There are four options:
- Create a separate domain in the first forest - This
separate domain will act as the repository for the administrators,
no matter how many domains or forests are created. This domain
should be tightly controlled and no one other than the service
provider's administrators should have accounts in the domain.
Explicit one-way trusts should then be established between this
administrative domain and each of the separate forest domains. This
is the recommended approach if this Active Directory directory
service model is required.
- Create the administrators in the shared domain - In this
example, the shared domain is fabrikam.com. This requires that an
explicit trust be established between the shared domain and the
second forest's domain. For security reasons this may be
unacceptable to the new hosted company.
- Create administrators in both forests - This is
problematic as each administrator will need to exist in every
forest that is created. Their passwords will be different and they
may have a different password and account policies applied to their
credentials. This option is not recommended.
- Create the administrators in the second forest domain -
Make a one-way trust back to the shared domain. This option is also
problematic due to the effect of the third forest. In addition, the
administrators in the second forest should not be able to affect
the shared domain. This option is not recommended.
The multiple-forests - Super Admin domain model may be used when:
- New hosted company needs a directory-enabled application that
extends the schema - You should not allow schema modifications to
be made to shared forests, unless those modifications are for all
hosted companies. Thus you may dedicate a forest to a customer
needing custom schema modifications to isolate those modifications
from the rest of the directory hierarchy.
- New hosted company requires stricter password and account
policies for the administrators of its forest - For example, if the
service provider's administrators need to log on by smart
- Service provider wants to stop unnecessary replication from
taking place between two geographically dispersed and unrelated
data centers - For example, suppose you run an African and a South
American data center. Bandwidth is at a premium and you do not want
to replicate objects back and forth to a shared global catalog.
Because the global catalog is shared at the forest level, deploying
two different domains in the same forest is not a practical
solution. In addition, the implementation of sites cannot be used
because the data is still replicated between the sites. Active
Directory sites only allow the replication to be scheduled, not
- Hosted company wants to deploy a domain controller in its own
premises for use as its internal network Active Directory domain -
In this case, you cannot guarantee the physical security of the
domain controller and therefore do not want to risk compromising
other hosted companies' data or services. Because a domain is not a
security boundary, you may want to dedicate an entire forest to a
customer to ensure its complete isolation.