Designing your Forest

Structure

ids.com

ce.ids.com

it.com

it.ids.com

ce.it.com

it.it.com

When you design active directory for

your organization you will have to
decide , whether you want single forest
or multiple forest.

Active Directory Design Basic

or
Active
Directory
Components
Forest
Domain Tree
Domain
Organizational Unit (OU)
Sites

Designing Forest

Deploying Single Forest

Deploying Multiple Fore

Deploying Single Forest

Most common configuration for

deploying forest in an organization
Main reason to deploy a single forest
is that it will share common
information across each of its
component domains
The information is shared include,
Schema , Configuration and Global
catalog

Schema : Basic Structure Of object

Configuration : maintain listing of
all domains and sites within a
forest, thus ensuring no duplicate
name are created in domain
Global Catalog: central repository
of information about abject in tree
or forest

Cont

The domain within forest are joined

together by kerberos v5 transitive
trust
Trust Relationship :

Making Decision

Same software is used across the

organization
Minimizing a single forest reduces
the number of administrative task
globally
In forest transitive trust relationship
is going to maintain , so no need to
maintain relationship manually

Deploying Multiple Forest

There are limited scenarios in which

you need to implement multiple forest
These scenario involves decentralized
organizations that perform much of
network operations within each
individual sector
Another scenario is ISP , they doesn't
want common directory for all their
client
In this case create separate forests for
each client to prevent clients from
browsing the directory of another client

While deploying multiple

forest problems you can face
are

More complicated and

expensive domain
structure

Every forest must have at least

one domain
Within each domain 2 dc requires
to maintain redundancy
Creating additional forest can lead
to additional hardware cost

Additional management cost

for forest-wide components
like
schema

Evan if two forest have identical

schema, the work effort is double
The schema modification must be
perform separately

Additional management
cost for trust relationship

If you deploy multiple forests , you

have to establish explicit one/two
way transitive trust relationship

Limited use of universal

principal names

If multiple forest exists only default user

principle name can be use if user is going
to authenticate by using user principal
name
User principal name = FQDN (fully Qualified
Domain Name), eg lata@nitdomain2.edu
Global catalog is not shared between
multiple forest
So lata@nit2.edu will not work