Tải bản đầy đủ (.pdf) (30 trang)

Tài liệu Module 7: Designing a Multiple-Domain Structure pptx

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (873.88 KB, 30 trang )





Contents
Overview 1
Identifying Business Needs 2
Accessing Resources Between Domains 5
Planning for Multiple-Domain Trees 9
Planning for Multiple-Tree Forests 13
Planning for Multiple Forests 16
Lab A: Designing a Multiple-Domain
Structure 19
Review 23

Module 7: Designing a
Multiple-Domain
Structure


Information in this document is subject to change without notice. The names of companies,
products, people, characters, and/or data mentioned herein are fictitious and are in no way intended
to represent any real individual, company, product, or event, unless otherwise noted. Complying
with all applicable copyright laws is the responsibility of the user. No part of this document may
be reproduced or transmitted in any form or by any means, electronic or mechanical, for any
purpose, without the express written permission of Microsoft Corporation. If, however, your only
means of access is electronic, permission to print one copy is hereby granted.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you any


license to these patents, trademarks, copyrights, or other intellectual property.

 2000 Microsoft Corporation. All rights reserved.

Microsoft, Windows, Windows NT, Active Directory, BackOffice, PowerPoint, Visual Basic, and
Visual Studio are either registered trademarks or trademarks of Microsoft Corporation in the
U.S.A. and/or other countries.

The names of companies, products, people, characters, and/or data mentioned herein are fictitious
and are in no way intended to represent any real individual, company, product, or event, unless
otherwise noted.

Other product and company names mentioned herein may be the trademarks of their respective
owners.

Project Lead: Andy Sweet (S&T OnSite)
Instructional Designers: Andy Sweet (S&T OnSite), Ravi Acharya (NIIT), Sid Benavente,
Richard Rose, Kathleen Norton
Instructional Design Consultants: Paul Howard, Susan Greenberg
Program Managers: Lorrin Smith-Bates (Volt), Megan Camp (Independent Contractor)
Technical Contributors: Angie Fultz, Lyle Curry, Brian Komar (3947018 Manitoba, Inc.), Jim
Clark (Infotec Commercial Systems), Bill Wade (Excell Data Corporation), David Stern, Steve
Tate, Greg Bulette (Independent Contractor), Kathleen Cole (S&T OnSite)
Graphic Artist: Kirsten Larson (S&T OnSite)
Editing Manager: Lynette Skinner
Editor: Jeffrey Gilbert (Wasser)
Copy Editor: Patti Neff (S&T Consulting)
Online Program Manager: Debbi Conger
Online Publications Manager: Arlo Emerson (Aditi)
Online Support: Eric Brandt (S&T Consulting)

Multimedia Development: Kelly Renner (Entex)
Testing Leads: Sid Benavente, Keith Cotton
Testing Developer: Greg Stemp (S&T OnSite)
Compact Disc and Lab Testing: Testing Testing 123
Production Support: Ed Casper (S&T Consulting)
Manufacturing Manager: Rick Terek (S&T OnSite)
Manufacturing Support: Laura King (S&T OnSite)
Lead Product Manager, Development Services: Bo Galford
Lead Product Managers: Dean Murray, Ken Rosen
Group Product Manager: Robert Stewart

Module 7: Designing a Multiple-Domain Structure iii


Instructor Notes
This module presents the design points to consider when planning a multiple-
domain structure. Included are strategies for assessing the need for multiple
domains, and reasons for maintaining a single-domain structure. The module
briefly examines the Kerberos V5 protocol security process and how it affects
trust relationships within a multiple-domain structure. The module also
examines how those trust relationships affect design. Finally, strategies are
provided for designing multiple domains to fit several different business
scenarios, including scenarios that require multiple-domain trees, multiple trees,
and multiple forests.
At the end of this module, students will be able to:
!
Identify criteria for determining whether a single or multiple-domain
structure is necessary to meet business needs.
!
Describe the trust relationships inherent in multiple-domain structures.

!
Plan a multiple-domain tree.
!
Plan a multiple-tree forest.
!
Plan multiple forests.

Materials and Preparation
This section provides you with the required materials and preparation tasks that
are needed to teach this module.
Required Materials
To teach this module, you need the following materials:
!
Microsoft
®
PowerPoint
®
file 1561b_07.ppt
!
Visio 2000

Preparation Tasks
To prepare for this module, you should:
!
Read all of the materials for this module.
!
Complete the lab.
!
Read the following technical white paper located on the Trainer Materials
compact disc:

• Windows 2000 Kerberos Authentication

Presentation:
45 Minutes

Lab:
30 Minutes
iv Module 7: Designing a Multiple-Domain Structure


Instructor Setup for a Lab
This section provides setup instructions that are required to prepare the
instructor computer or classroom configuration for a lab.
Lab A: Designing a Multiple-Domain Structure
Ensure that Visio 2000 Enterprise Edition is installed on the instructor
computer and all student computers and that the Active Directory template is
operational. Also ensure that the \\London\Solutions\Lab7
directory is shared
and accessible from the student computers.
This planning lab presents the students with a scenario and design criteria that
require the planning of multiple domains. In the first exercise, a simple two-
domain forest is necessary to meet the criteria.
The second exercise gives the students a scenario and criteria for a larger
organization where multiple domains are called for. There are two key elements
that the student should include in the design based on the criteria. First, given
the high security demands made in the criteria, the student should select an
empty root domain so that no part of the organization is subordinate to another.
Second, students should create a shortcut trust between
queensland.taztrade.msft and southpacific.taztrade.msft to optimize the sharing
of resources between those domains.

Module Strategy
Use the following strategy to present this module:
!
Identifying Business Needs
Explain the strategies used to assess the need for multiple domains. Explain
that a single-domain structure is preferable to a multiple-domain structure.
!
Accessing Resources Between Domains
Explain how the Kerberos V5 protocol security process is used to
implement authentication between domains and how it affects trust
relationships within a multiple-domain structure. Also, discuss the different
types of trusts between domains and how they are used to access resources
across domains.
!
Planning for Multiple-Domain Trees
Explain in detail the relationships between domains within a single tree.
Focus especially on how information is shared between domains.
Demonstrate the structure of an empty root domain. Discuss in detail the
possible scenarios that might require a multiple-domain structure instead of
a single-domain structure.
Module 7: Designing a Multiple-Domain Structure v


!
Planning for Multiple-Tree Forests
Begin by introducing multiple-tree forests. Explain the structure and
characteristics of a multiple-tree forest. Finally, describe the important
considerations while designing multiple-tree forests.
!
Planning for Multiple Forests

Introduce the concept of multiple forests. Describe the structure and
characteristics of multiple forests and how trusts are established between the
domains of two forests. Explain the scenarios that would encourage the use
of multiple forests.

Customization Information
This section identifies the lab setup requirements for a module and the
configuration changes that occur on student computers during the labs. This
information is provided to assist you in replicating or customizing Microsoft
Official Curriculum (MOC) courseware.
The lab in this module requires students to use Visio 2000 to document their
designs. Visio 2000 is demonstrated in course 1561B, module 3, Designing
Active Directory to Delegate Administrative Authority. If Visio has not been
previously demonstrated to students, refer to module 3 for instructions on
demonstrating Visio 2000.
The lab in this module includes a script to be run at the beginning and end of
the lab that creates and returns the computer to the default configuration for the
course. As a result, there are no lab setup requirements or configuration changes
that affect replication or customization.

Module 7: Designing a Multiple-Domain Structure 1


Overview
!
Identifying Business Needs
!
Accessing Resources Between Domains
!
Planning for Multiple-Domain Trees

!
Planning for Multiple-Tree Forests
!
Planning for Multiple Forests


Domains, trees, and forests are bordered units within Microsoft
®

Windows
®
2000 Active Directory

directory service. These units can share
resources but can also be administered separately. There is also a difference in
how these units intercommunicate, and how replication traffic flows between
them. If your organization requires more than one domain, tree, or forest, then
you must understand how information flows across these borders. The
information flow between units will help you decide whether you need a
structure more complex than a single domain, and if so, how to plan for the
most effective administration model.
At the end of this module, you will be able to:
!
Identify business needs that require a multiple-domain structure, and
business needs that can be met by a single domain.
!
Describe the trust relationships that allow users and resources to gain access
to multiple domains, and the security protocol used to authenticate access.
!
Plan an infrastructure in Active Directory that has multiple domains in a

single tree.
!
Plan an infrastructure in Active Directory that has multiple trees in a single
forest.
!
Plan an infrastructure in Active Directory that has multiple forests.

Slide Objective
To provide an overview of
the module topics and
objectives.
Lead-in
In this module, you will learn
about designing multiple
domains in Active Directory
and identifying business
situations that require
multiple domains.
2 Module 7: Designing a Multiple-Domain Structure


#
##
#

Identifying Business Needs
!
Reasons to Maintain a Single Domain
!
Reasons to Create Multiple Domains



The smallest tree in Active Directory consists of a single domain. While this is
the simplest design for an Active Directory structure, there are business
circumstances in an organization that require the addition of child domains to
the tree. Some business needs that may seem to require multiple domains might
be adequately met by a single domain structure. Before designing a multiple-
domain structure, you should first ensure that the design cannot be met by using
a single domain.
This section will discuss the reasons to maintain a single domain, and help you
identify the reasons that would require you to create multiple domains.
Slide Objective
To introduce the decision
options that exist when
creating multiple domains.
Lead-in
The initial Active Directory
structure is a single domain,
which should be adequate
for most business needs.
Occasionally multiple
domains may be required.
Module 7: Designing a Multiple-Domain Structure 3


Reasons to Maintain a Single Domain
!
Ease of Management
!
Easier Delegation

!
Fewer Members in
Domain Admins Group
!
Object Capacity Same as
Multiple Domain Structure
OU
OU
OU
OU
OU
OU
OU
OU
OU


The default structure in Active Directory begins with a single domain, and, if at
all possible, your structure should keep a single domain. Single domains offer
the following advantages over multiple-domain structures:
!
Ease of management. Single domains require less hardware to purchase and
maintain, less trusts to create, and less administrative groups to create and
maintain.
!
Easier delegation of administrative authority. In a single-domain structure,
you can create organizational units (OUs) as needed to delegate authority
over resources and Active Directory objects. Delegating administrative
authority is more complicated in a multiple-domain structure.
!

Fewer members in the Domain Admins group. With a single domain you
can keep membership of the powerful Domain Admins group to a
minimum, and use delegation to allow detailed control of directory objects
in Active Directory.
!
Object capacity same as multiple domain structure. You can theoretically
have over four billion objects in the global catalog. The global catalog
includes all objects in all domains in a forest, regardless of the number of
domains present. So, if the objects will not fit within a single domain, they
will not fit within a multiple-domain forest either.

Slide Objective
To describe the benefits of a
single-domain infrastructure.
Lead-in
A single domain can
accommodate many
business needs and is much
easier to administer.
4 Module 7: Designing a Multiple-Domain Structure


Reasons to Create Multiple Domains
!
Reasons for Using a Multiple-
Domain Tree:
$
Distinct domain-level
policies
$

Tighter administrative
control
$
Decentralized administration
$
Separation and control of
affiliate relationships
$
Reduced replication traffic
OU
OU
OU
OU
OU
OU
OU
OU
OU
OU
OU
OU
OU
OU
OU
OU
OU
OU
OU
OU
OU

OU
OU
OU
OU
OU
OU
OU
OU
OU
OU
OU
OU
OU
OU
OU


The single domain in Active Directory is the most flexible, least expensive, and
easiest to administer directory structure. However, when planning the design for
the Active Directory structure, you may want to consider additional domains if
your organization requires any of the following:
!
Distinct domain-level policies. Because account and password policies are
applied at the domain level, you can create separate domains with distinct
policies that will apply to the users in each domain.
!
Tighter administrative control. A domain is a security boundary. Domain
administrators cannot cross domain boundaries to manage other domains
without explicit permission.
!

Decentralized administration. In some organizations, divisions that make a
monetary investment in their own computer hardware, such as domain
controllers, want to retain complete administrative control of their hardware.
!
Separation and control of affiliate relationships. Large corporations often
form business affiliations by being involved in joint ventures or
partnerships. Multiple domains allow you to isolate administrative and
security control of shared resources and external users.
!
Reduced replication traffic. Within a domain, all objects and attributes are
replicated between all domain controllers in the domain. If a slow or
congested wide area network (WAN) link within a domain prevents Active
Directory replication from occurring within a necessary timeframe, consider
creating multiple domains to reduce replication traffic. The only data
replicated between separate domains are changes to the global catalog
server, configuration information, and schema.

Slide Objective
To describe business needs
that require multiple
domains.
Lead-in
A single domain is still the
most flexible Active
Directory structure, but there
are business needs that
require more than one
domain.
Module 7: Designing a Multiple-Domain Structure 5



#
##
#

Accessing Resources Between Domains
!
Authentication Across a Forest
!
Types of Trusts


You locate, access, and manage resources and information within a single
domain differently than you do across multiple domains. Security protocols
govern authentication between domains in a forest. Trusts are means to manage
authentication between domains in a forest. Understanding how these processes
differ can help you decide whether a multiple-domain tree model fits the
administrative needs of your organization.
Slide Objective
To introduce the differences
between accessing
resources within a single
domain and accessing
resources across multiple
domains.
Lead-in
When creating multiple
domains, you should
consider the process for
authenticating an individual

across multiple trust
relationships.
6 Module 7: Designing a Multiple-Domain Structure


Authentication Across a Forest
na.contoso.msft
na.contoso.msft
nwtraders.msft
nwtraders.msft
south.nwtraders.msft
south.nwtraders.msft
contoso.msft
contoso.msft
A
u
t
h
e
n
t
i
c
a
t
i
o
n

P

a
t
h
A
u
t
h
e
n
t
i
c
a
t
i
o
n

P
a
t
h
1
1
2
2
3
3
4
4

5
5
Kerberos
Kerberos


The Kerberos version 5 protocol, a security feature of Windows 2000, governs
access between domains within an Active Directory infrastructure. The
Kerberos V5 protocol employs three components: a client, a server, and a
trusted third party to mediate between them. The trusted intermediary in the
protocol is known as the Key Distribution Center, or KDC. In Windows 2000,
the domain controller functions as the KDC.
When accessing resources across a forest, the Kerberos V5 protocol trust path
must be followed. In the example, one tree of the forest consists of contoso.msft
and its child domain, na.contoso.msft. The other tree in the forest consists of
nwtraders.msft and its child domain, south.nwtraders.msft. If a user in
na.contoso.msft needs to gain access to resources in south.nwtraders.msft, the
following process occurs (without user interaction):
!
The user will first receive an authorization called a session ticket from the
KDC in the na.contoso.msft domain. The user presents the session ticket to
the KDC in contoso.msft.
!
The KDC in contoso.msft supplies the user with a session ticket for
nwtraders.msft.
!
The user presents the nwtraders.msft session ticket to the KDC in
nwtraders.msft.
!
The KDC in nwtraders.msft supplies a session ticket for the KDC in

south.nwtraders.msft, which will in turn supply a session ticket for the
desired server.

Slide Objective
To illustrate how
authentication occurs
between domains.
Lead-in
To access resources in
another domain, a user
must follow the trust path.
Module 7: Designing a Multiple-Domain Structure 7


Types of Trusts
Transitive
External
Shortcut


Windows 2000 uses trusts to allow users to access resources in different
domains. There are three types of trusts used in Windows 2000: transitive,
shortcut, and explicit trusts. Each type of trust follows a trust path between the
domain controllers for the source and target domains. A trust path is the series
of domain trust relationships that must be traversed by security in
Windows 2000 to pass authentication or query requests between any two
domains.
Transitive Trusts
A transitive trust is a two-way secure relationship that exists between each child
domain and its parents or to the root domain of the forest. Transitive trusts are

created automatically between parent and child domains, and between trees in a
forest. Because all child domains within a tree are derived from a common
parent domain, each domain in a tree will trust all other domains in the tree.
When you create a new tree as a result of promoting a server to a domain
controller, you must specify the root domain of the initial tree in the forest.
Thus, a trust relationship is established between the root domains of the new
tree and the initial tree. If you create a child domain, a trust relationship is
established between the child and the parent. Because this trust is transitive and
bi-directional, resources can be shared between all three trees with no further
trust configuration.
Transitive trusts make information accessible to all domains in the forest. Once
a user is authenticated, discretionary access control list (DACL) entries control
resource access privileges to users or groups.
Shortcut Trusts
You can shorten the trust path within a forest by creating a shortcut trust
specifically, or explicitly, between two domains within a forest. A shortcut trust
is a transitive trust intentionally created between two distant domains within the
same forest. By creating a shortcut trust, you optimize the authentication
process by creating a shorter trust path.
Slide Objective
To illustrate the three types
of trusts used in inter-
domain access.
Lead-in
Trusts are used to grant
access between domains in
a multiple-domain structure.
A shortcut trust is transitive
because the domains that it
connects within a forest are

already linked by a transitive
trust relationship.
8 Module 7: Designing a Multiple-Domain Structure


External Trusts
Domains in different forests do not automatically have a trust relationship. To
allow access between different forests, you must create an external trust
explicitly between two domains. Unlike transitive and shortcut trusts, external
trusts are one-way trusts that give a desired domain access only to the domain
originating the external trust. For a two-way trust to exist between two domains,
both domains must create external trusts to each other. Also, external trusts only
extend to the domains specified; any other transitive trusts associated with the
domains remain separate from the external trust.
While external trusts must be explicitly created and managed, they allow you to
customize access privileges for individuals in other forests, monitor activity
both within and between domains, and limit the scope of authenticated access to
the domain that is explicitly trusted. While the characteristics of an external
trust are important for inter-forest communication, you must plan external trusts
carefully to ensure proper resource management, trust placement, and
maintenance.
Module 7: Designing a Multiple-Domain Structure 9


#
##
#

Planning for Multiple-Domain Trees
!

Characteristics of Multiple-Domain Trees
!
Creating an Empty Root Domain
!
Design Guidelines


By default, a single-domain tree is created when the first server in a network is
promoted to a domain controller. However, you can construct a larger tree by
adding more domains to an existing tree. Before creating a multiple-domain
tree, you should understand the structure and characteristics of a multiple-
domain tree, and the organization's business situations that may require multiple
domains.
Slide Objective
To introduce multiple-
domain structures in Active
Directory.
Lead-in
Multiple-domain trees are
comprised of parent and
child domains.
10 Module 7: Designing a Multiple-Domain Structure


Characteristics of Multiple-Domain Trees
Child
Domain
nwtraders.msft
nwtraders.msft
us.nwtraders.msft

us.nwtraders.msft
sales.us.nwtraders.msft
sales.us.nwtraders.msft
Child
Domain
Child
Domain
europe.nwtraders.msft
europe.nwtraders.msft
Root
Root
Root
Transitive Trusts Exist
Between All Domains


When additional domains, or child domains, are attached to the initial domain
they form a hierarchical structure. Any child domain can be the parent of
additional child domains.
Domains Within a Tree Share a Single Tree Root
A tree has a single root and is built as a strict hierarchy. Each domain below the
root has exactly one immediate parent domain. Each level of the hierarchy is
directly related to the level above it and to the level below it.
An Active Directory tree hierarchy is a Domain Name System (DNS) hierarchy.
Child domains derive their names from the parent domain. For example, you
have an international company with a root domain named contoso.msft. To
have decentralized administration between the Europe and the United States
divisions, you can create a new domain for each and join them to the existing
tree. These new domains become europe.contoso.msft and us.contoso.msft.
Domains Within a Tree Share Information Through

Automatic Trusts
All domains within an Active Directory tree share a common directory schema,
configuration information, and global catalog. They also have automatic
transitive trust relationships that allow users in each domain to gain access to
available resources in all other domains in the tree.
Slide Objective
To illustrate the structure
and characteristics of a
multiple-domain tree.
Lead-in
The domains in a multiple-
domain tree are made up of
parent and child domains.
Module 7: Designing a Multiple-Domain Structure 11


Creating an Empty Root Domain
Child
Domain
nwtraders.msft
nwtraders.msft
usa.nwtraders.msft
usa.nwtraders.msft
Child
Domain
europe.nwtraders.msft
europe.nwtraders.msft
Root
Root
Root

Enterprise Admin is Sole
User in Root Domain
Enterprise Admin is Sole
User in Root Domain


An organization with decentralized administration may choose a single tree
with an empty root domain. An empty root domain contains no OUs and only
the enterprise administrator (or a small number of administrators) as the only
users in the domain. The advantage of this model is a contiguous namespace
with a distinct separation between divisions. In the scenario pictured in the
slide, the root domain holds the default administrator account as the enterprise
administrator. The two (or more) Information Technology (IT) groups in the
child domains could limit the number of users with access to this powerful
account. For example, the IT groups could establish a policy that requires the
enterprise administrator to log on with an authentication device such as a smart
card. The smart card could be secured in such a way that it requires a user from
each IT group to access it.
Slide Objective
To demonstrate the
structure of an empty root
domain.
Lead-in
A possible implementation
of a multiple-domain tree is
to create an empty root
domain.
12 Module 7: Designing a Multiple-Domain Structure



Design Guidelines
Design Needs that May Require a Multiple-Domain Tree:
!
Distinct Security Boundaries
!
Bandwidth Constraints on WAN Links
!
Legal Reasons for Separate Domains
!
Distinct Domain-Level Group Policy Settings

The following are design criteria that may require a multiple-domain tree.
!
You need a distinct security boundary. If your organization uses
decentralized administration, or if some groups must be separated for
security reasons, creating multiple domains allows each domain to
administer itself. Another reason to create separate domains is to reduce the
influence that the Enterprise Admins group has over all objects within a
domain.
!
You determine that replication traffic could overwhelm wide area network
(WAN) links. Within a domain, every attribute of every object is replicated
between domain controllers. If a WAN link within the domain is very slow
or congested, this could overwhelm the link, even if different sites are
created. In a multiple-domain structure, only the schema, configuration, and
global catalog are replicated, thereby reducing network traffic.
!
You have legal reasons for separating the domains; for example, some
organizations with a foreign presence may be required to maintain separate
domains for foreign user accounts.

!
You have distinct domain-level Group Policy settings, for example,
password restrictions for different groups, which can be set only at the
domain level.

Slide Objective
To identify conditions for
designing a multiple-domain
tree.
Lead-in
Here are some reasons for
creating a multiple-domain
tree.
Module 7: Designing a Multiple-Domain Structure 13


#
##
#

Planning for Multiple-Tree Forests
!
Characteristics of Multiple-Tree Forests
!
Design Guidelines


A forest is a collection of one or more Active Directory trees connected by two-
way, transitive trust relationships between the root domains of each tree. Before
creating a multiple-tree forest, you should understand the structure and

characteristics of a multiple-tree forest, and the organization's business
situations that may require multiple-tree forests.
Slide Objective
To introduce multiple-tree
forests in Active Directory.
Lead-in
Trees in a multiple-tree
forest are linked by
transitive trusts, but
maintain separate names.
14 Module 7: Designing a Multiple-Domain Structure


Characteristics of Multiple-Tree Forests
Tree 2
Root
Root
Root
Child
Child
Child
Child
nwtraders.msft
nwtraders.msft
domainB.domainA.nwtraders.msft
domainB.domainA.nwtraders.msft
Transitive Trust Relationship
Created Between Roots
Tree 1
Root

Root
Root
Child
Child
contoso.msft
contoso.msft
Child
Child
domain3.contoso.msft
domain3.contoso.msft
domain2.contoso.msft
domain2.contoso.msft
domainA.nwtraders.msft
domainA.nwtraders.msft


Trees in a forest share a common directory schema, configuration information,
and global catalog. Both the sharing of common data and the trust relationships
between the roots of trees distinguishes a forest from a set of unrelated trees.
Trees are identified by the DNS name of the first domain created in the tree.
This name is unique in the forest and is what separates trees within a forest.
Each tree forms a separate naming hierarchy that is based on different DNS root
domain names. The forest itself is identified by the DNS name of the initial tree
that was created in the forest, which is the root domain.
Although the roots of the separate trees have non-contiguous names, the trees
are a part of a single overall hierarchy, and Active Directory can still resolve
names of objects within the forest.
Before designing a new tree, you must first determine its structure by
determining the following:
!

The DNS domain name of the new tree. Remember that each tree has a
unique DNS domain name. Once you choose the name, you can then create
the new domain.
!
The structure of domains in the tree. This includes determining if additional
domains in the tree are necessary and identifying which domains are child
domains.

Slide Objective
To illustrate the structure
and characteristics of a
multiple-tree forest.
Lead-in
Trees in a forest are linked
by transitive trusts, and
share a common schema,
configuration, and global
catalog.
Module 7: Designing a Multiple-Domain Structure 15


Design Guidelines
Consider Using a Multiple-Tree Forest When You Need:
!
Distinct DNS names for Public Identities
!
Centralized Control Among All Active Directory Trees
and Domains

Large organizations may require multiple trees in a single forest to address the

following circumstances:
!
The organization has different public identities and needs to maintain
distinct names within Active Directory, yet have full access between the
trees. For example, the organization may have a subsidiary with its own
registered domain name, and want to maintain the separate name.
!
The organization requires centralized control of administration, and a global
organizational directory for full access of resources and information. The
trees in a forest still share a common directory schema, configuration
information, and global catalog.

Slide Objective
To describe conditions for
designing a multiple-tree
forest.
Lead-in
Here are some reasons for
creating a multiple-tree
forest.
16 Module 7: Designing a Multiple-Domain Structure


#
##
#

Planning for Multiple Forests
!
Characteristics of Multiple Forests

!
Design Guidelines


Multiple forests are comprised of separate and distinct forests that do not share
any information in Active Directory unless special trust relationships are
explicitly created. An organization's need for a multiple forest will most likely
arise through corporate acquisitions, or through conducting business with
limited business partners such as joint ventures or subsidiaries. Before creating
multiple forests, you should understand the structure and characteristics of a
multiple forest, and any business situations that may require multiple forests.
Slide Objective
To introduce the use of
multiple forests in Active
Directory.
Lead-in
Multiple forests do not share
a common schema,
configuration or global
catalog.
Module 7: Designing a Multiple-Domain Structure 17


Characteristics of Multiple Forests
Tree 1
Tree 2
Root
Root
Root
Child

Child
Root
Root
Root
Child
Child
Child
Child
contoso.msft
contoso.msft
Child
Child
domain3.contoso.msft
domain3.contoso.msft
nwtraders.msft
nwtraders.msft
domainB.domainA.nwtraders.msft
domainB.domainA.nwtraders.msft
domain2.contoso.msft
domain2.contoso.msft
One-Way External
Trusts Established
Among Specified
Domains Only
domainA.nwtraders.msft
domainA.nwtraders.msft


Multiple forest environments can be very difficult and complex to manage. This
type of environment is not recommended for a single organization with no

branches or subsidiaries, because any interaction between forests must be
explicitly created.
Forests do not share a common schema and configuration, nor do the global
catalog servers share information between each other. A directory
synchronization product will be needed to have a global organizational
directory listing between forests.
To allow users to gain access to information in multiple forests, you must
explicitly create one-way external trusts between domains of different
directories in Active Directory. To permit a two-way trust between domains,
both of the domains must create one-way external trusts with each other.
Slide Objective
To describe the structure
and characteristics of
multiple forests.
Lead-in
Multiple forests are possible
but are very difficult to
design and administer.
18 Module 7: Designing a Multiple-Domain Structure


Design Guidelines
Design Multiple Forests When:
!
You Do Not Want a Common Schema
!
You Do Not Want a Global Directory
!
You Need Limited Partner or Affiliate Relationships



The following are design criteria that may require multiple forests.
!
You do not want to have a common schema. Different components of your
organization may require schema modifications that are not desired by the
rest of the organization. Schema changes are not replicated across forests.
!
You do not want a global directory. Unless you establish directory
synchronization between the forests, there will be no default global
directory for an organization comprised of multiple forests.
!
You have partner or affiliate relationships. You may wish to have limited
access to resources between an organization’s partners or affiliated
companies, but want to keep the administration separate. Creating multiple
forests ensures separation of resources, and permits sharing only when
specifically authorized.

Slide Objective
To describe conditions for
designing multiple forests.
Lead-in
Here are some reasons for
creating multiple forests.
Module 7: Designing a Multiple-Domain Structure 19


Lab A: Designing a Multiple-Domain Structure


Objectives

After completing this lab, you will be able to:
• Design a domain strategy for Active Directory.

Prerequisites
Before working on this lab, you must have:
• Knowledge of the reasons for creating more than one Active Directory
domain, tree or forest in an organization.

Lab Setup
To complete this lab, you need the following:
• Visio 2000 installed on your computer.

Estimated time to complete this lab: 45 minutes
Slide Objective
To introduce the lab.
Lead-in
In this planning lab, you will
design a multiple-domain
structure for Active
Directory.
Explain the lab objectives.

×