- Domain Design Overview
- Choosing Your Domain Namespace
- New Domain Design Features in Windows .NET Server 2003
- Choosing Your Domain Structure
- Single Domain Model
- Multiple Subdomain Model
- Multiple Trees in a Single Forest Model
- Federated Forests Design Model
- Peer-Root Domain Model
- Placeholder Domain Model
- Special-Purpose Domains
- Renaming an Active Directory Domain
- Summary
- Best Practices
This chapter is from the book
This chapter is from the book
This chapter is from the book
Federated Forests Design Model
A new feature of Windows .NET Server 2003's Active Directory implementation is the addition of cross-forest transitive trusts. In essence, this allows you to establish transitive trusts between two forests with completely separate schemas that allow users between the forests to share information and to authenticate users.
The ability to perform cross-forest trusts and synchronization is not automatic, however, because the forest functionality of each forest must be brought up to Windows .NET functionality levels. What this means is that all domain controllers in each forest must first be upgraded to Windows .NET Server 2003 before any cross-forest trusts can be established. This can prove to be a difficult prospect for organizations already deployed with Windows 2000. Consequently, the federated forest design model is easier to consider if you do not currently have an Active Directory structure in place.
The federated forest design model is ideal for two different situations. One is to unite two disparate Active Directory structures in situations that arise from corporate acquisitions, mergers, and other forms of organizational restructuring. In these cases, two AD forests need to be linked to exchange information. For example, a corporate merger between two large organizations with fully populated Active Directory forests could take advantage of this capability and link their two environments, as shown in Figure 5.8, without the need for complex domain migration tools.
){kind=small}
Figure
5.8 Cross-forest trust between two completely different organizations needing
to share resources.
In this example, users in both forests now can access information in each other's forests through the two-way cross-forest trust set up between each forest's root.
The second type of scenario in which this form of forest design could be chosen is one in which absolute security and ownership of IT structure are required by different divisions or subsidiaries within an organization, but exchange of information is also required. For example, an aeronautics organization could set up two AD forests, one for the civilian branch of its operations and one for the military branch. This would effectively segregate the two environments, giving each department complete control over its environment. A one- or two-way cross-forest trust could then be set up to exchange and synchronize information between the two forests so as to facilitate communication exchange.
In Figure 5.9, a one-way cross-forest trust was set up between the civilian branch and the military branch of the sample aeronautics organization. In this example, this setup would allow only accounts from the military branch to be trusted in the civilian branch, in essence giving the military branch users the ability to access files in both forests. As with NT domains, cross-forest trusts are one way by default. Unlike NT and 2000 trusts, however, cross-forest trusts in Windows .NET Server 2003 are transitive. To set up two-way transitive trusts, you must establish two one-way trusts between the two forest roots.
){kind=small}
Figure
5.9 One-way cross-forest trust.
When to Choose Federated Forests
The concept of federated forests greatly enhances the abilities of Active Directory forests to exchange information with other environments. In addition, organizations that were reluctant to implement AD because of the lack of a solid security boundary between domains can now take heart in the ability of the federated forest design to allow specific departments or areas to have complete control over their own forests, while allowing for the transfer of information between the domains.
Real-World Design Example
To illustrate a good example of an organization that would choose a federated forest design model, let's consider fictional Conglomerate A, which is a food distributor with multiple sites worldwide. It currently operates a Windows .NET Server 2003 Active Directory implementation across its entire organization. All computers are members of the forest with a namespace of companyb.net. A root domain exists for conglomeratea.net, but it is not populated because all users exist in one of three subdomains: asia, europe, and na.
Conglomerate A has recently entered into a joint venture with Supplier A and would like to facilitate the sharing of information between the two companies and to exchange common address books. Supplier A also currently operates in a Windows .NET Active Directory environment and keeps all user and computer accounts in an Active Directory forest that is composed of two domains in the suppliera.com namespace and a separate tree with a DNS namespace of supplierabranch.org that reflects a certain function of one of its branches.
The decision was made to create a cross-forest trust between the two forests so that creden-tials from one forest are trusted by the other forest and information can be exchanged. The cross-forest trust was put into place between the root domains in each forest, as shown in Figure 5.10.
){kind=small}
Figure
5.10 Cross-forest trust between root domains in each forest.
Remember, that just as in NT 4.0, a trust does not automatically grant any permissions in other domains or forests; it simply allows for resources to be implicitly shared. Administrators from the trusting domain still need to manually grant access. In our example, administrators in both forests can decide what resources will be shared and can configure their environment as such.