Microsoft press windows server 2008 active directory resource kit - part 3 pdf

144 Part II: Designing and Implementing Windows Server 2008 Active Directory
Note Designing a Windows Server 2008 AD DS infrastructure is not significantly different
from designing an Active Directory infrastructure in Microsoft Windows 2000 or Windows
Server 2003. Windows Server 2008 AD DS includes several important new features that will
affect AD DS design, but many of the core concepts of AD DS have not changed, and many
of the design decisions have not changed. If you already have Active Directory deployed, you
can use this chapter to review your current design in preparation for upgrading to Windows
Server 2008 AD DS.
Defining Directory Service Requirements
Before you can begin designing your organization’s directory service, you must first under-
stand why your organization plans to deploy the directory service and the state of the current
directory service. Very few organizations deploy a new technology just because it is the latest
and greatest option. Before investing in a new technology, managers need to see a clear business
benefit. That means that you must understand and be able to clearly explain to business
decision makers how a new technology such as Windows Server 2008 AD DS will address
existing and new business requirements.
Figure 5-1 shows a checklist of the types of requirements that you need to collect when starting
your AD DS design.
Figure 5-1 Use the AD DS design requirements checklist to determine the information that
you need to collect.
Document
business
requirements
Document
functional
requirements
Document
service level
agreements
Document
legal

requirements
Document
security
requirements
Document
project
constraints
Chapter 5: Designing the Active Directory Domain Services Structure 145
Business Involvement in AD DS Design
When you design AD DS for a corporation, it is important to get the company’s manage-
ment involved in the design process. The business users are the primary consumers for
the services provided by the Information Technology (IT) infrastructure, so it is essential
that your design meet their requirements and have the support of their management.
The amount of involvement in the design process that business units require varies
greatly among companies. In almost every organization, however, the involvement
includes at least an approval of the high-level goals of the design project. These goals
might revolve around issues such as accessibility of information, security, ease of man-
agement, and usability. Business managers are also usually involved in high-level and
highly visible decisions that cannot easily be changed after deployment. These decisions
include how many forests and domains are needed in the network and the number of
domain namespaces to be deployed.
Defining Business and Technical Requirements
Organizations invest in technology to solve business problems or to provide new business
opportunities. Business requirements typically dictate the reasons a new technology is being
implemented within the organization. Technical requirements frequently define how the new
technology will be designed and deployed to address the business requirements.
Business Requirements
Business requirements can take many different forms. For example, an organization may
need to:
■ Become more efficient Most businesses are very competitive and strive to be more

efficient than their competitors. When evaluating new technologies, these organizations
typically will invest in the technology if it will improve efficiency.
■ Meet an external requirement Forces outside an organization, such as the government
or business partners, may impose requirements. For example, government regulations
may require that organizations ensure the privacy of all user and customer information.
■ Avoid disruptions to business processes A current technology may meet most business
requirements. However, if it is unreliable, an organization may invest in a new technology
that provides the requisite reliability and availability.
■ Explore new business areas or solutions Organizations sometimes use technologies
to pursue new business opportunities. For example, deploying Web-based tools for
selling products and services has significantly increased the business potential for many
organizations.
146 Part II: Designing and Implementing Windows Server 2008 Active Directory
A technology deployment is more likely to address an organization’s needs if business require-
ments are defined clearly and concisely at the project’s inception. Additionally, it is easier to
measure a project’s success if the project team is knowledgeable about the business problems
that the project must solve.
Functional Requirements
Functional requirements define a system’s expected behavior. Functional requirements are
derived from business requirements. Business requirements define the problem to address,
while functional requirements define how the proposed technology should solve that problem.
For example, an organization may define a business requirement that all users in all offices
must always be able to gain access to shared resources such as an e-mail system or business
applications during regular business requirements. The resulting functional requirement may
specify the server locations and configurations required to address the business requirement.
Functional requirements are used to create the functional specification, which describes the
proposed solution in exacting detail and forms the basis for project plans and schedules. The
functional specification is important because it:
■ Establishes an agreement between the deployment team and the technology consumer
or customer

This enables the team to determine the correct solution to meet the
customer’s expectations.
■ Provides in-depth project details to help the team determine if it is building the solution
correctly This, in turn, makes the solution easier to validate and verify.
■ Enables the team to estimate budgets and schedules The quantity of resources and
their respective skill sets are difficult to determine without the specific detail that
a functional specification provides.
Note
In addition to functional requirements, every design has nonfunctional requirements.
Nonfunctional specifications do not define what the system does but rather how the system
will perform and/or the quality of service it will provide. Common nonfunctional requirements
include system availability, maintainability, performance, reliability, and scalability.
Service Level Agreements
Service level agreements (SLAs) are understandings between an organization and the group
managing the information system infrastructure that define expected performance levels. It
is important to define an SLA because it documents the service expectations and requirements
that an organization expects the IT department to deliver. SLAs may define several categories
of expected performance, including:
■ Availability For example, an SLA may require that all users can logon on to the network
and access critical applications 99.99 percent of the time during business hours and
99.9 percent of the time during nonbusiness hours.
Chapter 5: Designing the Active Directory Domain Services Structure 147
■ Performance For example, an SLA may specify that all users should be able to logon to
AD DS within 15 seconds of entering their credentials.
■ Recovery For example, an SLA may stipulate that in the event of a single server failure,
the services provided by the server will be restored to at least 75% of normal capacity
within 4 hours of server failure.
Note
The SLAs that organizations use can vary from informal to very structured. Informal
SLAs often are not documented, but rather are general expectations for system performance

that are well known. For example, an organization may have an internal, unwritten policy that
certain servers should not be restarted during business hours except in cases of emergencies.
Formal SLAs typically are documented extensively and detail expectations determined from
negotiations between service providers and business customers. These SLAs may define exact
expectations for each system component in the system and may include penalties if expecta-
tions are not met. Often, the most formal SLAs are negotiated between business customers
and outsourced IT providers.
SLAs have a significant impact on a project’s scope and budget, so it is important to define
them at the project’s inception. Business requirements plus functional and nonfunctional
requirements typically form the basis for initial SLA negotiations. In most cases, the project
team and business sponsors negotiate the final SLA details. Initial requirements may set very
high expectations. However, meeting those high expectations can be expensive. For example,
if an SLA requires that all users in all offices be able to logon on to AD DS at all times, you may
need to deploy fully redundant systems or WAN connections throughout the organization.
The cost of this is likely would be prohibitive. Thus, the organization may negotiate a more
acceptable performance level at a more reasonable cost.
Legal Requirements
Information systems make it very easy to collect, store, and transmit information. Many coun-
tries have imposed compliance requirements that mandate how organizations ensure data
confidentiality. Examples of legislation restricting how organizations manage information
include:
■ United States:
❑ Sarbanes-Oxley Act of 2002 (SOX)
❑ Gramm-Leach-Bliley Act (Financial Modernization Act)
❑ Health Insurance Portability and Accountability Act of 1996 (HIPAA)
❑ Uniting and Strengthening America by Providing Appropriate Tools Required to
Intercept and Obstruct Terrorism Act of 2001 (USA Patriot Act)
■ Canada: The Personal Information Protection and Electronic Documents Act
■ Australia: Federal Privacy Act
148 Part II: Designing and Implementing Windows Server 2008 Active Directory

■ Europe: European Union Data Protection Directive (EUDPD)
■ Japan: Japan’s Personal Information Protection Act
When designing the AD DS infrastructure, you need to consider these legal requirements.
In some cases, you will be able to design technical solutions to address the requirements.
For example, if all customer information must be kept confidential from all but certain
specified users, you may choose to store customer information in a separate Active Directory
Domain Services (AD DS) forest or deploy an Active Directory Lightweight Directory Services
(AD LDS) instance with strict restrictions on who can access the data. To prevent users from
sending confidential data outside the organization, you may implement an Active Directory
Rights Management Services (AD RMS) solution.
Technical solutions can rarely address all of the legal requirements. For example, if you use
AD RMS to protect confidential data, a user can still use a digital camera to take pictures of the
confidential data and send the data outside the organization. Users with access to confidential
customer information can still share that information with unauthorized users. To address
these issues, organizations must complement the technical solutions with corporate policy-
based solutions that clearly specify acceptable actions and consequences for not following
acceptable actions.
Security Requirements
All IT deployments will also have security requirements. These requirements become espe-
cially important when deploying AD DS because AD DS is likely to be used to secure access
to most data, services, and applications on the network.
To identify security requirements, ask the following questions:
■ What are the organization’s security risks? There are many possible answers to this
question, including:
❑ Mobile users who travel extensively and must connect to the internal network to
gain access to e-mail, applications, or data.
❑ Users outside the organization who may require access to Web sites located in a
perimeter network and be able to authenticate using their internal AD DS user
accounts.
❑ Offices that are not physically secure, where malicious users might be able to gain

access to the network. Other offices may not have a secure location for storing
domain controllers or other servers.
❑ A database with confidential customer information that must be accessible to Web
applications running in the perimeter network.
■ How are the security requirements currently addressed? Almost all organizations have
addressed at least some security requirements. For example, virtually all organizations
Chapter 5: Designing the Active Directory Domain Services Structure 149
have implemented antivirus solutions and firewalls to protect the internal network from
Internet-based attacks.
■ What gaps exist between security requirements and current solutions? These gaps will
vary between different organizations. For example, some organizations have deployed
applications that require users to authenticate using credentials that are not secure
when transmitted on the network. To simplify the user experience in these situations,
some organizations will assign the same user name and password for the application as
is used to log on to AD DS. This means that if the credentials used to authenticate to the
application are compromised, the AD DS credentials are also compromised.
■ What general security requirements or guidelines must the project follow? Most organi-
zations have general security requirements that apply to all projects. These requirements
could include:
❑ All servers must be located in a secure server room which can be accessed by only
authorized users.
❑ All authentication traffic must be secured while transmitted on the network.
❑ All users who access the internal network through a virtual private network (VPN)
must use two-factor authentication.
Security requirements can sometimes conflict with business requirements. For example, a
business requirement may state that all users in a particular department must be able to
access the internal network through a VPN. The security requirement may state that all VPN
users must provide two-factor authentication. If not all users in the department have mobile
computers that support two-factor authentication, then there is a conflict between the busi-
ness requirement and the security requirement.

Security requirements often place restrictions on what a project can accomplish. A technical
solution may meet or exceed business requirements, but if the person who is responsible for
defining security requirements does not consider it secure, it may need to be revised or the
business requirement may need to be removed. In many organizations, some security require-
ments are not negotiable, while other security requirements may be modified to accommo-
date a critical business requirement.
Project Constraints
Project constraints define the project’s parameters by setting limits on what can be done. For
example, if the project has a fixed budget, planners may have to use the equipment they
can afford rather than the equipment they consider ideal for the job.
There are three general categories of project constraints:
■ Resource constraints A project’s budget is a common resource constraint. If the pro-
posed budget cannot meet the projected personnel costs, equipment costs, and software
150 Part II: Designing and Implementing Windows Server 2008 Active Directory
costs, the project cannot continue or may need to be modified to address the restraints.
Additionally, a project may have other resource constraints:
❑ The appropriate personnel may not be available or their training may not be
sufficient to complete the project.
❑ Computer resources or equipment may not be accessible.
■ Schedule constraints A project schedule also may restrict what the project can accom-
plish. For example, many organizations do not allow changes to the IT environment dur-
ing specific times, such as during the end of the corporate fiscal year or peak business
cycles. If a project is due for completion during one of these periods, the project scope
may require modification. Additionally, a project may be constrained by the schedule of
other projects.
■ Feature constraints Feature constraints can impact a project’s start or scope. For exam-
ple, if an organization is evaluating a new product based on a particular feature and that
feature is not available or does not meet the company requirements, the organization
may choose to cancel the project. If a particular feature is critical, the project scope may
be modified to include the feature.

The project team and business sponsors often negotiate project constraints, as well as busi-
ness requirements and SLAs. The budget may seem like a firm constraint, but if increasing the
budget results in meeting an important business requirement or SLA level, the budget may be
adjusted to include the requirement.
Documenting the Current Environment
Once you have gathered the directory service requirements, the next step is to analyze the cur-
rent network and directory environment. Analyzing the current environment helps determine
what needs to change when deploying the new infrastructure. This information provides a
starting point for determining the appropriate design and implementation plan for the Win-
dows Server 2008 deployment.
Figure 5-2 shows a checklist of the types of information that you need to collect when starting
your AD DS design.
Important
As you collect information about the current network infrastructure or
any other component in the current environment, you should also ensure that you collect
information about any planned changes to the environment. For example, if the WAN links
are going to be upgraded before AD DS will be deployed, include this information in your
documentation. These changes may interfere with the AD DS deployment because of project
dependencies or may result in changes to your design.
Chapter 5: Designing the Active Directory Domain Services Structure 151
Figure 5-2 AD DS design current environment checklist.
Documenting the Physical Network Infrastructure
When documenting the physical network infrastructure, include the following components:
■ The number, geographic locations, and link speed of all sites where network services
exist It is important to identify all locations that make up the network infrastructure,
such as buildings, campuses, and branch offices. You also must determine the connection
types and network speed for each location. It is also important to consider the physical
security of the various locations. For branch offices in particular, it is common to have
decreased physical security, and this will affect the design choices you have to make.
■ A routing topology map that illustrates the physical sites and the Internet Protocol (IP)

subnets in use at those sites
This map is useful in planning or integrating with the AD
DS site design.
■ Bandwidth, latency, and current usage Bandwidth is the transmission speed over a
network connection in kilobits per second (Kpbs). Latency refers to the time it takes,
in milliseconds, to transfer data between two points. Both of these factors combine to
determine how much data that can be transmitted in a set time period over the network.
This information, as well as the current applications using the network and the number
of users at various locations and their use patterns, can be used to create a design for
your AD DS implementation that provides a satisfactory user experience.
■ Firewall configuration requirements If your organization has deployed firewalls between
company locations, document the firewall locations and the firewall rules. Incorrectly con-
figured firewalls can disrupt DNS name resolution, AD DS replication, and authentication.
Document
physical
network
Document
name resolution
infrastructure
Document
Active Directory
infrastructure
Document
additional
infrastructure
components
Document
administrative
models and
processes

152 Part II: Designing and Implementing Windows Server 2008 Active Directory
■ Nontechnical constraints These include geographical, political, or cost-related restric-
tions resulting from a change or upgrade of network links between sites.
On the Disc
You can use the CurrentNetworkEnviroment.xlsx file on the CD to document the
current networking environment. Several tabs in the slide refer to associated network diagrams.
One of the best tools for creating network diagrams is Microsoft Office Visio. Four Visio tem-
plates that can be used for diagramming LAN and WAN configurations are included on the CD.
You can download additional Visio templates from />default.aspx. A sample WAN diagram (WANDiagram_Sample.vsd) is also included on the CD.
Documenting the Name Resolution Infrastructure
AD DS requires a DNS (Domain Name System) infrastructure so that domain controllers
can locate each other and so that client computers can locate domain controllers. When
documenting the DNS infrastructure, include the following:
■ What type of DNS software is currently in use? Is it able to handle service (SRV)
resource records?
■ Who maintains and administers the organization’s internal and external DNS servers
and zone information? What are the IP addresses of all DNS servers?
■ Who assigns DNS names and domains within the organization? Is there a centralized
authority for DNS namespace planning and control?
■ Where are internal DNS servers located on the network? What zones are stored on each
DNS server?
■ How is DNS name resolution across multiple namespaces configured? How are root
hints, forwarders, conditional forwarders, stub zones, and delegations used to facilitate
name resolution?
■ Are the DNS zones AD DS-integrated?
On the Disc
Refer to the DNS Zone Configuration and the DNS Server Configuration tabs
in the CurrentNetworkEnvironment job aid located on the CD to document the current name
DNS infrastructure.
Documenting the Active Directory Infrastructure

Most organizations that deploy AD DS will already be running some version of Active Directory.
Before starting your AD DS design, ensure that you understand the current environment.
When documenting the current Active Directory deployment, include the following:
■ Active Directory forest and domain topology
❑ Does your organization consist of a single forest or multiple forests? If the
organization has deployed multiple forests, you may want to explore options for
consolidating the forests.
Chapter 5: Designing the Active Directory Domain Services Structure 153
❑ How many domains are implemented in each forest?
❑ What is the purpose of each domain? In order to determine if you can consolidate
domains, you need to understand why each domain was created.
❑ If the organization has deployed multiple forests, what rationale does the
organization have for maintaining multiple forests? If the rationale for choosing
multiple domains is still valid, you will probably have to retain multiple forests.
If not, you will be able to explore the option of consolidating forests.
■ Active Directory trust configuration
❑ What trusts are configured in addition to the default trusts configured within
an AD DS forest? As you document the trusts, determine the rationale for each
trust. Is the rationale still valid?
❑ What trust relationships exist with external domains? Determine whether these
trusts are still required or if additional trusts are required.
■ What are the domain and forest functional levels? As you raise the domain and forest
functional levels, you gain new features in Active Directory. If the domain and forest
functional levels are not at the highest level supported by the operating systems on the
domain controllers, why has the functional level not been raised?
■ Active Directory site configuration: Document the current Active Directory site topology,
including:
❑ Number of configured sites
❑ Subnet configurations and their site association
❑ IP site links and their member sites

❑ IP site link costs and replication schedules
■ Domain controller and global catalog server configuration: As you analyze each Active
Directory site, document the configuration and location of each domain controller and
global catalog server. As part of the domain controller documentation, identify which
domain controllers are hosting the forest and domain operation master roles.
■ FSMO role holders: AD DS has a number of operation master roles and it is very impor-
tant to understand which domain controllers in the domain or forest holds them.
■ Time service configuration: Time synchronization is critical in an AD DS environment,
so you should review how time service is configured in your forest.
■ Organizational unit (OU) configuration: As you analyze the domain, document the current
OU structure. For each OU, document the location in the domain hierarchy, the purpose
for each OU, and the delegated permissions and linked Group Policy objects (GPOs).
■ Group Policy configuration: Many organizations use Active Directory Group Policy to
provide centralized management and security of users, groups and computers, and
other directory objects. Document the GPOs, the purpose for each GPO, the inheritance
and filtering settings for each GPO, and the GPO settings.
154 Part II: Designing and Implementing Windows Server 2008 Active Directory
■ Active Directory groups: Document the group configuration, including the group scope
and type, the group owners and membership list, and how the group is used. This is
particularly important for all groups with administrative permissions.
On the Disc
You can use the CurrentDirectoryEnviroment.xlsx file on the CD to document
the current Active Directory environment.
Current Active Directory Configuration and AD DS Design
An important requirement in AD DS design is balancing the optimal design for a
network in which it is currently deployed. As you prepare your AD DS design, consider
the current Active Directory design and the implications of migrating from that infra-
structure to a different design in AD DS. The current domain structure might not be
ideal. However, just upgrading the current domains is significantly easier (and less
costly) than creating the ideal AD DS structure and then migrating all of the domain

objects to the new domains. This means that you might be forced to work with a less-
than-ideal AD DS structure because you are required to upgrade the current domains.
Of course, you might also find that the current structure is so far from the ideal structure
that it is worth the extra work and cost of restructuring all the domains. Probably the
most common scenario will be one where the current structure is almost acceptable, but
you would like to make some changes. In this scenario, you might upgrade one or more
domains and then merge other domains into the upgraded domains.
As you prepare your AD DS design, consider creating an ideal AD DS design and then
create another design based on the optimal upgrade scenario for the current environ-
ment. Chances are good that your final design will fall somewhere between the ideal and
the optimal designs.
This interaction between an ideal design and what is realistically possible illustrates
another important aspect of AD DS design: it is almost always an iterative process. You
might start out with one design in mind, and as you gather additional information,
you will likely need to modify that design. As you start testing the implementation or
migration scenarios, you might again modify your AD DS design.
It is important, however, that some parts of your design be finalized before you begin
deployment. Design decisions such as the number of forests and domains as well as the
domain namespace design are difficult to change after deployment has started. Other
issues, such as final OU design and site design, are fairly easily changed after deployment.
Documenting Additional Infrastructure Components
In addition to the network infrastructure and directory components, you may need to collect
information on additional infrastructure components, such as:
■ Exchange Server implementation If your organization has deployed Exchange Server,
you will need to document the Exchange Server infrastructure. Exchange Servers and
Chapter 5: Designing the Active Directory Domain Services Structure 155
messaging clients have a strong dependency on AD DS that will affect the number and
placement of domain controllers and global catalog servers. In addition, if your organi-
zation has deployed or is planning on deploying Exchange Server 2007, you will need to
consider Exchange message routing when designing the site configuration. For more

details on how Exchange Server may influence your AD DS design, see the sidebar,
“Exchange Server 2007 and Site Design,” later in this chapter.
■ Directory enabled applications In addition to Exchange Server, document all other
directory-enabled applications deployed in the organization. In your documentation,
describe whether the application is currently using Active Directory or another directory
service, whether the application requires AD DS schema changes, and where the appli-
cation is deployed.
■ Backup and disaster recovery infrastructure In most cases, the AD DS domain control-
lers will need to integrate with the current backup and disaster recovery infrastructure.
Collect information on the backup and disaster recovery technology as well as on
backup schedules and processes.
■ Additional applications Create an inventory of the products used in your environment,
including antivirus solutions, storage management software, and system management
and monitoring tools.
Documenting Administrative Models and Processes
Your organization’s administrative structure and processes have great influence on the IT
infrastructure design. This is particularly true with an AD DS design because of the flexibility
that AD DS provides for delegating administrative tasks. When documenting the administra-
tive model, include the following:
■ Current organizational administrative model In some organizations, IT management
may be centralized, while in other organizations, the responsibilities may be delegated
to regional areas or individual business units. The most common approach is a combi-
nation of the two, in which some IT functions are centralized, such as network provi-
sioning and security, while other functions, such as user account or desktop computer
management, are delegated to geographic or business subdivisions.
■ User account administrative model In a centralized environment, a single group of
administrators may perform these tasks for all users throughout the organization. In a
decentralized environment, this responsibility may lie with the departmental team or
with some other team, such as the human resources or corporate security departments.
■ Business unit structure It is not necessary to explore exhaustively the interrelationships

between an organization’s business units or divisions. However, it is useful to examine
some aspects of these relationships. For example:
❑ Do separate business units or divisions require security boundaries between
them? If so, a multiple-forest design may be required.
156 Part II: Designing and Implementing Windows Server 2008 Active Directory
❑ What are the requirements for communication between different business units?
For example, is a unified directory or address list necessary for the entire organization?
❑ How is cross-unit communication controlled? In other words, which group is
responsible for locating and resolving authentication, network, or protocol
problems that hinder communication between users and resources in different units?
■ Troubleshooting processes Most large organizations have a well-defined troubleshooting
process that may include multiple levels of support. The information about the current
troubleshooting processes is useful when you create the deployment plan and also
helps to ensure that the appropriate administrators receive the necessary training for
troubleshooting the AD DS deployment.
■ Change control process The change control process varies greatly between organiza-
tions. Some organizations have not implemented a formal change control process,
while others implement strict change requests, approval, and notification processes. Key
questions to ask regarding change control processes include:
❑ How does the organization implement IT changes? You need to identify specific
processes that take place when changes are implemented.
❑ How are IT infrastructure changes approved? Before changes are made, specific
approval may be required by IT managers, enterprise administrators, or security
personnel. You need to document who the decision makers are and how they
affect the change-approval process.
❑ How are change notifications handled? Before the change takes place, all affected
users must be notified of the change and any impact it may cause. It is important
to document all current change-notification processes and the requirements
specifying when change notifications are required.
❑ What are the emergency escalation notification processes? If issues arise during

implementation of the approved change, you will need to know who to contact to
provide troubleshooting and recovery procedures.
❑ What are the time frames for making changes that may impact availability? Many
organizations limit when critical network services can be changed or taken offline.
❑ What are the risk management processes related to change management? A
complete change control process includes a risk analysis and processes for
mitigating risks.
Designing the Forest Structure
After collecting the business and technical requirements and documenting the current
environment, you are ready to start designing the AD DS infrastructure. Probably the most
important decision you need to make early in the design process is how many forests you will
create. Deploying a single AD DS forest makes it easy to share and access information within
the company. It also makes it easy to centrally manage the entire directory infrastructure.
Chapter 5: Designing the Active Directory Domain Services Structure 157
However, using a single forest for a large corporation also requires a significant degree of
cooperation and interdependence between possibly diverse and disconnected business units.
Ultimately, the number of forests you deploy depends on what is more important in your
company: sharing information with ease across all the domains in the forest or being able to
maintain fully isolated control of a part of the directory structure.
Figure 5-3 shows the process for creating a forest design.
Figure 5-3 Creating a forest design.
Determine the
number of forests
Determine the
forest design model
Determine the
forest integration
Determine the
forest trust design
Require multiple

forests
Require one
forest
For each forest
Determine the
forest owner
Define the forest
change control process
Research the
implications of
choosing one
or more forests
Determine if you
will require more
than one forest
158 Part II: Designing and Implementing Windows Server 2008 Active Directory
Forests and AD DS Design
An AD DS forest is designed to be a self-contained unit. Inside the forest, it is easy to share
information and collaborate with other users in the same unit. However, because the forest
is a self-contained unit, the actions of one person can potentially impact everyone else in the
forest. As you design the highest level of the AD DS infrastructure, you must decide whether
you need to deploy one forest or multiple forests. Each forest is an integrated unit because it
has the following characteristics:
■ Global catalog The forest can have many global catalog servers but has only one global
catalog. The global catalog makes it easy to locate objects in any domain in the forest
and to log on to any domain in the forest, regardless of which domain hosts your user
account.
■ Configuration directory partition All domain controllers share the same configuration
directory partition. This configuration information is used to optimize replication of
information throughout the forest, to store application information for directory-

enabled applications, and to share information through application directory partitions.
■ Trusts All of the domains in the forest are connected by two-way transitive trusts. There
is no option to change this.
Note
One of the best illustrations of the way a single forest is used to make collaboration
easier is seen in how Microsoft Exchange 2000 Server and later versions use forests. The forest
boundary is also the boundary for the Exchange Server organization. Exchange Server stores
most of its configuration information in the configuration directory partition, making it easy
to manage message routing throughout a large organization. The global address list (GAL) is
made up of all the e-mail recipients in the global catalog. Having a single Exchange Server
organization is highly desirable for most companies. Within one organization, calendar infor-
mation, public folders, and recipient information is accessible to everyone, and many types of
collaborations are enabled by default. As soon as you deploy multiple organizations (and
multiple forests), these benefits are much more difficult to implement.
Although AD DS makes the sharing of information easier, it also enforces a number of restric-
tions that require the different business units in a company to cooperate in several different
ways. These restrictions include:
■ One schema All the domains in the forest share a single schema. Although this sounds
simple enough, this might be the most important reason for a corporation to deploy
multiple forests. If one business unit decides to deploy an application that modifies the
schema, all business units are affected. This can become overwhelming if 20 business
units decide that they want to deploy applications that modify the schema. Every
schema modification must be tested to ensure that it does not conflict with other
schema changes.
Chapter 5: Designing the Active Directory Domain Services Structure 159
■ Change control policies Because changes made to the forest can affect every domain
and because most significant changes should only be performed in a centralized
manner, a well-defined change control policy must be in place.
■ Centralized administration Choosing to deploy a single forest means that some
components of network administration must be centralized. For example, the only

group with the right to change the schema is the Schema Admins group. The only group
with the right to add and remove domains from the forest is the Enterprise Admins
group. Both of these groups exist in the forest root domain and the actions of these
administrators will impact the entire forest. The Enterprise Admins group is automati-
cally added to the domain local Administrators group on every domain controller in the
forest. For some companies, this type of centralized administration is not acceptable.
■ Trusted administrators Deploying a single forest requires a degree of trust from all
administrators in all domains. Any administrator with the rights to administer a domain
controller can make changes that will affect the entire forest. This means that all domain
administrators must be highly trusted. You can reduce the risk of administrators making
changes that will affect the entire forest by implementing RODCs in locations without
highly trusted administrators.
As you deal with the question of how many forests you need to deploy, you will need to balance
the benefits of deploying a single forest with the ways in which a single forest requires a high
level of integration between domains, OUs, and the business units that these objects represent.
Single or Multiple Forests
As mentioned earlier, the most significant question that you need to answer when creating
your forest design is whether you will have a single forest or multiple forests. This decision
should be made before deployment because it is very difficult to change after deployment.
There is no one-step process to merge forests; rather, you must move whatever objects you
want in the new forest from the old forest. Also, there is no easy way to split a single forest into
two. You must create a separate forest and then move objects from one to the other.
The most common AD DS forest deployment is a single forest. For most companies, the benefits
of a shared global catalog, built-in trusts, and a common configuration directory partition are
more important than maintaining a complete separation of all administrative roles. As you work
with designing AD DS, your first choice should always be to deploy a single forest. Assume that
you will be deploying a single forest, but be prepared to be convinced to do otherwise.
Having said this, there are clearly situations where multiple forests are the best option:
■ Some companies deploy separate AD DS forests in perimeter networks (or DMZs).
Most organizations deploy servers that need to be directly accessible from the Internet

in a perimeter network to provide an extra level of security for the internal network.
These servers can be deployed as stand-alone servers, but by deploying a separate AD
DS forest in the perimeter network, you can take advantage of the computer and user
160 Part II: Designing and Implementing Windows Server 2008 Active Directory
management features provided by AD DS while still maintaining isolation from the
internal AD DS forest.
■ Some companies do not have a strong requirement for intracompany collaboration.
In some companies, business units operate quite independently of each other, with
little need to exchange information other than e-mail. These companies are not giving
anything up by deploying multiple forests.
■ Some companies require a complete separation of network information. For security or
legal reasons, a company might be required to ensure that some network information
not be accessible to anyone outside a business unit. By default, the information in one
forest is not visible in any other forest.
■ Some companies require incompatible schema configurations. If two parts of the
organization require a unique schema because they are deploying applications that
make incompatible changes to the schema, you must create separate forests.
■ Some companies cannot agree on centralized administrative procedures. If business
units in the company cannot agree on policies for forest or schema change control, or if
they cannot agree on centralized administration, you will have to deploy separate forests.
■ Some companies must limit the scope of trust relationships. Within a forest, all domains
share a transitive trust, and there is no option to break these trusts. If your network
environment requires a trust configuration where there cannot be a two-way transitive
trust between all domains, you must use multiple forests.
For some companies, deploying multiple forests might be an appealing option. However,
deploying multiple forests adds significant complexity to the network infrastructure. Some of
these issues are:
■ Increased administrative effort required to manage the network. At least one domain as
well as the forest-level configuration must be managed in each forest.
■ Decreased ability of users to collaborate. One example of this is searching for resources

on the network. Users are no longer able to search the global catalog for resources in
the other forest. Users must be trained in how to search for resources outside of the
global catalog.
■ Additional administrative effort required for users to access resources between forests.
Administrators must configure the trusts rather than using the built-in trusts. If any
information must be synchronized between the forests, this must also be configured.
Business Involvement and Forest Design
Few companies have purely technical reasons to deploy more than one forest. A forest
can contain multiple domains, with each domain containing hundreds of thousands of
objects. The domains can be deployed with multiple namespaces and with distinct
administration for each domain.
Chapter 5: Designing the Active Directory Domain Services Structure 161
However, when you present decision makers in your organization with the list of forest
requirements, such as centralized control, a common schema, or trusted administrators,
you are sure to meet resistance. The most common reasons why companies deploy
multiple forests is company politics or the inability of different departments or business
units to work out how to deal with the centralized components of managing a single
forest. In some cases, the company cannot agree on a forest modification or schema
modification process. In other cases, the fact that a domain administrator in one domain
can affect all other domains in the forest means that a single forest is not acceptable. This is
especially true in the common scenario in which a number of formerly independent
companies must now work together due to corporate takeovers or mergers.
Separate forests might be the answer for some of these companies, but you must also
alert the decision makers to what they will lose if they do insist on multiple forests.
Implementing multiple forests enables autonomy between business units, but also
means that it is much more difficult to share information and the environment will be
much more costly to manage.
Designing Forests for AD DS Security
For some companies, the decision to deploy more than one forest will come down to whether
the company requires administrative autonomy or administrative isolation between business

units. In AD DS, there are many types of administrative activity including both the configura-
tion of the directory services (forest configuration, domain controller placement, Domain
Name System [DNS] configuration) and management of the data in the directory service
(managing user or group objects, Group Policy objects, and so forth).
Service and Data Owners and Administrators
In large organizations, AD DS administrative roles are often divided into different cate-
gories. One way to describe the different categories is to distinguish between service
owners and administrators and data owners and administrators:
■ Service owners and administrators are responsible for AD DS as a service. That is,
they are responsible for the design and administration of the AD DS infrastruc-
ture. The service owners will make the decisions on how many forests, domains,
and sites will be required to ensure that the AD DS service meets the company
requirements. The service administrators have the required rights and permis-
sions to create and manage these AD DS objects.
■ Data owners and administrators are responsible for the data that is stored in AD
DS. The data owners set policies and processes for managing the data, and the
data administrators have the rights and permissions to create the AD DS objects
within the structure defined by the service owners and administrators.
162 Part II: Designing and Implementing Windows Server 2008 Active Directory
As a best practice, an organization should have very few service administrators. That is,
very few accounts should have the required permissions to change the AD DS structure.
By default, the Domain Admins in the forest root domain, Enterprise Admins, and
Schema Admins groups have service owner permissions. However, because data admin-
istrator permissions can be limited to specific containers within an OU, the organization
may have significantly more data administrators. To configure data administrator
accounts, you should create the required groups and accounts and assign permissions
specific to the container where the data administrator requires access.
You need to consider both service administrators and data administrators when designing
for administrative isolation or autonomy. Although a service administrator may have a
higher level of permissions, a data administrator can still make changes to AD DS that

will affect the entire forest. For example, when a data administrator creates a new user
account, the global catalog for the entire organization is modified.
For a more detailed discussion on the role of service and data owners and administra-
tors, see “Creating a Forest Design” at />library/ff92f142-66ea-498b-ad0f-a379c411eb6e1033.mspx?mfr=true. This guide is based
on deploying Windows Server 2003 forests. Many of the principles apply to Windows
Server 2008. You should also check the Windows Server 2008 TechCenter site for an
updated version of this guide.
Administrative autonomy means that you have complete administrative control over some
component of the forest. You might have administrative autonomy at the forest level, domain
level, or OU level. However, administrative autonomy does not mean that you have ultimate or
exclusive control. For example, you might be able to completely administer your domain, but
the Enterprise Admins group from the forest root domain also has administrative permissions
to your domain.
Administrative isolation, on the other hand, means that you have exclusive control over a
component of the directory. If you have administrative isolation, no one else has any control
over your part of the forest, and no one else can modify the directory service configuration or
modify the data in your part of the forest.
AD DS provides many ways to achieve administrative autonomy. Domain administrators can
do anything they want in a domain. OU administrators can be given full rights to create and
administer any types of objects in an OU. A single forest in AD DS is designed for administra-
tive delegation and autonomy.
However, if you require administrative isolation, the only way to achieve this is through the
creation of separate forests. Part of the reason for this is because of the way AD DS is designed.
The Enterprise Admins group is automatically added to each domain’s local Administrators
group. The Domain Admins group has full administrative control over every object in the
domain and is automatically added to the Administrators group on every computer in the
Chapter 5: Designing the Active Directory Domain Services Structure 163
domain. Although the default configuration can be modified and the groups removed from
the lower-level administrative groups, the higher-level administrators can always regain con-
trol of lower-level objects. This means that no part of the forest is isolated administratively.

Another reason a separate forest is needed for administrative isolation is because of the
possibility of malicious actions on the part of administrators in the domain. Anyone with
administrative access to a domain controller can violate the administrative isolation of any
other partition in the forest. An administrator might install software on the domain controller
in one domain that modifies the directory information for every domain in the forest. The
administrator might modify his or her own security identifier (SID) so that it appears that he
or she is a member of the Enterprise Admins group and then use this access to make forest-
wide changes.
All of the domain controllers and partitions in the forest are tightly integrated, and any change
made on one writable domain controller will be replicated to all other domain controllers.
There is no security check on the validity of replicated information; there is only a security
check on making changes to the directory information. So, if a malicious administrator man-
ages to make a change to the directory information, all other domain controllers will accept
the replicated change without question. For these reasons, you must create separate forests if
you require administrative isolation. In some cases, you might be required to guarantee com-
plete isolation of a directory partition. If so, you must accept the added administrative effort
and loss of collaboration that comes from deploying multiple forests.
Many companies, however, require administrative autonomy along with a reasonable
assurance that administrators from other partitions in the forest will not act maliciously. This
reasonable assurance can be addressed in most companies by doing the following:
■ Putting only highly trusted administrators into groups that have administrative control
over domain controllers. These groups include the Domain Admins group as well as
the domain’s local Administrators, Server Operators, and Backup Operators groups.
Administrative tasks that do not require access to the domain controllers should be
delegated to other groups.
■ Physically securing the domain controllers with only highly trusted administrators
given access to the servers.
■ Auditing all actions performed by high-level administrators.
High-level administrators should log on using the administrative account only when
necessary. These administrators should also have normal user accounts for day-to-day work.

Forest Design Models
At a high level, there are three common forest design models used when creating the forest
design. Most organizations will require one of these forest design models, although you may
need to use a combination of designs in some organizations.
164 Part II: Designing and Implementing Windows Server 2008 Active Directory
Organizational Forest Model
In the organizational forest model, the forests are designed along some organizational criteria.
For example, an organization with multiple business units or geographical locations, or an
organization that was formed by acquisitions or mergers, may choose to use an organizational
forest model. To enable access to resources between the organizational entities, you can
configure forest trusts between forests or external trusts between specific domains in each
forest. See Figure 5-4 for an illustration of the organization forest model.
Note
If an organization has deployed only a single forest, it is using the organizational
forest model.
Figure 5-4 An organizational forest model.
In this model, all user accounts and shared resources related to each organizational entity are
stored within the relevant forest. By creating separate forests, you can ensure administrative
autonomy and isolation between the business units.
Optional
forest trust
Optional
external trust
Adatum.com
Users
Servers
Group
Shared Resources
NA.Adatum.com
Users

Servers
Group
Shared Resources
Fabrikam.com
Users
Servers
Group
Shared Resources
Chapter 5: Designing the Active Directory Domain Services Structure 165
Resource Forest Model
In the resource forest model, user and group account management is isolated from resource
management by creating separate forests for each function. All user and group accounts are
stored in one or more account forests, and all shared resources are configured on servers in
one or more resource forests. The resource forests do not contain user accounts other than
administrative accounts and service accounts required by applications.
In the resource forest model, you must configure trusts between the two forests. In most cases,
this will be a one-way forest trust configured so that users in the account forest can access the
resources contained in the resource forest. You can enable two way trusts, external trusts, or
forest trusts with selective authentication in this model. See Figure 5-5 for an illustration of
the organization forest model.
Figure 5-5 A resource forest model.
The resource forest model enables administrative autonomy and isolation for both the
account and resource forests.
Restricted Access Forest Model
The restricted access forest model is a variation on the organizational forest model. In a
restricted access forest model, a separate forest is created to contain user accounts and shared
resources that must be isolated from the rest of the organization. The restricted access forest
is different than the organizational forest in that no trusts are configured between the two
domains.
The restricted access forest is designed to ensure administrative isolation. This means that no

user account in a forest outside the restricted access forest can have any permissions or access
to any data in the forest. If users in the organizational forest require access in the restricted
access forest, they must have a separate user account created in this forest and must have two
One-way
forest trust
Adatum.com
Users
Domain
Controllers
Group
Domain
Controllers
AdatumResources.com
Servers
Shared
Resources
166 Part II: Designing and Implementing Windows Server 2008 Active Directory
client computers, each joined to a different forest. See Figure 5-6 for an illustration of the
restricted access forest model.
Figure 5-6 A restricted access forest model.
Defining Forest Ownership
Regardless of how many forests you deploy, you will need to identify the forest owners for
each forest. In technical terms, it is easy to define who the forest owners are. The Schema
Admins group, the Enterprise Admins group, and the Domain Admins group in the root
domain can be considered the forest owners because they control what changes can be made
to the forest. However, these roles are purely technical, and the people in these groups are
almost never the final authority on whether or not modifications are actually made to the
forest. For example, the Schema Admins group can change the schema, but a member of the
Schema Admins group will usually not have the authority to decide whether a request for a
schema change will be approved.

Forest owners should possess a combination of technical expertise and business awareness.
They should be people who understand the overall business requirements of an organization,
but who also understand the technical implications of fulfilling all these requirements. Forest
owners might decide that an application that modifies the schema will be deployed because it
brings significant business value to the company. The schema administrator is then given
the task of modifying the schema as required.
In a company with multiple business units, the forest ownership group should be made up of
representatives from all the business units. Although it is important that all business units be
represented, this group must also be able to function efficiently. That is, a process must be in
place so that the group can efficiently decide whether or not a forest-level change will be
implemented. If implementing a global change takes an inordinate amount of time, individual
business units might regret that they ever agreed to deploy a single forest.
Users must have
accounts and
client computers
in both forests
No trust
is configured
between forests
Adatum.com
Users
Servers
Group
Shared Resources
AdatumRestricted.com
Users
Servers
Group
Shared Resources
Chapter 5: Designing the Active Directory Domain Services Structure 167

Forest Change Control Policies
The first task for forest owners is to define a forest change control policy. The forest change
control policy defines what changes can be made to the forest-level configuration and under
what circumstances those changes can be made. Essentially there are two types of forest
changes: schema changes and configuration directory partition changes (for example, add or
remove domains or application directory partitions, or modify the site configuration).
The forest change control policy also defines the procedures for testing, approving, and imple-
menting any forest change. This is especially significant for schema changes, because schema
changes are not easily reversed, and any schema change must be compatible with all other
schema changes. The forest change control policy should define the testing procedure for
schema changes, and the forest owners should provide a test lab for testing these changes. The
forest change control policy should require thorough testing of all forest-level changes, but
should also ensure that the testing can be done expeditiously. If each change request takes a
very long time to process, the frustration level for the users will keep increasing.
The forest change control policy should be in place before you deploy AD DS. In companies
with diverse and separate business units, developing this policy might be difficult and time-
consuming, but it will not be any easier after AD DS has been deployed. If business units can-
not agree on a forest change control policy before deployment, you might need to make the
decision to deploy multiple forests.
On the Disc
You can use the Forest Design Decisions tab in the ADDS_DesignDocument.xlsx
spreadsheet on the CD to document your forest design decisions.
Designing the Integration of Multiple Forests
Organizations that need multiple forests may still require some integration between the
forests. For example, in the organizational or resource forest model, users in one forest will
require access to resources in another forest. Organizations that use separate forests but still
want to enable some of the collaboration features available with Exchange Server will also
need to design some means of integration between multiple forests.
There are two high-level options for enabling the integration of forests. If organizations only
need to provide access to resources between forests, then they can configure inter-forest

trusts. If organizations need to provide more advanced integration between forests, they can
explore options for implementing some type of directory synchronization between forests.
Note
Active Directory Federated Services provides another alternative for providing access
to applications in one forest to users in another forest. For more details, see Chapter 19, “Active
Directory Federated Services.”
168 Part II: Designing and Implementing Windows Server 2008 Active Directory
Designing Inter-Forest Trusts
The easiest way to enable access to shared resources between forests is to configure trusts
between the forests or between domains in each of the forests. When configuring trusts
between forests, you can either configure forest trusts, which means that you establish
transitive trusts between the forest root domains, or you can configure external trusts
between any two domains in both forests.
Note
Before configuring trusts between AD DS forests, you must ensure that domain
controllers in either forest can resolve the DNS addresses for domain controllers in the other
forest. The easiest way to enable name resolution between forests is to configure conditional
forwarders in each forest. As well, both forests in a forest trust must be configured at least at
the Windows Server 2003 functional level (or higher).
Designing Forest Trusts
When you create a forest trust, you are establishing a trust relationship between the forest root
domains in the two forests. When you design the forest trust configuration, you will need to:
■ Design the forest trust direction
■ Design selective authentication
■ Design SID filtering
■ Design UPN suffix routing
Designing Forest Trust Direction When you configure a forest trust, you can choose the
trust direction. When creating the forest trust design, always plan on the least level of access
while still meeting the business requirements. For example, in a resource forest scenario, you
should be able to configure a one-way trust from the account forest to the resource forest.

Enable two-way trusts only if users in both forests require access to resources in the other forest.
Designing Selective Authentication The second option that you can configure when
creating a forest trust is selective authentication. By enabling selective authentication, you
have more control over which groups of users in a trusted forest can access shared resources
in a trusting forest and which resources they can access. When forest-wide authentication is
enabled, users who are authenticated over an inter-forest trust are automatically provided the
Authenticated Users SID of the trusting forest. The Authenticated Users SID is used to grant
many of the default rights for users in a forest. Because of this, after you set up an inter-forest
trust, users from the trusted forest receive some default rights to all of the resources in the
trusting forest that are accessible by the Authenticated Users group.