Forest Plan (Book 2 of 5)

8/14/2019 Forest Plan (Book 2 of 5)

1/122

2004 Mustan Bharmal. All Rights Reserved.

Table of Contents

1. INTRODUCTIONTOTHE FOREST PLAN................................................................................................. ..........31.1. BACKGROUND INFORMATION........................................................................................... .........................31.2. FOREST PLAN PROCESSES....................................................................................................... ..............31.3. DELIVERABLESOF FOREST PLAN PROCESSES.......................................................................... ...................3

1.4. INTER-PROCESS DEPENDENCIES...................................................................................... ........................41.5. PROCESSTO CREATETHE FOREST PLAN...................................................................................... .............52. DETERMINATIONOFTHE NUMBEROF DOMAINS REQUIRED.............................................................................. ...62.1. PROCESS OBJECTIVE................................................................................................... .........................62.2. BACKGROUND INFORMATION........................................................................................... .........................62.3. PROCESS APPROACH........................................................................................................................... ..62.4. PROCESS COMPONENTS.................................................................................................................... .....72.5. DELIVERABLESOF PROCESS COMPONENTS....................................................................................... ..........72.6. INTER-COMPONENT DEPENDENCIES........................................................................................................... 82.7. PROCESSTO DETERMINETHE NUMBEROF DOMAINS REQUIRED................................................... ...................92.8. PROCESS CONSIDERATIONS.................................................................................................................. .103. DESIGNOFTHE STRUCTUREAND RELATIONSHIPSOF MULTIPLE DOMAINS..................................................... ......223.1. BACKGROUND INFORMATION........................................................................................ ..........................22

3.2. PROCESS APPROACH........................................................................................................................ ...223.3. PROCESS COMPONENTS.................................................................................................................. .....223.4. DELIVERABLESOF PROCESS COMPONENTS..................................................................................... ..........223.5. INTER-COMPONENT DEPENDENCIES........................................................................................................ .233.6. PROCESSTO DESIGNTHE STRUCTUREAND RELATIONSHIPSOFTHE DOMAINS......................................... ..........233.7. PROCESS CONSIDERATIONS.................................................................................................................. .234. DESIGNOF SHORT-CUT TRUST RELATIONSHIPS........................................................................ ...................284.1. BACKGROUND INFORMATION........................................................................................ ..........................284.2. PROCESS COMPONENTS.................................................................................................................. .....284.3. DELIVERABLESOF PROCESS COMPONENTS..................................................................................... ..........284.4. INTER-COMPONENT DEPENDENCIES........................................................................................................ .284.5. PROCESSTO DESIGN SHORT-CUT TRUST-RELATIONSHIPS.......................................................... .................294.6. PROCESS CONSIDERATION................................................................................................... .................29

5. DETERMINATIONOFTHE BOUNDARIESAND CONTENTOF EACH DOMAIN.......................................... ...................345.1. PROCESS OBJECTIVES................................................................................................................ .........345.2. PROCESS OBJECTIVES................................................................................................................ .........345.3. BACKGROUND INFORMATION........................................................................................ ..........................345.4. PROCESS APPROACH........................................................................................................................ ...345.5. PROCESS COMPONENTS.................................................................................................................. .....355.6. DELIVERABLESOF PROCESS COMPONENTS..................................................................................... ..........355.7. INTER-COMPONENT DEPENDENCIES........................................................................................................ .355.8. PROCESSTO DETERMINETHE BOUNDARIESAND CONTENTOF EACH DOMAIN................................ ...................365.9. PROCESS CONSIDERATIONS.................................................................................................................. .366. DETERMINATIONOFTHE SIZEOFTHE ACTIVE DIRECTORY DATABASEFORTHE FOREST.......................................... 446.1. PROCESS OBJECTIVES................................................................................................................ .........446.2. BACKGROUND INFORMATION........................................................................................ ..........................446.3. PROCESS APPROACH........................................................................................................................ ...466.4. PROCESS COMPONENTS.................................................................................................................. .....476.5. DELIVERABLESOF PROCESS COMPONENTS..................................................................................... ..........476.6. INTER-COMPONENT DEPENDENCIES........................................................................................................ .476.7. PROCESSTO DETERMINETHE SIZEOFTHE ACTIVE DIRECTORY DATABASEFORTHE FOREST................................ 486.8. PROCESS CONSIDERATIONS.................................................................................................................. .487. DESIGNOFTHE FOREST ROOT DOMAIN........................................................................... ..........................517.1. BACKGROUND INFORMATION........................................................................................ ..........................517.2. PROCESS APPROACH....................................................................................................................... ...517.3. PROCESS COMPONENTS.................................................................................................................. .....517.4. DELIVERABLESOF PROCESS COMPONENTS..................................................................................... ..........527.5. INTER-COMPONENT DEPENDENCIES........................................................................................................ .527.6. PROCESSTO DESIGNTHE FOREST ROOT DOMAIN............................................................... ......................537.7. PROCESS CONSIDERATIONS.................................................................................................................. .538. DESIGNOF APPLICATION DIRECTORY PARTITIONSWITHINA FOREST..................................................... .............73

Page 1 of 122 Last printed 28/5/2004 12:03 a5/p5


2/122


8.1. PROCESS OBJECTIVES................................................................................................................ .........738.2. PROCESS SCOPE...................................................................................................... .........................738.3. BACKGROUND INFORMATION........................................................................................ ..........................738.4. PROCESS APPROACH........................................................................................................................ ...738.5. PROCESS COMPONENTS.................................................................................................................. .....748.6. DELIVERABLESOF PROCESS COMPONENTS..................................................................................... ..........74

8.7. INTER-COMPONENT DEPENDENCIES........................................................................................................ .748.8. PROCESSTO DESIGN APPLICATION DIRECTORY PARTITIONSWITHINA FOREST..................................................758.9. PROCESS CONSIDERATIONS.................................................................................................................. .759. DESIGNFOR DIRECTORY QUOTAS..................................................................................... ........................939.1. BACKGROUND INFORMATION........................................................................................ ..........................939.2. PROCESS APPROACH........................................................................................................................ ...949.3. PROCESS COMPONENTS.................................................................................................................. .....949.4. DELIVERABLESOF PROCESS COMPONENTS..................................................................................... ..........949.5. INTER-COMPONENT DEPENDENCIES........................................................................................................ .949.6. PROCESSTO DESIGN DIRECTORY QUOTAS................................................................................... ............959.7. PROCESS CONSIDERATIONS.................................................................................................................. .9510. SELECTIONAND RAISINGOFTHE FOREST FUNCTIONAL LEVEL....................................................... ..............10710.1. PROCESS OBJECTIVES........................................................................................................... ..........107

10.2. PROCESS SCOPE.................................................................................................. .........................10710.3. BACKGROUND INFORMATION.................................................................................... ..........................10710.4. PROCESS APPROACH............................................................................................................ ...........11210.5. PROCESS COMPONENTS...................................................................................................... .............11210.6. DELIVERABLESOF PROCESS COMPONENTS......................................................................... ..................11210.7. INTER-COMPONENT DEPENDENCIES............................................................................................. ........11310.8. PROCESSTO SELECT & RAISETHE FOREST FUNCTIONAL LEVELFORTHIS FOREST........................................ 11310.9. PROCESS CONSIDERATIONS...................................................................................................... .........113



3/122


1. Introduction to the Forest Plan

It is necessary for every organisation, planning the execution of design activities to generate aWindows Server 2003 Active Directory infrastructure, to execute at least one Forest Plan. Thisis regardless of any preconceptions on the number of forests and domains required.

It is necessary to create one Forest Plan for each required production forest within aWindows Server 2003 Active Directory infrastructure for an organisation. A production forestis a forest that directly supports one or more business processes within the organisation, andhence the organisation will depend upon the existence of that forest. Note that this designmethodology does not recommend the creation of a Forest Plan for non-production forests,such as parallel test forests within the organisation, which only indirectlysupport businessprocesses within the organisation, such as change control infrastructures, and so on.

Note that it is only possible to execute the processes within each forest plan followingcompletion of the Organisation-wide Active Directory Plan design process to determine theboundaries and content of each required forest.

1.1. Background InformationThis design methodology defines a forest as a virtual entity, with a distinct logical boundarythat represents one or more Active Directory domains, each of which share a commonSchema, Configuration, Global Catalog, and an Active Directory replication topology.

A Forest Plan caters for the design of those components of an Active Directory infrastructuredefined, created, deployed, or managed only at the forest level, except the replicationtopology, which the Site Plan covers.

Note that references to this forest or this Active Directory forest within this Forest Planimplicitly refer only to the Active Directory forest that this Forest Plan supports.

1.2. Forest Plan ProcessesThe forest plan is composed of the following processes:

Determination of the number of domains required within the forest. Where it is possible to

identify the requirement for the design and deployment of multiple domains, then there willbe the requirement to:

Design the structure and relationships of the multiple domains within the forest

Determine the boundaries and content of each required domain within the forest. Note,

if only one domain is required, then the boundary and content of this domain will bedetermined by the Organisation-wide Active Directory Plan design process todetermine the boundaries and contents of each forest.

Design of short-cut trust-relationships between domains within the forest

Determination of the size of the Active Directory database for the forest

Design of the forest root domain for the forest

Design of application directory partitions for the forest

Design of directory quotas for the forest

Selection and raising of the functional level of the forest

1.3.Deliverables of Forest Plan ProcessesThe forest plan processes will have the following deliverables:



4/122


The determination of the number of domains required within the forest.

The design for the structure and relationships of multiple domains within the forest

The determination of the boundaries and content of each domain to be created within the

forest

The design for short-cut trust-relationships between domains within the forest

The determination of the size of the Active Directory database for the forest

The design of the components of the forest root domain for the forest

The design of application directory partitions for the forest

The design of directory quotas for the forest

The process to select and raise the functional level of the forest

1.4. Inter-Process DependenciesEach process within the forest plan will have the following inter-process dependencies:

Forest Plan Inter-Process Dependencies for Forest Plan

STARTDetermination of the

number of domains

required

Design of Application

Directory Partitions

within a forest

Design for Directory

Quotas

Selection and raising of

the forest functional

level

Design of short-cut trust

relationships

Determination of the

size of the Active

Directory database for

the forest

Design of the structure

& relationships of

multiple domains


boundaries and content

of each domain

Design of the forest root

domain

2 0 0 4 M U S T A N S HI R B H A R M A L



5/122


1.5. Process to Create the Forest PlanForest Plan Process to Create the Forest Plan

YES

NO

Is there a

requirement for a

multiple domainforest?

Execute process

design of the structure& relationships of

multiple domains

Execute processdesign of short-cut trust

relationships

START

Execute process

determination of the

number of domainsrequired

Execute processdetermination of the

boundaries and content

of each domain

Execute process

determination of thesize of the Active

Directory database for

the forest

Execute processdesign of the forest root

domain

Execute processdesign of Application

Directory Partitions

ENDExecute process

design of Directory

Quotas

Execute process

Selection and raising ofthe forest functional

level 2 0 0 4 M U S T A N S H I R B H A R M A L



6/122


2. Determination of the Number of Domains Required

This design methodology requires all organisations to execute this process, regardless of anypreconceptions as to the number of domain required within this forest.

2.1. Process ObjectiveThe objective of this process is to assist an organisation in the determination of the totalnumber of domains that this Windows Server 2003 Active Directory forest is required tosupport.

Note that the objective of this process is only to assist an organisation in the determination ofthe actual number of domains required within the forest only:

At the time of the design of the forest and

To meet the requirements of the organisation, based upon the factors and their

considerations listed within this process

2.2. Background InformationA forest can contain multiple domains, and a minimum of one domain controller is required tocreate a domain within a forest. However, every domain created within a forest will have anassociated management, financial and operational overheads.

2.2.1. Forest Root Domain

Where there is the requirement for a single domain forest, then by default, this domain will bethe forest root domain for a forest, and will play a crucial role in the operation of the forest.

Because of the critical dependency upon the forest root domain for the continuity of the ActiveDirectory forest infrastructure, the selection of the forest root domain is an essential design

component for the forest.

The domain selected to be the forest root domain for a forest can be either a dedicated(placeholder) domain, or a dual-function domain. The selection of a dedicated placeholderdomain for the forest root implies, in the strictest sense, that there will be more than onedomain within the forest. Where the forest root domain will hold many user and computeraccounts, and hence function as a normal Active Directory domain, then this implies a dual-function domain. The use of a dual-function domain for the forest root domain does not implya single domain forest as the dual-function forest root domain could be one of many within theforest.

The considerations for the selection of a dedicated domain or the use of dual-function domainas the forest root domain hence play an important role in the determination of the number ofdomains required for the forest.

2.3. Process ApproachWhen executing the process to determine the requirement for a multiple domain ActiveDirectory forest, the recommended approach to the design of a domain infrastructure for anActive Directory forest is to keep it simple. This hence implies only a single domaininfrastructure, or only a few domains within each forest.

To support this recommendation, this design methodology states the following null hypothesisfor this process:

A single domain for the forest can adequately meet all the Active Directory-relatedrequirements for the forest without the requirement to create a multiple domain infrastructure

within the forest.



7/122


It is then necessary to conduct an investigation to disprove this null hypothesis and hencedetermine the number of domains required for the forest. Where it is not possible to disprovethis hypothesis, then it will stand true and only a single domain will be required for the forest.

This design methodology hence recommends execution of the following approach for thisprocess:

1. Understand the potential management, financial and operational overheads associatedwith the design and deployment of a multiple domain Active Directory infrastructure

2. Determine whether the option to design and deploy a multiple domain infrastructure forthe forest is viable or not

3. If the option of a multiple domain forest is not viable, then the logical extensions to thisconclusion will hence be:

a. The single domain for the forest will be the forest root domain for the forest and hencea dual-function domain

b. The boundary and content of this domain will be that of the forest, determined within

the Organisation-wide Active Directory Plan process to determine the boundariesand content of the forests.

4. If the option of a multiple domain forest is viable, then determine the requirement to useeither a dedicated (placeholder) domain or a dual-function domain for the forest rootdomain of the forest.

5. Where it is possible to identify the requirement for a dual-function domain, as the forestroot domain, then the process to design the forest root domain executed later in theforest plan will identify this domain.

6. Determine the actual number of domains required (at the time of design of the ActiveDirectory infrastructure) for the forest based upon the considerations presented within this

process.

2.4. Process ComponentsBased upon the above approach, this process is composed of the following threecomponents:

Determination of the viability of a multiple domain infrastructure within the forest for the

organisation

Determination of the requirement to use a dedicated (placeholder) forest root domain or a

non-dedicated (and hence dual-function) domain to act as the forest root domain

The determination of the number of domains required within the forest

2.5. Deliverables of Process ComponentsThis process will have the following deliverables:

The determination of the viability of a multiple domain infrastructure for the forest

The determination of the requirement to create dedicated (placeholder) or a dual-function

forest root domain

The determination of the number of domains required within the forest and the

justifications for the generation of each required domain



8/122


2.6. Inter-Component DependenciesEach component of this process will have the following inter-component dependencies:

Forest Plan Inter-Component Dependencies for

Process to Determine the Number of Domains

Required

START


number of domainsrequired for this forest

Determination of therequirements for a

dedicated or dual-function forest root

domain


viability of a multipledomain forest

2 0 0 4 M U S T A N SH I R B H A R M A L



9/122


2.7. Process to Determine the Number of Domains RequiredForest Plan Process to Determine the Number of Domains Required PART 1

NO

Is there

compliance

with any of the

overheads

discussed?START

END

Execute

B1-B3

Execute

A1-A4

YES

YES

NO

This forest will required

a single domain

Execute process

determination of

the size of the

Active Directory

database for the

forest

Is there

a requirement

to restrict

membership to theDomain Admins

group?

Consider the creation of

a dedicated forest root

domain for this forest

YES

Evaluate and discuss

the potential

implications of themanifestation of these

overheads

Are the

potential

implications

acceptable?

Answer each of these

questions to determine

the requirements for a

dual-function or

dedicated forest root

domain NO

Consider the creation of

a dual-function forest

root domain for this

forest

NO

Is there

a requirement

to retain control over

forest-wide

changes?

YES

NO

Is there arequirement to

create a minimal

replication footprint

or a forest root

domain?

YES

NO


ensure the

continuity of

a forest?

NO

YES

Have all

questions beenanswered?

Is a

dedicated

forest rootdomain

required?

YES

Document the

justifications for the

design and

implementation of a

dedicated forest root

domain

YES

NO

2 0 0 4 M U S T A N S HI R B H A R M A L

Go To

Part 2



10/122


Forest Plan Process to Determine the Number of Domains Required PART 2

END

Execute

B4-B6

Execute

A5 & A6

Is there arequirement for

serviceautonomy?

NOExecute

A7

YES Determine the minimum

number of domainsrequired to support

requirements for serviceautonomy

Is therea requirement

to control AD

replicationtraffic?

YES

Determine the minimumnumber of domainsrequired to support

requirements to

partition replicationtraffic

Execute

A8 & A9

NO


to use anSMTP-onlyWAN link?

Determine the minimum

number of domainsrequired to support use

of SMTP over IP Inter-Site Link

YES

Execute

A10NO


create more than 2

million directoryobjects within the

forest?

Execute

A11NO

Determine the minimumnumber of domains

required to effectively

partition the largenumber of required

directory objects

YES


preserve thestructure of a legacy

multiple domaininfrastructure?

Determine the minimum

number of domainsrequired to preserve the

structure of a legacydomain infrastructure

YES

Determine the total number

of domains required for thisdomain, and document the

justifications to support eachrequired domain

NO

Execute process

design of thestructure and

relationships ofmultiple domains

2 0 0 4 M U S T A N S H I R B H A R M A L

From

Part 1

2.8. Process ConsiderationsConsider the following information when executing this process to determine the number ofdomains required for the forest.

Presented within the following three sections are the considerations for this process:

1. Considerations for the determination of the viability of a multiple domain infrastructure(within the forest for the organisation)

2. Considerations for the determination of the requirements for a dedicated or dual functionforest root domain

3. Considerations for the determination of the number of domains required for the forest

2.8.1. Determination of the Viability of a Multiple Domain Infrastructure

Consider the following information when determining the viability of the decision for anorganisation to proceed with the design and deployment of a multiple domain infrastructure forthe forest.

Factor B1: Understanding the management overheads of multiple domains

Criteria for Execution: Explore the considerations for the execution of this factor

where an organisation wishes to understand the management overheads associatedwith the management of a multiple domain infrastructure within this forest.

Factor Considerations: Consider the following information where it is possible to

identify compliance with the above criteria within an organisation:



11/122


Every domain the forest owner(s) design and implement is associated with a significantmanagement overhead. For example, there will be a management overhead associatedwith the following:

The management of all domain-level components of the Active Directory for eachrequired domain within each forest, such as the security infrastructure, object

management and so on.

The requirements to manage multiple inter-domain trust relationships for cross-domain resource access. It is possible to create these trust-relationships betweendomains within the forest (short-cut trusts), between forests (cross-forest trusts),and between external domains (non-transitive).

Where an organisation has a limited number of trained resources that will beresponsible for the management of the Active Directory infrastructure of this (or all)forest(s), then they may become over utilised, which may lead to a reduction in theperformance and efficiency of the Active Directory infrastructure.

Similarly, where an organisation will have a widely distributed and decentralised

administration model for its Active Directory infrastructure, a lack of cooperation andcoordination of Active Directory management tasks may potentially lead to thediscontinuity of business operations.

An organisation with a (geographically) widely distributed multiple domaininfrastructure may notice divergence of the Global Catalog for the forest within eachphysical location of the organisation. Inter-Site replication latencies associated withthe replication overheads of multiple domains within the forest may contribute toGlobal Catalog divergence.

Factor B2: Understanding the financial overheads of multiple domains


where an organisation wishes to understand the financial overheads associated withthe management of a multiple domain infrastructure within this forest.



Each required domain within a forest is associated with financial overheads that requireconsideration. Although it is possible to identify a few financial overheads associatedwith a multiple domain forest, shared across each required domain, it is possible toidentify financial overheads unique to each required domain. For example, eachrequired domain is associated with the following unique financial overheads:

Each domain within a forest, that will support a production environment, and hence

business processes, will require a recommended minimum of two domaincontrollers for redundancy.

Based upon the boundary and content of a domain may increase the financialoverheads associated with the domain. For example, where a domain requiresrepresentation across multiple geographical locations, with low available bandwidthinter-location network links, then each remote location may require a local domaincontroller, and hence:

An additional server hardware cost and maintenance overhead

A requirement to ensure the physical security of these remote domain controllers,which may be costly to implement

A requirement to employ local administrators to manage the local domaincontrollers, and so on



12/122


These factors hence increase the total cost of ownership for each domain.

Factor B3: Understanding the operational overheads of multiple domains


where an organisation wishes to understand the operational overheads associated with

the management of a multiple domain infrastructure within this forest.



Each additional domain within an Active Directory forest contributes to operationaloverheads associated with the forest. For example:

All domain controllers for a domain contain a full replica of every object and attributeheld within the Domain partition of their domain. Hence, any changes to any objectheld within the Domain partition will require replication to all the domain controllersfor that domain. The design and implementation of multiple domains within anorganisation may hence have a measurable impact on the network utilisation from

Active Directory replication traffic, and especially across low-bandwidth wide areanetwork links. As a result, the quality of service may deteriorate from the heavilyutilised network infrastructure unless the design of this infrastructure serves topartition such network traffic.

Many organisations undergo internal re-structuring exercises or mergers /acquisitions that could negate the function, role, or existence of a domain within theorganisation. Hence, the smaller the ratio of domains to objects within anorganisation, the better the domain infrastructure is able to withstand organisationre-structuring exercises.

2.8.2. Determination of the Requirements for a Dedicated or Dual-Function Forest RootDomain

Consider the following when determining the requirements for the design and use of adedicated (placeholder) or a dual-function domain as the forest root domain:

Factor A1: Requirement to control the membership of the Domain Admins group in the

forest root domain


where an organisation wishes to determine the requirements to control membership ofthe Domain Admins group, in the forest root domain.



The design of Windows Server 2003 Active Directory permits member securityprincipals within the Domain Admins group in the forest root domain, the ability toaccess and take ownership of all resources controlled by any domain within the forest.It is hence necessary to strictly control membership to this security group, especiallywhere the forest is required to support multiple domains. For this reason, the domain isnot a security boundary for data and services within a forest.

The creation of a dedicated (empty) forest root domain, not required to support normalusers within the organisation, provides the ability to control membership to the DomainAdmins group.

Where an organisation is considering the design and deployment of a multiple domain

infrastructure for the forest, and can identify compliance with one or more of thefollowing criteria, then the forest owner(s) should consider the design and use of adedicated forest root domain:



13/122


It is possible to identify a decentralised administration model for the forest, and un-trusted administrators of domains within the forest

It is possible to identify un-trusted administrators (employees or non-employees ofthe organisation) within a centralised administration model for the forest

The organisation requires the enforcement of a strict security policy for the ActiveDirectory infrastructure, influenced and regulated by business continuityrequirements of the organisation.

This design methodology recommends the use of the restricted group policy settingwithin a Group Policy Object (GPO), applied at the domain level for the forest rootdomain, to control and monitor the membership of this group.

Using the above information, execute an analysis to determine the requirement torestrict membership to the Domain Admins group in the forest root domain, withoutthe requirement for the design of an extensive delegation of control infrastructure foreach required ORMI within a domain.

If it is possible to identify this requirement, then consider the creation of a dedicatedforest root domain for this forest.

Factor A2: Requirement to retain operational control over forest-level components of the

Active Directory infrastructure


where an organisation:

Has a decentralised administration model for the Active Directory infrastructure, and

Wishes to determine the requirements to retain operational control over forest-levelcomponents

Factor Considerations: Upon identification of the criteria for the application of this

factor within an organisation, consider the following information:

Within a multiple domain infrastructure or a forest, the forest owner(s) must retaincontrol over the management of forest-level components. All domains within the forestdepend upon the continuity of the forest. Hence, the business continuity of allautonomous divisions and non-autonomous divisional structures within theorganisation, represented within these domains are also dependent upon the continuityof the forest.

The most important aspect of the forest, managed only at the forest-level, and with ascope of impact of the entire forest, is the Active Directory Schema. Rights to manageand modify the Schema are restricted to members of the Schema Admins securitygroup in the forest root domain.

Another aspect of forest management is control over the creation of new domainswithin the forest. Only member security principals of the Domain Admins or theEnterprise Admins security groups in the forest root domain have the right to createnew domains and new domain trees within a forest.

It is hence possible to create a dedicated (placeholder) forest root domain to providethe foundation of the centralised control and execution of all management tasks thatmay influence the operation of the entire forest.

Factor A3: Requirement to create a minimal replication footprint for the forest root domain

Criteria for Execution: Explore the considerations for the execution of this factorwhere an organisation:



14/122


Has a WAN infrastructure that will support a geographically distributed ActiveDirectory infrastructure, and

Wishes to consider the requirements to generate a minimal replication footprint forthe forest root domain via the creation of a dedicated forest root domain

Factor Considerations: Consider the following information where it is possible toidentify compliance with the above criteria within an organisation:

The continuity of the forest is directly dependent upon the continued presence of atleast one domain controller representing the forest root domain. The creation ofmultiple domain controllers to support the forest root domain may provide faulttolerance for this domain, where hardware or software failures may temporarily bringdown one or more domain controllers.

However, this strategy of multiple domain controllers for the forest root domain does notprotect the forest where all domain controllers are in the same physical location, as asite-specific disaster may permanently bring down the entire site, all domain controllers,and hence the entire forest. For example, a site may experience a flood, fire, or other

natural disasters like earthquakes or hurricanes, and so on, or manufactured disasters,such as terrorist attacks.

Hence, most organisations, represented across multiple geographical locations,consider the placement of domain controllers for the forest root domain in multiplelocations. However, although this will protect the forest against a site-specific disaster,this has added overheads to support replication between the forest root domaincontrollers.

A dual-function forest root domain, supporting many hundreds or thousands of directoryobjects, will have a significant inter-Site replication footprint, which may influence thelevels of available network bandwidth on inter-Site WAN links.

Hence, the creation of a dedicated placeholder domain, to serve as the forest rootdomain, may support a minimal replication footprint because such domains usually donot hold many objects (additional to the default set of objects). Hence, the replication ofthis small domain across high-latency, low-bandwidth WAN links can provide protectionagainst geographic location specific disasters and hence assist in the maintenance ofthe continuity of the forest.

Note that it is also necessary to distribute domain controllers that represent the forestroot domain to each geographical location where inter-domain user access will occur.Any request between domains with a trust path separated by the forest root will need togo through a domain controller for the forest root domain, unless a short-cut trust to thedestination domain is present.

Factor A4: The requirement to ensure the business continuity dependent upon the forest


where an organisation has:

Identified that any disruption to the normal operation of the Active Directoryinfrastructure via the temporary or total absence or failure of the forest root domainmay have a serious impact on the continuity of operations and processes within theorganisation, and

Identified that there are / may be plans within the organisation to execute internalrestructuring exercises or a merger with / acquisition of another organisation





15/122


The design and implementation of a dedicated placeholder domain for the forest rootcan ensure the continuity of the Active Directory infrastructure. The creation of domainswithin an organisation, to reflect aspects of the business model and structure of theorganisation, may jeopardise the existence of these domains, following business re-organisations, mergers, and acquisitions.

However, a dedicated placeholder domain provides protection against redundancysince its role within the organisation is critical to the operation of the entire ActiveDirectory forest. This protection hence reflects the stability of the forest.

2.8.3. Determination of the Number of Domains Required

Consider the following when determining the number of domains this forest is required tosupport.

Presented within the following two sections are the considerations for the execution of thisstep within this process:

1. Considerations for the factors no longer influential the determination of the number ofdomains required for a Windows Server 2003 forest

2. Considerations for the factors influential in the determination of the number of domainsrequired for a Windows Server 2003 forest

2.8.3.1. Non-Influential Factors in the Determination of the Number of Domains Required

Within organisations with an existing Windows NT 4.0 multiple domain infrastructure, theconsiderations employed to influence the design for the current domain infrastructure may nolonger apply.

The technical differences in capabilities and operation between Windows NT 4.0 andWindows Server 2003 invalidate many of the earlier justifications for a multiple domainenvironment. It is important tot note that there are also differences between the legacy

Windows 2000 Active Directory and the Windows Server 2003 Active Directory.

These considerations (for a Windows NT 4.0 domain model and a Windows 2000 ActiveDirectory infrastructure, where appropriate) are discussed within this step to ensure theirdiscount from considerations in determination of the number of domains required.

Factor B4: The maximum size of a SAM database


where an organisation, with a legacy Windows NT 4.0 domain infrastructure, wouldconsider the creation of a new domain upon identification of compliance with themaximum limit on the size of the SAM (Security Accounts Manager) database.


The Microsoft Knowledge Base article (KB130914) provides the details of how the SAMdatabase for a Windows NT 4.0 domain realistically, can only grow to a maximum of40Mb in size. In order to reduce the potential size of the SAM database, manyWindows NT 4.0 administrators typically opted for a Master Domain, or Multiple MasterDomain model.

These models involved the creation of Windows NT 4.0 Resource Domains that heldonly computer accounts and groups. Only the master domain(s) held user accounts,resulting in a maximum of (approximately) 40,000 user accounts per master domain(where a user account is approximately 1Kb in size, a computer account is 0.5Kb, and

a group (with around 300 members) is approximately 4Kb).



16/122


An indexed sequential access method (ISAM) table manager provides the foundation ofa Windows Server 2003 Active Directory database. This database is a version of theExtensible Storage Engine (ESE) database that has a theoretical maximum size limit of16 terabytes (TB) (on an NTFS partition).

The Registry for the Windows Server 2003 operating system does not limit the

theoretical maximum number of user accounts that a single Active Directory databasecan hold. However, the disk and memory capacity of the Windows Server 2003 ActiveDirectory domain controllers does influence the maximum number of users accountsthat a single Active Directory database can hold.

A typical large sized organisation may hence realistically create a single WindowsServer 2003 Active Directory domain to support over a few hundred thousand objects.

Factor B5: The requirement to delegate administrative control within the organisation


where an organisation, with a legacy Windows NT 4.0 domain infrastructure, wouldconsider the creation of a new domain to allow the delegation of control over

organisation resources, without compromising the security of the Domain Admins groupof a domain.



Windows NT 4.0 does not provide the ability to delegate control over domain resourcesto standard user accounts, unless those accounts are members of the built inadministration groups, such as the Domain Admins user group.

Hence, the only method to allow a hybrid administration model (centralised anddecentralised) in Windows NT 4.0 was to create multiple domains, as the domain wasthe most granular administrative unit available.

Windows Server 2003 Active Directory allows the assignment of permissions overdomain objects to standard domain user accounts (this process is termed delegation ofcontrol). This hence negates the requirement for the creation of multiple domains forthis purpose. See the Domain Plan process Design for Delegation of ControlInfrastructure for details.

Factor B6: Requirements for unique user account security options


where an organisation, with a legacy Windows 2000 Active Directory domaininfrastructure, would consider the creation of a new domain to permit the use of uniquesecurity options for user accounts.



In Windows 2000 Active Directory, it was only possible to apply the required securityoptions for user accounts (password policy, account lockout policy, Kerberos policy)within a GPO implemented at the domain level.

However, in Windows Server 2003 Active Directory, it is possible to generate multipleGPOs, which contain these security policy settings for user accounts, and implementthem at any OU level within a domain.

This hence supports the requirements for unique security options for user accounts byautonomous divisions represented within an Active Directory domain as an OU, and

hence negates the requirements for multiple domains to support this requirement.



17/122


2.8.3.2. Influential Factors in the Determination of the Number of Domains Required

Consider the following when determining the number of domains required for a forest:

Factor A5: The requirement to establish domain-level service autonomy

Criteria for Execution: Explore the considerations for the execution of this factorwhere an organisation wishes to establish service autonomy within the organisation viathe implementation of multiple domains within a forest.



An organisation may agree to allow a forest owner to determine forest-wideconfiguration, but still require domain-level service autonomy.

Where it is possible to identify the requirement for autonomy to perform and manageany one of the following elements of domain management by a domain owner, then thismay indicate the requirement to create a separate domain with the forest:

Domain-level UPNs: Only a domain owner can set different User Principal Name(UPN) suffixes for user accounts within the domain. For example, a domain with thedomain name of xyz.abc.com would have the default UPN suffix [email protected]. However, the users within the domain xyz may have e-mailaddress suffixes of @xyz.com, and hence, the domain owner can create a UPN forthe domain of @xyz.com. The users can hence log on to the domain with their e-mail addresses and user account password. It is possible to define multiple UPNs atthe domain level.

Service availability and security: A domain owner has the ability to create, remove,backup, and restore domain controllers in order to meet a desired level of serviceavailability. Note however, that the security breach of any domain controller within a

domain in a forest may potentially jeopardise the entire forest and all the domainswithin the forest. Hence, it is important to assure the network and physical securityof all domain controllers within a forest, especially when allowing service autonomy.The onus and responsibility for this must hence reside with the domain owner.

Politics and ownership issues: In medium to large organisations, where there maybe many divisions and departments (and even sub-companies), issues may arisesurrounding the ownership of, and responsibility for domains, domain managementtasks and the data within these divisions that is controlled (authentication andauthorisation) by these domains. These may be resolved by allowing the discretedivisions or department ownership and responsibility of their own domain within aforest in the organisation.

External trust-relationships: The domain owner can determine which domains inother forests to trust via the creation of external (non-transient) trust relationships.

Compliance with international differences: A local domain owner can manage thecompliance of the domain with the local legal, security, financial and businesspractice policies of an organisation that has an international presence.

Factor A6: The requirement to disallow service autonomy within a forest


where an organisation does not wish to relinquish control of objects that fall within theboundary of a forest or domain within a forest.





18/122


The owner(s) of the forest may wish to prevent autonomous divisions within theorganisation from gaining service autonomy via the creation of discrete domains.

For example, the owner(s) for the forest may wish to ensure compliance with high-priority security policies. Delegation of service autonomy may imply the provision ofcontrol over domain controllers for a non-root domain to an autonomous division within

the organisation.

The forest owner(s) may distrust the administrators of the autonomous division, forexample, due to a history of undisciplined management, and hence wish to prevent aforest-wide disaster via the physical compromise of a domain controller for a non-rootdomain. The compromise of any domain controller within the forest by a maliciousattacker, due to the lax physical security infrastructure for an autonomous division, maycompromise the integrity and operation of the entire forest.

It is also important to note that a single Windows Server 2003 domain may representand support multiple autonomous divisions, via the design and implementation ofdiscrete object and resource management infrastructures (ORMIs). See the DomainPlan for details of ORMIs. An ORMI may support service autonomy, to a degree, and

hence may negate the requirements for the design and implementation of multiplediscrete domains.

Factor A7: The requirement to control Active Directory replication and network utilisation


where an organisation wishes to understand the impact of a multiple domain ActiveDirectory replication topology on the LAN infrastructure of the organisation.



The majority of network traffic caused by Active Directory replication derives from intra-

domain replication between domain controllers of a domain. The level of daily networktraffic caused by the replication of the forest Schema and Configuration partitions to alldomain controllers within a forest is minimal since these partition receive very few andinfrequent changes.

The partitioning of the forest into multiple domains, on a well-planned networkinfrastructure, can isolate the network traffic. However, it is important to note thefollowing points:

All domain controllers, whether in a single or multiple domain forest, must bepresent on the production network for the organisation, and hence must be able tocommunicate with each other. A domain controller within a forest cannot functionwithout errors whilst in network incommunicado.

It may be possible to identify a network infrastructure and TCP/IP architecture forthe organisation where all domain controllers for multiple domains may reside, forexample, on the same subnet and LAN. This may occur where the network architectfailed to provide consideration to the design of segregated, routed, subnetted, andvirtual LANs and so on, then. In this scenario, network utilisation caused by ActiveDirectory replication will increase substantially, and hence it will not be possible tonote any improvements from the partitioning of a forest in to multiple domains, fromthe perspective of utilisation of the local area network bandwidth.

Factor A8: The requirement to attain compliance with limitations within the current

/proposed WAN infrastructure within the organisation


where an organisation has:



19/122


A WAN infrastructure with inter-location network links that cannot support thesynchronous replication transport protocol (RPC over IP) but can only support theasynchronous transport protocol (SMTP over IP)

Users and computers within the terminus locations of these network links thatrequire representation within, and support by, the forest



For inter-Site replication, it is only possible to use the SMTP over IP inter-Sitereplication transport protocol to replicate inter-domain and non-domain namingcontexts. This replication transport protocol cannot support intra-domain replicationtraffic. Hence, there may be the requirement to establish a separate domain where it ispossible to identify the criterion for this factor.

It is important to note that the use of an SMPT over IP Site Link requires the installationand configuration of an Enterprise Certificate Authority to issue the source anddestination domain controllers with X.509 certificates. The domain controllers will

employ these encryption keys, within these certificates, to encrypt data transmittedbetween them using this transport protocol.

Factor A9: Firewall port restrictions may require the use SMTP over IP as the transport

protocol for a Site Link

Criteria for Execution: The consideration for this factor are to be explored where an

organisation:

Has identified the presence of firewall restrictions on the selection of replicationtransport protocols, and

Wishes to understand the impact of these restrictions on the determination of the

number of domains required for a forest



An organisation may be required to employ the SMPT over IP replication transportprotocol for inter-Site replication where it is possible to identify compliance with thefollowing criteria:

The organisation has two or more physical locations, which are potential ActiveDirectory Sites

Two or more of these locations are connected together via a WAN link

There is a firewall in place between a domain controller on a LAN within one Siteand a domain controller on a LAN within another Site

The firewall is configured to prevent the flow of RPC over IP traffic on ports 137 and139

Where it is possible to identify all of the above criteria for the application of the factorwithin an organisation, then the Site Link(s) that connect the Sites via a RPC over IPport restricted firewall may have to use as the transport protocol (assuming the firewallrestrictions will permit port 25 traffic).

The same considerations as for the previous factor that would require the use of SMTPover IP as the transport protocol for a Site Link will apply for this factor



20/122


Factor A10: The requirement to comply with the capacity limits of an Active Directory

domain


where an organisation has identified the requirement to populate the Active Directoryinfrastructure with an excess of one or two million objects.



Although an Active Directory database (NTDS.dit), via its structure and design, cantheoretically grow to 16Tb in size (and hence hold approximately16,384,000,000,000Kb / 4Kb = 4,096,000,000,000 user accounts), this is not practical.For example, it would not be possible to backup an Active Directory database of thissize within a typical backup window.

One may question the likelihood of an organisation populating a production ActiveDirectory domain with between one and two million user accounts. However, note thatthis process discusses objects, and not just user accounts, which represent just one of

the many types of objects that an Active Directory can hold. Everything within the ActiveDirectory is an object and hence represented within the Active Directory database witha finite data size footprint.

For example, it is possible to publish shared folder objects within an Active Directory,and most organisations can very easily publish hundreds, thousands, or even hundredsof thousands of shared folder objects to an Active Directory. The use of Distributed LinkTracking, although disabled y default in t Windows Server 2003 Active Directory, mayalso populate an Active Directory domain partition with many objects.

Consideration must be taken primarily towards the impact on the network from thereplication of changes to these objects; the impact on the storage and memoryrequirements of the domain controllers that will host this Active Directory; and the

consequences of database divergence. With so many objects hosted within a multi-master replication model, even if regular changes were made to only a smallpercentage of these objects, this may represent a vast number of changes that have tobe replicated to all domain controllers for this domain.

For example, domain controllers supporting a production domain with one to two millionobject may never reach convergence, where 10 percent change per working day isexpected. Ten percent of two million objects equate to 200,000 changes every workingday, or about 2,200 changes propagated every five minutes for intra-Site replication.

Hence, the probability of attaining convergence of the Active Directory databases on allthe domain controllers for this domain becomes very low.

Although this scenario will have a low incidence of application within the majority oforganisations wishing to design and deploy and Active Directory infrastructure, it is notan impossible scenario. Hence, where an organisation may potentially populate anActive Directory infrastructure with millions of objects, this design methodologyrecommends the creation of one or more new domains to hold the new objects. It ispossible to segregate the objects into domains using categories such as securityprincipals and non-security principals, and object types. This categorisation of objectscan assist in the determination of the number of domains required to support a largenumber of objects within the forest.

Factor A11: Requirement to preserve an existing legacy (Windows NT 4.0 or Windows

2000) multiple domain infrastructure via in-place upgrades


where an organisation:



21/122


Has identified the presence of a multiple domain Windows NT 4.0 and / or Windows2000 domain infrastructure, and

Wishes to consider the requirements to preserve the design for the existing multipledomain infrastructure


It is possible to assign legacy domain infrastructures within an organisation, hosting twoor more domains, to one of the following example categories:

The current design for the legacy domain infrastructure is a result of careful planningguided by the requirements to comply with business and technical requirements,which are all still valid within the organisation.

The current design for the legacy domain infrastructure is a result of careful planningguided by the requirements to comply with business and technical requirements.However, it is now no longer possible to identify any valid supporting requirements

for the continued existence for the majority of the existing domain infrastructure,from any of the original business and technical requirements.

The current design for the legacy domain infrastructure is a result of careful planningguided by the requirements to comply with business and technical requirements.However, it is now possible to identify that the original business and technicalrequirements supporting the existence of one or more of the existing domains areno longer valid, and hence these domains are potentially redundant.

The current design for the legacy domain infrastructure does not reflect any carefulplanning for compliance with business and technical requirements. The domaininfrastructure has superfluous, redundant, and inefficient qualities, manifested at thedomain level.

The current design for the legacy domain infrastructure, although initially plannedwith care to support compliance with business and technical requirements, greworganically and outside of the control of the IT function within the organisation. Theorganic growth is a reflection of mergers, acquisitions, pending spin-offs, and soon. The current design for the domain infrastructure within the organisation hassuperfluous, redundant, and inefficient qualities, manifested at the domain level.

From these above example categories, of which it is possible to define many more, onlycompliance with the first category supports the exact retention of the current domaininfrastructure. This is a rare occurrence within the majority of organisations.

Windows Server 2003 Active Directory provides greater opportunities for theconsolidation of multiple domain infrastructures that will reap the following examplebenefits to an organisation:

The reduction in the administrative overheads associated with the management of amultiple domain infrastructure

The reduction in the financial overheads for the management and maintenance ofmultiple domain controller servers for each domain within the organisation, andhence a total cost of ownership saving associated with the provision of a directoryservice infrastructure for the organisation.

Where an organisation is adamant that it does not wish to consider consolidation orrestructuring exercises, then it may be possible to validate the requirement toimplement a multiple domain infrastructure to meet this requirement for theorganisation.



22/122


3. Design of the Structure and Relationships of MultipleDomains

Execute this process where it is possible to identify the requirement to create multipledomains within a forest for the organisation. This process will assist the organisation in the

design of the structure and relationships of multiple domains within each forest.

3.1. Background InformationWhere an organisation has identified the requirement for a multiple domain forest, then thenext step in the creation of a forest plan is to determine the structure and relationships ofthese multiple domains within the forest.

This process will provide examples of the factors that can influence the structure andrelationships of multiple domains within a forest, and the considerations for each listed factor.

Using the information provided, an organisation can hence make an informed decision as tothe final structure and relationships for the multiple domains of the forest.

This design methodology recognises a number of approaches to support the logicalarrangement of multiple domains within a forest. However, the structure must adhere to therule that each child domain can have only exactly one parent domain.

Determination of the structure and relationships of the domains within the forest permitsassignment of the distinguished names for the domains. The process Design of a DNSInfrastructure, executed as a component of the Organisation-wide Active Directory Plan, willbuild upon the results of this process to identify the tree structure(s) required for each forest,and hence the number of DNS namespaces, and domains within each DNS namespace /tree.

3.2. Process Approach

This design methodology recommends execution of the following approach to determine therequired structure and relationships for the domains within the forest:

1. Consider all factors that will influence the design of the structure and relationships ofmultiple domains within a forest

2. Determine the applicable factors and hence the required structure and relationships forthe domains

3.3. Process ComponentsBased upon the above approach, design the structure and relationships of multiple domainswithin a forest is composed of the following components:

Understand all factors influential to the design of the structure and relationships of multipledomains within a forest

Determine the required structure and relationships for the domains

3.4. Deliverables of Process ComponentsThis process will have the following deliverables:

An understanding of all factors applicable to the organisation that will influence the design

for the structure and relationships of multiple domains within the forest

The generation of a design for the required structure and relationships for multiple

domains within the forest



23/122


3.5. Inter-Component DependenciesEach component of this process will have the following inter-component dependencies:

Forest Plan Inter-Component Dependencies for

Process to Design the Structure and Relationships of

Multiple Domains within a Forest

START

Determine the requireddesign for the structure

and relationships ofmultiple domains

Understand factorsinfluential to the design

of the structure &relationships of multiple

domains 2 0 0 4 M U S T A N S H I R B H A R M A L

3.6. Process to Design the Structure and Relationships of the DomainsForest Plan Process to Design the Structure and Relationships of Multiple Domains

NO

Is there a

requirement to

implement specificdomain namespaces

within this

forest?

START

END

Execute

A2

YES

Determine the number

of domain trees that

require creation within

this forest

ExecuteA1

Is there a

requirement to limit

the maximum depth

of a domain

hierarchy?

YES

Determine the

maximum required

depth for a domain

hierarchy

NO

Execute

A3


to support searches

within multiple

domains using a

single

query?

YES

Determine the design

requirements for the

domain hierarchy to

support this

requirement

NOExecute

A4

Is there

a requirement

to facilitate regular

intra-forest

resource

access?

YESDetermine the detailsfor all requirements to

support intra-forest

resource access

NOExecute

A5

Is there

a requirement

to preserve a legacy

domain structure

via in-place

upgrades?

YES

Determine the detailsfor all requirements to

support intra-forest

resource access

Use all factors identified as

been applicable to the

organisation and generate a

design for the structure and

relationships of the domains

within this forest

NO


3.7. Process ConsiderationsConsider the following information when determining the required design for the structure andrelationships of multiple domains within a forest:



24/122


Factor A1: The requirement to implement specific domain namespace(s)


where an organisation wishes to consider the requirements to implement two or moredomain namespaces within the forest.


As defined earlier, a forest is a virtual entity supporting one or more domains, logicallygrouped together, and sharing a common Schema and Configuration partition, acommon Global Catalog, and a common replication topology. A forest does not restrictthe number of domain namespaces possible for creation within the forest. Hence, if forexample, a forest has ten domains, there could be ten distinct domain namespaceswithin the forest, and the only relationships the domains have to each other is theirpresence within the boundary of the forest-level components.

Where an organisation has several sub-divisions, major departments, sub-companiesand so on, which require representation within the forest as discrete domains, the

domain namespaces could reflect the function, role, or name of the division,department, or sub-company. This may hence assist in clearly identifying theboundaries for service autonomy between the divisions, departments, sub-companies,and so on.

For example, an organisation (Natsum) requires a single forest to support itself andthree sub-companies, each represented as discrete domain within the organisationssingle forest. The organisation (as a whole) will have one administration domain, andthe forest will have a dedicated forest root domain called Root.Natsum.com. Theorganisation has hence decided to arrange and hence name these domains asRoot.Natusm.com and Admin.Root.Natsum.com. The names of the sub-companiesare MAB1, MAB2, and MAB3 respectively. Each sub-company has two domains andwill arrange and hence name them as MAB.com and ChildA.MAB.com.

Using these four (including the organisations domains) domain namespaces, theservice autonomy boundaries are clearly defined within the forest.

The following diagram illustrates this example:

MAB3.com

ChildA.

MAB2.com

ChildA.

MAB1.comChildA.

MAB3.com

Admin.Root.

Natsum.

com

Root.

Natsum.

com

MAB2.comMAB1.com

Forest Root

DomainTree Root Domains


Figure 10.1: Example Illustration of Multiple Domain Trees in a Forest

This design methodology recommends consideration of multiple DNS namespaces,and hence domain trees, within a forest where it is possible to identify compliance withthe following criteria:

The organisation has identified the requirement to implement a specific domainnamespace(s) that will influence the distinguished names of the domains within theforest in order to:



25/122


Distinguish a domain / set of domains within a forest (via a tree structure)

Distinguish a domain / set of domains between multiple forests within theorganisation

Reflect the mapping between domain ownership and positioning / function / role

within the structure of the organisation

The organisation has a requirement to use domain trees and not alternative UPNsuffixes to represent discrete namespaces within the forest.

Note that it is possible to elevate the earlier example to the forest level where sub-companies of an organisation enforce autonomy or isolation at the forest level via theimplementation of multiple forests within the organisation. The domain namespaces forthe forest root domains or sub-domains within each forest could hence reflect theautonomy or isolation requirements for these sub-companies.

Note that the structure and relationships of multiple domains within a forest influencesthe Fully Qualified Domain Name (FQDN) of a computer account object. To allow

different primary DNS suffixes, a domain administrator may create a restricted list ofallowed suffixes by creating the msDS-AllowedDNSSuffixes attribute in the domainobject container. It is possible for the domain administrator to create and manage thisattribute via Active Directory Service Interfaces (ADSI) or the Lightweight DirectoryAccess Protocol (LDAP).

Factor A2: Requirement to control the maximum depth of a domain hierarchy


where an organisation wishes to understand the influence of compliance with technicalrequirements, to control the maximum depth of a domain hierarchy, on the design forthe structure and relationships of domains within the forest.


The domain namespace forms a component of the distinguished names of objectswithin a domain. For example, within a domain with a distinguished name ofChildB.ChildA.MAB2.com, a computer account object called MAB2APPSERVER2would have a distinguished name of MAB2APPSERVER2.ChildB.ChildA.MAB2.com.

A computer name is limited to 63 UTF-8 bytes per label and 255 UTF-8 bytes for thefully qualified domain name (FQDN). This hence places a technical limit on themaximum depth for a domain hierarchy, based upon the length of the names of thedomains within the hierarchy and the length of the computer account names within thedomains.

This design methodology hence recommends a limit on the depth of a domainshierarchy be established at between three and four domains deep (depending upon thelength of the individual domain names).

Note that the deeper a domain hierarchy becomes, then the sooner the limit on theFQDN applies, and the harder the FQDN will become to remember.

Factor A3: Requirement to implement the ability to search multiple domains in a forest

within a single query


where an organisation wishes to understand the influence of the arrangement ofmultiple domains within a forest using multiple domain namespace hierarchies on theexecution of searches and LDAP referrals within the forest.



26/122




If a user within a domain wishes to search for an object within the forest and does notknow the location or the distinguished name for this object, the user can instigate anLDAP search for this object.

If the domain in which this user resides is within a hierarchy of domains (a tree) withinthe forest, and the object she is searching for resides within a domain within thishierarchy, then the search she instigates will find that object very quickly.

This is because the domain hierarchy of Windows Server 2003 Active Directory allowsa search to be instigated in multiple domains in one query, as each level of thehierarchy has information about the levels immediately above it and below it. Thishierarchy information eliminates the need for the knowledge of the location of aparticular object in order to find it. In Windows NT 4.0 and earlier, a user must knowboth the domain and the server where the object is located in order to find it.

Implementation of the domains within the forest into non-contiguous namespaces

results in the requirement to generate multiple LDAP referrals, and not a single query,to find the object, hence increasing the search time.

Factor A4: Requirement to facilitate name resolution and authentication for frequent

resource access between domains within a forest


where an organisation wishes to understand the influence of the requirement tofacilitate intra-forest name resolution and authentication via the design for the structureand relationships of multiple domains within a forest.



When determining the influence of requirements to facilitate frequent requests for intra-forest name resolution and authentication on the design for the structure andrelationships of domains within a forest, consider the following:

Depending upon the distinguished name assigned to a domain name at the time ofcreation, each domain within a forest trusts, via bi-directional transitive trustrelationships, either a parent or the forest root domain.

This bi-directional transitive trust relationship model supports intra-forest resourceaccess by security principals with the appropriate permissions within the domaincontrolling a resource.

The domain hierarchy generates a trust path. Where a trust-path is greater thanthree or four domain hops long, each instance of a request for resource accesswithin a destination domain generates Kerberos referrals across each intermediatedomain. This can hence increase the time taken to access the resource in thedestination domain and increase the workload on the domain controllers in theintermediate domains, especially where this is a frequent occurrence.

This design methodology proposes the following two potential solutions to thisscenario:

The first solution requires the creation of domain hierarchies of shorter depth tominimise the length of trust-paths between domains, which commonly participatein inter-domain resource access activities.



27/122


The second solution requires the creation of inter-domain and intra-forest short-cut trust relationships between domains within the forest, to decrease the lengthof a trust-path.

Where possible, in these early stages of the design of the structure andrelationships of multiple domains within a forest, this design methodology

recommends the execution of the first solution. This hence requires consideration ofthe potential trust-path lengths between domains within a forest, based upon theidentification of those domains within the forest that may support frequent inter-domain resource access.

Although the design and implementation of short-cut trust relationships can reducethe trust-path, this design methodology does not recommend their use tocompensate for a poor design for the structure and relationships of multiple domainswithin a forest. Note also that for each short-cut trust relationship designed, it isnecessary to consider the associated management overheads. (See the processdesign of short-cut trust-relationships for details of the considerations for thedesign of short-cut trusts.).

Factor A5: Requirement to preserve a legacy domain structure and relationship via in-place upgrades


where an organisation wishes to consider the influence on the requirements to preservea legacy domain infrastructure on the design for the structure and relationships ofmultiple domains.



Although Windows NT 4.0 domain infrastructures do not employ DNS domainnamespaces to define their structure and relationships, they do employ mono or bi-

directional external trust relationships. The presence and direction of the trustrelationships between Windows NT 4.0 domains defines the relationships between thedomains. For example, a mono-directional trust relationship between an account anda resource domain, where the resource domain trusts the account domain, definestheir relationship.

Within legacy Windows 2000 Active Directory infrastructures, domain namespaces andinternal bi-directional transitive trust relationships define the relationships betweenmultiple domains in each forest, and between forests.

Where the organisation wishes to preserve the current number and type ofrelationships between multiple legacy domains, then this will influence the design forthe structure and relationships of these domains within the Windows Server 2003

Active Directory forest.



28/122


29/122


4.5. Process to Design Short-Cut Trust-RelationshipsForest Plan Process to Design the Short-Cut Trust Relationships

YES

Is there

compliance

with the criteria for

the design of

short-cut

trusts?

START END

Execute

A2

NO

Identify the minimum number of

short-cut trust required, the

domains that require the short-cut

trusts, and the required

direction(s) for the trusts

Execute

A1

2 0 0 4 M U S T A N S

Date post:	31-May-2018
Category:	Documents
Upload:	mustan
View:	212 times
Download:	0 times

Forest Plan (Book 2 of 5)

Documents