Designing the Forest Structure | MCSE: Windows Server 2003 Active Directory and Network Infrastructure Design Study Guide (70-297)

Before you determine the domain layout, you need to decide on the forest structure. A forest is made up of multiple domains that share the same schema, configuration container, and global catalog and are linked by two-way transitive trust relationships. Most designers try to start with a single forest design, and rightfully so. A single forest is by far the easiest structure to administer, but it allows high-level administrators to have control over all resources within the forest.

Several reasons exist for why a network architect would design a multiple forest infrastructure:

Network administration is separated into autonomous groups that do not trust one another.
Business units are politically separated.
Business units must be separately maintained for legal reasons.

You need to isolate the schema or configuration containers.

Note	This isolation will affect Microsoft s Active Directory Application Mode (ADAM) containers also. (ADAM is also referred to as Application Data Partitions.) For more information on ADAM see the MCSE: Windows Server 2003 Active Directory Planning, Implementation, and Maintenance Study Guide .

You need to limit the scope of trusts between domains.

For each of these reasons, isolation or autonomy of services or data is necessary. If data or service isolation is a requirement, you will need multiple forests. You are apt to encounter the following complications when you have a multiple forest design:

Each forest maintains its own schema.
Each forest maintains its own configuration container.
Trusts and trust maintenance between domains in different forests must be manually configured.
Replication of objects becomes manual.

Before Windows Server 2003 s Active Directory came to be, having a multiple forest design was very difficult to administer if you needed forests to collaborate. Windows Server 2003 s Active Directory has been beefed up with enhancements that allow you to create forest trusts, which make sharing of resources easier.

You can create forests trusts between two forests so that the resources can be accessed by accounts in the remote domain. These trust relationships can be built to control exactly where the accounts have access and which accounts can access the remote forest. New features such as partially transitive trusts and Security Identifier (SID) filtering can be used if only certain accounts need to have access.

Note	For more information concerning SID filtering, see the white paper Using SID Filtering to Prevent Elevation of Privilege Attacks from the Microsoft website.

As the network architect, you need to determine if your design really needs multiple forests. Although you may find that the groups responsible for the services and data would like to have isolation, they may not really need it. Make sure everyone involved understands the costs involved in maintaining multiple directory services within the organization. Having separate service administrators for each forest incurs additional training and overlapping job responsibilities. When you create the forest design, you should take the following best practices to heart:

When designing the forest, always start with the simplest design, the single forest.
Determine whether the service administrators need to have service isolation or autonomy before you create additional forests.
If collaboration is required, a single forest works the best.
Use OUs for data autonomy instead of additional forests.
Create a schema modification policy.

Forests can be designed based on the need to provide isolation, autonomy, or collaboration. Depending on the administrative model used, the forest takes on either an organization-based design or is built with resource separation or isolation in mind.

Implementing an Organization-Based Forest

Organization-based forests are the most common type of forest. Using this design, an organization s resources are placed within the forest and organized so that the appropriate groups have control over the resources they need. In Chapter 1, we discussed the differences among the administration models and identified some of the reasons they affect the design of Active Directory. One of the models that we discussed was the decentralized model. Although companies choose the decentralized model for several reasons, one of the primary reasons is autonomy of control. If the companies require autonomy, a department or division could have a domain created for them, or OUs could be built within a domain.

In Chapter 1, we also outlined various business models. The departmental model identifies business units that make up an organization. The product/services-based model identifies different divisions of an organization based on the products that the organization provides. Either of these two models can use the organization-based forest design.

The departmental model usually takes on a single forest design with all of the departments broken up into different domains or OUs. This allows the entire organization s resources to be administered efficiently . Using this single forest approach, all of the resources within the directory service are represented within the global catalog. No additional means of interoperating are necessary. You can achieve autonomy of control over the resources by delegating control to the owners of domains and OUs. Figure 3.5 shows an example of an organizationbased forest using OUs for the business units. In this example, the manufacturing division has been given its own domain within the forest. The Model Shop and Quality Assurance departments are controlled by administrators from the Manufacturing domain, whereas the Marketing, Human Resources, and Accounting departments are controlled by administrators from the HQ domain.

Figure 3.5: Organization-based forest

The product/service-based model may take on a single forest structure with each product having its own domain. However, companies that have merged or acquired other companies may need to support multiple forests until the resources can be incorporated into a single forest design. Some organizations use a forest for each of the product lines. Creating the multiple organization forest structure allows for isolation among the product lines. Resource access can still be granted through trust relationships, but administrative control is broken apart based on the service administrators for each forest. Figure 3.6 shows an example of a company with two different business units that need to have isolation of control, yet want to allow access to resources. The forest trust is built so that the resources are available to users, but the administrative control is isolated.

Figure 3.6: Isolated organization-based forest

Implementing a Resource Forest

If certain resources need to be isolated from the rest of the organization, then you can create a resource forest. A resource forest is one in which the resources, such as shared folders, printers, member servers, and so on, are located within their own forest so that the owners of the resource can control them. Usually, the resource forest does not have any user accounts within the forest with the exception of the service administrator accounts that are required to maintain the forest.

Using this type of forest, an organization can make sure that the resources contained within the resource forest are not affected by the loss of services in any other forest. For instance, a manufacturing company that has resources in different geographical locations, especially those in different countries , may create a forest so that communication failures or a disaster at one location will not affect the resources and their reliance on the directory service. Figure 3.7 shows an example of a resource forest.

Figure 3.7: Resource forest

As mentioned before, having multiple forests adds to the administrative overhead. Resource forests need to have trust relationships created with the other forests. Because the directory services are isolated, the resource forest service administrators are probably different than the service administrator for other forests. Additional training and overlapping of responsibilities may occur. Decide how you will administer the additional forests prior to creating them.

Implementing a Restricted-Access Forest

A restricted-access forest completely separates service administrators from one another. Although you can build trust relationships to allow users to access the resources within the remote forest, the service administrators from the two forests are not allowed to administer the other forest s services. If the organization has any need for isolation of services, this is the type of forest structure that you need to build. Figure 3.8 shows an example of a restricted-access forest. Notice that no trust relationships exist among the domains that make up either forest. This not only keeps administration isolated, but access to resources is restricted to accounts within the forest only.

Figure 3.8: Restricted-access forest

Real World Scenario ”Making Use of Isolation

In order to meet the requirements of a defense contract that would bring in $28 million, Argobot had to meet the strict requirements of the contract. The primary requirement was that the specifications for the parts they would be contracted to build could only be accessed by the team that would be assigned to the project. Due to the nature of the project, the specifications dictated that the data could not be passed on the same physical network as the current business data. Complete isolation was required.

Six months earlier, Argobot had lost a contract with another firm. At that time, they had removed several pieces of machinery from an area of their building and consolidated their operations to become more efficient. The vacated area became a staging area. After discussing the network requirements for the defense contract, it was decided that the vacated area could be transformed into a separate entity within the organization. New cabling was run throughout for the new systems and all of the devices were connected to the segregated network.

Because the services and data had to be completely isolated from the rest of the organization, a new forest was decided upon. Because none of the accounts within the existing forest would have access to the new forest and a forest trust would not be built, the Defense Department isolation requirement could be met.

Windows Server 2003 was chosen as the operating system of choice, and an Active Directory forest was built for the new project. Members of the Information Technology team were chosen to be the service and data administrators for the new forest. A single domain was built and the member servers were added to support the new organization. Due to their ability to adapt quickly and meet all of the requirements of the project, Argobot won the contract.

Take for example a company that has governmental defense contracts. The company may create a forest to isolate the top-secret information from the rest of the company. In this scenario, the users who need access to information from both forests may have two access terminals that they use, each terminal is a member of only one of the forests and is separated on different physical networks. Another option is to use a server-based client access tools such as Terminal Services or Citrix MetaFrame to access desktops for each of the forests. With this method, the forests would have to share parts of the same physical network, which could pose other security considerations like the ability of capturing the network packets using a network monitoring device or software.

Using the flowchart in Figure 3.9, you will be able to decide how the forest structure should be designed.

Figure 3.9: Flowchart to determine isolated or autonomous control

A discussion of forests cannot end without covering one of the most important parts of the forest ”the schema. The schema contains the building blocks of the forest. Every domain within the forest shares the same schema so that the objects have a common set of attributes that define them. Because the schema is such an important part of Active Directory, you should not take changes to the schema lightly.