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 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 card.
  • 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 eliminated.
  • 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.