© 2004 Mustan Bharmal. All Rights Reserved.

Table of Contents
1. INTRODUCTION TO THE FOREST PLAN................................................................................................. ..........3 1.1. BACKGROUND INFORMATION........................................................................................... .........................3 1.2. FOREST PLAN PROCESSES....................................................................................................... ..............3 1.3. DELIVERABLES OF FOREST PLAN PROCESSES.......................................................................... ...................3 1.4. INTER-PROCESS DEPENDENCIES...................................................................................... ........................4 1.5. PROCESS TO CREATE THE FOREST PLAN...................................................................................... .............5 2. DETERMINATION OF THE NUMBER OF DOMAINS REQUIRED.............................................................................. ...6 2.1. PROCESS OBJECTIVE................................................................................................... .........................6 2.2. BACKGROUND INFORMATION........................................................................................... .........................6 2.3. PROCESS APPROACH........................................................................................................................... ..6 2.4. PROCESS COMPONENTS.................................................................................................................... .....7 2.5. DELIVERABLES OF PROCESS COMPONENTS....................................................................................... ..........7 2.6. INTER-COMPONENT DEPENDENCIES........................................................................................................... 8 2.7. PROCESS TO DETERMINE THE NUMBER OF DOMAINS REQUIRED................................................... ...................9 2.8. PROCESS CONSIDERATIONS.................................................................................................................. .10 3. DESIGN OF THE STRUCTURE AND RELATIONSHIPS OF MULTIPLE DOMAINS..................................................... ......22 3.1. BACKGROUND INFORMATION........................................................................................ ..........................22 3.2. PROCESS APPROACH........................................................................................................................ ...22 3.3. PROCESS COMPONENTS.................................................................................................................. .....22 3.4. DELIVERABLES OF PROCESS COMPONENTS..................................................................................... ..........22 3.5. INTER-COMPONENT DEPENDENCIES........................................................................................................ .23 3.6. PROCESS TO DESIGN THE STRUCTURE AND RELATIONSHIPS OF THE DOMAINS......................................... ..........23 3.7. PROCESS CONSIDERATIONS.................................................................................................................. .23 4. DESIGN OF SHORT-CUT TRUST RELATIONSHIPS........................................................................ ...................28 4.1. BACKGROUND INFORMATION........................................................................................ ..........................28 4.2. PROCESS COMPONENTS.................................................................................................................. .....28 4.3. DELIVERABLES OF PROCESS COMPONENTS..................................................................................... ..........28 4.4. INTER-COMPONENT DEPENDENCIES........................................................................................................ .28 4.5. PROCESS TO DESIGN SHORT-CUT TRUST-RELATIONSHIPS.......................................................... .................29 4.6. PROCESS CONSIDERATION................................................................................................... .................29 5. DETERMINATION OF THE BOUNDARIES AND CONTENT OF EACH DOMAIN.......................................... ...................34 5.1. PROCESS OBJECTIVES................................................................................................................ .........34 5.2. PROCESS OBJECTIVES................................................................................................................ .........34 5.3. BACKGROUND INFORMATION........................................................................................ ..........................34 5.4. PROCESS APPROACH........................................................................................................................ ...34 5.5. PROCESS COMPONENTS.................................................................................................................. .....35 5.6. DELIVERABLES OF PROCESS COMPONENTS..................................................................................... ..........35 5.7. INTER-COMPONENT DEPENDENCIES........................................................................................................ .35 5.8. PROCESS TO DETERMINE THE BOUNDARIES AND CONTENT OF EACH DOMAIN................................ ...................36 5.9. PROCESS CONSIDERATIONS.................................................................................................................. .36 6. DETERMINATION OF THE SIZE OF THE ACTIVE DIRECTORY DATABASE FOR THE FOREST................................. .........44 6.1. PROCESS OBJECTIVES................................................................................................................ .........44 6.2. BACKGROUND INFORMATION........................................................................................ ..........................44 6.3. PROCESS APPROACH........................................................................................................................ ...46 6.4. PROCESS COMPONENTS.................................................................................................................. .....47 6.5. DELIVERABLES OF PROCESS COMPONENTS..................................................................................... ..........47 6.6. INTER-COMPONENT DEPENDENCIES........................................................................................................ .47 6.7. PROCESS TO DETERMINE THE SIZE OF THE ACTIVE DIRECTORY DATABASE FOR THE FOREST................................48 6.8. PROCESS CONSIDERATIONS.................................................................................................................. .48 7. DESIGN OF THE FOREST ROOT DOMAIN........................................................................... ..........................51 7.1. BACKGROUND INFORMATION........................................................................................ ..........................51 7.2. PROCESS APPROACH....................................................................................................................... ...51 7.3. PROCESS COMPONENTS.................................................................................................................. .....51 7.4. DELIVERABLES OF PROCESS COMPONENTS..................................................................................... ..........52 7.5. INTER-COMPONENT DEPENDENCIES........................................................................................................ .52 7.6. PROCESS TO DESIGN THE FOREST ROOT DOMAIN............................................................... ......................53 7.7. PROCESS CONSIDERATIONS.................................................................................................................. .53 8. DESIGN OF APPLICATION DIRECTORY PARTITIONS WITHIN A FOREST..................................................... .............73

Page 1 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

8.1. PROCESS OBJECTIVES................................................................................................................ .........73 8.2. PROCESS SCOPE...................................................................................................... .........................73 8.3. BACKGROUND INFORMATION........................................................................................ ..........................73 8.4. PROCESS APPROACH........................................................................................................................ ...73 8.5. PROCESS COMPONENTS.................................................................................................................. .....74 8.6. DELIVERABLES OF PROCESS COMPONENTS..................................................................................... ..........74 8.7. INTER-COMPONENT DEPENDENCIES........................................................................................................ .74 8.8. PROCESS TO DESIGN APPLICATION DIRECTORY PARTITIONS WITHIN A FOREST..................................................75 8.9. PROCESS CONSIDERATIONS.................................................................................................................. .75 9. DESIGN FOR DIRECTORY QUOTAS..................................................................................... ........................93 9.1. BACKGROUND INFORMATION........................................................................................ ..........................93 9.2. PROCESS APPROACH........................................................................................................................ ...94 9.3. PROCESS COMPONENTS.................................................................................................................. .....94 9.4. DELIVERABLES OF PROCESS COMPONENTS..................................................................................... ..........94 9.5. INTER-COMPONENT DEPENDENCIES........................................................................................................ .94 9.6. PROCESS TO DESIGN DIRECTORY QUOTAS................................................................................... ............95 9.7. PROCESS CONSIDERATIONS.................................................................................................................. .95 10. SELECTION AND RAISING OF THE FOREST FUNCTIONAL LEVEL....................................................... ..............107 10.1. PROCESS OBJECTIVES........................................................................................................... ..........107 10.2. PROCESS SCOPE.................................................................................................. .........................107 10.3. BACKGROUND INFORMATION.................................................................................... ..........................107 10.4. PROCESS APPROACH............................................................................................................ ...........112 10.5. PROCESS COMPONENTS...................................................................................................... .............112 10.6. DELIVERABLES OF PROCESS COMPONENTS......................................................................... ..................112 10.7. INTER-COMPONENT DEPENDENCIES............................................................................................. ........113 10.8. PROCESS TO SELECT & RAISE THE FOREST FUNCTIONAL LEVEL FOR THIS FOREST.................................. ......113 10.9. PROCESS CONSIDERATIONS...................................................................................................... .........113

Page 2 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

1.

Introduction to the Forest Plan
It is necessary for every organisation, planning the execution of design activities to generate a Windows Server 2003 Active Directory infrastructure, to execute at least one Forest Plan. This is 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 a Windows Server 2003 Active Directory infrastructure for an organisation. A “production” forest is a forest that directly supports one or more business processes within the organisation, and hence the organisation will depend upon the existence of that forest. Note that this design methodology does not recommend the creation of a Forest Plan for “non-production” forests, such as parallel test forests within the organisation, which only indirectly support business processes 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 following completion of the “Organisation-wide Active Directory Plan” design process to “determine the boundaries and content of each required forest”.

1.1.

Background Information This design methodology defines a forest as a virtual entity, with a distinct logical boundary that represents one or more Active Directory domains, each of which share a common Schema, Configuration, Global Catalog, and an Active Directory replication topology. A Forest Plan caters for the design of those components of an Active Directory infrastructure defined, created, deployed, or managed only at the forest level, except the replication topology, which the “Site Plan” covers. Note that references to “this forest” or “this Active Directory forest” within this Forest Plan implicitly refer only to the Active Directory forest that this Forest Plan supports.

1.2.

Forest Plan Processes The 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 will be 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 be determined by the “Organisation-wide Active Directory Plan” design process to “determine 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 Processes The forest plan processes will have the following deliverables:

Page 3 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved. • 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 Dependencies Each process within the forest plan will have the following inter-process dependencies: Forest Plan – Inter-Process Dependencies for Forest Plan START
Determination of the number of domains required Design of Application Directory Partitions within a forest Design of the structure & relationships of multiple domains

Design of short-cut trust relationships

Design for Directory Quotas

Determination of the boundaries and content of each domain Determination of the size of the Active Directory database for the forest Design of the forest root domain
© 2004 MUSTANSHI
R

Selection and raising of the forest functional level

BHAR

MAL

Page 4 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved. 1.5.

Process to Create the Forest Plan Forest Plan – Process to Create the Forest Plan
Execute process “determination of the number of domains required” Is there a requirement for a multiple domain forest?

START

Execute process “design of short-cut trust relationships”

Execute process “design of the structure & relationships of multiple domains” Execute process “determination of the size of the Active Directory database for the forest” Execute process “design of the forest root domain” Execute process “Selection and raising of the forest functional level”

YES

Execute process “determination of the boundaries and content of each domain”

NO

Execute process “design of Application Directory Partitions”

Execute process “design of Directory Quotas”

END
© 2 0 0 4 MU S TAN SH I
R

BHAR

MAL

Page 5 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

2.

Determination of the Number of Domains Required
This design methodology requires all organisations to execute this process, regardless of any preconceptions as to the number of domain required within this forest.

2.1.

Process Objective The objective of this process is to assist an organisation in the determination of the total number of domains that this Windows Server 2003 Active Directory forest is required to support. Note that the objective of this process is only to assist an organisation in the determination of the 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 Information A forest can contain multiple domains, and a minimum of one domain controller is required to create a domain within a forest. However, every domain created within a forest will have an associated 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 be the 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 Active Directory 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 placeholder domain for the forest root implies, in the strictest sense, that there will be more than one domain within the forest. Where the forest root domain will hold many user and computer accounts, and hence function as a normal Active Directory domain, then this implies a dualfunction domain. The use of a dual-function domain for the forest root domain does not imply a single domain forest as the dual-function forest root domain could be one of many within the forest. The considerations for the selection of a dedicated domain or the use of dual-function domain as the forest root domain hence play an important role in the determination of the number of domains required for the forest.

2.3.

Process Approach When executing the process to determine the requirement for a multiple domain Active Directory forest, the recommended approach to the design of a domain infrastructure for an Active Directory forest is to “keep it simple”. This hence implies only a single domain infrastructure, or only a few domains within each forest. To support this recommendation, this design methodology states the following null hypothesis for this process: “A single domain for the forest can adequately meet all the Active Directory-related requirements for the forest without the requirement to create a multiple domain infrastructure within the forest”.

Page 6 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

It is then necessary to conduct an investigation to disprove this null hypothesis and hence determine the number of domains required for the forest. Where it is not possible to disprove this 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 this process: 1. 2. 3. Understand the potential management, financial and operational overheads associated with the design and deployment of a multiple domain Active Directory infrastructure Determine whether the option to design and deploy a multiple domain infrastructure for the forest is viable or not If the option of a multiple domain forest is not viable, then the logical extensions to this conclusion will hence be: a. The single domain for the forest will be the forest root domain for the forest and hence a 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 boundaries and content of the forests”. 4. If the option of a multiple domain forest is viable, then determine the requirement to use either a dedicated (placeholder) domain or a dual-function domain for the forest root domain of the forest. Where it is possible to identify the requirement for a dual-function domain, as the forest root domain, then the process to “design the forest root domain” executed later in the forest plan will identify this domain. Determine the actual number of domains required (at the time of design of the Active Directory infrastructure) for the forest based upon the considerations presented within this process.

5.

6.

2.4.

Process Components Based upon the above approach, this process is composed of the following three components: • 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 Components This 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

Page 7 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved. 2.6.

Inter-Component Dependencies Each 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
Determination of the viability of a multiple domain forest Determination of the requirements for a dedicated or dualfunction forest root domain

Determination of the number of domains required for this forest
© 2 0 0 4 MU ST AN SHI
R

BHAR

MAL

Page 8 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved. 2.7.

Process to Determine the Number of Domains Required
Forest Plan – Process to Determine the Number of Domains Required – PART 1
Is there compliance with any of the overheads discussed? NO Answer each of these questions to determine the requirements for a dual-function or dedicated forest root domain Are the potential implications acceptable? Evaluate and discuss the potential implications of the manifestation of these overheads NO

START

Execute B1-B3

YES

This forest will required a single domain Execute process “determination of the size of the Active Directory database for the forest”

Execute A1-A4 NO

YES

END
Is a dedicated forest root domain required? YES Document the justifications for the design and implementation of a dedicated forest root domain

Is there a requirement to restrict membership to the “Domain Admins” group? YES

Have all questions been answered?

YES

NO

Go To Part 2

Is there a requirement to retain control over forest-wide changes?

Consider the creation of a dedicated forest root domain for this forest YES YES Is there a requirement to ensure the continuity of a forest? NO YES

NO

Is there a requirement to create a minimal replication footprint or a forest root domain?

NO

NO Consider the creation of a dual-function forest root domain for this forest

© 2 004 MUSTAN SH I

R

BHARMAL

Page 9 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Forest Plan – Process to Determine the Number of Domains Required – PART 2
Is there a requirement for service autonomy? Is there a requirement to control AD replication traffic? NO YES YES Determine the minimum number of domains required to support requirements for service autonomy Execute A8 & A9

From Part 1

Execute B4-B6

Execute A5 & A6

NO

Execute A7

YES

Determine the minimum number of domains required to effectively partition the large number of required directory objects

Determine the minimum number of domains required to support requirements to partition replication traffic

Execute A11

NO

Is there a requirement to create more than 2 million directory objects within the forest?

Execute A10

NO

Is there a requirement to use an SMTP-only WAN link? YES

Is there a requirement to preserve the structure of a legacy multiple domain infrastructure?

NO

Determine the minimum number of domains required to support use of SMTP over IP InterSite Link

YES Determine the minimum number of domains required to preserve the structure of a legacy domain infrastructure Determine the total number of domains required for this domain, and document the justifications to support each required domain Execute process “design of the structure and relationships of multiple domains”

END
© 2004 MUSTANSHI R BHARMAL

2.8.

Process Considerations Consider the following information when executing this process to determine the number of domains required for the forest. Presented within the following three sections are the considerations for this process: 1. 2. 3. Considerations for the determination of the viability of a multiple domain infrastructure (within the forest for the organisation) Considerations for the determination of the requirements for a dedicated or dual function forest root domain 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 an organisation to proceed with the design and deployment of a multiple domain infrastructure for the 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 associated with 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:

Page 10 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Every domain the forest owner(s) design and implement is associated with a significant management overhead. For example, there will be a management overhead associated with the following:  The management of all domain-level components of the Active Directory for each required domain within each forest, such as the security infrastructure, object management and so on.  The requirements to manage multiple inter-domain trust relationships for crossdomain resource access. It is possible to create these trust-relationships between domains 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 be responsible 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 the performance 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 and coordination of Active Directory management tasks may potentially lead to the discontinuity of business operations.  An organisation with a (geographically) widely distributed multiple domain infrastructure may notice divergence of the Global Catalog for the forest within each physical location of the organisation. Inter-Site replication latencies associated with the replication overheads of multiple domains within the forest may contribute to Global Catalog divergence. • Factor B2: Understanding the financial overheads of multiple domains ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the financial overheads associated with 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: Each required domain within a forest is associated with financial overheads that require consideration. Although it is possible to identify a few financial overheads associated with a multiple domain forest, shared across each required domain, it is possible to identify financial overheads unique to each required domain. For example, each required 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 domain controllers for redundancy.  Based upon the boundary and content of a domain may increase the financial overheads associated with the domain. For example, where a domain requires representation across multiple geographical locations, with low available bandwidth inter-location network links, then each remote location may require a local domain controller, 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 domain controllers, and so on

Page 11 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 These factors hence increase the total cost of ownership for each domain. • Factor B3: Understanding the operational overheads of multiple domains ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the operational overheads associated with 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: Each additional domain within an Active Directory forest contributes to operational overheads associated with the forest. For example:  All domain controllers for a domain contain a full replica of every object and attribute held within the Domain partition of their domain. Hence, any changes to any object held within the Domain partition will require replication to all the domain controllers for that domain. The design and implementation of multiple domains within an organisation may hence have a measurable impact on the network utilisation from Active Directory replication traffic, and especially across low-bandwidth wide area network links. As a result, the quality of service may deteriorate from the heavily utilised network infrastructure unless the design of this infrastructure serves to partition 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 the organisation. Hence, the smaller the ratio of domains to objects within an organisation, the better the domain infrastructure is able to withstand organisation re-structuring exercises. 2.8.2. Determination of the Requirements for a Dedicated or Dual-Function Forest Root Domain Consider the following when determining the requirements for the design and use of a dedicated (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 ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the requirements to control membership of the “Domain Admins” group, in the forest root domain. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The design of Windows Server 2003 Active Directory permits member security principals within the “Domain Admins” group in the forest root domain, the ability to access 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, especially where the forest is required to support multiple domains. For this reason, the domain is not a security boundary for data and services within a forest. The creation of a dedicated (empty) forest root domain, not required to support normal users within the organisation, provides the ability to control membership to the “Domain Admins” 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 the following criteria, then the forest owner(s) should consider the design and use of a dedicated forest root domain:

Page 12 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 It is possible to identify a decentralised administration model for the forest, and untrusted administrators of domains within the forest  It is possible to identify un-trusted administrators (employees or non-employees of the organisation) within a centralised administration model for the forest  The organisation requires the enforcement of a strict security policy for the Active Directory infrastructure, influenced and regulated by business continuity requirements of the organisation. This design methodology recommends the use of the “restricted group” policy setting within a Group Policy Object (GPO), applied at the domain level for the forest root domain, to control and monitor the membership of this group. Using the above information, execute an analysis to determine the requirement to restrict membership to the “Domain Admins” group in the forest root domain, without the requirement for the design of an extensive delegation of control infrastructure for each required ORMI within a domain. If it is possible to identify this requirement, then consider the creation of a dedicated forest root domain for this forest. • Factor A2: Requirement to retain operational control over forest-level components of the Active Directory infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor 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-level components ♦ 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 retain control over the management of forest-level components. All domains within the forest depend upon the continuity of the forest. Hence, the business continuity of all autonomous divisions and non-autonomous divisional structures within the organisation, represented within these domains are also dependent upon the continuity of the forest. The most important aspect of the forest, managed only at the forest-level, and with a scope of impact of the entire forest, is the Active Directory Schema. Rights to manage and modify the Schema are restricted to members of the Schema Admins security group in the forest root domain. Another aspect of forest management is control over the creation of new domains within the forest. Only member security principals of the “Domain Admins” or the “Enterprise Admins” security groups in the forest root domain have the right to create new domains and new domain trees within a forest. It is hence possible to create a dedicated (placeholder) forest root domain to provide the foundation of the centralised control and execution of all management tasks that may 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 factor where an organisation:

Page 13 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Has a WAN infrastructure that will support a geographically distributed Active Directory infrastructure, and  Wishes to consider the requirements to generate a minimal replication footprint for the forest root domain via the creation of a dedicated forest root domain ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The continuity of the forest is directly dependent upon the continued presence of at least one domain controller representing the forest root domain. The creation of multiple domain controllers to support the forest root domain may provide fault tolerance for this domain, where hardware or software failures may temporarily bring down one or more domain controllers. However, this strategy of multiple domain controllers for the forest root domain does not protect the forest where all domain controllers are in the same physical location, as a site-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 multiple locations. However, although this will protect the forest against a site-specific disaster, this has added overheads to support replication between the forest root domain controllers. A dual-function forest root domain, supporting many hundreds or thousands of directory objects, will have a significant inter-Site replication footprint, which may influence the levels of available network bandwidth on inter-Site WAN links. Hence, the creation of a dedicated placeholder domain, to serve as the forest root domain, may support a minimal replication footprint because such domains usually do not hold many objects (additional to the default set of objects). Hence, the replication of this small domain across high-latency, low-bandwidth WAN links can provide protection against geographic location specific disasters and hence assist in the maintenance of the continuity of the forest. Note that it is also necessary to distribute domain controllers that represent the forest root 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 to go through a domain controller for the forest root domain, unless a short-cut trust to the destination domain is present. • Factor A4: The requirement to ensure the business continuity dependent upon the forest ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation has:  Identified that any disruption to the normal operation of the Active Directory infrastructure via the temporary or total absence or failure of the forest root domain may have a serious impact on the continuity of operations and processes within the organisation, and  Identified that there are / may be plans within the organisation to execute internal restructuring exercises or a merger with / acquisition of another organisation ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation:

Page 14 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

The design and implementation of a dedicated placeholder domain for the forest root can ensure the continuity of the Active Directory infrastructure. The creation of domains within an organisation, to reflect aspects of the business model and structure of the organisation, may jeopardise the existence of these domains, following business reorganisations, mergers, and acquisitions. However, a dedicated placeholder domain provides protection against redundancy since its role within the organisation is critical to the operation of the entire Active Directory 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 to support. Presented within the following two sections are the considerations for the execution of this step within this process: 1. 2. 2.8.3.1. Considerations for the factors no longer influential the determination of the number of domains required for a Windows Server 2003 forest Considerations for the factors influential in the determination of the number of domains required for a Windows Server 2003 forest Non-Influential Factors in the Determination of the Number of Domains Required Within organisations with an existing Windows NT 4.0 multiple domain infrastructure, the considerations employed to influence the design for the current domain infrastructure may no longer apply. The technical differences in capabilities and operation between Windows NT 4.0 and Windows Server 2003 invalidate many of the earlier justifications for a multiple domain environment. 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 Active Directory infrastructure, where appropriate) are discussed within this step to ensure their discount from considerations in determination of the number of domains required. • Factor B4: The maximum size of a SAM database ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation, with a legacy Windows NT 4.0 domain infrastructure, would consider the creation of a new domain upon identification of compliance with the maximum limit on the size of the SAM (Security Accounts Manager) database. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The Microsoft Knowledge Base article (KB130914) provides the details of how the SAM database for a Windows NT 4.0 domain realistically, can only grow to a maximum of 40Mb in size. In order to reduce the potential size of the SAM database, many Windows NT 4.0 administrators typically opted for a Master Domain, or Multiple Master Domain model. These models involved the creation of Windows NT 4.0 Resource Domains that held only 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).

Page 15 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

An indexed sequential access method (ISAM) table manager provides the foundation of a Windows Server 2003 Active Directory database. This database is a version of the Extensible Storage Engine (ESE) database that has a theoretical maximum size limit of 16 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 database can hold. However, the disk and memory capacity of the Windows Server 2003 Active Directory domain controllers does influence the maximum number of users accounts that a single Active Directory database can hold. A typical large sized organisation may hence realistically create a single Windows Server 2003 Active Directory domain to support over a few hundred thousand objects. • Factor B5: The requirement to delegate administrative control within the organisation ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation, with a legacy Windows NT 4.0 domain infrastructure, would consider the creation of a new domain to allow the delegation of control over organisation resources, without compromising the security of the Domain Admins group of a domain. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Windows NT 4.0 does not provide the ability to delegate control over domain resources to standard user accounts, unless those accounts are members of the built in administration groups, such as the Domain Admins user group. Hence, the only method to allow a hybrid administration model (centralised and decentralised) in Windows NT 4.0 was to create multiple domains, as the domain was the most granular administrative unit available. Windows Server 2003 Active Directory allows the assignment of permissions over domain objects to standard domain user accounts (this process is termed delegation of control). This hence negates the requirement for the creation of multiple domains for this purpose. See the Domain Plan process “Design for Delegation of Control Infrastructure” for details. • Factor B6: Requirements for unique user account security options ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation, with a legacy Windows 2000 Active Directory domain infrastructure, would consider the creation of a new domain to permit the use of unique security options for user accounts. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: In Windows 2000 Active Directory, it was only possible to apply the required security options 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 multiple GPOs, which contain these security policy settings for user accounts, and implement them at any OU level within a domain. This hence supports the requirements for unique security options for user accounts by autonomous divisions represented within an Active Directory domain as an OU, and hence negates the requirements for multiple domains to support this requirement.

Page 16 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

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 factor where an organisation wishes to establish service autonomy within the organisation via the implementation of multiple domains within a forest. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: An organisation may agree to allow a forest owner to determine forest-wide configuration, but still require domain-level service autonomy. Where it is possible to identify the requirement for autonomy to perform and manage any one of the following elements of domain management by a domain owner, then this may 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 the domain name of “xyz.abc.com” would have the default UPN suffix of “@xyz.abc.com”. However, the users within the domain “xyz” may have e-mail address suffixes of “@xyz.com”, and hence, the domain owner can create a UPN for the domain of “@xyz.com”. The users can hence log on to the domain with their email addresses and user account password. It is possible to define multiple UPNs at the 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 service availability. 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 domains within the forest. Hence, it is important to assure the network and physical security of 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 may be many divisions and departments (and even sub-companies), issues may arise surrounding the ownership of, and responsibility for domains, domain management tasks and the data within these divisions that is controlled (authentication and authorisation) by these domains. These may be resolved by allowing the discrete divisions or department ownership and responsibility of their own domain within a forest in the organisation.  External trust-relationships: The domain owner can determine which domains in other forests to trust via the creation of external (non-transient) trust relationships.  Compliance with international differences: A local domain owner can manage the compliance of the domain with the local legal, security, financial and business practice policies of an organisation that has an international presence. • Factor A6: The requirement to disallow service autonomy within a forest ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation does not wish to relinquish control of objects that fall within the boundary of a forest or domain within a forest. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation:

Page 17 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

The owner(s) of the forest may wish to prevent autonomous divisions within the organisation from gaining service autonomy via the creation of discrete domains. For example, the owner(s) for the forest may wish to ensure compliance with highpriority security policies. Delegation of service autonomy may imply the provision of control 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, for example, due to a history of undisciplined management, and hence wish to prevent a forest-wide disaster via the physical compromise of a domain controller for a non-root domain. The compromise of any domain controller within the forest by a malicious attacker, due to the lax physical security infrastructure for an autonomous division, may compromise the integrity and operation of the entire forest. It is also important to note that a single Windows Server 2003 domain may represent and support multiple autonomous divisions, via the design and implementation of discrete object and resource management infrastructures (ORMIs). See the Domain Plan 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 multiple discrete domains. • Factor A7: The requirement to control Active Directory replication and network utilisation ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the impact of a multiple domain Active Directory replication topology on the LAN infrastructure of the organisation. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The majority of network traffic caused by Active Directory replication derives from intradomain replication between domain controllers of a domain. The level of daily network traffic caused by the replication of the forest Schema and Configuration partitions to all domain controllers within a forest is minimal since these partition receive very few and infrequent changes. The partitioning of the forest into multiple domains, on a well-planned network infrastructure, can isolate the network traffic. However, it is important to note the following points:  All domain controllers, whether in a single or multiple domain forest, must be present on the production network for the organisation, and hence must be able to communicate with each other. A domain controller within a forest cannot function without errors whilst in network incommunicado.  It may be possible to identify a network infrastructure and TCP/IP architecture for the organisation where all domain controllers for multiple domains may reside, for example, on the same subnet and LAN. This may occur where the network architect failed to provide consideration to the design of segregated, routed, subnetted, and virtual LANs and so on, then. In this scenario, network utilisation caused by Active Directory replication will increase substantially, and hence it will not be possible to note any improvements from the partitioning of a forest in to multiple domains, from the 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 ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation has:

Page 18 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 A WAN infrastructure with inter-location network links that cannot support the synchronous replication transport protocol (RPC over IP) but can only support the asynchronous transport protocol (SMTP over IP)  Users and computers within the terminus locations of these network links that require representation within, and support by, the forest ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: For inter-Site replication, it is only possible to use the SMTP over IP inter-Site replication transport protocol to replicate inter-domain and non-domain naming contexts. This replication transport protocol cannot support intra-domain replication traffic. Hence, there may be the requirement to establish a separate domain where it is possible to identify the criterion for this factor. It is important to note that the use of an SMPT over IP Site Link requires the installation and configuration of an Enterprise Certificate Authority to issue the source and destination domain controllers with X.509 certificates. The domain controllers will employ these encryption keys, within these certificates, to encrypt data transmitted between 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 replication transport protocols, and  Wishes to understand the impact of these restrictions on the determination of the number of domains required for a forest ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: An organisation may be required to employ the SMPT over IP replication transport protocol for inter-Site replication where it is possible to identify compliance with the following criteria:  The organisation has two or more physical locations, which are potential Active Directory 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 Site and 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 and 139 Where it is possible to identify all of the above criteria for the application of the factor within an organisation, then the Site Link(s) that connect the Sites via a RPC over IP port restricted firewall may have to use as the transport protocol (assuming the firewall restrictions will permit port 25 traffic). The same considerations as for the previous factor that would require the use of SMTP over IP as the transport protocol for a Site Link will apply for this factor

Page 19 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved. • Factor A10: The requirement to comply with the capacity limits of an Active Directory domain ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation has identified the requirement to populate the Active Directory infrastructure with an excess of one or two million objects. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Although an Active Directory database (NTDS.dit), via its structure and design, can theoretically grow to 16Tb in size (and hence hold approximately 16,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 this size within a “typical” backup window. One may question the likelihood of an organisation populating a production Active Directory domain with between one and two million user accounts. However, note that this 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 Active Directory is an object and hence represented within the Active Directory database with a 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 hundreds of thousands of shared folder objects to an Active Directory. The use of Distributed Link Tracking, although disabled y default in t Windows Server 2003 Active Directory, may also populate an Active Directory domain partition with many objects. Consideration must be taken primarily towards the impact on the network from the replication of changes to these objects; the impact on the storage and memory requirements of the domain controllers that will host this Active Directory; and the consequences of database divergence. With so many objects hosted within a multimaster replication model, even if regular changes were made to only a small percentage of these objects, this may represent a vast number of changes that have to be replicated to all domain controllers for this domain. For example, domain controllers supporting a production domain with one to two million object may never reach convergence, where 10 percent change per working day is expected. Ten percent of two million objects equate to 200,000 changes every working day, 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 all the domain controllers for this domain becomes very low. Although this scenario will have a low incidence of application within the majority of organisations wishing to design and deploy and Active Directory infrastructure, it is not an impossible scenario. Hence, where an organisation may potentially populate an Active Directory infrastructure with millions of objects, this design methodology recommends the creation of one or more new domains to hold the new objects. It is possible to segregate the objects into domains using categories such as security principals and non-security principals, and object types. This categorisation of objects can assist in the determination of the number of domains required to support a large number 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 ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:

Page 20 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Has identified the presence of a multiple domain Windows NT 4.0 and / or Windows 2000 domain infrastructure, and  Wishes to consider the requirements to preserve the design for the existing multiple domain infrastructure ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: It is possible to assign legacy domain infrastructures within an organisation, hosting two or more domains, to one of the following example categories:  The current design for the legacy domain infrastructure is a result of careful planning guided 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 planning guided 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 planning guided by the requirements to comply with business and technical requirements. However, it is now possible to identify that the original business and technical requirements supporting the existence of one or more of the existing domains are no longer valid, and hence these domains are potentially redundant.  The current design for the legacy domain infrastructure does not reflect any careful planning for compliance with business and technical requirements. The domain infrastructure has superfluous, redundant, and inefficient qualities, manifested at the domain level.  The current design for the legacy domain infrastructure, although initially planned with care to support compliance with business and technical requirements, grew “organically” and outside of the control of the IT function within the organisation. The “organic” growth is a reflection of mergers, acquisitions, pending spin-offs, and so on. The current design for the domain infrastructure within the organisation has superfluous, redundant, and inefficient qualities, manifested at the domain level. From these above example categories, of which it is possible to define many more, only compliance with the first category supports the exact retention of the current domain infrastructure. This is a rare occurrence within the majority of organisations. Windows Server 2003 Active Directory provides greater opportunities for the consolidation of multiple domain infrastructures that will reap the following example benefits to an organisation:  The reduction in the administrative overheads associated with the management of a multiple domain infrastructure  The reduction in the financial overheads for the management and maintenance of multiple domain controller servers for each domain within the organisation, and hence a total cost of ownership saving associated with the provision of a directory service infrastructure for the organisation. Where an organisation is adamant that it does not wish to consider consolidation or restructuring exercises, then it may be possible to validate the requirement to implement a multiple domain infrastructure to meet this requirement for the organisation.

Page 21 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

3.

Design of the Structure and Relationships of Multiple Domains
Execute this process where it is possible to identify the requirement to create multiple domains 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 Information Where an organisation has identified the requirement for a multiple domain forest, then the next step in the creation of a forest plan is to determine the structure and relationships of these multiple domains within the forest. This process will provide examples of the factors that can influence the structure and relationships 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 to the final structure and relationships for the multiple domains of the forest. This design methodology recognises a number of approaches to support the logical arrangement of multiple domains within a forest. However, the structure must adhere to the rule that each child domain can have only exactly one parent domain. Determination of the structure and relationships of the domains within the forest permits assignment of the distinguished names for the domains. The process “Design of a DNS Infrastructure”, executed as a component of the “Organisation-wide Active Directory Plan”, will build 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 the required structure and relationships for the domains within the forest: 1. 2. Consider all factors that will influence the design of the structure and relationships of multiple domains within a forest Determine the applicable factors and hence the required structure and relationships for the domains

3.3.

Process Components Based upon the above approach, design the structure and relationships of multiple domains within a forest is composed of the following components: • Understand all factors influential to the design of the structure and relationships of multiple domains within a forest • Determine the required structure and relationships for the domains

3.4.

Deliverables of Process Components This 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

Page 22 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved. 3.5.

Inter-Component Dependencies Each 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
Understand factors influential to the design of the structure & relationships of multiple domains Determine the required design for the structure and relationships of multiple domains
© 2 0 0 4 MU ST AN SHI
R

BHAR

MAL

3.6.

Process to Design the Structure and Relationships of the Domains Forest Plan – Process to Design the Structure and Relationships of Multiple Domains
Is there a requirement to implement specific domain namespaces within this forest? NO Is there a requirement to limit the maximum depth of a domain hierarchy? Execute A2 Determine the number of domain trees that require creation within this forest YES YES Determine the maximum required depth for a domain hierarchy NO Is there a requirement to support searches within multiple domains using a single query?

START

Execute A1

YES

Determine the design requirements for the domain hierarchy to support this requirement

Execute A3

NO

Execute A4

YES

Is there a requirement to preserve a legacy domain structure via in-place upgrades?

Execute A5

NO

Is there a requirement to facilitate regular intra-forest resource access?

Determine the details for all requirements to support intra-forest resource access

NO

Determine the details for all requirements to support intra-forest resource access

YES

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

END
© 2 0 0 4 MU S TA NSH I
R

BHAR

MAL

3.7.

Process Considerations Consider the following information when determining the required design for the structure and relationships of multiple domains within a forest:

Page 23 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved. • Factor A1: The requirement to implement specific domain namespace(s) ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to consider the requirements to implement two or more domain namespaces within the forest. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: As defined earlier, a forest is a virtual entity supporting one or more domains, logically grouped together, and sharing a common Schema and Configuration partition, a common Global Catalog, and a common replication topology. A forest does not restrict the number of domain namespaces possible for creation within the forest. Hence, if for example, a forest has ten domains, there could be ten distinct domain namespaces within the forest, and the only relationships the domains have to each other is their presence within the boundary of the forest-level components. Where an organisation has several sub-divisions, major departments, sub-companies and 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 the boundaries for service autonomy between the divisions, departments, sub-companies, and so on. For example, an organisation (“Natsum”) requires a single forest to support itself and three sub-companies, each represented as discrete domain within the organisation’s single forest. The organisation (as a whole) will have one administration domain, and the forest will have a dedicated forest root domain called “Root.Natsum.com”. The organisation has hence decided to arrange and hence name these domains as “Root.Natusm.com” and “Admin.Root.Natsum.com”. The names of the sub-companies are MAB1, MAB2, and MAB3 respectively. Each sub-company has two domains and will arrange and hence name them as “MAB<n>.com” and “ChildA.MAB<n>.com”. Using these four (including the organisation’s domains) domain namespaces, the service autonomy boundaries are clearly defined within the forest. The following diagram illustrates this example:
Forest Root Domain Tree Root Domains

Root. Natsum. com

Admin.Root. Natsum. com

MAB1.com

MAB2.com

MAB3.com

ChildA. MAB1.com

ChildA. MAB2.com

ChildA. MAB3.com
© 2 0 0 4 MU S TAN SH I
R

BHARMAL

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 with the following criteria:  The organisation has identified the requirement to implement a specific domain namespace(s) that will influence the distinguished names of the domains within the forest in order to:

Page 24 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Distinguish a domain / set of domains within a forest (via a tree structure)  Distinguish a domain / set of domains between multiple forests within the organisation  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 UPN suffixes to represent discrete namespaces within the forest. Note that it is possible to elevate the earlier example to the forest level where subcompanies of an organisation enforce autonomy or isolation at the forest level via the implementation of multiple forests within the organisation. The domain namespaces for the forest root domains or sub-domains within each forest could hence reflect the autonomy or isolation requirements for these sub-companies. Note that the structure and relationships of multiple domains within a forest influences the Fully Qualified Domain Name (FQDN) of a computer account object. To allow different primary DNS suffixes, a domain administrator may create a restricted list of allowed suffixes by creating the msDS-AllowedDNSSuffixes attribute in the domain object container. It is possible for the domain administrator to create and manage this attribute via Active Directory Service Interfaces (ADSI) or the Lightweight Directory Access Protocol (LDAP). • Factor A2: Requirement to control the maximum depth of a domain hierarchy ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the influence of compliance with technical requirements, to control the maximum depth of a domain hierarchy, on the design for the structure and relationships of domains within the forest. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The domain namespace forms a component of the distinguished names of objects within a domain. For example, within a domain with a distinguished name of “ChildB.ChildA.MAB2.com”, a computer account object called “MAB2APPSERVER2” would 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 the fully qualified domain name (FQDN). This hence places a technical limit on the maximum depth for a domain hierarchy, based upon the length of the names of the domains within the hierarchy and the length of the computer account names within the domains. This design methodology hence recommends a limit on the depth of a domains hierarchy be established at between three and four domains deep (depending upon the length of the individual domain names). Note that the deeper a domain hierarchy becomes, then the sooner the limit on the FQDN 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 ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the influence of the arrangement of multiple domains within a forest using multiple domain namespace hierarchies on the execution of searches and LDAP referrals within the forest.

Page 25 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: If a user within a domain wishes to search for an object within the forest and does not know the location or the distinguished name for this object, the user can instigate an LDAP search for this object. If the domain in which this user resides is within a hierarchy of domains (a tree) within the forest, and the object she is searching for resides within a domain within this hierarchy, then the search she instigates will find that object very quickly. This is because the domain hierarchy of Windows Server 2003 Active Directory allows a search to be instigated in multiple domains in one query, as each level of the hierarchy has information about the levels immediately above it and below it. This hierarchy information eliminates the need for the knowledge of the location of a particular object in order to find it. In Windows NT 4.0 and earlier, a user must know both 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 ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the influence of the requirement to facilitate intra-forest name resolution and authentication via the design for the structure and relationships of multiple domains within a forest. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When determining the influence of requirements to facilitate frequent requests for intraforest name resolution and authentication on the design for the structure and relationships of domains within a forest, consider the following:  Depending upon the distinguished name assigned to a domain name at the time of creation, each domain within a forest trusts, via bi-directional transitive trust relationships, either a parent or the forest root domain.  This bi-directional transitive trust relationship model supports intra-forest resource access by security principals with the appropriate permissions within the domain controlling a resource.  The domain hierarchy generates a trust path. Where a trust-path is greater than three or four domain “hops” long, each instance of a request for resource access within a destination domain generates Kerberos referrals across each intermediate domain. This can hence increase the time taken to access the resource in the destination domain and increase the workload on the domain controllers in the intermediate domains, especially where this is a frequent occurrence.  This design methodology proposes the following two potential solutions to this scenario:  The first solution requires the creation of domain hierarchies of shorter depth to minimise the length of trust-paths between domains, which commonly participate in inter-domain resource access activities.

Page 26 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 The second solution requires the creation of inter-domain and intra-forest “shortcut” trust relationships between domains within the forest, to decrease the length of a trust-path.  Where possible, in these early stages of the design of the structure and relationships of multiple domains within a forest, this design methodology recommends the execution of the first solution. This hence requires consideration of the potential trust-path lengths between domains within a forest, based upon the identification of those domains within the forest that may support frequent interdomain resource access.  Although the design and implementation of “short-cut” trust relationships can reduce the trust-path, this design methodology does not recommend their use to compensate for a poor design for the structure and relationships of multiple domains within a forest. Note also that for each “short-cut” trust relationship designed, it is necessary to consider the associated management overheads. (See the process “design of short-cut trust-relationships” for details of the considerations for the design of “short-cut” trusts.). • Factor A5: Requirement to preserve a legacy domain structure and relationship via inplace upgrades ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to consider the influence on the requirements to preserve a legacy domain infrastructure on the design for the structure and relationships of multiple domains. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Although Windows NT 4.0 domain infrastructures do not employ DNS domain namespaces to define their structure and relationships, they do employ mono or bidirectional external trust relationships. The presence and direction of the trust relationships between Windows NT 4.0 domains defines the relationships between the domains. For example, a mono-directional trust relationship between an “account” and a “resource” domain, where the resource domain trusts the account domain, defines their relationship. Within legacy Windows 2000 Active Directory infrastructures, domain namespaces and internal bi-directional transitive trust relationships define the relationships between multiple domains in each forest, and between forests. Where the organisation wishes to preserve the current number and type of relationships between multiple legacy domains, then this will influence the design for the structure and relationships of these domains within the Windows Server 2003 Active Directory forest.

Page 27 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

4.

Design of Short-Cut Trust Relationships
“Short-cut” trust-relationships refer to trust relationships manually created between domains within a forest. The objective of this process is to assist an organisation in the determination of the requirement for the creation of short-cut trust-relationships between domains within a forest.

4.1.

Background Information Because all domains within a forest are automatically linked (along a trust-path) by bidirectional transitive trust-relationships, the only reason to manually create a short-cut trustrelationship between two domain in a forest is to improve authentication performance for interdomain resource access. All short-cut trust relationships are transitive and one-way only. Hence, for a bi-directional short-cut trust-relationship, there will be the requirement to create two one-way short-cut trustrelationships. Note that it is important to assess the management overheads associated with each short-cut trust-relationship created within a forest. Because these trust-relationships require manual creation, they will require monitoring and management, and the onus on execution of these activities may reside with the forest owner(s).

4.2.

Process Components The process to design short-cut trust-relationships between domains within a forest consists of the following components: • Determination of the requirements for the design of short-cut trust relationships • Determination of the number and direction of the required short-cut trust-relationship(s) (one-way or bi-directional) between the domains within the forest

4.3.

Deliverables of Process Components The process to design short-cut trust relationships will have the following deliverables: • Identification of the requirements for the design of one or more short-cut trust relationships between domains within the forest • Identification of the domains that will require a short-cut trust relationship between them • Identification of the number and direction of the trust-relationship(s) (one-way or bidirectional) between the domains within the forest

4.4.

Inter-Component Dependencies Each component of this process will have the following inter-component dependencies:
Forest Plan – Inter-Component Dependencies for Process to Design Short-Cut Trust Relationships START
Determine the requirements for the design of short-cut trust relationships Determine the number and direction of required short-cut trust relationships
© 2 0 0 4 MU ST AN SHI
R

BHAR

MAL

Page 28 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved. 4.5.

Process to Design Short-Cut Trust-Relationships Forest Plan – Process to Design the Short-Cut Trust Relationships
Is there compliance with the criteria for the design of short-cut trusts? YES Execute A2 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
© 2 0 0 4 MU S TAN SH I
R

START

Execute A1

NO

END

BHARMAL

4.6.

Process Consideration Consider the following when generating the design for short-cut trust relationships between domains within the forest: • Factor A1: Determination of the requirements for short-cut trust relationships ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the requirements for the design of one or more short-cut trust relationships between domains within the forest. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The default inter-domain transitive trust relationships within a forest support the majority of inter-domain resource access requirements, without significant performance issues. This design methodology hence recommends the design and implementation of shortcut trust relationships only where it is possible to identify compliance with all of the following criteria:  The forest supports multiple domains (more than five or six)  It is possible to identify two or more domains within the forest that require regular access to resources between themselves, either one-way or two-way  The domains that have inter-domain resource access requirements are logically separated by more than three or four domain hops along the default trust-path  Two or more domains may utilise any short-cut trusts, due to their transitive nature  The number of hops on this trust-path is causing a noticeable and measurable degradation in authentication performance for inter-domain resource access because:  The domain controllers for one or more domains along the default trust path are located in different geographical locations to the source and destination domains, and separated by low bandwidth WAN links / multiple WAN link hops  The bridgehead domain controllers for one or more domains along the default trust path are heavily over utilised, with respect to server hardware resources, and hence offer degraded response times to LDAP referrals

Page 29 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

If it is not possible to identify compliance with all of the above criteria, then this design methodology recommends against the design and implementation of short-cut trust relationships. However, where it is possible to identify compliance with all of the above criteria, then it is necessary to determine the following:  The minimum number of short-cut trusts required, and the optimum location for implementation of the short-cut trust(s) within the forest  The direction of each required short-cut trust relationship • Factor A2: Determination of the design requirements for the required short-cut trust relationships ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement to implement one or more short-cut trustrelationships within the forest, and  Wishes to determine the design requirements for the short-cut trust relationships ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When determining the design requirements for short-cut trust relationships, consider the following. When determining the minimum number of short-cut trusts required, and the optimum location for their implementation within the forest, consider the following:  Short-cut trust relationships are transitive, in the direction of the trust. Hence, multiple domains may use a short-cut trust relationship, and its use is not restricted to the domain hosting the trust.  Hence, when determining the requirements for short-cut trust relationships, the minimum number should be employed, as they will be shared by domains (where necessary) in close trust-path-proximity to the short-cut trust.  This design methodology proposes execution of the following approach to determine the minimum number of short-cut trusts required, and the domains within the forest to host the trust relationships:  Identify all “resource” domains that host resources to which security principals in other “account” domains in the forest require frequent access  Generate a mapping of each identified “account” domain to one or more “resource” domains within the forest  Identify the number of hops in the trust paths between each “resource” and “account” domain mapping  Identify any trust path routes (between the account domain to resource domain trust paths) common to multiple mappings of account and resource domains  Identify any domains and their domain controllers that the trust path created by the short-cut trust relationship(s) must avoid, where possible. For example, domains with domain controllers in remote geographical locations separated by multiple WAN link hops and low bandwidth links, and so on.

Page 30 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Identify all viable and desired trust paths that will support all required account and resource domain mappings based upon the paths which provide the least number of hops for all mappings  Determine the minimum number of short cuts trusts required to implement the desired trust path(s), and the domains where the trusts require implementation. Note that these may not necessarily be the actual “resource” and “account” domains. It is logical to employ other domains that bridge the desired trust-paths, common to multiple resource-account domain mappings, due to the transitive nature of the short-cut trusts.  This design methodology provides the following example of the execution of this approach to design short-cut trusts within a forest:  An organisation has a single forest supporting sixteen domains and three DNS namespaces, represented as the forest root domain (A1.com) and two domain tree hierarchies (B1.com and C1.com). The following diagram illustrates this forest infrastructure:

B1.com

A1.com

C1.com

1.B1.com

2.B1.com

7.C1.com

8.C1.com

3.1.B1.com

4.2.B1.com

9.7.C1.com

10.7.C1.com

11.8.C1.com

5.3.1.B1. com

6.4.2.B1. com

12.10.7.C1. com

13.10.7.C1. com

© 2004 MUSTANSHI BHARMAL

R

Figure 11.1: Sample Forest Infrastructure for Short-Cut Trusts  The organisation has identified that “resource” domains “8.C1.com” and “11.8.C1.com” contain resources which security principals in “account” domains “1.B1.com”, “3.1.B1.com”, “5.3.1.B1.com”, “2.B1.com”, “4.2.B1.com”, and “6.4.2.B1.com” require frequent access.  The required account-resource domain mappings, and the number of hops across the default trust paths between the account and resource domains are illustrated in the following table:
“Account” Domains “Resource” Domains & Hops using Default Trust Paths 8.C1.com 1.B1.com 3.1.B1.com 5.3.1.B1.com 2.B1.com 4.2.B1.com 6.4.2.B1.com 11.8.C1.com

 (4)  (5)  (6)  (4)   (6)

   (7)  (5)  (6)  (7)

Page 31 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Table 11.1: Mapping of Account Domains to Resource Domains & Default Trust Path Hops between Account and Resource Domains  The organisation wishes to avoid inclusion of the forest and tree root domains within the trust paths, as the closest (in network proximity) domain controllers for these domains are only contactable by the account domains across multiple WAN link hops. These WAN links are associated with significant latencies.  The organisation has identified that all account domains on the “1.B1.com” domain hierarchy share the requirements to access the resource domain “8.C1.com”.  The organisation has identified that all account domains on the “2.B2.com” domain hierarchy share the requirements to access the resource domain “11.8.C1.com”.  The organisation has identified that three account domains require access to both identified resource domains.  Using this information, the organisation decides to create two short-cut trust relationships, as depicted in the following diagram:
Short-Cut Trusts
B1.com A1.com C1.com

1.B1.com

2.B1.com

7.C1.com

8.C1.com

3.1.B1.com

4.2.B1.com

9.7.C1.com

10.7.C1.com

11.8.C1.com

5.3.1.B1. com

6.4.2.B1. com

12.10.7.C1. com

13.10.7.C1. com

© 2004 MUSTANSHI BHARMAL

R

Figure 11.2: Sample Short Cut Trusts for Example Forest  The short-cut trust between account domain “4.2.B1.com” and resource domain “8.C1.com” links all account domains in the “2.B1.com” domain hierarchy with both resource domains  The short-cut trust between account domain “3.1.B1.com” and resource domain “8.C1.com” links all account domains in the “1.B1.com” domain hierarchy with both resource domains  Note that the short-cut trust for the “2.B1.com” domain hierarchy links the account domain “4.2.B1.com” and resource domain “8.C1.com” even though this account domain has no requirements to access resources in this resource domain. The point of implementation of this trust is hence a reflection of the most logical location, which serves multiple inter-domain access requirements.  Following implementation of these short-cut trusts, within this example scenario, it is possible to identify significant improvements in trust path hops between account and resource domains, as depicted within the following table:

Page 32 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

“Account” Domains

“Resource” Domains & Hops Using Default & Short-Cut Trust Paths 8.C1.com Hops with Default Trusts Hops with Short Cut Trusts 11.8.C1.com Hops with Default Trusts Hops with Short Cut Trusts

1.B1.com 3.1.B1.com 5.3.1.B1.com 2.B1.com 4.2.B1.com 6.4.2.B1.com

4 5 6 4 N/A 6

2 1 2 2 N/A 2

N/A N/A 7 5 6 7

N/A N/A 3 3 2 3

Table 11.2: Improvements in Trust Path Hops after Implementation of Short-Cut Trusts

Page 33 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

5.

Determination of the Boundaries and Content of Each Domain
Where an organisation has identified the requirement(s) to partition a forest into multiple domains, then it will be necessary to determine the boundaries and content of each domain within the forest. This information will facilitate their design and implementation within the organisation.

5.1.

Process Objectives The objective of this process is to determine the logical and physical boundary and content of each domain that requires creation within the forest. This information, once determined, is invaluable in assisting the execution of later processes in this Forest Plan, and in the Site, Domain, and Migration Plans for this design methodology. Documentation of the boundary and content of each required domain is invaluable to organisations contemplating the design and implementation of a significant number of domains, as it permits reinforcement of the scope of administrative, security, and replication boundaries.

5.2.

Process Objectives The objective of this process is to map the logical boundaries and contents of domains, as a reflection of the function and role within the organisation, to logical and physical aspects of the organisation.

5.3.

Background Information The boundary for a domain refers to the administrative, security, and replication boundary of a domain. As an administrative and security boundary, all permissions (such as object or attribute rights) flow down only to objects within the domain and never to other domains. As a replication boundary, only domain controllers that exclusively represent the domain will receive a full replica of the domain partition for the Active Directory database of the forest. The purpose, function, and role of the domain within the forest directly influence the administrative, security, and replication boundaries of a domain. This process will present the factors influential in the determination of the boundary of a domain, based upon its purpose, function, and role within the forest. Knowledge of the boundary, function, and purpose of each domain that requires creation, will assist in the identification of the distribution of objects between the multiple domains of a forest, and hence assist in determination of the contents of a domain. The content of a domain refers to the users and computers (grouped, for example, by department, division, geography, and so on) and all other objects (such as printer objects, Shared Folder objects, and so on) that will require representation, publication, and management within that domain. Where it is possible to identify the requirement to create a dedicated forest root domain, this process will provide examples of the factors, and their considerations, that will influence the determination of the boundary and content for this domain.

5.4.

Process Approach The results from the “Organisation-wide Active Directory Plan” process to “determine the boundaries and content of the forests” represents the starting point for this process, which will further sub-divide the boundary and content of the forest into the identified domain partitions. This design methodology proposes the following approach for the execution of this process: 1. Determine the intended function and role of each required domain within the forest

Page 34 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

2.

Identify all logical and physical aspects of an organisation that will: a. Require representation within each required domain, and b. Support the normal operation of each required domain within the production environment for the organisation

3. 5.5.

Determine the boundaries and content of each required domain, including a dedicated forest root domain (where required)

Process Components The process to determine the boundaries and content of each required domain is composed of the following components: • Determination of the intended function and role of each required domain • Identification of the logical and physical aspects of an organisation that will influence the boundary and contents of each required domain • Determination of the boundaries and content of each domain in the forest, including (where required) a dedicated forest root domain

5.6.

Deliverables of Process Components The process to determine the boundaries and content of each required domain will have the following deliverables: • The determination of the function and role of each required domain • The identification of the logical and physical aspects of an organisation that will influence the boundary and contents of each required domain • The identification of the boundaries and content of each required domain

5.7.

Inter-Component Dependencies Each component of this process will have the following inter-component dependencies:
Forest Plan – Inter-Component Dependencies for Process to Determine the Boundary and Content of Each Required Domain
Determine the function and role of each required domain

START

Determine the logical and physical representations of each required domain

Determine the boundary and content of each required domain

© 2004 MUSTANSHI

R

BHAR

MAL

Page 35 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved. 5.8.

Process to Determine the Boundaries and Content of Each Domain
Forest Plan – Process to Determine the Boundaries and Content of Each Domain START
Execute A1 – A7 Determine the boundary and content of each required domain based upon the functions and roles of the domains Execute B1 Execute A8 – A10

END

Generate the design for the boundary and contents of each required domain

Execute D1

Determine the boundary and content of each required domain based upon the logical and physical aspects of the organisation
© 2004 MUSTANSHI
R

BHAR

MAL

5.9.

Process Considerations Consider the following information when determining the boundaries and content of each required domain within the forest: Presented within the following three sections are the considerations for this process: 1. 2. 3. Considerations for the determination of the function and role of each required domain Considerations for the identification of the physical and logical aspects of the organisation that will influence the boundary and content of each required domain Considerations for the determination of the boundary and content of each required domain

5.9.1.

Determination of the Function and Role of Each Required Domain Consider the following when determining the function and role of each domain that requires creation within the forest: • Factor A1: Understanding the function and roles of domains ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the functions and roles of domains, and the influence of these metadata aspects of domains on their boundary and content. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology recognises the following examples of categories that describe the function of a domain:  A domain represents a boundary for the semi-autonomous administration of objects and resources represented within the domain, and controlled by the domain.  A domain represents a boundary for the security of objects and resources represented within the domain, and controlled by the domain.  A domain represents a boundary for replication of changes to objects represented within the domain  The name of a domain represents a component in the distinguished names (DNs) of objects represented within the domain, and within child domains, and in the UPNs for user account objects

Page 36 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 A domain may represent a placeholder for a forest or tree of domains The majority of these example categories provide the foundation for the creation of domains, as discussed in the earlier process “determination of the number of domains required”. It is possible to describe the role of a domain from the perspective of the objects and the business and technical requirements the domain supports. For example, a domain with a function to exclusively represent a forest, as a dedicated forest root domain, has a role to ensure the continuity of the forest. This domain can execute its intended role via abstraction from the typical functions of domains, to provide an administrative boundary for object and resource management. • Factor A2: Influence of requirements for service autonomy on boundary and content of domains ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for creation of one or more domains within the forest to support the function of domain-level service autonomy, and  Wishes to understand the influence of this requirement on the determination of the boundary and content of these domains ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The design and implementation of one or more domains within a forest, to support domain-level service autonomy, generates a logical administrative boundary within the forest, represented by the logical boundary of the domains. The creation of a domain to support domain-level service autonomy will define the scope of the management infrastructure that will support the domain. Hence, supporting domain creation for service autonomy hence implies the multiplication of an administration layer to allow the discrete management of a separate domain. The boundaries that represent departments, divisions and so on, within the organisation define the scope of each administration unit or layer. For example, an organisation and / or forest owner(s) permit the creation of a non-root domain to support service autonomy. A team of administrators will exclusively manage all aspects of that domain, and the objects and resources represented within the domain, and controlled by the domain. Departments A, B, C, and D within the organisation represent the exclusive scope of routine administration tasks of these administrators. Hence, all users, computers, and resources within these computers logically and exclusively aligned to these departments, will hence require representation within the domain. Hence, it is possible to deduce the following:  The boundary for this domain is represented by:  The scope of administration of the administrators required to support this domain  The logical boundaries of departments A, B, C, and D, which define the scope of administration of the administrators required to support this domain  The minimum contents of this domain is represented by the users, computers, and resources within these computers / controlled by these computers, which are exclusively aligned to departments A, B, C, and D

Page 37 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved. • Factor A3: Influence of requirements to partition a forest with more that two million objects on boundary and content of domains ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement to partition a forest with more than two million objects into multiple domains, and  Wishes to understand the influence of this requirement on the determination of the boundary and content of the domains ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The likelihood of an organisation populating an Active Directory with over two million live and active user account and computer account objects is quite rare. Hence, where an organisation may have over two million objects, then the majority of these objects are likely to be other types of objects, such as File Volume Share objects, and other custom objects. Hence, in this scenario, it is recommended (to facilitate object management) that all security principal objects be grouped into one domain, and all non-security principal objects are grouped into other domains, based upon their object type. The partitioning of the forest using object type will hence influence the determination of the logical boundary and the content of each domain. • Factor A4: Influence of requirements to preserve a legacy multiple domain infrastructure on the boundary and content of the domains ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement to port a legacy multiple domain infrastructure to a new Windows Server 2003 Active Directory forest, and  Wishes to understand the influence of this requirement on the determination of the boundary and content of the domains ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The execution of an in-place upgrade of a legacy domain infrastructure assumes the requirements to preserve the following:  The number of domains  The current function and roles of the domains  The current contents of the domains  The current logical and physical boundaries of the domains Where this assumption is invalid, then it is necessary to define the boundaries and contents of each required domain. For example, the organisation may wish to execute pre-migration directory clean up tasks on the legacy domains, which may hence alter the contents of each in-scope domain.

Page 38 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

The organisation may also wish to consolidate domains into object and resource management infrastructures (ORMIs) (see Domain Plan for details of ORMIs) within other domains. This may preserve the administrative boundaries and contents of the original source domains, but naturally extend the boundaries and contents of the target domains. • Factor A5: Influence of requirements for a dedicated forest root domain on the boundary and content of this domain ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement to create a dedicated forest root domain to meet one or more of the following requirements:  The requirement to restrict the membership of the “Domain Admins” group for the forest root domain  The requirement to retain control over the management of forest-wide components such as the Schema  The requirement to create a minimal replication footprint for the forest root domain  The requirement to ensure the business continuity of the forest root domain against restructuring or consolidation exercises within the organisation  Wishes to understand the influence of these requirement on the determination of the boundary and content of the domain ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The membership of the “Domain Admins” group for this domain defines the administrative boundary of a dedicated forest root domain. Where there is a requirement for the replication of the dedicated forest root domain to multiple physical locations, for protection against a site-specific disaster, then these locations define the replication boundary for this domain. The security boundary for the forest root domain is the entire forest itself due to the inherent rights and permissions assigned to the “Domain Admins” group of this domain. When an organisation strictly follows the recommendations stated by this design methodology for the use and function of a dedicated forest root domain, then the content of this domain will be limited only to a few user (the members of the “Domain Admins” group) and computer accounts. The small content of this domain would also assist in the creation of a minimal replication footprint. • Factor A6: Influence of a single network link to a physical location, which does not support the RPC over IP transport protocol, on the boundary and content of a domain ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation has:  Identified the requirement to implement an SMTP over IP Site Link to a remote Site with only one network link to an from that Site that does not support RPC over IP  The remote Site is represented within the forest as a domain, and

Page 39 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Wishes to understand the influence of this requirement on the determination of the boundary and content of the domain ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The physical boundaries of the terminus Site for a domain, created to meet this requirement, will hence represent the boundary of the domain. The users, computer, groups, and other objects present within this terminus Site will represent the content of such a domain. • Factor A7: Influence of the requirement to partition Active Directory replication network traffic on the boundary and content of a domain ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement to partition the Active Directory replication traffic for a forest via the partitioning of the forest into domains, and  Wishes to understand the influence of this requirement on the determination of the boundary and content of the domain ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The partitioning architecture of the network topology, which supports the forest and the domains within the forest, will hence define the boundary of a domain created to meet this requirement. The grouping of divisions, departments, sub-companies and so on, which regularly use specific areas of the network topology of the organisation, into domains to effect the partitioning of the network traffic will hence define the contents of the domains. 5.9.2. Identification of the Logical and Physical Aspects of an Organisation Represented by Domains Consider the following when executing an analysis to identify the logical and physical aspects of an organisation directly represented and supported by domains within this forest: • Factor B1: Understanding the logical and physical aspects of an organisation represented and supported by domains ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand:  The logical and physical aspects of an organisation represented and supported by domains, and  The influence of these metadata aspects of the organisation on the boundary and content of the domains ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The objective of this step within this process is to assist in the identification of all logical and physical aspects of an organisation that require representation and support by the required domains within the forest.

Page 40 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Although the onus is with the organisation to define their specific logical and physical aspects that require identification, this design methodology provides the following examples:  The users and computers within an organisation  The departments and other divisional structures within an organisation  The network infrastructure (LAN and WAN) that will support the routine operations of each required domain • Factor A8: Mapping of users and computers within an organisation to domains ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand how to map users and computers within an organisation to domains. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Where an organisation has identified the requirement for the design and implementation of a multiple domain infrastructure within a forest, then it is necessary to partition all users and computers represented and supported by the forest into the required domains. This design methodology proposes the following approach to map users and computers to required domains within a forest:  Identify all of the users and computers the forest is required to represent and support. The results of the process “determination of the boundary and content of each required forest” will provide this information.  Use the identified function and role of the domains within the forest to guide in the identification of the users and computers each domain will support and represent It is important to note that users and computers typically require exclusive alignment to individual domains, and rarely require representation and support within multiple domains, especially in the same forest. It is hence a very simple matter to partition and map users and computers to the boundaries of required domains. • Factor A9: Mapping of departments and other divisional structures within an organisation to domains ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand how to map departments and other divisional structures within an organisation to domains. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The mapping of departments and divisions to one or more required domains within a forest is not a simple undertaking within the majority of organisations. This is because domain boundaries do not always exactly align to the boundaries of one or more divisional structures within an organisation. The identified function, role, and administrative boundaries for the required domain will provide guidance on identification of divisional structures that require exclusive or shared representation and support by required domains.

Page 41 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved. • Factor A10: Mapping of a supporting network infrastructure within an organisation to domains ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand how to map a supporting network infrastructure within an organisation to domains. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The partitioning and mapping of a supporting LAN and WAN infrastructure for an organisation to each required domain is not a simple undertaking within the majority of organisations. All domains within a forest will share some common aspects and partitions of a supporting network infrastructure, by virtue of their membership to the forest and hence requirement to replicate forest-level components of the Active Directory. However, the function and role of a domain may dictate that the majority of its representation and reliance upon a supporting network infrastructure is restricted to specific partitions of the network. For example, a forest owner permits the creation of a domain support requirements for service autonomy by an autonomous division within the organisation. Two remote office locations exclusively support all logical and physical elements of this autonomous division. Dedicated WAN links connect these locations to the HQ for the organisation, to support replication with other GC servers, and so on, within the forest. Hence, the LAN infrastructure within each remote office location, and the dedicated WAN links, collectively represent the exclusive network infrastructure for the domain for this autonomous division. 5.9.3. Determination of the Boundary and Content of Each Required Domain Consider the following when determining the boundary and content of each required domain within the forest: • Factor D1: Understanding the proposed format for the report on the boundary and content of each required domain ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the required format for the report on the boundary and content of each required domain. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When generating a report on the boundary and content of each required domain, this design methodology proposes that the report contains the following information, for each required domain:  A detailed description of the function(s) and role(s) of each required domain, and how they influence the boundary and content of the domains  A detailed description of the following boundaries of each required domain:  The administrative boundaries  The security boundaries  The network and replication boundaries

Page 42 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Any other boundaries identified by the organisation  A detailed description of the content of each required domain, identifying:  The minimum and required content  The potential content of each required domain (for example, all user, computer, and group account objects within a legacy Windows 2000 domain, following completion of pre-migration directory clean up tasks, and an in-place upgrade of this domain)  Generate diagrams to illustrate each type of logical and physical boundary identified for each required domain  Generate diagrams to illustrate, at a high-level, the logical and physical contents of each required domain

Page 43 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

6.

Determination of the Size of the Active Directory Database for the Forest
This process requires execution for each production forest required by the organisation, regardless of the number of domains that require creation within the forest. This process relies and builds upon the results of the process to determine the boundaries and content of each domain within the forest. This information will assist the determination of the numbers and types of objects each required domain is to support and represent. This process will assist in the determination of the size of the Active Directory database for each domain with the forest and for the Global Catalog servers for the forest.

6.1.

Process Objectives Prior to the execution of this process, it is important to understand the objective of this process, which is to derive an understanding of the potential, preliminary, size of an Active Directory database for the forest. It is not the objective of this process to determine the exact size of an Active Directory database, down to Kilobytes, because that is impossible to do, even in a production Windows Server 2003 Active Directory infrastructure. The size of an Active Directory database will regularly fluctuate because the directory service is fluid and not static. Hence, where precise information about the types of objects and their numbers that will be populated within the Active Directory may not be readily available (applicable to the majority of organisations during this phase of the Active Directory design) then educated guesses will suffice.

6.2.

Background Information Whether an Active Directory implementation will be required to support a large number of objects (user and computer account objects, groups, printer objects, Shared Folder objects and so on) or not, it is very important to determine the expected size of the Active Directory database for a forest. The determined size of the Active Directory database will provide the foundation for identifying the following information: • The resource requirements for the domain controllers required to support the initial Active Directory infrastructure, such as the amount of RAM required, the disk capacity requirements for domain controllers and for Global Catalog servers and so on. • The resource requirements for the domain controllers required to handle a growing Active Directory that reflects the growth and expansion of the organisation. • The expected requirements for network bandwidth utilisation to support Active Directory replication between domain controllers and between Global Catalog servers within and between Sites The primary metadata aspects of an object created and present within an Active Directory database that contribute to its size are the attributes for the objects, and the data value(s) for these attributes. The creation of most objects within an Active Directory database requires population of a minimum number of attributes with data values, unique to that object or not. These mandatory attributes typically only represent a small fraction of the number of attributes available for an object, and are either mandatory to the object class for compliance with X.500 specifications, or as a proprietary requirement by Active Directory. For example, the user object class has no strict mandatory attributes, but a significant collection of optional attributes. However, creation of a user account object in Active Directory

Page 44 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

requires population of the following minimum “mandatory” (to Active Directory) attributes (example below is using the display names and not directory names for these attributes): • A value in either of all of the following attributes: ♦ The “first name” attribute ♦ The “initials” attribute ♦ The “last name” attribute ♦ The “full name” attribute (automatically populated by Active Directory with any values entered in the “first name”, “initials”, and “last name” attributes, or will accept values independent of these attributes) • A value in the “user logon name” attribute It is not necessary to define any other attributes when creating a user account object, using GUI tools, in Active Directory. Hence, when determining the size of an Active Directory database for a forest, the results can be quite specific because of the known initial sizes of specific objects typically populated within the Active Directory database. It is possible to execute the process to determine the size of an Active Directory database either manually or via the use of a free utility available from the Microsoft download web site called “ADSizer”. This design methodology recommends, where possible, the use of this utility to model the predicted Active Directory infrastructure for the forest. Note, however, that at the time of publication of this methodology, the available version of ADSizer supported sizing of only the Active Directory for Windows 2000 and Exchange 2000, and not Windows Server 2003 and Exchange Server 2003. However, the use of this tool is still viable because: • The objective of this process is to gain only an indication of the approximate size of the Active Directory database, and not the exact sizes, and • It is only possible to identify a few changes between Windows 2000 and Windows Server 2003 Active Directory, with respect to the sizes of objects This utility can identify the following information based upon user input: • The predicted size of the Active Directory database for each domain, and for the forest (Global Catalog Active Directory database) • The number of recommended domain controllers and Global Catalog (GC) servers per Site • The recommended size, specifications and number of hard disk drives and their RAID array configuration for the domain controllers and GC servers • The recommended minimum amount of RAM for each domain controller and GC server • The expected network bandwidth utilisation from Active Directory replication between domain controllers and GC servers, as a reflection of the expected number of changes (additions deletions and modifications) that require execution within each domain in the forest • The minimum recommended inter-Site bandwidth requirements

Page 45 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

This tool, which operates as a wizard, asks specific questions about object types and object modification routines and so on, used to determine a predicted size for an Active Directory database. This tool is associated with the following examples of advantages and disadvantages: • An advantage associated with the use of this utility is the use of built-in formulas to calculate, quite accurately, the predicted size of a GC Server Active Directory database. These formulas build upon the knowledge of the default attribute set that is populated to the Global Catalog for the forest, and hence the sizes of these attributes and so on. • An example of a limitation for this utility is that it is only able to calculate the predicted size of an Active Directory database using information about known objects. A typical enterprise Active Directory infrastructure may, however, be populated with non-standard objects that fall outside of the scope of this utility. This process provides an organisation with the steps and considerations for the determination of the size of an Active Directory database for a forest via the use of this utility, or via the execution of a manual process. The following table lists the size (in bytes) of typical objects created / published within an Active Directory forest:
Object / Attribute User object (with mandatory attributes) Computer account object (with mandatory attributes) Population of additional attribute Groups (irrespective of the type of group) Group members (dependent upon the number of members) Organisational Units (with mandatory attributes) Contact object (with mandatory attributes) X.509 Certificates Printer object (with mandatory attributes) Volume Share object (with mandatory attributes) Blob objects Access Control Entry Size (in bytes) 4,366 4,086 100 bytes per string attribute 2,097 Approximately 10 bytes / member 1,992 1,678 2,181 2,412 1,573 File Size + 25% 60 bytes per new ACE

Table 13.1: Typical and Default Object and Attribute Sizes in Windows Server 2003 Active Directory It is important to note that the objective of this process is not to support determination of the numbers of domain controllers required for each domain within the forest, and the number of GC server required for the forest. Execution of the Site Plan process, “design for domain controllers and GC servers”, will assist an organisation in the determination of this information. 6.3. Process Approach This design methodology proposes execution of the following approach to determine the size of the Active Directory database for the forest:

Page 46 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

1. 2.

Determine the numbers and types of objects each domain within the forest is required to support and represent Use a manual process or the ADSizer utility to determine the sizes of the Active Directory database (ntds.dit) for the following: a. The domain partition for each required domain b. The GC servers for the forest

3. 6.4.

Determine the total size of the Active Directory database for the forest

Process Components To reflect the above objectives and approach, this process to determine the size of the Active Directory database for the forest is comprise of the following components: • Determination of the numbers and types of objects to be held within each required domain • Determination of the sizes of the Active Directory database (NTDS.dit) for: ♦ The domain controllers within each domain (and hence the domain partition) ♦ The GC servers for the forest • Determination of the size of the Active Directory database for the forest

6.5.

Deliverables of Process Components The deliverables for this process are: • The estimated database size of the Active Directory for each domain within the forest • The estimated database size of the Active Directory for the Global Catalog servers for the forest • The estimated database size of the Active Directory for the entire forest (as the sum of the results of the previous two components) Note that the information derived from this process will be critical to the execution of the following subsequent processes: • The Domain Plan process “design domain controller hardware specifications” • The following Site Plan processes: ♦ “Determination of the number of Sites required for the forest” ♦ “Design of Domain Controllers and GC Servers” ♦ “Design Site Link Objects and the Site Link Topology”

6.6.

Inter-Component Dependencies Each component of this process will have the following inter-component dependencies:

Page 47 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Forest Plan – Inter-Component Dependencies for Process to Determine the Size of Active Directory Database for the Forest
Determination of the size of the Active Directory database for each domain Determination of the size of the Active Directory database for GC servers

START

Determination of the numbers and types of objects to be held within each required domain

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

© 2004 MUSTANSHI

R

BHAR

MAL

6.7.

Process to Determine the Size of the Active Directory Database for the Forest
Forest Plan – Process to Determine the Size of the Active Directory Database for the Forest
Is there a requirement to use the ADSizer tool? YES Use a design laboratory to build a test copy of this domain within the test forest Record the size (in bytes) of the Active Directory database (ntds.dit) for the empty domain on a non-GC server Load the Active Directory with 100% of the expected numbers of an object type Select a domain within the forest and determine the initial and projected numbers and types of objects that will be populated within this domain

START

Execute A1

NO

Execute A2 Download the latest version of the “ADSizer” tool from the Microsoft web site

Record the degragmented size (in bytes) of the ntds.dit file for the object type

YES

Is this the first object type? NO

Accounted for all object types for this domain?

Record the defragmented size (in bytes) of the Active Directory database (ntds.dit) for this object type, deduct the previous recorded size, then add to empty (starting) ntds.dit size NO Calculate object size (for each object type) using formula: Object size (bytes) = [Compressed ntds.dit size (bytes) minus Compressed ntds.dit start size (bytes)] divided by number of objects and multiplied by 1024 Force replication between all domain controllers in forest, and from a GC in the forest determine the ntds.dit size

Repeat test process for next object type

NO (Repeat For Each Domain)

Gather the required information for the Active Directory Sizer tool

YES

Determine the ntds.dit database size for the domain

Execute the Active Directory Sizer tool for each required domain in the forest

YES

Accounted for all required domains in forest?

Generate the required reports for results of the ADSizer tool executions

END
© 2004 MUSTAN
SHI R

BH

ARMAL

6.8.

Process Considerations Consider the following information when determining the size of the Active Directory database for the forest:

Page 48 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved. • Factor: Factoring in the potential growth of the Active Directory forest ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation has identified that the forest has a growth potential, with respect to the numbers and types of objects it will store and manage, due to:  The growth of the organisation / acquisitions of other organisations  The introduction of directory-enabled applications that will store data within the Active Directory, via the addition of new objects or the extension of existing objects via new attributes and so on ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The introduction of new / extension of existing objects within the Active Directory forest can affect the results of the processes that rely upon the knowledge of the approximate potential size of the Active Directory database for each domain, the GC servers, and the forest. The introduction of objects into the Active Directory that represents users and computers from an acquired organisation may quite rapidly increase the size of the Active Directory database. This will have a direct impact on the performance of the domain controllers within the forest and the volume of Active Directory replication traffic generated in response to the introduction of the new objects. It is possible to identify a similar scenario when an organisation introduces new directory-enabled applications, such as Microsoft Exchange Server 2003, that extends existing objects (user accounts, groups, contact objects) and adds new objects and data to the Active Directory. Hence, where possible, it is important to identify any plans the organisation has that will directly or indirectly expand the size of the Active Directory databases within the forest. Where an organisation has prior knowledge of the details of such plans and the timescales for their implementation, then where appropriate, these details should be included into the sizing calculations. • Factor: The information to be gathered per domain to accurately size the domain controllers ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation is considering the use of the “ADSizer” utility to calculate the size of an Active Directory database and other relevant information. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The ADSizer utility wizard will request the following information:  The total number of users in the domain, as the total number of concurrent users  The total number of attributes per user object (Active Directory automatically assigns each user a number of attributes. Additional attributes based on the business uses of the Active Directory service should be included in the estimate)  The average number of groups to which a typical user requires membership (the number of groups a user belongs to can affect the time to process a logon request, as the logon request evaluates user access by looking at the access granted to each group the user belongs to)

Page 49 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Average logon rate per second during peak hours (interactive, batch and network), where:  Interactive logon is for users who will be interactively using the machine, such as a user logging on using Terminal Services, a remote shell, or similar process.  Batch logon is for batch servers, where processes may be executing on behalf of a user without their direct intervention; or for higher performance servers that process many clear-text authentication attempts at a time, such as mail or Web servers.  Network logon is for high performance servers to authenticate clear text passwords. This type of logon is associated with access requirements to other network resources, such as remote servers or printers.  Password expiration rate (in days)  The number of computers running Windows 2000 or later operating systems that the domain is required to support and represent  The number of other computers in this domain running pre-Windows 2000 operating systems  The number of other objects published in this domain. Other objects are any objects other than users and computers that will be included in Active Directory. For example, user groups, organisational units, contacts, printers, or shares represent "other objects".  The desired average CPU utilisation limit for each domain controller.  The preferred CPU type for domain controllers, and the number of processors required of the CPU type specified  Administration: This section allows an administrator to specify the administratorgenerated workload for object addition, deletion, or modification to Active Directory. It is necessary to enter the planned average number of objects added, deleted, or modified on a daily, weekly, or yearly interval.  Microsoft Exchange 2000 / Exchange Server 2003: Microsoft Exchange 2000 / Exchange Server 2003 uses Active Directory for directory services, transport and name resolution. If planning to install Exchange 2000 / Exchange Server 2003, enter the average number of messages per user/per day and the average number of recipients for each message.  DNS related issues: This section allows an administrator to specify whether Active Directory-integrated DNS zones will be used, the number of dial-in connections (per day) that will be made by computers joined to the domain, the duration of DHCP leases, and the behaviour of the DNS Server aging and scavenging feature.  Other Active Directory-enabled application issues: This section covers other Active Directory-enabled applications not specifically known by the tool. Changes introduced by Active Directory Connector (ADC) or other directory synchronisation programs (such as Microsoft Directory Synchronisation Services) should be estimated in operations per second for searching, adding, deleting, and modifying objects

Page 50 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

7.

Design of the Forest Root Domain
This process requires execution following completion of the process, “determination of the number of domains required”, regardless of whether a dedicated or a dual-function domain is required as the forest root domain. Where an organisation identified the requirements for the design and implementation of a dual-function forest root domain and the forest is required to support two or more domains, a component of this process involves the selection of a domain within the forest to become the forest root domain.

7.1.

Background Information The function and role of the forest root domain is critical to an Active Directory forest. A domain can become the forest root domain for a forest by virtue of been the first domain to be created within the forest. All other domains within the forest will rely upon its continued presence and correct operation. References to a forest from an external domain / forest target the forest root domain. It is only possible to implement cross-forest trusts (between Windows Server 2003 Active Directory forests) between the forest root domains of the forests. The design for the forest root domain should hence reflect its importance within the forest and the organisation.

7.2.

Process Approach This design methodology proposes execution of the following approach to generate a design for the forest root domain: 1. Select a domain, required for the forest, to become the forest root domain where an organisation has identified the requirement for a dual-function forest root domain, within a forest supporting multiple domains. Determine the design requirements for the assignment of a DNS domain name to the forest root domain Determine the design requirements for the redundancy / high-availability of the forest root domain Determine the design requirements for the placement of the domain controllers representing the forest root domain Determine the design requirements for the forest-level FSMO roles (Schema Master and Domain Naming Master) Determine the design requirements for the “Domain Admins” global security group.

2. 3. 4. 5. 6. 7.3.

Process Components Based upon the above approach to the design of a forest root domain, this process is comprised of the following components: • Selection (where required) of a dual-function domain as the forest root domain • Determination of the design requirements for the assignment of a DNS domain name to the forest root domain • Determination of the design requirements for the redundancy / high-availability of the forest root domain • Determination of the design requirements for the placement of the domain controllers representing the forest root domain

Page 51 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved. • Determination of the design requirements for the forest-level FSMO role servers • Determination of the design requirements for the “Domain Admins” group within the forest root domain 7.4. Deliverables of Process Components The process to design the forest root domain for the forest will have the following deliverables: • The identification (where required) of the dual-function domain to be created as the forest root domain for the forest • The determination of the design requirements for the assignment of a DNS domain name to the forest root domain • The generation of a design to ensure the redundancy and high-availability of the forest root domain • The generation of the a design for the placement of the domain controllers representing the forest root domain • The generation of a design for the security, functionality, placement, and redundancy of the forest-level FSMO roles • The generation of a design for the “Domain Admins” global security group for the forest root domain, identifying the membership (based upon selection criteria) and the management best practices for this group 7.5. Inter-Component Dependencies Each component of this process will have the following inter-component dependencies:
Forest Plan – Inter-Component Dependencies for Process to Design the Forest Root Domain
Determination of the design requirements for assignment of a DNS name to the forest root domain Selection (where required) of the dualfunction forest root domain Determination of the design requirements for the forest-level FSMO roles Determination of the design requirements for the placement of the domain controllers representing the forest root domain

START
Determination of the design requirements for the redundancy / highavailability of the forest root domain Determination of the design requirements for the Domain Admins group

© 2004 MUSTANSHI

R

BHARMAL

Page 52 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved. 7.6.

Process to Design the Forest Root Domain
Forest Plan – Process to Design the Forest Root Domain

START

Is there a requirement for a dedicated forest root domain?

NO

Is there a requirement for >1 domain within forest?

YES

Execute A1

Define criteria for selection of dual-function forest root domain and identify required domain

YES Execute A2

NO

Create the required single domain within this forest as a dual-function forest root domain

Pass identified design requirements for DNS name to Organisation-Wide Active Directory Process “Design of DNS Infrastructure”

Execute B1

Execute A3 & A4

Execute D1

Does the organisation have two or more geographical locations?

Execute D2

Execute A5

Execute B2

YES NO Execute B3

END

Execute D4

Execute A10-A11

Execute B4

Execute D3

Execute A6 – A9
© 2004 MUSTANSH
I R

BHAR

MAL

7.7.

Process Considerations Consider the following information when generating the design for the forest root domain. Presented within the following six sections are the considerations for this process: 1. 2. 3. 4. 5. 6. Considerations for the selection (where required) of a dual-function domain to be the forest root domain Considerations for the determination of the design requirements for the assignment of a DNS name to the forest root domain Considerations for the determination of the design requirements for the redundancy / high-availability of the forest root domain Considerations for the determination of the design requirements for the placement of domain controllers for the forest root domain Considerations for the determination of the design requirements for the forest-level FSMO roles Considerations for the determination of the design requirements for the “Domain Admins” group in the forest root domain

7.7.1.

Selection of a Dual-Function Forest Root Domain Consider the following when executing the step within the process to select, from a forest to support multiple domains, the required domain to become a dual-function forest root domain: • Factor A1: Criteria for selection of a dual-function forest root domain

Page 53 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved. ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the design and implementation of two or more domains within the forest,  Has not identified the requirement for the design of a dedicated placeholder forest root domain, and  Wishes to understand and determine the criteria for the selection of a dual-function domain to become the forest root domain ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Although the onus is with the forest owner(s) to define their criteria to support and guide the selection of the dual-function forest root domain, this design methodology proposes the following example criteria:  A dual-function forest root domain should be the smallest required domain within the forest. A domain with the fewest number of objects within any domain in the forest will have a smaller replication footprint and will require less management.  A dual-function forest root domain should be the most stable domain within the forest: A domain within the forest that is the most resistant to any potential restructuring or consolidation exercises within the organisation and the forest.  A dual-function forest root domain should be a domain with a geographically distributed representation. A domain with domain controllers placed within more than one physical location can provide resilience against site-specific disasters such as fires, floods, theft and so on.  A dual-function forest root domain should be a domain that requires management by the fewest and most trusted administrators. A small domain with minimal administrative overhead will allow a smaller number of trusted administrators to manage this domain. This is critical when considering the membership of the “Domain Admins” group for this domain. This design methodology strongly recommends extensive use of delegation of control (see Domain Plan process “design of a delegation of control infrastructure” for details) for non-administrator accounts within a dual-function forest root domain.  A dual-function forest root domain should be a domain that primarily represents an organisation within the forest, and managed centrally from the head office of the organisation.  A dual-function forest root domain should be a domain with guaranteed network and physical security for all of its domain controllers in all locations. The critical and sensitive function of the forest root domain demands that all domain controllers for this domain are network and physically secured.  A dual-function forest root domain should be the domain with predicted highest availability statistics, based upon the hardware specifications and configuration for its domain controllers. A domain, supported by domain controllers hosted on servers with redundant configurations, would comply with the high-availability requirements for the forest root domain.  A dual-function forest root domain should be the domain with the best network connectivity to all geographical locations within the organisation that host other domain controllers for the forest. A domain represented by domain controllers in close network proximity to any network hubs, would have a higher probability in retaining network connectivity with the other domain controllers within the forest.

Page 54 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Using the above example criteria, execute the following:  Determine the criteria for the selection of a dual-function forest root domain  Evaluate all required domains within the forest against the defined criteria and identify the most appropriate domain to become the dual-function forest root domain. 7.7.2. Determination of the DNS Name Design Requirements for the Forest Root Domain Consider the following information when determining the design requirements for the assignment of a DNS name to the identified forest root domain: • Factor A2: Determination of the design requirements for the DNS name of the forest root domain ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Wishes to determine the design requirements for the DNS domain name for the forest root domain, and  Pass the design requirements to the Organisation-Wide Active Directory Plan process “Design of a DNS Infrastructure” ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology recommends execution of the Organisation-Wide Active Directory Plan process, “design of a DNS infrastructure”, to provide the DNS domain name for the forest root domain of this forest. The objective of this step within this process is to assist an organisation in the determination of the design requirements for the assignment of a DNS name to the forest root domain. When executing the process, “design of a DNS infrastructure”, consider the following information pertinent to the assignment of a DNS name to a forest root domain:  The selected DNS name for the forest root domain should be stable. This design methodology proposes that the forest owner(s) consider the following example criteria for the selection of a stable DNS domain name:  The DNS domain name does not reflect any component or metadata aspect of the organisation / forest owner(s) that has a high probability for change. For example, selection of the name of the organisation or division where the organisation is planning the execution of: • A complete, organisation-wide re-branding initiative, or • A merger with an equal sized organisation and the name of the organisation may hence change to reflect both merged organisations.  Registration of the selected DNS domain name on the Internet, with ICANN, may provide stability and ensures uniqueness of the name.  The use of a completely generic, non-Internet registered DNS domain name for the forest root domain protects the forest from proprietary domain name changes, such as “root.local”, “forest1.local”, “forest1.com”, and so on.

Page 55 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Note that Windows Server 2003 Active Directory supports the use of a new tool called “Domain Rename”. However, this design methodology does not recommend this tool as an alternative to a lack of investment and consideration into the design of the forest root domain DNS name, and strongly recommend consideration of the following information about the use of this tool:  This tool allows the renaming of the DNS and / or NetBIOS names of a domain within a Windows Server 2003 Active Directory forest, including the forest root domain.  It is only possible to employ this tool against domains within a forest raised to the “Windows Server 2003” functional level.  This design methodology requires organisations to understand that the renaming of domains is not a routine process and requires consideration for use only under extreme circumstances. For example, where an organisation has merged with or acquired another organisation, and is required to rename a consolidated forest to represent both organisations.  Consider the use of an internal DNS domain name for the forest root domain. The use of an internal DNS root will ensure protection of the internal DNS root from exposure to the Internet. Additionally, the DNS server that will host the private root zone is authoritative for all names within the internal DNS namespace.  The DNS domain name for the forest root domain must use an internationally acceptable DNS name. It is possible for the misinterpretation of a DNS domain name, which may have a benign or functional name in one language, as an offensive or derogatory name when translated in another language for a country that hosts the organisation. Hence, consideration for international differences and acceptability of domain names is necessary where the DNS name for a forest root domain will be visible in multiple countries and cultures. Using the above information, execute the following:  Determine the criteria for the selection of a DNS name for the forest root domain  Pass these criteria to the Organisation-Wide Active Directory Plan process “Design of a DNS Infrastructure” 7.7.3. Determination of the Design Requirements for the Redundancy / High-Availability of the Forest Root Domain Consider the following infrastructure when determining the design requirements for the redundancy and / or high-availability of the forest root domain: • Factor B1: Understanding the consequences of the loss of the forest root domain ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the consequences associated with the loss of the forest root domain, prior to determination of the design requirements fro the redundancy / high-availability of the forest root domain. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Prior to understanding the consequences of the “loss” of the forest root domain, it is important to understand the actual content of the term “loss”. The complete “loss” of a forest root domain implies compliance with the following criteria:

Page 56 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 All domain controllers for the forest root domain are irrecoverably lost  It is not possible to identify any backups for any of the forest root domain controllers to support the restore of the forest root domain Within most organisations executing this design methodology, this is a completely unlikely scenario. Hence, “loss” of a forest root domain realistically implies compliance with the following criteria:  Two or more domain controllers for the forest root domain are irrecoverably lost, but there is still one or more domain controllers available and representing the forest root domain, or  All domain controllers for the forest root domain are irrecoverably lost, but the organisation has backups of one or more of the domain controllers and is able to restore the forest root domain, or  There is temporary loss of network connectivity between the domain controllers for the forest root domain and other domain controller representing other domains. Loss of network connectivity to all root domain controllers effectively represents the “loss” of this domain from the perspective of the other domains in the forest. “Loss” of the forest root domain hence realistically only applies to the temporary loss of availability, performance, and functionality of the forest root domain, and very rarely the complete, permanent, and irrecoverable loss of this domain. Note that when the forest root domain is actually completely lost, this does not result in the sudden “death” of the rest of the forest, with all domains and domain controllers immediately and permanently shutting down. The following are examples of what may actually happen to the other domains within the forest after the permanent loss of the forest root domain:  It is no longer possible to introduce new domains within the forest  It is no longer possible to modify the Schema  It is no longer possible to query, search, access resources between domains within the forest previously linked via a trust path that involved the forest root domain (inter-tree) It is possible to identify a number of other significant consequences from the permanent loss of the forest root domain. However, all organisations will accept that the permanent loss of the forest root domain is unacceptable and is associated with extensive administrative and financial overheads to attain recovery from this scenario. The only supported recovery option is to build a completely new parallel forest, and execute inter-forest migrations as soon as possible. When a forest root domain is “temporarily” lost, this does not have as significant an impact on the operation of the rest of the forest as the complete and permanent loss of this domain. However, although this scenario is also unacceptable, it is associated with less extensive administrative and financial overheads to the organisation for recovery. Hence, when determining the design requirements for the redundancy and highavailability of the forest root domain, this design methodology recommends execution of the following approach:  Determine the design requirements for solutions and options to prevent the complete and permanent loss of the forest root domain. This design methodology deems that it is not feasible to invest time into the development of solutions to “recover” from the permanent loss of the forest root domain, as the focus for these solutions and option must be on prevention.

Page 57 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Determine the design requirements for solutions and options to prevent and recover from the temporary loss of functionality and performance of the forest root domain. This design methodology strongly recommends in the development of solutions to support both the prevention of a temporary loss of this domain, and the recovery from any temporary losses. • Factor A3: Determination of the design requirements for solutions and options for prevention of the complete and permanent loss of the forest root domain ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the design requirements for solutions and options to prevent the complete and permanent loss of the forest root domain. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: As stated earlier, it is only possible to identify the complete and permanent loss of the forest root domain via compliance with the following criteria:  The complete and irrecoverable loss of all domain controllers that represent the forest root domain, and  The complete absence of all viable backups of any of domain controllers that represent the forest root domain Hence, solutions and options to prevent these scenarios must focus on the prevention of complete server loss and complete loss of all viable backups. This design methodology proposes the following options and solutions to prevent the manifestation of this unacceptable scenario:  Design and implementation of multiple domain controllers for the forest root domain. The number of domain controllers required must:  Meet or exceed the minimum of two domain controllers  Respect the size of the domain (number of objects) and the distributed replication requirements for this domain (see later). Note that the introduction of too many domain controllers will also increase the financial and administrative overheads for the domain.  Distribution of domain controllers for the forest root domain in multiple geographical locations, including dedicated DR locations for the organisation. This strategy will protect the forest root domain from the most likely cause of a complete loss, the site-specific disaster. A site-specific disaster (such as flood, fire, earthquake, burglary, terrorism, vandalism, and so on) may destroy all domain controllers for the forest root domain if all are located in the same physical location. Note that the employment of this strategy is only possible within organisations that can support the following criteria:  The organisation owns or is permanently represented within two or more physical locations  A site-specific disaster would not affect all of the locations for the organisation, and hence this discounts such “locations” as different floors in a building, or buildings adjacent to each other (as fires and floods may spread to encompass adjacent buildings, and so on)  The discrete physical locations have reliable network connectivity to the primary location(s) for the organisation

Page 58 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 The discrete locations can provide physical access security for the servers, and they will not be placed within public access areas  Design and implementation of a backup and recovery infrastructure to support the domain controllers representing the forest root domain. Although volume 2 of this design methodology comprehensively covers the design of an Active Directory backup and recovery infrastructure, for this process, ensure that the design of a backup and recovery infrastructure includes the following elements:  The use of a trusted native or proprietary backup software solution  The use of a trusted proprietary backup hardware solution, such as a tape library  The design and implementation of a backup schedule that executes, for example, a complete backup each night of each domain controller in the forest root domain  The design of a restore policy and procedures, to perform regular test restores of backups, once a week. It is imperative that a restore and test restore strategy accompanies a backup strategy, to validate the backups and the backup strategy. Using the above information, execute the following:  Execute an analysis to identify all potential causes for the complete and permanent loss of the forest root domain  Determine and document all design requirements for solutions to prevent the complete and permanent loss of the forest root domain • Factor A4: Determination of the design requirements for solutions and options for prevention of the temporary loss of the forest root domain ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the design requirements for solutions and options to prevent the temporary loss of functionality and performance the forest root domain. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology proposes that the identification of one or more of the following examples contingencies may result or lead to the temporary loss of functionality and performance the forest root domain:  The loss of one or more (but not all) domain controllers representing the forest root domain may result in the degraded performance of the forest root domain, due to the increased workload on the remaining domain controller(s). The possible solutions to prevent and recovery from this scenario include:  To prevent this scenario, this design methodology proposes execution of the following approach: • Identify all potential causes of a domain controller outage (hardware, software, configuration, human errors, and so on) • Design solutions to prevent the manifestation of these causes, where possible and feasible  To recover from this scenario, this design methodology proposes execution of the following approach:

Page 59 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved. • For each identified potential cause of a domain controller outage, identify the potential solutions to recover from the outage • Select an option based upon the feasibility and viability for its design and execution • Design the procedure, and execute necessary steps to support the procedure  For example, where an identified potential cause for server outage is failure of a hardware component on the server, such as the power supply unit (PSU), then: • A solution to prevent the manifestation of this scenario from generating a server outage is to install a redundant PSU • A viable and feasible solution to support speedy recovery from this contingency is to: ♦ Procure one or more spare PSU to keep permanently in stock ♦ Design the procedure for the emergency replacement of an PSU  The loss of network connectivity between domain controllers in the forest root domain, and between domain controllers representing other domains within the forest, temporarily places the forest root domain incommunicado. The possible solutions to prevent and recovery from this scenario include:  To prevent this scenario, this design methodology proposes execution of the following approach: • Identify all potential causes of a network outage (hardware, software, configuration, human errors, and so on) • Design solutions to prevent the manifestation of these causes, where possible and feasible  To recover from this scenario, this design methodology proposes execution of the following approach: • For each identified potential cause of a network outage, identify the potential solutions to recover from the outage • Select an option based upon the feasibility and viability for its design and execution • Design the procedure, and execute necessary steps to support the procedure  For example, where an identified potential cause for network outage is failure of a WAN link between the HQ and a hub site, then: • A solution to prevent the manifestation of this scenario from generating a network outage is to install a redundant WAN link • A viable and feasible solution to support speedy recovery from this contingency is to: ♦ Procure a Service Level Agreement (SLA) with the network service provider that guarantees, for example, restoration of a failed WAN link within a few hours

Page 60 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved. ♦ Design the procedure for the emergency re-routing of network traffic across the redundant and, for example, low bandwidth, temporary WAN link  The failure of hardware components within the servers running the domain controllers for the forest root domain  The failure of a hardware backup solution to execute a backup schedule, or perform test restores, such as:  Hardware failure  Lack of tape media  The failure of a backup software solution to execute a backup schedule, or perform test restores  Human administrative errors directly, or indirectly, resulting in the temporary loss of availability of one or more of the domain controllers for the forest root domain. Continuity of the IT infrastructure and the organisation depends almost exclusively upon presence and compliance with rules and procedures, and the use of a methodical and disciplined approach by IT administrators. The absence or lack of compliance with rules, procedures, and discipline will inevitably lead to disruption of business and technical continuity.  The failure of the physical and network security infrastructure to protect the integrity of the domain controllers for the forest root domain  The unavailability of “contingency hardware stock”, necessary to support the continued operation of the forest root domain  The absence of a disaster recovery procedure and supporting infrastructure, such as:  One or more spare servers which can be built as temporary domain controllers  The availability of automated installation of standard server build for Windows Server 2003 domain controllers and script for execution of Active Directory Installation Wizard Using the above information and approaches, execute the following:  Execute an analysis to identify all potential causes for the temporary loss of functionality and performance the forest root domain  Determine and document all design requirements for solutions to prevent the temporary loss of functionality and performance the forest root domain • Factor D1: Understanding the proposed format and content of the design for the redundancy / high-availability of the forest root domain ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has completed all analysis to determine the design requirements for the redundancy / high-availability of the forest root domain, and  Wishes to understand the required format and content for this design ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation:

Page 61 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

When generating a design for the redundancy / high-availability of the forest root domain, this design methodology proposes that the report contains the following information:  A detailed design for one or more solutions to prevent the complete and permanent loss of the forest root domain  A detailed design for one or more solutions to prevent the temporary loss of functionality and performance of the forest root domain  A detailed design for one or more solutions to support recovery from the temporary loss of functionality and performance of the forest root domain 7.7.4. Determination of the Design Requirements for the Placement of the Forest Root Domain Controllers Consider the following when determining the design requirements for the logical and physical placement of the domain controllers representing the forest root domain: • Factor B2: Understanding placement requirements for domain controllers representing the forest root domain ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has a multiple domain forest, with domain controllers representing non-root domains distributed across two or more geographical locations, and  Wishes to understand the requirements for the placement of domain controllers representing the forest root domain ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology identifies the following two categories for requirements, which influence the design for the placement of domain controllers representing the forest root domain:  Requirements to ensure the availability of the forest root domain in the event of sitespecific disasters  Requirements to improve performance of specific Active Directory-related activities that rely upon network connectivity to domain controllers in the forest root domain The requirements to ensure the continued availability of the forest root domain require the distribution of these domain controllers across multiple geographical locations, each not influenced by a site-specific disaster at another. Compliance with this requirement naturally requires the presence of multiple locations, and the other criteria outlined earlier, in the determination of the availability requirements for the forest root domain. The requirements to improve performance of specific Active Directory-related activities relate to the following examples:  The function(s) of the domain controllers representing the forest root domain, such as:  Support for the forest-level FSMO roles, Schema Master and Domain Naming Master. For example, all Active Directory-related activities that involve connection

Page 62 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

with domain controllers hosting these FSMO roles requires good network connectivity, such as: • Installation of Active Directory-enabled applications, which extend / modify the Schema, requires good network connectivity to the Schema Master • The execution of the Active Directory Installation Wizard to add or remove a domain within the forest requires good network connectivity to the Domain Naming Master  Support for the Enterprise Admins and Domain Admins groups  Support for raising the functional level of the forest, and hence enabling of advanced features for all domains and domain controllers within the forest, and so on.  The role of the forest root domain within the forest, such as:  The “root” domain for all inter-tree trust paths within the forest  The “root” domain for all inter-forest “Forest Trust” relationships within an intranet / extranet federated forest infrastructure (see the Organisation-Wide Plan process “design of federated forest infrastructures” for details)  The source for all replication of changes to the Active Directory Schema and Configuration partition for the forest, to all other domain controllers within the forest • Factor A5: Determination of the design requirements for the placement of the domain controllers representing the forest root domain ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has a multiple domain forest, with domain controllers representing non-root domains distributed across two or more geographical locations, and  Wishes to determine the design requirements for the logical and physical placement of the forest root domain controllers ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When determining the design requirements for the placement of the domain controllers representing the forest root domain, consider the following:  See the earlier step within this process, “determination of the design requirements for the redundancy / high-availability of the forest root domain”, for considerations on these placement requirements.  The placement of domain controllers for the forest root domain to improve performance of the forest and Active Directory-related activities must hence support the following:  Replication of changes to the Active Directory Schema and Configuration partition from the forest root domain, which all domain controllers within the entire forest must receive, will generate significant replication “waves”. The impact of these replication waves on network utilisation may be significant, and there may be requirements for their completion as soon as possible.

Page 63 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 The execution of LDAP referrals along default trust paths within the forest, and so on.  Where organisations have a hub-and-spoke network infrastructure, the domain controllers for the forest root domain require placement in the hub site.  Where organisations do not have a strict hub-and-spoke network configuration, then more careful consideration is required for the placement of these domain controllers. This design methodology proposes execution of the following approach to determine the placement requirements for in these domain controllers in these scenarios:  Identify the distribution requirements for the domain controllers for all other domains within the organisation.  Where these domain controllers are located within multiple locations, determine the frequency of their requirements to contact the domain controllers representing the forest root domain.  Prioritise the locations hosting domain controllers with the highest frequency of access requirements to the forest root domain  Identify the locations within this list that have the least quality network links to the location primarily hosting the forest root domain controllers  Use this information to determine the most appropriate placement requirements for the domain controllers representing the forest root domain. Using the above information and approach, determine and document all design requirements that will influence the placement of the domain controllers for the forest root domain. • Factor D2: Understanding the proposed format and content of the design for the placement of the domain controllers for the forest root domain ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has completed all analysis to determine the design requirements for the placement of domain controllers for the forest root domain, and  Wishes to understand the required format and content of the design ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When generating a design for the placement of the domain controllers for the forest root domain, this design methodology proposes that the report contains the following information:  A detailed design for the logical placement of these domain controllers on the network infrastructure within the organisation  A detailed design for the physical placement of these domain controllers within the geographical locations for the organisation  A diagram illustrating the logical and physical placement requirements for these domain controllers

Page 64 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

7.7.5.

Determination of the Design Requirements for the Forest-Level FSMO Roles Consider the following when determining the design requirements for the forest-level FSMO roles: • Factor B3: Understanding the design requirements for the forest-level FSMO roles ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the design requirements for the forestlevel FSMO roles. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Each Windows Server 2003 Active Directory forest supports two forest-level FSMO roles, the Schema Master and Domain Naming Master. This design methodology requires that the design for these FSMO roles must include the following components:  A design for the physical and network security of these FSMO roles  A design for the functionality requirements of these FSMO roles  A design for the logical and physical placement of these FSMO roles  A design for the redundancy and availability of these FSMO roles • Factor A6: Determination of the design requirements to secure the forest-level FSMO roles ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the design requirements to ensure the physical and network security of the forest-level FSMO roles. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The execution of many Active Directory-related activities relies upon the continued presence of the domain controllers hosting these forest-level FSMO roles. The level of physical and network security afforded these domain controllers will directly influence their continuity in the event of security breaches. The unauthorised access to these roles can also compromise the integrity and continuity of the forest. For example, an attacker may be able to introduce corruptions to the Schema with disastrous consequences for the entire forest. Note that where the forest owner(s) support many autonomous divisions within the forest, as independent domains, then the owner(s) may be required to comply with SLAs from these divisions, on the continuity and integrity of the forest. Compromise of these FSMO roles can potentially compromise the security and integrity of all resources controlled by the entire forest. When determining the design requirements for the protection of these FSMO roles from physical and network security breaches, consider the following:  The design for the physical security of these FSMO roles may require additional levels of physical security from other servers and domain controllers. For example, in a secured server room, with access only to members of the Enterprise Admins group in the forest root domain.

Page 65 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Securing two domain controllers that host these FSMO roles is more demanding than securing a single domain controller. Hence, this design methodology recommends the placement of both of these forest-level FSMO roles on a single domain controller.  The use of the IPSEC policy “Secure Server (Require Security)” will provide a level of network security, to prevent unsecured communications with un-trusted clients.  The use of a hardware solution to filter and screen all network traffic to and from the FSMO roles will also provide adequate network-level security. Using the above information, execute the following:  Determine the design requirements to ensure the physical security of these FSMO roles  Determine the design requirements to ensure adequate network security for these FSMO roles, without compromising their function and role within the forest. • Factor A7: Determination of the design requirements to support the functionality requirements of the forest-level FSMO roles ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the design requirements to support the functionality of these forest-level FSMO roles. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The function of the Domain Naming Master FSMO role is to control and make changes to the forest-wide domain name space of the directory, which is the Partitions\Configuration naming context or “LDAP://CN=Partitions,CN=Configuration,DC=<domain>”. The domain controller hosting this FSMO role is also the only domain controller that can add or remove a domain from the directory, and add or remove cross references to domains in external directories. The functionality and role of this FSMO role in the forest hence requires that the host domain controller is aware of all domains within the entire forest prior to the approval of the use of a new domain name. It is hence imperative that the host domain controller for the Domain Naming Master role is also a Global Catalog server for the forest. Note that this configuration requirement, to support the functionality of the Domain Naming Master role, will hence have an influence on the network placement and connectivity of the host domain controller, to support the GC server role. • Factor A8: Determination of the design requirements for the logical and physical placement of the forest-level FSMO roles ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the design requirements for the logical and physical placement of the forest-level FSMO roles. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When determining the design requirements for the logical and physical placement requirements for the forest-level FSMO roles, consider the following:  The logical placement considerations for these roles include the fact that it is possible for any domain controller for any domain within the forest to host these

Page 66 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

forest-level FSMO roles. This is a reflection of the fact that these roles are flexible (and hence “Flexible” Single Master Operations), and that these roles are forestlevel roles, and hence restricted to domain controllers within the boundaries of the forest, and not by domain boundaries.  This design methodology proposes the following recommendations for the determination of the logical placement of these roles:  These roles should remain within the default domain for these roles, at the time of their creation, which is the forest root domain (and hence the inclusion of this design component within the design for the forest root domain).  Where possible, the forest owner(s) should resist moving these FSMO roles between domain controllers, unless there is an emergency requirement.  It is important to ensure that attempts to move these FSMO roles do not reflect a lack of investment and consideration into the design of the supporting network infrastructure, and the placement of these domain controllers.  The physical placement considerations for these roles include the requirements to support Active Directory-related activities that require network connectivity with the forest-level FSMO roles. See earlier for appropriate considerations.  Note that some routine Active Directory-related activities and operations may have a seemingly innocuous relationship with the forest-level FSMO roles. For example, the creation of a system attendant resource on a clustered Exchange 2000 solution requires connectivity and connection to the Schema Master FSMO role.  Note that execution of contingency procedures to, for example, recover from a downed FSMO role, may require good network connectivity with the infrastructure to support the execution of disaster recovery procedures. For example, a DR procedure to recover from a failed domain controller, which exhibits significant and irreparable (within scope of SLA) damage, requires the deployment of a new domain controller on stand-by server hardware. The DR procedure employs the use of an automated network installation of the standard server build (using a RIS server as a PXE-boot server to retrieve an image of a base build). However, the standby server and the network installation infrastructure reside in different physical locations to the required location for the FSMO role(s). This may hence influence the design for the placement of the forest-level FSMO roles. Using the above information, execute the following:  Determine the design requirements for the logical placement of the forest-level FSMO roles within the network infrastructure for the organisation  Determine the design requirements for the physical placement of the forest-level FSMO roles within the geographical locations for the organisation • Factor A9: Determination of the design requirements to support the continued availability of the forest-level FSMO roles ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the design requirements to support the continued availability of the forest-level FSMO roles. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When determining the design requirements to support the continued availability of the forest-level FSMO roles, consider the following:

Page 67 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 The design for the continued availability of these forest-level FSMO roles must address the following:  The identification of the possible contingencies that result in the unavailability of these FSMO roles  The design of solutions to prevent these possible contingencies  The design of solutions to recover from these possible contingencies  Although the onus is with the forest owner(s) to identify contingencies, specifically associated with these forest-level FSMO roles, that require consideration for design, this design methodology proposes the following examples:  The moving of FSMO roles between domain controllers is marginally associated with the risk of failure in the completion of the transfer  The malicious seizure of these roles  The possible solutions to prevent the occurrence of such contingencies include the design and enforcement of strict guidelines, procedures, and criteria for the execution of a FSMO role transfers.  This design methodology recommends the identification of a “standby FSMO role server” to support the emergency transfer or seizure of these roles. The “standby FSMO role server” is required to comply with the following criteria:  Is an active domain controller in the forest root domain (recommendation)  Is configured as a GC server  Has the support of an adequate physical and network security infrastructure, commensurate to the hosting (even temporary) of the forest-level FSMO roles. Using the above information and approach, execute the following:  Determine the potential contingencies that may result in the unavailability of the forest-level FSMO roles  Determine the design requirements for solutions to prevent the occurrence of such contingencies  Determine the design requirements for solutions to detect and recover from such contingencies • Factor D3: Generation of the design for the forest-level FSMO roles ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has complete all design analysis tasks to determine the design requirements for the security, functionality, logical and physical placement, and the redundancy and availability of the forest-level FSMO roles, and  Wishes to generate the design to support the identified requirements ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology requires that the design for the forest-level FSMO roles comprise the following format and contents:

Page 68 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 A detailed design for the physical and network security of the forest-level FSMO roles  A configuration requirement to ensure that the domain controller hosting the Domain Naming Master FSMO role operates as a Global Catalog server  A detailed design for the logical placement of the forest-level FSMO roles within the network infrastructure for the organisation  A detailed design for the physical placement of the forest-level FSMO roles within the geographical locations for the organisation  A detailed design for solutions to prevent, detect, and recover from contingencies resulting in the unavailability of the forest-level FSMO roles  A detailed design for the use of a standby FSMO role server, identifying the following:  The identification of the domain controller to support this role  The design of the procedure for the transfer or seizure of the forest-level FSMO roles in the event of an emergency, or planned maintenance requirement  Supporting diagrams to illustrate the designs 7.7.6. Determination of the Design Requirements for the Forest Root “Domain Admins” Group Consider the following when determining the design requirements for the “Domain Admins” built-in security group, within the forest root domain: • Factor B4: Understanding the design requirements for the forest root “Domain Admins” group ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the design requirements for the forest root “Domain Admins” security group. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Member security principals of the “Domain Admins” security group, within the forest root domain, have the most powerful rights and permissions within the entire forest. Hence, the design for the “Domain Admins” security group is entirely from the perspective of controlling membership to this group. Hence, this design methodology proposes that design for the “Domain Admins” group is comprised of the following components:  The determination of the design requirements for selection criteria for membership to the “Domain Admins” group  The determination of the design requirements for the solutions to control membership to the “Domain Admins” group • Factor A10: Determination of the design requirements for the membership selection criteria for “Domain Admins” group ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the design requirements for criteria to

Page 69 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

control selection of security principals to become members of the “Domain Admins” group, for the forest root domain. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The “Domain Admins” security group for the forest root domain (and all other domains) is a Global group and hence can only accept member security principals created within the domain. This hence automatically restricts the scope of membership. Where an organisation has elected for the design and implementation of a dedicated (placeholder) forest root domain, then this domain will have a very limited number of custom security principals. Although the onus is with the forest owner(s) to define their criteria for selection of members to this “Domain Admins” group, this design methodology provides the following example criteria:  The members of this security group must be highly trusted administrators within the entire organisation, and by the scope of the organisation represented by boundaries of the forest. The scope of the trust must extend from the board of directors of the organisation, as the members of the “Domain Admins” group in the forest root domain are able to access any and all data within all computers represented and controlled by the forest.  The members of this security group are not required to perform routine administrative functions, as their user account may hence be required to logon to multiple servers, and so on. This will increase the risk of a security breach.  The members of this security group are readily contactable and can execute administrative functions if required in emergencies, or for routine operations. Using the above information, execute the following:  Determine the criteria for the selection of members for the “Domain Admins” security group within the forest root domain.  Document all required selection criteria  Identify all potential members of the Domain Admins group for evaluation against the defined criteria • Factor A11: Determination of the design requirements for the management of the “Domain Admins” group and other security principals in the forest root domain ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the design requirements for management procedures and solutions to control the use and membership of the Domain Admins global security group, and other security principals. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When determining the design requirements for the solutions and management procedures to control membership to the “Domain Admins” group, consider the following:  Note that it is only possible to modify the membership of the “Domain Admins” security group in the forest root domain, (read and write “members” property of the group) using the security context of the following security principals:

Page 70 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Security principals currently members of the “Domain Admins” security group in the forest root domain  Security principals not currently members of the “Domain Admins” security group in the forest root domain, but members of the: • Just the “Administrators” built-in group in the forest root domain • Just the “Enterprise Admins” built-in group in the forest root domain  Note the members of the “Account Operators” group in the forest root domain have insufficient rights to modify the membership of the “Domain Admins” group.  Hence, the scope of management controls and solutions must also encompass management of the “Administrators” and “Enterprise Admins” security groups in the forest root domain.  This design methodology proposes consideration of the following potential solutions to control and manage these security groups:  It is essential to keep the number of security principal members to these groups to the bare minimum.  Prevent the addition of other security groups as members of these groups, as it may be difficult to control the membership of these member groups, especially if they belong to other domains within the forest, or trusted external domains.  Enable auditing of changes to the membership of these groups within the forest root domain  Control the membership of these groups using the “Restricted Groups” policy within a Group Policy Object applied at the domain level and configured with the default refresh interval.  For a dedicated forest root domain, restrict physical access to the forest root domain controllers to members of these groups only  Restrict physical access to the system state backups for the forest root domain controllers to the members of these groups only Using the above information, execute the following:  Determine the design requirements for solutions to control and manage the “Domain Admins” groups  Identify all security principals that may have the right to modify the membership to the “Domain Admins” group  Determine the design requirements for solutions to control and manage the “Enterprise Admins”, “Administrators”, and “Schema Admins” groups, and all other security groups and security principals with the right to modify the membership of this group. • Factor D4: Generation of the design for the “Domain Admins” group in the forest root domain ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has complete all design analysis tasks to determine the design requirements for the “Domain Admins” Global security group for the forest root domain, and

Page 71 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Wishes to generate the design to support the identified requirements ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology requires that the design for the “Domain Admins” Global security group for the forest root domain comprise the following format and contents:  Execution of an evaluation of all identified potential members against the defined selection criteria  Identify all required members of the “Domain Admins” Global security group in the forest root domain. Note that for a dedicated forest root domain, it is necessary to create the user accounts for these users within this domain, and not another “account” domain within the forest.  Generate the design for the solutions to control and manage the “Domain Admins”, “Enterprise Admins”, “Schema Admins”, “Administrators”, and all other identified security principals within the forest root domain.

Page 72 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

8.

Design of Application Directory Partitions within a Forest
The concept of the Application Directory Partition (ADP) is new to Windows Server 2003 Active Directory. An application directory partition is similar to the existing Schema, Configuration, and Domain partitions of an Active Directory database, but follows slightly different rules for creation, replication, and management.

8.1.

Process Objectives The objective of this process is to assist an organisation in the execution of the following: • Determination of the requirement for the creation and management of one or more custom application directory partitions (ADPs) within the forest • Generation of the design for one or more custom ADPs within the forest, where required

8.2.

Process Scope The scope of this process is restricted to the determination of the requirements for one or more ADPs, and, where required, the design for the following aspects of ADPs: • The design for the name and namespace of each required ADP • The design for the security of each required ADP • The design for the delegation of creation of ADPs The design of a replication topology for each required ADP is outside of the scope of this process and Forest Plan, but within the scope of the Site Plan, as the process “design of replication topologies for application directory partitions”.

8.3.

Background Information The only application directory partitions created by default within an implementation of a Windows Server 2003 Active Directory forest, are the DNS ADPs. Custom ADPs require manual creation, by a member of the Enterprise Admins group in the forest root domain, or automatic (scripted) creation by an application that will use the partition. It is possible to delegate elements of the manual creation of ADPs. The purpose of an application directory partition is to hold data, within the Active Directory database, exclusively for the use of a directory-enabled application or service. For example, Windows Server 2003 DNS can store DNS zone data within a default or custom application directory partition.

8.4.

Process Approach This design methodology proposes execution of the following approach to design one or more custom ADPs for this forest: 1. 2. 3. Understand the features and functions of ADPs Determine the requirements for the design of one or more custom ADPs, and the applications and services each required ADP will support Where there is a requirement for the design of one or more custom ADPs, then: a. Determine the characteristics for the data each required custom ADP will hold b. Determine the design requirements for the name and namespace for each required custom ADP

Page 73 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

c.

Determine the design requirements for the selection of the security descriptor domain for each required custom ADP

d. Determine the design requirements for the delegation of ADP creation 4. 8.5. Generate a design for each required custom ADP

Process Components Based upon the above approach, this process is composed of the following seven components: • Understanding ADPs • Determination of the requirements for the design and implementation of one or more ADPs • Determination of the data characteristics for the ADPs • Determination of the design requirements for the name and namespace for ADPs • Determination of the required security descriptor domain for each ADP • Determination of the design requirements for the delegation of ADP creation • Generation of a design for each required custom ADP

8.6.

Deliverables of Process Components This process will have the following deliverables: • An understanding of the functions and features of ADPs within Windows Server 2003 Active Directory forest • The determination of the requirements for the design of one or more custom ADPs • The identification of the applications and services that will require support via the design and implementation for custom ADPs • The identification of the number of ADPs required • The identification of the nature, size, and frequency of change of the data that the applications / services will store within each required custom ADP • The generation of a design for the name and namespace for each required custom ADP • The identification of the security descriptor reference domain for each required custom ADP • The generation of a design to support the delegation of creation of one or more custom ADPs

8.7.

Inter-Component Dependencies Each component of this process will have the following inter-component dependencies:

Page 74 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Forest Plan – Inter-Component Dependencies for Process to Design ADPs within a Forest START
Understanding ADPs Determination of the requirements for ADPs

Determination of the data characteristics of the required ADPs

Determination of the design requirements for the name and namespace for ADPs

Determination of the required security descriptor domain for each ADP

Determination of the design requirements for the delegation of ADP creation

Generation of a design for each required custom ADP
© 2004 MUSTANSHI
R

BHAR

MAL

8.8.

Process to Design Application Directory Partitions within a Forest Forest Plan – Process to Design ADPs within the Forest
Is there a requirement for custom ADPs?

START

Execute B1 – B5

Execute A1

YES Execute B7 Execute A5 – A6 Execute B6 Execute A2 – A4

Execute A7

Execute D1

Execute B8 – B9

Execute A8 NO

Execute A9 Is there a requirement to delegate the creation of custom ADPs? NO YES Execute A11 Execute D2

YES

Is there a requirement to identify specific security descriptor reference domains? NO

Execute A10

END
© 2004 MUSTANSHI
R

BH

AR MAL

8.9.

Process Considerations Consider the following when designing ADPs for this forest. Presented within the following seven sections are the consideration for this process:

Page 75 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

1. 2. 3. 4. 5. 6. 7. 8.9.1.

Considerations to assist in the understanding of the function and features of custom ADPs Considerations for the determination of the requirement for custom ADPs Considerations for the determination of the characteristics of the data to be stored in a custom ADP Considerations for the determination of the design requirements for the name and namespace for custom ADPs Considerations for the determination of the required security descriptor domain for each custom ADP Considerations for the determination of the requirement to delegate the creation of custom ADPs Considerations for the generation of the design for custom ADPs

Understanding ADPs Consider the following when attempting to understand the function and features of custom ADPs within Windows Server 2003 Active Directory forests: • Factor B1: What are ADPs? ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the concept of application directory partitions. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Application Directory Partitions, or ADPs, are logical partitions of an Active Directory ntds.dit database, just like the Schema, Configuration, and Domain partitions. Each ADP is hence associated with a virtual boundary for the data and object held within the ADP. The objectives for ADPs are hence to provide a location for the storage of application and service specific data, without interfering with the operation of any other discrete partitions within the Active Directory database. Windows 2000 Active Directory supported the use of Active Directory-Integrated DNS zones, but the DNS zone data was stored within the respective Domain partition of the Active Directory database, and hence increased the size of the replication footprint of this partition. The DNS zone data hence replicated to all domain controllers within the domain, regardless of whether these domain controllers had the DNS server service installed, and hence the capability to access and use this DNS zone data. It is possible to design unique and discrete replication topologies for ADPs, where replication of a custom ADP is only between those Windows Server 2003 domain controllers that require local access to the data within the ADP. The design of custom replication topologies for ADPs is a component of the Site Plan, executed via the process “design of replication topologies for application directory partitions”. The following diagram is a high-level example of the virtual partitioning of an Active Directory database, and an illustration of the replication of these partitions to domain controllers within a forest. In the example below, replication of ADP1 takes place to a domain controller in the “A1.com” and “2.1.A1.com” domains, and replication of ADP2 takes place only to a domain controller in the “1.A1.com” domain.

Page 76 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Schema

Configuration

A1.com

1.A1.com DC.A1.com 2.1.A1.com DC.1.A1.com ADP1 A1.com

1.A1.com

ADP2

DC.2.1.A1.com

2.1.A1.com

© 2004 MUSTANSHI R BHAR MAL

Figure 15.1: Example of ADPs within a Windows Server 2003 Active Directory Forest • Factor B2: Understanding the rules and conditions for creation of custom ADPs ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the specific rules and conditions necessary to support the creation of a custom ADP within the forest. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The creation of custom ADPs within a Windows Server 2003 is associated with the following facts  Microsoft has not defined any technical limits on the maximum number of ADPs a Windows Server 2003 Active Directory forest is able to support. Limitations on the maximum number of ADPs are a reflection of the feasible management, replication, and financial overheads associated with each required custom ADP, the forest owner(s) / organisation is willing to accommodate.  It is only possible to create custom ADPs within a Windows Server 2003 Active Directory forest, and only on Windows Server 2003 domain controllers in the forest. Replication and use of ADPs is restricted to Windows Server 2003 domain controllers.  A prerequisite to the creation of a custom ADP within a Windows Server 2003 Active Directory forest is that a Windows Server 2003 domain controller, and not a Windows 2000 domain controller, hosts the forest-level FSMO role, Domain Naming Master. Where the current host of this FSMO role is a Windows 2000 domain controller, then it is necessary to transfer this role temporarily to a Windows Server 2003 domain controller, create the custom ADP, then transfer the role back to the original host domain controller.  A custom ADP is capable of holding any Windows Server 2003 Active Directory objects, except security principal objects (user, computer, group (security-enabled) account objects), as it uses the same Active Directory Schema.  The objects created and stored within a custom ADP are not, by default, replicated to the Global Catalog for the forest.  An ADP is required to comply with the same DNS and X.500 distinguished name (DN) naming conventions as other objects within the Active Directory. The creation

Page 77 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

of a custom ADP requires the assignment of a naming context within the forest (see later for details).  The placement of custom ADPs within a forest is determined by:  Specific namespace requirements for the ADPs  Requirement to logically group ADPs within a forest  Requirements to use a specific domain partition as the default security descriptor reference domain for the application directory partition • Factor B3: Understanding the uses and capabilities of custom ADPs ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the uses and capabilities of custom ADPs, to assist in the determination of their requirement for the forest. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The design for Windows 2000 Active Directory only permitted the storage of data that met the criteria of been “relatively static but globally interesting”. The design of the replication functions of Windows 2000 Active Directory reflected these data characteristics. However, custom ADPs within Windows Server 2003 Active Directory, allow an organisation to extend the functionality of an Active Directory infrastructure to now hold dynamic data, and hence generate a greater return on investment for the design and deployment of this infrastructure. Dynamic data within an ADP can be stored as “dynamic objects”, which are a new feature of Windows Server 2003 Active Directory, and are created from a new auxiliary object class called “Dynamic-Object”. Note that the use of “dynamic objects” is only available when the functional level of the forest is operating at “Windows Server 2003”. The use of an Active Directory infrastructure to hold dynamic data hence allows the use of LDAP and ADSI to access and manage the data stored within these partitions. The replication of an ADP to only specific Windows Server 2003 domain controllers within a forest facilitates the continued and distributed availability of an ADP without:  Compromising the viability of the dynamic data it stores due to replication latencies  Creating superfluous replication traffic via the unnecessary replication to all domain controllers for a domain / forest • Factor B4: Understanding the characteristics of “dynamic objects” ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the characteristics of “dynamic objects” when determining the requirements for custom ADPs within this forest. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The “Dynamic-Object” auxiliary class contains an (optional) attribute called entryTTL that provides each object created within this class a time-to-live value. This value is set during object creation, and can be modified post-object creation. However, the absence of any modifications to the value of this attribute results in its removal from the Active Directory by the normal garbage-collection processes, once the time-to-live expires for this object.

Page 78 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

It is important to note that a dynamic object deleted because its TTL has expired does not leave a tombstone object. Note that it is not possible to convert an object created as a dynamic entry to become a static entry, and vice versa. • Factor B5: Understanding the influence of data characteristics on the design and use of custom ADPs ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation is considering the use of an ADP but wishes to understand how the characteristics of the data to be stored within an ADP will influence the decision to use an ADP or not. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Where an application generates a large volume of data and each unit of data can be categorised as large (for example, hundreds of kilobytes in size or larger), then this application may not be suitable for the use of an ADP. This is because the host of an ADP must be a Windows Server 2003 domain controller and hence, the requirement to read and write large volumes of data on a regular basis (assumed due to the dynamic nature of the data to be stored in the ADP) will have a direct impact on the performance of each host domain controller. There may also be an associated detrimental impact on the network infrastructure for the, albeit selective, replication of the large objects within the ADP. Where an application generates a large volume of data that is extremely volatile, but requires replication to multiple physical locations within the organisation, then the use of an ADP may not be suitable for this application. Inter-Site replication latencies may also work against the requirement to use up-to-date data that is extremely volatile (such as financial or short-term data gathering statistical metadata). 8.9.2. Determination of the Requirements for Custom ADPs Consider the following when determining the requirements for the design and implementation of one or more custom ADPs within the forest: • Factor A1: Determination of the requirements for custom ADPs using examples of applications and services that can benefit from the use of an ADP ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to identify examples of applications and services that can use ADPs when determining the requirement for ADPs. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Microsoft Windows Server 2003 DNS is an example of a service that can use an ADP within a forest to store zone data. In Windows 2000 Active Directory, the Windows 2000 DNS service could only store data within the Active Directory as “Active Directoryintegrated-zones” that were replicated to all domain controllers within a domain, whether they ran the DNS service or not. Windows Server 2003 DNS and Active Directory supports the following options for storage and replication of DNS zone data within the Active Directory (see the Organisation-Wide Active Directory Plan process “Design of a DNS Infrastructure” for details):

Page 79 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Storage of the DNS zone data in the default ADP “ForestDNSZones”, and hence replication to all Windows Server 2003 domain controllers in the forest operating DNS.  Storage of the DNS zone data in the default ADP “DomainDNSZones”, and hence replication to all Windows Server 2003 domain controllers in the domain operating DNS.  Storage of the DNS zone data in the domain partition, and hence replication to all domain controllers within the domain (this option is provided fro backwards compatibility with legacy Windows 2000 domain controller operating DNS.  Storage of the DNS zone data in a custom ADP, and hence selective replication to Windows Server 2003 domain controllers in the forest included within the “Replica List” for the custom ADP. TAPI-based programs can use TAPI application directory partitions to store and retrieve information to facilitate H.323-based IP telephony calls and multicast conferencing. The TAPI application directory partition will publish the user names, computer names, and IP addresses which the TAPI can then use to translate user or computer names to IP addresses. Note that most applications and services, designed to create and use ADPs within a forest typically, contain tools and utilities to automate the creation, management, and deletion of an associated custom ADP. This design methodology strongly recommends, where possible, the exclusive use of any tools provided with an application or service for the creation and management of custom ADPs. The “domain management” section of the Windows Server 2003 command line tool, ntdsutil.exe, supports the creation and management of custom ADPs. Using the above information, execute the following:  Determine the requirements for the design and implementation of one or more custom ADPs  Where there is a requirement for the design and implementation of one or more custom ADPs, then determine the following:  The applications and services that will require support via custom ADPs  The total number of custom ADPs required 8.9.3. Determination of the Data Characteristics for Required Custom ADPs Consider the following where an organisation has identified the requirements for the design and implementation of one or more custom ADPs, and wishes to determine the data characteristics (nature, size, and frequency of change) for each required custom ADP: • Factor A2: Determination of the security requirements for data to be stored within an ADP ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the design and implementation of one or more custom ADPs, and  Wishes to determine security requirements to be associated with the data each custom ADPs may be required to store.

Page 80 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Most custom ADPs will support the storage and use of dynamic data. Where the nature of dynamic data is security sensitive, such as dynamic financial data, then it is necessary to consider unauthorised access to this data as a security breach. The selection of the default “security descriptor domain” (see later step) must hence reflect the security requirements of such data. Execute an analysis to determine any requirements to secure access to data stored within any required custom ADP. • Factor A3: Determination of the size of the data to be stored within an ADP ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the design and implementation of one or more custom ADPs, and  Wishes to determine the size of the data each required ADP will store, the impact of the size of the data to be stored within an ADP on the host domain controllers, and the subsequent influence on the design of a replication topology for an ADP ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Where there is a requirement to configure an application to use an ADP to store and use its data, and where the size of this data may be substantial (hundreds (or more) of kilobytes per object / groups of objects), then this will influence the associated storage requirements for a host Windows Server 2003 domain controller. Large volumes of data within one or more custom ADPs, replicated to a host Windows Server 2003 domain controller, will increase the size of the Active Directory database (NTDS.dit). This may hence place greater demands on disk space and requirements to support greater I/O processing by the host domain controllers. Large volumes of data written to an Active Directory ADP, replicated to other Windows Server 2003 domain controller hosts, will have an impact on the supporting network infrastructure via bandwidth consumption to transport this data. Using the above information, execute an analysis to determine the following:  The size of the data each ADP will be required to initially store, and the growth potential and requirements for this data  The influence of the data sizing requirements on the design for the hardware specifications of the Windows Server 2003 domain controllers hosting the ADPs  The influence of the size and frequency of change of this data on the replication requirements of the ADP • Factor A4: Determination of the volatility of the data to be stored within an ADP ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation  Has identified the requirement for the design and implementation of one or more custom ADPs, and

Page 81 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Wishes to determine the volatility of the data each custom ADP is required to store, the impact of this volatility on the host domain controllers, and the influence on the design of a replication topology for an ADP ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Dynamic data stored within a custom ADP that changes very frequently would incur an overhead on the host Windows Server 2003 domain controller, to write each completed transaction to the transaction logs, and then to the Active Directory database. This design methodology recommends consideration of the potential for substantial increases in intra-Site replication traffic due to custom ADP replication. For example, the replication of a custom ADP, supporting dynamic data that experiences very frequent large changes, to one or more other Windows Server 2003 domain controllers within the same Site. Note that inter-Site replication latencies may have an impact on the validity of volatile data stored within an ADP upon arrival at a destination domain controller. Using the above information, execute an analysis to determine the following:  The predicted volatility of the data each custom ADP will be required to store  The influence of the volatile nature of data on the design for the hardware specifications of the Windows Server 2003 domain controllers hosting the ADPs  The influence of the volatility, and hence frequency of change of this data, on the replication requirements of the ADP 8.9.4. Determination of the Design Requirements for the Name and Namespace of an ADP Consider the following where an organisation has identified the requirements for the design and implementation of one or more custom ADPs, and wishes to determine the DNS name and namespace design requirements for each required custom ADP: • Factor B6: Understanding namespace rules for custom ADPs ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the design and implementation of one or more custom ADPs, and  Wishes to understand the DNS namespace rules for custom ADPs ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: As discussed earlier, the assigned DNS namespace and naming context of a custom ADP influences its placement within the forest. It is possible to create a custom ADP within a Windows Server 2003 Active Directory forest as:  A new tree, and hence a discrete DNS namespace  A child of an existing domain partition  A child of another existing custom ADP within the forest The following illustrations depict these three naming context options for custom ADPs:

Page 82 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

ADP1

A1.com

1.A1.com

2.1.A1.com

© 2004 MUSTANSHI

R

BHAR

MAL

Figure 15.2: A Custom ADP (ADP1) Created as a New DNS Namespace

A1.com

1.A1.com ADP1.1.A1.com

2.1.A1.com

© 2004 MUSTANSHI

R

BH

ARMAL

Figure 15.3: A Custom ADP (ADP1) Created as a Child of an Existing Domain

A1.com

1.A1.com

ADP1.1.A1.com 2.1.A1.com

© 2 0 0 4 MU S TA N S H I

R

BHAR

MAL

ADP2.ADP1. 1.A1.com

Figure 15.4: A Custom ADP (ADP2) Created as a Child of an Existing Custom ADP (ADP1) Note that it is not possible to create a new Active Directory Domain as a child of an existing custom ADP.
ADP1

A1.com

1.A1.com

A2.ADP1
© 2004 MUSTANSHI
R

BHARMAL

Figure 15.5: Cannot Create a Domain as a Child of a Custom ADP • Factor A5: Determination of the namespace design requirements for the application(s) that will use each required ADP

Page 83 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved. ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the design and implementation of one or more custom ADPs, and  Wishes to determine the namespace design requirements for specific applications that will use the required ADPs ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Because an ADP is a component of the overall forest namespace, it uses the same DNS and X.500 DN naming conventions as other naming contexts within the forest, such as domains. The name, presence, and position within a namespace of a naming context such as an ADP will influence the X.500 DN for this partition and all objects created within this partition. Applications that use LDAP or ADSI to access or manage data within an ADP may use the X.500 DN of an ADP to access the objects held within this partition, for example, to initiate a search within this ADP for specific objects and so on. Hence, it is possible to configure an application to start all searches at a specific RDN within the forest namespace to facilitate the search facility for clients of this application. If an application is already configured to use a namespace that is not currently represented within the forest (where the custom ADP for this application requires creation), then it is possible to assign this custom ADP this required namespace and hence exist as a new tree within the forest. Using the above information, execute an analysis to determine the following:  The applications that will use the custom ADPs  The namespace design requirements for these applications the appropriate ADPs are required to support • Factor A6: Determination of the design requirements to group multiple ADPs for ease of management ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the design and implementation of one or more custom ADPs, and  Wishes to determine the design requirements to group multiple custom ADPs within a forest, to simplify their management ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The distinguished name of a custom ADP within a forest defines its logical placement within the forest. As discussed and illustrated earlier, it is possible to design and implement custom ADPs as child ADPs of other custom parent ADPs. The design and implementation of the logical grouping of multiple custom ADPs within a forest is associated with the following advantages:  LDAP and application searches configured with a base DN at the root of a custom ADP-tree will generate continuation references to the child custom ADPs.

Page 84 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 The grouping of ADPs within can forest can assist in the exclusion of their namespaces from within LDAP searches for non-ADP related information. For example, it is possible to configure a metadirectory solution to exclude a complete DN within the Active Directory DIT, and hence improve performance of the solution.  The grouped ADPs may share the same “security descriptor reference domain” (see later for details) and hence a common administration model Note that the grouping of custom ADPs into an “ADP-tree” will generate a dependency between children and parent ADPs. The continued existence of a child ADP will hence depend upon the continued existence of the parent ADP. This may hence influence the ability to remove unwanted ADPs, where it is possible to identify one or more dependents upon their existence. Using the above information, execute an analysis to determine the following:  The requirements to group custom ADPs together within an Active Directory DIT to support ease of management, LDAP searches, and so on  The custom ADPs that require logical collation into groups and the ADPs that require exclusion from one or more groups of ADPs • Factor B7: Understanding the assignment of the default security descriptor reference domain for an ADP ♦ Criteria for Execution: The considerations for this factor are to be considered where an organisation:  Has identified the requirement for the design and implementation of one or more custom ADPs, and  Wishes to consider the influence of the assignment of the default security descriptor reference domain for an ADP on namespace design options ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: (See the next step for details on security descriptor domains for custom ADPs) If the application or service that creates the ADP does not specify a specific domain to represent the “security descriptor domain” for the ADP, then Active Directory automatically selects a default domain. The selection of a default “security descriptor domain” is a reflection of the logical positioning of the new custom ADP within the forest namespace. The next section discusses the rules for assignment of the default “security descriptor domain”. Where an organisation does not wish to change the default assignment of the “security descriptor reference domain” of a custom ADP, then it should consider the name and namespace positioning of an ADP carefully. Note that this design methodology does not recommend any changes to the assigned “security descriptor reference domain” for a custom ADP following the creation and population of the ADP with objects and data. If there is a requirement for a specific custom domain to represent the “security descriptor reference domain” for an ADP, then it is necessary to define this, within a “cross-reference” object, prior to the creation of the custom ADP. • Factor A7: Determination of the name resolution design requirements for ADPs ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:

Page 85 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Has identified the requirement for the design and implementation of one or more custom ADPs, and  Wishes to determine the name resolution design requirements for clients to find and access a custom ADP ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Because an ADP is an integral component of the forest namespace, and it must comply with the same DNS naming conventions as other partitions within the forest (such as domains), it is necessary to reference it via the DNS infrastructure for the forest. Where there is a requirement for the use of LDAP version 3.0 to access and manage a custom ADP, then it is necessary to:  Create a DNS zone to support the namespace of the custom ADP, and  Create, within this DNS zone, an appropriate LDAP service resource record (SRV RR) Using the above information, execute an analysis to determine the following:  The requirements to support name resolution by clients of each required custom ADP  The design requirements for the DNS infrastructure to support these name resolution requirements • Factor D1: Generation of the design for the name and namespace of each required custom ADP ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has complete all design analysis tasks to determine the design requirements for the name and namespace of each required custom ADP, and  Wishes to generate the design to support the identified requirements ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology requires that the design for the name and namespace of each required custom ADP comprise the following format and contents:  A detailed design of the name and namespace for each required custom ADP to support the following:  The namespace requirements of applications that will use the custom ADPs  The grouping of ADPs to support ease of their management, execution of LDAP queries, and so on.  The design of modifications to the DNS infrastructure for the Active Directory to support name resolution by clients of custom ADPs 8.9.5. Determination of the Required Security Descriptor Domain for an ADP Consider the following information when determining the design requirements for the selection and assignment of the required “security descriptor reference domain” for each custom ADP:

Page 86 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved. • Factor B8: Understanding security descriptor reference domains ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the design and implementation of one or more custom ADPs, and  Wishes to understand the concepts of security descriptor reference domains, and their relationships with custom ADPs ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The “security descriptor reference domain” defines a domain name for the default security descriptor for objects inside a custom application directory partition. Hence, the “security descriptor reference domain” determines the domain whose administrative groups will have permissions to manage the partition. For example, a custom ADP, named ADP1.A1.com, references the security descriptor of the A1.com domain, and hence, the administrators of the domain A1.com will be able, by default, to manage this custom ADP. • Factor B9: Understanding the assignment rules for default security descriptor reference domains ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the design and implementation of one or more custom ADPs, and  Wishes to understand the rules used to assign the default security descriptor reference domain for a custom ADP ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: As stated earlier, where an administrator elects not to use a cross-reference object to define a specific domain to be the “security descriptor reference domain” for a custom ADP, prior to its creation, then Active Directory will assign a default “security descriptor reference domain”. Active Directory uses the following rules to assign a default “security descriptor reference domain” to a custom ADP:  Upon creation of a custom ADP as a new tree in a forest, Active Directory assigns the forest root domain as its default “security descriptor reference domain”, and hence only the appropriate security principals within this domain may manage the custom ADP.  Upon creation of a custom ADP as a child partition of an existing domain partition, Active Directory assigns the parent domain as its default “security descriptor reference domain”, and hence only the appropriate security principals within this domain may manage the custom ADP.  Upon creation of a custom ADP as a child partition of an existing custom ADP, Active Directory assign the parent domain of the parent ADP as the child ADPs default “security descriptor reference domain”, and hence only the appropriate security principals within this domain may manage the child custom ADP.

Page 87 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

The following illustrations explain these rules for assignment of the default “security descriptor reference domain” for custom ADPs:
Default Security Descriptor Reference Domain

ADP1

A1.com

Forest Root Domain

1.A1.com

2.1.A1.com

© 2004 MUSTANSHI

R

BHAR

MAL

Figure 15.6: Assignment of Forest Root Domain as Default Security Descriptor Reference Domain for Custom ADP Created as new Tree

Default Security Descriptor Reference Domain 1.A1.com

A1.com

ADP1.1.A1.com 2.1.A1.com
© 2004 MUSTANSHI
R

BHAR

MAL

Figure 15.7: Assignment of Parent Domain as Default Security Descriptor Reference Domain for Custom ADP

Default Security Descriptor Reference Domain 1.A1.com

A1.com

ADP1.1.A1.com 2.1.A1.com

© 2004 MUSTANSHI

R

BHAR

MAL

ADP2.ADP1. 1.A1.com

Figure 15.8: Assignment of Parent Domain as Default Security Descriptor Reference Domain for Custom Child ADP • Factor A8: Determination of the influence of requirements to secure ADP data on the selection of the security descriptor reference domain ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the design and implementation of one or more custom ADPs, and  Wishes to determine the influence of the nature of the data, which a custom ADP will store, on the selection of the security descriptor reference domain

Page 88 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The selection of a “security descriptor reference domain” for a custom ADP assigns administrators within this domain access and management rights to the ADP and the data stored within the ADP. Hence, where the proposed contents of an ADP, such as variable financial data, have a requirement for a constrained security access profile, then it is necessary to select the “security descriptor reference domain” with care. It is necessary to develop and apply an access control model for a custom ADP at the time of creation. Due to the representation of a custom ADP within a forest as a naming context, and association with a “security descriptor reference domain” (default or custom), all objects within the ADP will have an access control list with the default permissions derived from the associated “security descriptor reference domain”. It is hence necessary to consider this inheritance of permissions within an ADP when designing the security model for the ADP. Using the above information, execute an analysis to determine the following:  The requirements to secure access to data held within a custom ADP (from previous analysis to determine the name and namespace requirements for custom ADPs)  The security principals to which the ADP owner(s) / data owner(s) wish to allow and disallow access and management of the data  The requirements for the selection of a specific security descriptor reference domain, and not the default domain assigned by Active Directory, using the rules outlined above. • Factor A9: Selection of the security descriptor reference domain ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation  Has identified the requirement for the design and implementation of one or more custom ADPs, and  Has identified the requirement for the selection of a specific domain to represent the security descriptor reference domain for one or more custom ADPs  Wishes to select the required domain ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: If an application or service does not specify, during the creation of an ADP, the domain partition that will provide the default assignments of security descriptors for ADP objects, then Active Directory assigns a default “security descriptor reference domain”. If there is a manual requirement to select a custom “security descriptor reference domain” for a custom ADP, then it is necessary to execute the following:  Identify the required domain to become the “security descriptor reference domain” for a custom ADP, prior to the creation and population of the custom ADP with objects and data, and  Create “cross-reference” object that specifies the DN for the security descriptor reference domain for the custom ADP

Page 89 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Note that after creation of a custom ADP, it is possible to use the command line tool, ntdsutil.exe, to amend the reference domain for the ADP, prior to population of the ADP with objects and data. Note that execution of this command requires the security context of a member of the “Enterprise Admins” group in the forest root domain, or the “Domain Admins” in the reference domain for the ADP. Using the above information, execute the following:  Select the required security descriptor reference domain for each appropriate custom ADP  Generate a diagram illustrating the logical relationships between ADPs and security descriptor reference domains 8.9.6. Determination of the Requirement to Delegate the Creation of ADPs Consider the following when determining the requirements to delegate the creation of ADPs within a Windows Server 2003 Active Directory forest: • Factor A10: Determination of the requirements to delegate ADP creation to support a distributed and / or decentralised administration model for the Active Directory forest ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the design and implementation of one or more custom ADPs, and  Wishes to determine the requirements to delegate the creation of custom ADPs due to the presence of a distributed and / or decentralised administration model for the Active Directory forest ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The creation of an ADP within a forest requires the security context of a member of the “Domain Admins” group (of the “security descriptor reference domain” for the ADP) or the “Enterprise Admins” group for the forest. Where administrators of a domain are not members of the Domain Admins group for the domain, and there is a requirement to permit them to create custom ADPs, then it is necessary to delegate the rights to execute this task. It is possible for members of the “Domain Admins” or “Enterprise Admins” groups to delegate the creation of custom ADPs via the pre-creation of a “cross-reference” object within the Active Directory, and assignment of the permission to create a custom ADP to the delegated administrator(s). Using the above information, execute the following:  Determine the requirements to delegate the creation of custom ADPs to one or more administrators within one or more domains in the forest  Determine the administrators that require the delegated right to create one or more custom ADPs • Factor A11: Determination of the requirements to control the creation parameters of a custom ADP delegated for creation ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:

Page 90 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Has identified the requirement for the design and implementation of one or more custom ADPs  Has identified the requirement to delegate the creation of one or more custom ADPs, and  Wishes to determine the requirements to control the creation parameters for custom ADPs, delegated for creation ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Pre-creation of the cross-reference object supports control over the following creation parameters for custom ADPs:  The name of the ADP  The security descriptor reference domain for the ADP  The replica list detailing the domain controllers to host replicas of the ADP Using these three creation parameters, members of the Domain Admins and Enterprise Admins groups can hence carefully control delegation of the creation of custom ADPs within the forest. Using the above information, execute the following:  Determine the requirements to control one or more of the three creation parameters for custom ADPs  Where there is a requirement to control these creation parameters, determine the following:  The creation parameters that require control  The custom ADPs, delegated for creation, that require assignment of pre-defined values for one or more of these creation parameters  The required values for these creation parameters 8.9.7. Generation of the Design for Custom ADPs Consider the following when generating the design for each required custom ADP: • Factor D2: Understanding the required format and content of the design for each required custom ADP ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the design and implementation of one or more custom ADPs, and  Wishes to understand the required content and format of the design for each required custom ADP ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology requires that the design for each required custom ADP comprise the following format and contents:

Page 91 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 A detailed description of the application or service which requires support via a custom ADP within the Windows Server 2003 Active Directory forest  A detailed description of the characteristics of the data each custom ADP is required to support  A detailed description and diagrams illustrating the required name and namespace for each required custom ADP, and the design requirements for the supporting DNS infrastructure (DNS zone and LDAP SRV RRs, where required), and so on.  A detailed design of the requirements for the use of an Active Directory-assigned (default) “security descriptor reference domain” or a custom selected reference domain  A detailed design of the requirements for the delegation of creation of custom ADPs within the forest, identifying:  The required custom ADPs delegated for creation  The procedure for the creation of the cross-reference object(s), and the definition of the required creation parameters for the appropriate custom ADPs Following completion and verification of the design for custom ADPs, distribute copies of the completed designs to the application / service administrators within the forest.

Page 92 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

9.

Design for Directory Quotas
Directory quotas are a new feature for Windows Server 2003 Active Directory. The functionality and design concepts of directory quotas closely reflect the “Disk Quotas” feature introduced in Windows 2000 Server, with the extension now to Windows Server 2003 Active Directory.

9.1.

Background Information The primary objective for the use of directory quotas is to prevent denial of service (accidentally or maliciously by an administrator or other delegated security principal that has the right to create objects within a directory partition) via the population of an Active Directory with so many objects that a domain controller depletes all available disk space. As many organisations are familiar with the disk quota feature introduced with Windows 2000, the following table provides a comparison between disk quotas and directory quotas:
Feature Default Settings Point of Application Disk Quotas (Windows 2000 and Windows Server 2003) Disk quotas are not enabled and set by default NTFS formatted disk volumes. It is not possible to set disk quotas on file or folders on the volume. Directory Quotas (Windows Server 2003 Active Directory) Directory quotas are not enabled and set by default Directory partitions within a Windows Server 2003 Active Directory infrastructure (it is not possible to set directory quotas on (for example) OUs in a directory partition) Quotas are set per security principal, per directory partition Number of objects within the directory partition The number of objects owned by a security principal in the directory partition Manually set for the directory partition (when directory quotas are enabled) and applies to all security principals that do not have an explicit quota limit set. The default (but modifiable) setting is unlimited (no limit on the number of objects) The members of the Domain Admins and Enterprise Admins groups are exempt from quota limits on a directory partition Only Windows Server 2003 domain controllers can enforce directory quotas on a directory partition Directory quotas are managed only from the command prompt using the “DS* quota” tools such as: dsadd (add); dsget (retrieve information); dsmod (modify); dsmove (move); dsquery (query); dsrm (remove)

Scope of Application Unit of Control Quota Measurement Default Quota Settings for Security Principals

Quotas are set per user, per volume Disk space on the disk volume (in bytes) The volume of disk space that is owned by a security principal on a disk volume Manually set for entire disk volume for all security principals (when disk quotas are enabled) that do not have an explicit quota limit set

Default Quota Settings for Administrators Enforcement of Quotas Interface for Managing Quotas

The members of the local Administrators group are exempt from quota limits on a disk volume with quotas enabled Any Windows 2000 and Windows Server 2003 server can use and enforce disk quotas Disk quotas can be managed from a Windows interface or command prompt (using the “fsutil quota” tool)

Table 16.1: Comparison between Disk and Directory Quotas

Page 93 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved. 9.2.

Process Approach This design methodology proposes execution of the following approach to design directory quotas: 1. 2. 3. Understand the concepts of directory quotas Determine the requirements for the design and implementation of directory quotas Where it is possible to identify the requirements for the design and implementation of directory quotas, then: a. Identify the directory partitions where directory quotas are required b. Identify the security principals to receive directory quota limits c. Determine the design requirements for directory quota limits

d. Determine the design requirements for the tombstone quota factors for each required directory quota limit 9.3. Process Components Based upon the above approach, this process is composed of the following six components: • Understanding the concepts of directory quotas • Determination of the requirements for the design and implementation of directory quotas • Identification of the target directory partitions where quotas are required, and the security principals to receive directory quota limits • Determination of the design requirements for the directory quota limits • Determination of the design requirements for the tombstone quota factors for each required directory quota limit • Generation of the design for directory quotas 9.4. Deliverables of Process Components This process will have the following deliverables: • An understanding of the concepts of directory quotas • Determination of the requirements for the design and implementation of directory quotas within this forest • Identification of the required directory partition(s) to receive directory quotas, and the security principals to receive directory quota limits • Determination of the design requirements for the directory quota limits • Determination of the design requirements for the tombstone quota factor values for each required directory quota limit • Generation of a design for directory quotas 9.5. Inter-Component Dependencies Each component of this process will have the following inter-component dependencies:

Page 94 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Forest Plan – Inter-Component Dependencies for Process to Design Directory Quotas START
Understanding directory quotas Determination of the requirements for directory quotas Identification of the target domain partition(s) and security principals

Generation of a design for directory quotas

Determination of the design requirements for tombstone quota factor values for each required directory quota

Determination of the design requirements for directory quota limits
© 2004 MUSTANSHI
R

BHARMAL

9.6.

Process to Design Directory Quotas
Forest Plan – Process to Design Directory Quotas
Is there a requirement for the design of directory quotas? YES Is there a requirement modify the default tombstone quota factor? Execute A6 Execute D1 Execute A2 – A5 NO NO YES Execute A7 Execute D2

START

Execute B1 – B2

Execute A1

END
© 2 0 0 4 MU ST AN SH I
R

BHAR

MAL

9.7.

Process Considerations Consider the following when generating a design for directory quotas. Presented within the following six sections are the considerations for this process: 1. 2. 3. 4. 5. 6. Considerations to assist in the understanding of the function and features of directory quotas Considerations for the determination of the requirement for directory quotas Considerations for the identification of the target directory partition and security principals Considerations for the determination of the design requirements for the required directory quota limits Considerations for the determination of the design requirements for the tombstone quota factors for each required directory quota Considerations for the generation of a design for directory quotas

9.7.1.

Understanding Directory Quotas Consider the following when attempting to understand the concepts of directory quotas in Windows Server 2003 Active Directory:

Page 95 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved. • Factor B1: Understanding concepts of directory quotas Windows Server 2003 Active Directory ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the concepts of directory quotas in Windows Server 2003 Active Directory ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology recognises six key concepts of directory quotas that require understanding prior to generation of the design. These six concepts are:  The concept of tombstone quota factors  The concept of object types within the scope of directory quotas  The concept of quota enforcement  The concept of the “NTDS Quotas” container  The concept of quota application to forest-wide directory partitions  The concept of quota warnings When attempting to understand tombstone quota factors, consider the following:  Following the “deletion” of an object within a directory partition of an Active Directory infrastructure, Active Directory does not actually delete this object. Instead, Active Directory converts the object into a tombstone object, to facilitate the removal of all replicas of this object held on all other domain controllers that hold copies of this directory partition. The default age for a tombstone object is 60 days.  Each directory partition, with directory quotas enabled, is associated with a tombstone quota factor. The default setting for the tombstone quota factor is 100, specifying that all objects and tombstone objects within the directory partition, owned by a security principal, will equally contribute to the measurement of compliance against the quota limit for that security principal.  It is possible to adjust the tombstone quota factor, at the partition level, to become a percentage of the actual quota limit for the directory partition, for a security principal. For example, if a directory partition quota limit of 100 objects is set, and the tombstone quota factor is set to 25%, then each object that is deleted and exists as a tombstone within that directory partition will now only be measured as a quarter of an object. Hence, four tombstone objects will count as one normal object. When attempting to understand the concept of object types within the scope of directory quotas, consider the following:  The definition of directory quota limits on a directory partition only specifies limits on the numbers of objects owned by a security principal. There is no specification as to the types of objects to which the directory quota limits apply.  Hence, the only method to control the types of objects a security principal may create within a directory partition is via the use of permissions, which are inherent, assigned, or inherited by the security principal. For example, a Windows Server 2003 member print server, as a security principal within an Active Directory domain, has the inherent permission to publish print queue objects within the Active Directory. Hence, the computer account for the member print server owns all print queue objects published to the Active Directory by that computer.

Page 96 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

When attempting to understand the concept of quota enforcement, consider the following:  Active Directory enforces quota limits only against originating directory operations, and not against replicated operations.  As it is only possible for a Windows Server 2003 domain controller to enforce directory quotas, quotas set on a directory partition will only be effective where all the domain controllers for a partition are Windows Server 2003 domain controllers. This will hence influence the selection of directory partitions to support directory quotas. When attempting to understand the concept of the “NTDS Quotas” container, consider the following:  It is only possible to view the “NTDS Quotas” container using the security context of a member of the “Domain Admins” or “Enterprise Admins” security groups.  Active Directory automatically creates a single “NTDS Quotas” container for each directory partition within the forest upon creation of the partition. The “NTDS Quotas” container will exist regardless of the enabled or disabled (default) status of quota limits for that directory partition.  The “NTDS Quotas” container holds the “Quota Control” entry objects, which Active Directory creates when upon activation of directory quota limits for that directory partition. The quota control objects detail the security principals assigned a quota, and the quota limits assigned to this security principal. When attempting to understand the concept of quota application to forest-wide directory partitions, consider the following:  Although the Active Directory Schema and Configuration partitions are both logical partitions within the Active Directory database, only the Configuration partition supports the configuration and assignment of directory quotas. The Schema partition does not support the “NTDS Quotas” container, and hence does not support directory quotas.  Although it is possible to enable directory quotas on the Configuration partition, it is not feasible for most Active Directory forests. This is because the Configuration partition is a forest wide partition, and as only Windows Server 2003 domain controllers can enforce directory quotas, directory quotas may only be effective against this partition where all domain controllers within the forest are operating Windows Server 2003. When understanding the concept of quota warnings, consider the following:  Active Directory only enforces directory quotas against originating directory operations, and not against replication operations, and hence Active Directory only generates quota warnings when originating directory operations exceed defined quota limits.  If the execution and completion of an originating directory operation may exceed a quota limit for the security principal executing the operation, then Active Directory displays a warning notice. This hence prevents the completion of any originating directory operations that triggered the warning, such as the creation of an object within the directory partition. The following is an example of the warning notice Active Directory display when the originating directory operation, to create a new user account named “quotasuser2”, exceeds the quota limit for the security principal executing the operation:

Page 97 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

Figure 16.1: Directory Quota Limit Warning 9.7.2. Determination of the Requirement for Directory Quotas Consider the following information when determining the requirements for the design and implementation of directory quotas within one or more directory partitions for this forest: • Factor B2: Understanding the spectrum of application of directory quotas ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the spectrum of application of directory quotas when determining their requirement for the forest. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: As stated in the background information section of this process, the primary objective for directory quotas are to prevent accidental or malicious denial of service via the creation of a large number of objects that eventually depletes the disk space on one or more domain controllers within a forest. However, directory quotas can have many other uses, such as:  Facilitating the forest owner by controlling the size of the Global Catalog for the forest by limiting the number of objects created within a forest.  Facilitating the network team by controlling intra- and inter-Site replication traffic generated by the creation, modification and deletion of objects within the Active Directory  Facilitating the management of domain controller hardware resources such as CPU cycles and RAM by limiting the number of objects that have to be written and replicated by the domain controllers of a directory partition  Enforcing security policies on object creation within the forest, especially where there are requirements to delegate object creation tasks to security principals not members of the Domain Admins group in each domain. • Factor A1: Determination of the requirements for directory quotas within a forest ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the requirements for the design and implementation of directory quotas within a forest. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When determining the requirements for the design and implementation of directory quotas, consider the following examples of their use within a forest:

Page 98 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 Because directory quotas are set at the directory partition level, they can be set for the Configuration partition of a forest, a domain partition within a forest, or an application directory partition within a forest.  In organisations where there is a decentralised administration model and the requirement to create domains to permit service autonomy, it is possible for the forest owner to apply directory quotas to each of these domains. The forest owner may hence gain control over the number of objects created and populated to the Global Catalog of a forest.  Within forests where custom application directory partitions are required, the use of directory quotas can limit the number of objects created by the clients of the ADP.  Metadirectory solutions configured to create objects within a directory partition of a forest can, if incorrectly configured and unchecked, very easily create thousands (or more) objects. The application of a directory quota limit on the security principal used to provide the security context for the metadirectory solution could assist in preventing this scenario. Note that it is necessary to ensure consideration to the ownership of the objects created by the metadirectory solution and the long-term impact of directory quotas. Using the above examples of the uses of directory quotas within a forest, determine the requirements for the use of directory quotas within this forest, to control the excessive creation and / or deletion of objects within directory partitions. 9.7.3. Identification of the Target Directory Partitions and Security Principals Consider the following information where an organisation has identified the requirements for the design and implementation of directory quotas, and wishes to identify the target directory partitions and security principals for the directory quotas: • Factor A2: Selection of directory partition(s) to receive directory quotas ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirements for the design and implementation of directory quotas, and  Wishes to select one or more directory partitions to receive directory quotas ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When determining the directory partition(s) within a forest that require assignment of directory quotas, consider the following:  The selection criteria must reflect the primary objectives of directory quotas, which are to control the creation and deletion of directory objects within a directory partition.  Although the onus is with the forest owner(s) to define their criteria for the selection of a target directory partition, this design methodology proposes the following example criteria:  A directory partition is subject to the frequent and large volumes of originating directory objects, such as the creation of significant numbers of directory objects by delegated, non-administrator security principals. For example, a domain required to support one or more autonomous divisions within the organisation.

Page 99 of 122

Last printed 28/5/2004 12:03 a5/p5

© 2004 Mustan Bharmal. All Rights Reserved.

 A directory partition is subject to the creation and deletion of significant numbers of directory objects by automated processes such as directory integration solutions, Active Directory-enabled applications, services, and so on.  A directory partition is supported by domain controllers in remote and unsecured (physical and network) locations.  Domain controllers in logical network locations, such as a DMZ, support a directory partition, and hence are susceptible to denial of service attacks.  Directory quotas are unsuitable for directory partitions compliant with the following example criteria:  Physically and network secured domain controllers, managed exclusively by trusted administrators, support a directory partition, such as a dedicated forest root domain.  Only trusted administrators execute all originating directory operations, such as object creation and deletion, within a directory partition.  A custom ADP has a “security descriptor reference domain”, which is a trusted domain, supported exclusively by secured domain controllers, and trusted administrators. Using the above information, execute the following:  Define the selection criteria for the identification of a directory partition to receive directory quotas.  Evaluate all identified directory partitions within the forest that can support directory quotas, and evaluate each partition against the defined criteria.  Identify all directory partitions required to receive directory quotas. • Factor A3: Selection of security principals to receive directory quotas ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirements for the design and implementation of directory quotas, and  Wishes to identify all target security principals for directory quotas within each inscope directory partition ♦ Factor Considerations: When determining the security principals within each in-scope directory partition that require assignment of directory quotas, consider the following:  Prior to selection of target security principals, it is necessary to note the following:  When selecting security principals to assign quota limits to, only select security principals with the inherent appropriate permissions to create and delete objects within the selected directory partition, or security principals delegated these permissions.  Remember that there is no control on the types of objects created, just the number of objects owned by a security principal.

Page 100 of 122 12:03 a5/p5

Last printed 28/5/2004

© 2004 Mustan Bharmal. All Rights Reserved.

 Quota limits should target, where possible, security groups rather than individual security principals. This approach will facilitate the management of directory quotas where quotas can be enforced or removed simply by changing the membership of the appropriate security groups.  The effective quota limits for security principals, members of multiple security groups that have individual quota limits applied, will be the maximum of the quotas assigned to this security principal. Hence, this is an important consideration when selecting security groups to apply quota limits, which do not exclusively support this function.  Only those security principals that reside within a nominated or default assigned “security descriptor reference domain” for a custom ADP, can be assigned directory quotas for that custom ADP.  Although the onus is with the forest owner(s) to define their criteria for the selection of security principals to receive directory quotas, this design methodology proposes the following example criteria:  Security principals delegated the permission to create objects within a directory partition, but have the potential to attempt a denial of service attack.  Security principals within a domain, created to support service autonomy, which have been delegated the right to create objects such as (for example) shared folder objects and so on. It is very easy to publish a large number of shared folder objects to an Active Directory partition.  The security principal used as the security context for an application, configured to create objects within a directory partition such as a domain or an ADP, is a potential candidate for directory quotas. For example, applications like metadirectory solutions can, if incorrectly configured, very easily create thousands of objects in a directory partition in an automated mode. The impact of this on the domain controller hardware resources and the supporting network infrastructure (from the replication traffic subsequently generated) can be substantial Using the above information, execute the following:  Define the criteria for the selection of security principals to receive directory quotas  For each identified in-scope directory partition, identify all appropriate security principals, and evaluate against the defined criteria.  Identify all security principals within each in-scope directory partition required to receive directory quotas. 9.7.4. Determination of the Design Requirements for Directory Quota Limits Consider the following information when determining the design requirements for directory quota limits, for assignment to all security principals identified within in each in-scope directory partition: • Factor A4: Determination of the influence of the requirements for security principals to execute delegated duties on the design for directory quota limits ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirements for the design and implementation of directory quotas, and

Page 101 of 122 12:03 a5/p5

Last printed 28/5/2004

© 2004 Mustan Bharmal. All Rights Reserved.

 Wishes to determine the influence of the requirements for identified target security principals to perform their delegated duties, when determining the required quota limits ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When determining the limits to be set on directory quota entries for security principals, consideration should be given to the delegated duties of the security principal that will receive (directly or indirectly via group membership) the directory quota limit. If a security principal is required to create objects, then that security principal will own all objects unless there is manual transference of object ownership to another security principal, and hence to the quota limit of that security principal. This design methodology proposes an example approach to control the number of objects a delegated security principal can create, but not restrict the execution of their assigned duties. This approach involves the following:  Implement a directory quota limit that represents the typical number of objects that a security principal will create within a set period, such as a week or month.  Upon expiration of this set period and / or compliance with the quota limit, transfer the ownership of the objects created by that security principal to another security principal, such as the Domain Admins group.  The transference of object ownership will effectively reset the quota count, allowing the security principal to create objects once again. This approach hence allows a delegated security principal to create objects as per their duties, but limits the number of objects they create to (for example) meet security requirements within the organisation. An example of a scenario, where this approach is applicable, is for help desk operators within an organisation allowed to create user accounts within a domain / OU within a domain. Using the above information and example approach, execute the following:  Determine the originating directory activities that identified security principals are required to execute, such as creation of directory objects  Determine the requirements for the procedures to transfer ownership of objects created by these security principals, to reduce / reset their quotas  Determine the required frequency for execution of the tasks to transfer ownership  Determine the minimum and maximum number of objects each security principal is may create between each execution of transference of object ownership  Determine the minimum quota limit for each in-scope security principal / group of security principals • Factor A5: Determination of the influence of the dynamic nature of the objects, to be created within the directory partition, on the determination of the required quota limits ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirements for the design and implementation of directory quotas, and

Page 102 of 122 12:03 a5/p5

Last printed 28/5/2004

© 2004 Mustan Bharmal. All Rights Reserved.

 Wishes to determine the influence of the dynamic nature of objects, which require creation within an in-scope directory partition, on the determination of the required quota limits ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The nature of the objects that require creation within a directory partition can influence the design of the quota limits, such as a custom ADP that holds dynamic objects. Because of the dynamic nature of the objects, they may be deleted fairly soon after their creation. Hence, the design for the limits on the number of dynamic objects that require creation within, for example, an ADP should reflect the average time to live for these objects. For example, if it has been determined that an application is required to create 1000 objects within a custom ADP per day (evenly throughout the day) and the average TTL for these objects is 24 hours, then every 24 hours these objects would be deleted from the ADP. Hence, the quota limit for the ADP should be set to 1500 objects (to allow for contingency) since the number of objects that will be owned by the security principal for this application will remain at a constant 1000 every day. Note that the deletion of dynamic objects may not generate a tombstone objects, and hence the tombstone quota factor may not apply. It is hence important to consider non-dynamic objects that have a short time to live, because these objects will create tombstone objects following their deletion from the directory partition. Hence, these objects will still contribute to the quota limit for the owner security principal until 60 days have passed following object deletion. Using the above information, execute the following:  Determine the nature of directory objects that will require creation and deletion within in-scope directory partition, and the influence of these requirements on the determination of the required directory quota limits.  Determine the influence of dynamic objects on the design for the required directory quota limits, within each in-scope directory partition. • Factor D1: Understanding the required format and content of the design for directory quota limits ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the design and implementation of directory quotas on one or more directory partitions within the forest  Has determined the design requirements for the directory quota limits, and  Wishes to understand the required content and format of the design for the required directory quota limits ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology requires that the design for required directory quota limits comprise the following format and contents:  A detailed design for the required approaches to manage object ownership and compliance with quota limits once implemented within the production environment Page 103 of 122 12:03 a5/p5 Last printed 28/5/2004

© 2004 Mustan Bharmal. All Rights Reserved.

 A detailed design for the required directory quota limits on each directory partition, identifying:  The target security principals  The directory quota limits for the target security principals  A diagram illustrating the:  Directory partitions within the forest  The directory partitions with directory quotas enabled  The high-level details of the required directory quotas for these partitions  The directory partitions with directory quotas disabled (default) 9.7.5. Determination of the Design Requirements for Tombstone Quota Factors Consider the following information when determining the design requirements for tombstone quota factors for directory partitions with directory quotas enabled and set: • Factor A6: Determination of the influence of the requirements for security principals to execute delegated duties on the design for tombstone quota factors ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirements for the design and implementation of directory quotas, and  Wishes to consider the requirements for identified target security principals to perform their delegated duties, when determining the required tombstone quota factors for the required directory quotas limits ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The requirement to not restrict the duties of a security principal delegated the right to create objects also applies to the design of the tombstone quota factor where that security principal is assigned the permissions to delete objects that they have created. If the deletion of objects created by a security principal with an assigned quota limit is not considered, the quota count for that security principal will not be decremented for any objects that they delete until 60 days have passed. This can hence influence their abilities to execute their assigned duties, and increase administrative overheads. Where security principals may be required to delete objects they created on a regular basis (as dynamic objects) between transfers of object ownership, then it is necessary to reduce the tombstone quota factor, to accommodate more deleted objects than undeleted objects. For example, a security principal employed as a service account for a metadirectory solution may delete objects more frequently, on each scheduled execution of an object flow, than create objects. This design methodology requires that the determination of the appropriate tombstone quota factor for a directory partition must determine the following:  The frequency of object deletion by the security principal that owns / creates the objects and has a quota limit assigned

Page 104 of 122 12:03 a5/p5

Last printed 28/5/2004

© 2004 Mustan Bharmal. All Rights Reserved.

 The percentage representation that deleted objects have against new objects created by the security principal Using the above information, execute the following:  Determine the originating directory activities that identified security principals are required to execute, such as creation of directory objects, which may be influenced by the design for tombstone quota factors  Determine the requirement to use the default value (100) (where one tombstoned object has an equal weighting against a quota limit as a non-tombstoned object) or the requirement to reduce the tombstone quota factor, and hence permit the security principals to delete objects more frequently than create objects.  Where there is a requirement to reduce the default value (100) for the tombstone quota factor, determine minimum required factor value. • Factor A7: Determination of the influence of security requirements for object deletion ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirements for the design and implementation of directory quotas, and  Wishes to determine the influence of security requirements for object deletion when determining the required tombstone quota factors for the required directory quotas limits ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: It is possible to employ the tombstone quota factor to enforce the security requirements for a domain partition to prevent, for example, the excessive deletion of objects, and hence the concurrent recreation of new objects. It is important to be aware of the security implications associated with a reduction in the tombstone quota factor. For example, it is possible for a help desk user, assigned a tombstone quota factor less than 100, to create many temporary user accounts, delete the majority of the accounts created and only retain a few active accounts, but still not exceed their quota limits. However, with the default value for the tombstone quota factor, the help desk user will not be able to create any new objects for 60 days, until the graceful removal of the tombstone objects from the directory partition via the garbage collection processes. It is important to note that the tombstone quota factor applies to the directory partition level and will hence affect all directory quota assignments for that partition. Note that dynamic objects created within an ADP do not generate tombstone objects following their deletion by the Active Directory due to the expiry of their TTL value. Using the above information, determine the influence of security requirements on the determination of the requirements, and values, for tombstone quota factors. • Factor D2: Understanding the required format and content of the design for tombstone quota factors ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:

Page 105 of 122 12:03 a5/p5

Last printed 28/5/2004

© 2004 Mustan Bharmal. All Rights Reserved.

 Has identified the requirement for the design and implementation of directory quotas on one or more directory partitions within the forest  Has determined the requirements to design custom tombstone quota factors, and  Wishes to understand the required content and format of the design for the required tombstone quota factor values ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology requires that the design for tombstone quota factors comprise the following format and contents:  A detailed design for the required tombstone quota factors for each directory partition that requires directory quota limits  A diagram illustrating the required custom tombstone quota factors against each directory partition that requires directory quota limits

Page 106 of 122 12:03 a5/p5

Last printed 28/5/2004

© 2004 Mustan Bharmal. All Rights Reserved.

10.

Selection and Raising of the Forest Functional Level
This process requires execution where an organisation wishes to select and / or raise the functional level of the forest from the default level, to implement features only available in the higher functional levels. As the highest functional level for the forest is “Windows Server 2003”, this process does not require execution for any forests already at this functional level.

10.1.

Process Objectives The objectives of this process are to assist an organisation in the design of a process to select and / or raise the functional level for this forest via execution of the following: • Attainment of an understanding of the considerations associated with selection and raising of the functional level for this forest • Determination of the business and technical objectives and requirements to select and / or raise the functional level of the forest where the current forest functional level is not “Windows Server 2003” • Identification of the prerequisite tasks that require execution to raise the functional level for this forest • Design of the process to select and / or raise the functional level for this forest

10.2.

Process Scope The following elements define the scope for this process: • The logical boundary for this Windows Server 2003 Active Directory forest • The requirements for the continued presence or absence of Windows domain controllers running legacy (Windows NT 4.0 and Windows 2000) operating systems within domains supported by this forest

10.3.

Background Information Prior to the execution of this process to raise the functional level for this forest, it is necessary to understand the following concepts: • The concept of forest functional levels for Windows Server 2003 Active Directory forest • The differences between the forest functional levels in feature and legacy domain controller operating system support • The potential paths to the “Windows Server 2003” forest functional level • The variables this process to select and / or raise the functional level for this forest is required to address

10.3.1. Concept of Forest Functional Levels Forest functional levels are a new feature for Windows Server 2003 Active Directory based upon Windows 2000 Active Directory Mixed and Native mode features. Functional levels, as their name suggests, allow the managed implementation of new features within a Windows Server 2003 Active Directory infrastructure following the upgrade or decommissioning of remnants of legacy directory services within the forest (Windows NT 4.0 and Windows 2000 domain controllers).

Page 107 of 122 12:03 a5/p5

Last printed 28/5/2004

© 2004 Mustan Bharmal. All Rights Reserved.

A Windows Server 2003 Active Directory forest can exist within one of the following three forest functional levels: 1. 2. 3. “Windows 2000” forest functional level “Windows Server 2003 Interim” forest functional level “Windows Server 2003” forest functional level

The functional level of a Windows Server 2003 Active Directory forest is hence a strict reflection of the requirements for this forest to support any legacy Windows NT 4.0 and Windows 2000 domain controllers within any domain within this forest. Thus, the operating system used by member servers and client computers within any domain within this forest has no influence on the functional level for this forest. A forest at the “Windows Server 2003” functional level will continue to support, for example, member servers and clients operating legacy Windows operating systems such as Windows NT 4.0 Server and Workstation, respectively. The top functional level is “Windows Server 2003”, as a forest at this level only supports Windows domain controllers running the Windows Server 2003 operating system. A Windows Server 2003 Active Directory forest obtains a forest functional level upon creation of the first Windows Server 2003 domain controller for the forest within one of the following scenarios: • As a fresh installation of a Windows Server 2003 Active Directory forest • Via the in-place upgrade of a Windows NT 4.0 PDC for a domain • Via the in-place upgrade of a Windows 2000 domain controller within an existing mixed or native mode Windows 2000 domain • Via the creation of an additional Windows Server 2003 domain controller into an existing mixed or native mode Windows 2000 domain Creation of the first Windows Server 2003 domain controller, in one of the above scenarios, will define one of two possible default forest functional levels. The following table illustrates this:
Legacy Directory Service No legacy directory service, only Windows Server 2003 Active Directory Only Windows NT 4.0 Domain(s) Windows NT 4.0 and Windows 2000 Active Directory Only Windows 2000 Active Directory Default Windows Server 2003 Forest Functional Level “Windows 2000” “Windows Server 2003 Interim” “Windows 2000” “Windows 2000”

Table 17.1: Potential Forest Functional Levels to Reflect Current Legacy Directory Service Infrastructures 10.3.2. Differences between Forest Functional Levels The support for legacy operating systems for domain controllers within a forest is the foundation for the differences between the forest functional levels. Where there is a continued requirement to support domain controllers running legacy operating systems within this forest, then it is necessary to disable the advanced Windows Server 2003 features for all domain controllers within a forest via the forest functional level. Remove the requirement to support Page 108 of 122 12:03 a5/p5 Last printed 28/5/2004

© 2004 Mustan Bharmal. All Rights Reserved.

the domain controllers running legacy operating systems and it is possible to remove the restrictions by raising the forest functional level. Raising the functional level to “Windows Server 2003” indicates to the Windows Server 2003 domain controllers within the forest that the domain owner(s) have no future requirements to introduce any new domain controllers running legacy operating systems, and it is thus safe to enable the advanced features. Note that although this process enables advanced features, it is irreversible and raising the forest functional level hence permanently disables support for domain controllers running the appropriate legacy operating systems. Each of these three forest functional levels supports domain controllers running the following different combinations of Windows server operating systems: 1. “Windows 2000” forest functional level supports Windows NT 4.0, Windows 2000, and Windows Server 2003 domain controllers. Within this functional level, it is hence possible to introduce new additional domain controllers running any of these Windows Server operating systems. “Windows Server 2003 Interim” forest functional level supports only Windows NT 4.0 and Windows Server 2003 domain controllers. Within this functional level, it is hence not possible to introduce new additional domain controllers running the Windows 2000 Server operating system. Note the following about this special functional level: a. It is selectable within the Active Directory Installation Wizard only when upgrading a Windows NT 4.0 PDC to create the first domain in the forest b. It is possible to raise the forest functional level (prior to “Windows Server 2003”) for the target forest of an upgraded Windows NT 4.0 domain, to the “Windows Server 2003 Interim” forest functional level via ADSI. See the Migration Plan process “design of the required migration path(s)”, and the step within this process, “determination of the specific pre-migration tasks to prepare a target domain”, for details on setting the “Windows Server 2003 Interim” forest functional level. All upgraded Windows NT 4.0 domains created within a Windows Server 2003 forest, raised to the “Windows Server 2003 Interim” forest functional level, will inherit this functional level. 3. “Windows Server 2003” forest functional level only supports Windows Server 2003 domain controllers. Within this functional level, it is hence not possible to introduce any new additional domain controllers running any legacy (Windows NT 4.0 or Windows 2000) Windows Server operating system.

2.

The following diagram illustrates a summary of the differences in the features available within each forest functional level, and the differences in support for legacy Windows domain controllers:

Page 109 of 122 12:03 a5/p5

Last printed 28/5/2004

© 2004 Mustan Bharmal. All Rights Reserved.

W2K3 DC

LEGEND:
“NT4" = Windows NT 4.0 “W2K" = Windows 2000 “W2K3" = Windows Server 2003 “DC" = Domain Controller

Improvements in GC Replication InetOrgPerson object class change Improvements in Schema Management Cross-Forest TrustRelationships Creation of Dynamic Objects Domain Renaming
NT4 DC W2K3 DC

Improved Group Membership Replication Improved ISTG algorithm
W2K3 DC

Improved Group Membership Replication Improved ISTG algorithm Application Directory Partitions Universal Group Caching

W2K DC NT4 DC

Application Directory Partitions Universal Group Caching

Application Directory Partitions Universal Group Caching

DCPROMO from Media

DCPROMO from Media

DCPROMO from Media
© 2004 MUSTANSHI
R

BHAR

MAL

“Windows 2000”

“Windows Server 2003 Interim”

“Windows Server 2003”

Figure 17.1: Feature Comparison and Domain Controller Support within Different Forest Functional Levels 10.3.3. Potential Paths to the “Windows Server 2003” Forest Functional Level The potential paths to the “Windows Server 2003” forest functional level depend upon the presence and requirements to support legacy operating systems within an organisation. Illustrated below are the potential upgrade paths from the “Windows 2000” and “Windows Server 2003 Interim” levels to the “Windows Server 2003” forest functional level:

Page 110 of 122 12:03 a5/p5

Last printed 28/5/2004

© 2004 Mustan Bharmal. All Rights Reserved.

Forest Plan – Potential Paths to Raise Forest Functional Level to “Windows Server 2003” LEGEND:
“NT4" = Windows NT 4.0 “W2K" = Windows 2000 “W2K3" = Windows Server 2003 “DC" = Domain Controller YES Add a new Windows Server 2003 domain controller to an existing legacy Windows domain infrastructure Is there a requirement to add to an existing Windows domain infrastructure?

START

New Windows Server 2003 Domain Controller

NO Either no existing Windows domain infrastructure or no requirement to add to existing Windows domain infrastructure

NT4 DC

W2K DC

NT 4 DC

W2K DC

W2K3 DC

Windows NT 4.0 Domain

Windows 2000 (Mixed Mode) Domain

Windows 2000 (Native Mode) Domain

Windows Server 2003 Domain

NT4 DC

NT4 DC

W2K3 DC Via ADSIEdit

W2K DC

W2K3 DC

“Windows Server 2003 Interim” Forest Functional Level

“Windows 2000” Forest Functional Level

W2K3 DC

“Windows Server 2003” Forest Functional Level
© 2 0 0 4 MU S TAN SH I
R

BHAR

MAL

Figure 17.2: Potential Upgrade Paths between Forest Functional Levels to the “Windows Server 2003” Forest Functional Level

Page 111 of 122 12:03 a5/p5

Last printed 28/5/2004

© 2004 Mustan Bharmal. All Rights Reserved.

10.3.4. Variables in the Process to Raise the Functional Level for this Forest This process, to raise the functional level for this forest, is required to identify and address the following three variables associated with forest functional levels: 1. 2. 3. 10.4. The presence or absence of legacy (Windows NT 4.0 and Windows 2000) domain controllers within this forest The active and passive requirements to select and / or raise the functional level for this forest The tasks, where necessary, to attain compliance with prerequisites to raising the functional level for this forest

Process Approach Within a production environment, the process to raise the functional level of a forest is simply a matter of opening the “raise forest functional level” dialog box, selecting the desired level, and clicking “OK”. However, this simple action can drastically influence business continuity within the entire forest and, as this process is irreversible, this further compounds the consequences of such an action. It is hence imperative that this process is approached in a methodically manner, with all pertinent considerations take into account, and all prerequisites for this process understood, identified, and executed. To reflect the requirements for care and consideration demanded by the process to raise the functional level for this forest, this design methodology proposes the following approach: 1. 2. 3. 4. Understand the prerequisites and criteria for raising the functional level for this forest Determine the active and passive requirements to raise the functional level for this forest Qualify the identified active and passive requirements to select and / or raise the functional level for this forest Generate the design to raise the functional level for this forest

10.5.

Process Components Based upon the above approach, the process to select and / or raise the functional level for this forest is composed of the following components: • Understanding the prerequisites and criteria for raising the functional level for this forest • Determination of the active and passive requirements to raise the functional level for this forest • Qualification of the identified active and passive requirements to select and / or raise the functional level for this forest • Generation of the design to raise the functional level for this forest

10.6.

Deliverables of Process Components The process to raise the functional level for this domain will have the following deliverables: • An understanding of the: ♦ Differences in features and operating system support for legacy Windows domain controllers within each Windows Server 2003 Active Directory forest functional level, and Page 112 of 122 12:03 a5/p5 Last printed 28/5/2004

© 2004 Mustan Bharmal. All Rights Reserved. ♦ The prerequisites and criteria to raise the functional level for this forest, and ♦ The potential paths to raise the functional level of a Windows Server 2003 Active Directory forest to the “Windows Server 2003” level • The determination of the active and passive requirements to raise the functional level for this forest • The criteria required to qualify the identified requirements • The results of the evaluation of identified requirements against the defined criteria • The list of prerequisite tasks that require execution prior to raising the functional level for this forest • The generation of the design to select / raise the functional level for this forest 10.7. Inter-Component Dependencies Each component of this process will have the following inter-component dependencies:
Forest Plan – Inter-Component Dependencies for Process to Select and Raise the Forest Functional Level START
Understand the prerequisites and criteria to raise the forest functional level Determination of the active and passive requirements to select / raise the forest functional level Qualification of identified active and passive requirements to select / raise the forest functional level
© 2 0 0 4 MU S TAN SH I
R

Generation of design to select / raise the functional level for this forest

BHAR

MAL

10.8.

Process to Select & Raise the Forest Functional Level for this Forest Forest Plan – Process to Select and Raise the Forest Functional Level
Execute B1 – B2 Execute A1 Is there a requirement to raise the forest functional level? YES Execute D1 Execute A2 – A3 Execute B3
© 2004 MUSTANSHI
R

START

NO

END

BHARMAL

10.9.

Process Considerations Consider the following information when selecting and / or raising the functional level of this Windows Server 2003 Active Directory forest. Presented within the following four sections are the considerations for this process: 1. Consideration to assist in understanding the prerequisites and criteria for raising the functional level for this forest

Page 113 of 122 12:03 a5/p5

Last printed 28/5/2004

© 2004 Mustan Bharmal. All Rights Reserved.

2. 3. 4.

Considerations for the determination of the active and passive requirements to raise the functional level for this domain Considerations for the qualification of the identified active and passive requirements to raise the functional level for this domain Considerations for the generation of the design to raise the functional level for this domain

10.9.1. Understanding the Prerequisites for Raising the Functional Level for this Forest Consider the following information when attempting to understand the prerequisites for raising the functional level for this forest: • Factor B1: Understanding prerequisites to raising the forest functional level ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the prerequisites to raising the forest functional level ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When attempting to understand the prerequisites to raising the forest functional level, consider the following:  The process to raise the forest functional level is a one-way irreversible process. Figure 17.2 illustrates the potential paths for the process to raise the forest functional level.  It is necessary to execute the process to raise the forest functional level, using the security context of a member of the Enterprise Admins” security group within the forest root domain.  This design methodology recommends execution of the process to raise the functional level of this forest on the domain controller hosting the Schema Master FSMO role.  It is only possible to raise the functional level of a forest to “Windows Server 2003” where is possible to identify compliance with both of the following criteria:  All the domains within the forest are at the domain functional level of “Windows 2000 Native” or “Windows Server 2003”, and  All domain controllers within all domains are running only Windows Server 2003.  Note that all domains within the forest operating at the “Windows 2000 Native” domain functional level will be automatically upgraded to the “Windows Server 2003” domain functional level when the forest is raised to the “Windows Server 2003” functional level. 10.9.2. Determination of the Requirements to Raise the Functional Level for this Forest Consider the following information when determining the active and passive requirements to raise the functional level for this forest: • Factor B2: Understanding active and passive requirements to raise the forest functional level ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:

Page 114 of 122 12:03 a5/p5

Last printed 28/5/2004

© 2004 Mustan Bharmal. All Rights Reserved.

 Is able to identify that this forest is not at the “Windows Server 2003” forest functional level, and  Wishes to understand the concept of active and passive requirements to raise the functional level for this forest ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology identifies two perspectives for the requirements to raise the functional level of this forest. These are:  Active requirements to raise the forest functional level, and  Passive requirements to raise the forest functional level An “active” requirement to raise the forest functional level is one where the owner(s) of the forest wish to enable one or more advanced features, currently disabled by the current functional level for this forest, via the active removal or upgrade of all legacy domain controllers within each domain in the forest. Where it is not possible for forest owner(s) to identify any specific business or technical requirements for new advanced features, they may adopt a passive approach to raising the forest functional level. A natural consequence of the removal of support for legacy domain controllers is that the forest functional level may be raised, and hence passively enable the new advanced features. Note that a passive requirement to raise the functional level may be associated with the fact that this forest was a “green field” forest implementation, and not an “upgrade” of an existing legacy Windows 2000 forest. The noticeable differences between these approaches are the timescales to accomplish these requirements. The active pursuit to enable new advanced features will hasten processes to upgrade or remove legacy domain controllers within each domain for this forest, as there may be a business or technical driver to support the requirements for the new feature(s). The focus for a passive approach may be on the gradual upgrade or removal of legacy domain controllers in line with planned processes, and hence this approach is typically associated with a longer timescale for completion. • Factor A1: Determination of the specific active and / or passive requirements to raise the functional level for this forest ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified that this forest is not currently at the “Windows Server 2003” forest functional level, and  Wishes to determine the active and / or passive requirements to raise the functional level of this forest ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The identification of the drivers and requirements to raise the functional level for this forest will influence the following:  The potential path taken towards the “Windows Server 2003” forest functional level, where more than “one hop” is necessary (from “Windows 2000” to “Windows Server 2003 Interim” to “Windows Server 2003”) Page 115 of 122 12:03 a5/p5 Last printed 28/5/2004

© 2004 Mustan Bharmal. All Rights Reserved.

 The timescales to achieve this requirement  The qualification of the identified requirements via their evaluation against defined criteria  The prerequisite tasks that require execution prior to raising the forest functional level This design methodology recommends the following approach to determine the requirements to raise the functional level for this forest:  Determine the current forest functional level for this forest.  Identify any active requirements to raise the functional level for this forest via execution of the following steps:  Examine the background information section of this process to understand the advanced features available within each forest functional level.  Conduct an analysis against each advanced feature and determine any business or technical requirements for these features.  Where it is possible to identify the active requirement for one or more advanced features, then execute the following:  Grade the requirements via the assignment of a priority value for each feature. For example, where it is possible to identify the requirements for six advanced features, grade them from one to six where one is the highest priority requirement, and six the lowest.  Determine the target functional level based upon the requirement(s) to enable a specific required feature set for this forest  Based upon the status of this forest, determine the prerequisite tasks that require execution to raise the forest to the desired functional level. For example, it may be possible to identify the following requirements: • The requirement to develop an action plan to remove any dependencies upon legacy domain controllers, such as compliance with the minimum recommended number of domain controllers for each domain within this forest to preserve their integrity • The requirement to replace existing server hardware for the domain controllers to comply with the minimum hardware specifications of standard server builds • There may be financial and technical issues associated with the legacy domain controllers within this forest that require resolution, such as: ♦ Budgetary constraints on the purchase of new server hardware may result in the requirements to retain legacy domain controllers operating on old server hardware. ♦ There may be compatibility issues of the old server hardware for the legacy domain controllers with the minimum hardware specifications specified within the standard server builds for Windows Server 2003 domain controllers within this forest. ♦ It may be possible to identify the requirements to retain legacy domain controllers to support legacy line of business applications. Note that it also may not be possible to upgrade the legacy LOB applications or there may Page 116 of 122 12:03 a5/p5 Last printed 28/5/2004

© 2004 Mustan Bharmal. All Rights Reserved.

be an upgrade / replacement scheduled for the near future. Until these issues are resolved, there is a requirement to retain the legacy domain controllers.  Identify any dependencies in the execution of the identified tasks and the potential timescales for their execution  Identify any passive requirements to raise the functional level for this forest via execution of the following steps:  Conduct an analysis to determine the current level of compliance of the forest with the prerequisites to raising the forest functional level. For example, this forest may not currently support, or have any future requirements to support legacy domain controllers, and is hence compliant with prerequisites to raise its functional level.  Where it is possible to identify existing legacy domain controllers within this forest, then determine their retention requirements and dependencies upon the legacy domain controllers. Note that raising the functional level for this forest may jeopardise its ability to support future requirements for legacy domain controllers.  Where it is possible to identify passive requirements to raise the functional level for this forest, then execute the following:  Determine the attainable functional level for this forest based upon the status of the forest or the completion of proposed tasks to remove or upgrade legacy domain controllers, where necessary.  Identify any prerequisite tasks that require execution to raise the forest to the desired functional level  Identify any dependencies in the execution of the identified tasks and the potential timescales for their execution Using the above information and approach, conduct an analysis to determine the following:  Any active requirements to raise the functional level for this forest  Where it is possible to identify any active requirements, then determine the priorities for any identified feature requirements, the target functional level to attain required features, and any associated prerequisite tasks and dependencies.  Any passive requirements to raise the functional level for this forest  Where it is possible to identify any active requirements, then determine the attainable functional level(s) based upon the current or proposed status for this forest, and any prerequisite tasks, their dependencies and timelines for execution, which require execution to raise the forest to the desired functional level. 10.9.3. Qualification of the Requirements to Raise the Functional Level for this forest Consider the following information when determining the criteria to qualify the identified requirements to raise the functional level for this forest, and evaluating the identified requirements against the defined criteria: • Factor B3: Understanding the requirements to define criteria ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation: Page 117 of 122 12:03 a5/p5 Last printed 28/5/2004

© 2004 Mustan Bharmal. All Rights Reserved.

 Has identified one or more active and / or passive requirements to raise the functional level for this forest, and  Wishes to understand the requirements to define criteria to qualify the active / passive requirements ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: It is quite simple to raise the functional level for this forest, requiring only a member of the “Enterprise Admins” group to select and implement the required functional level. However, to support the long-term consequences of this irreversible action, it is necessary to qualify all requirements to raise the functional level of this forest. Note that the onus is with the owner(s) of the forest and / or the organisation to take the initiative to define the specific criteria and evaluate identified active / passive requirements to raise the functional level against their defined criteria. This design methodology proposes that all identified active and passive requirements to raise the functional level for this forest must comply with defined feasibility criteria. If the requirements to raise the functional level are feasible, they may be designed and implemented, and vice versa. The criteria to evaluate the feasibility of the requirements to raise the functional level will identify whether the prerequisites for the execution of this action are met, and hence whether they are feasible propositions. Note that it is possible to action the lack of compliance with these criteria and hence ensure the feasibility of a proposal to raise the functional level for this forest. Following the definition of the criteria to qualify the identified requirements to raise the functional level for this forest, it will hence be possible to identify the following:  The feasibility status for the proposals to raise the functional level for this forest  The requirements and details of an action plan to attain compliance with previously failed criteria. • Factor A2: Determination of the criteria that will qualify the feasibility of proposals to raise the functional level for this forest ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified one or more active and / or passive requirements to raise the functional level of this forest, and  Wishes to determine the criteria that will qualify the feasibility of these identified requirements ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The objectives of these criteria are to evaluate and qualify all proposals and requirements to raise the functional level of this forest. When determining the criteria to evaluate and qualify the feasibility of identified requirements, consider the following:  These criteria must identify support for all prerequisites to raising the functional level for this forest.

Page 118 of 122 12:03 a5/p5

Last printed 28/5/2004

© 2004 Mustan Bharmal. All Rights Reserved.

 The following are examples of criteria to evaluate the feasibility of proposals to irreversibly raise the functional level of this forest:  Following the rise in the functional level for this forest to “Windows Server 2003”, it will not be possible to identify any future requirements for the support of domain controllers within this forest running legacy (Windows NT 4.0 and / or Windows 2000) Windows Server operating systems not supported by the new functional level. Note that without compliance with these criteria, it is unfeasible to implement the requirements to raise the functional level of this forest. There may be a future requirement to introduce additional legacy domain controllers into this forest to support, for example, the following example requirements: • It is possible to identify the requirement to consolidate multiple legacy Windows NT 4.0 domains into this new Windows Server 2003 Active Directory forest. As part of the migration process, there is a temporary requirement to introduce Windows NT 4.0 domain controllers into this forest. The selection of the “Windows Server 2003 Interim” forest functional level may hence be required to support this requirement. • It is possible to identify the requirement to consolidate multiple legacy Windows 2000 domains and forests into this new Windows Server 2003 domain and forest, and the server hardware for the legacy domain controllers is not capable of supporting Windows Server 2003. The hardware refresh cycle for servers in this forest will dictate procurement of new server hardware, and until then, it is necessary to continue support for the legacy Windows 2000 domain controllers.  Where this forest currently supports Windows NT 4.0 and / or Windows 2000 domain controllers, it is possible to either remove them or upgrade them to Windows Server 2003 domain controllers without: • Compromising the resilience, stability, performance, and availability of this forest, or • Compromising business continuity in any way  The introduction and employment of any new advanced features associated with the rise in functional level of this forest will not compromise the security, resilience, stability, performance, and availability of this forest, or business continuity in any way. Use the above information to determine the criteria necessary to qualify all requirements to raise the functional level for this forest. • Factor A3: Evaluation of identified requirements against define criteria ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified one or more active and / or passive requirements to raise the functional level for this forest,  Has defined the criteria to qualify the identified requirements, and  Wishes to execute the evaluation of the identified requirements against the defined criteria ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation:

Page 119 of 122 12:03 a5/p5

Last printed 28/5/2004

© 2004 Mustan Bharmal. All Rights Reserved.

This design methodology proposes the following approach to evaluate the feasibility of the proposal to raise the functional level for this forest:  Select an identified active or passive requirement to raise the functional level for this forest and evaluate the requirement against the defined criteria to determine its feasibility. Where there is a lack of compliance with a specific criterion, then develop an action plan to permit compliance.  Following the evaluation of all criteria to determine the feasibility of a requirement, execute all action plan tasks to ensure compliance, where necessary. If there was a requirement to execute an action plan, re-evaluate the requirement with all defined feasibility criteria. If it is still not possible to attain compliance with all defined feasibility criteria, then abandon the active or passive requirement to raise the functional level for this forest. Where it is possible to attain compliance with all defined feasibility criteria, then proceed with the design to implement the requirement.  Following evaluation of all identified active and passive requirements list the requirements that qualify against the defined criteria as feasible. The following are examples of the evaluation process, using the sample criteria defined above, to qualify the feasibility of an active or passive requirement to raise the functional level for this forest. The results of the evaluation process will be the identification of the feasibility of a requirement to raise the functional level of this forest and, where necessary, the action plan tasks to ensure compliance with defined criteria.  Criteria: Following the rise in the functional level for this forest to “Windows Server 2003”, it will not be possible to identify any future requirements for the support of domain controllers within this forest running legacy (Windows NT 4.0 and / or Windows 2000) Windows Server operating systems not supported by the new functional level.  Evaluation: Where it is possible to identify a lack of compliance with this criteria, then execute one of the following options as part of an action plan:  If it is possible to identify compliance with the following criteria, then it is possible to raise a “Windows 2000” forest functional level to the “Windows Server 2003 Interim” level: • The forest owner(s) have identified a potential future requirement to introduce a legacy Windows NT 4.0 domain controller into this forest (via an upgrade of a Windows NT 4.0 domain and the requirement continue support for BDCs), and • The forest owner(s) have not identified any requirements to support Windows 2000 domain controllers, currently or in the future  It is possible to raise the forest functional level to “Windows Server 2003 Interim” using ADSIEdit. See the Migration Plan process “design of the required migration path(s)”, and the step within this process, “determination of the specific premigration tasks to prepare a target domain”, for details on setting the “Windows Server 2003 Interim” forest functional level.  Where the current forest functional level is at “Windows 2000” and the forest owner(s) have identified a potential future requirement to introduce additional Windows 2000 domain controllers into this forest, then it is not possible to raise the functional level of this forest.

Page 120 of 122 12:03 a5/p5

Last printed 28/5/2004

© 2004 Mustan Bharmal. All Rights Reserved.

 Criteria: The removal or upgrade of existing legacy domain controllers to meet the prerequisites to the rise in functional level of this forest will not compromise the resilience, stability, performance, and availability of this forest, or business continuity in any way.  Evaluation: In order to evaluate this criterion, it is necessary to execute the following:  Identify the potential for the removal or upgrade of existing legacy domain controllers to compromise the resilience, stability, performance, and availability of this forest. For example, removing existing domain controllers that support interactive logons may increase the workload of remaining domain controllers within domains in this forest. Upgrading the operating system of legacy domain controllers to Windows 2000 or Windows Server 2003 (as appropriate for the target functional level) may decrease performance of the domain controllers and domains if the server hardware is incapable of supporting the workload on the domain controller.  Identify the potential for the removal or upgrade of existing legacy domain controllers to compromise business continuity. For example, removal of a Windows NT 4.0 domain controller without identification of the dependencies it generates on business critical processes, such as line of business applications that depend upon Windows NT 4.0 domain controllers, will hence compromise business continuity as the LOB may cease to function correctly.  Where it is possible to identify a lack of compliance with this criterion, and identify the potential cause(s), develop an appropriate counteraction plan, where possible. If it is not possible to counter the potential causes for the lack of compliance with this criterion, then it may not be possible to raise the functional level for this forest.  Criteria: The introduction and employment of any new advanced features associated with the rise in functional level of this forest will not compromise the security, resilience, stability, performance, and availability of this forest, or business continuity in any way.  Evaluation: In order to evaluate this criterion, it is necessary to execute the following:  Where this is an active requirement to introduce and use new advanced features, then for each required new feature, identify the potential for its use to compromise the security, resilience, etc, of this forest.  Where it is possible to identify a lack of compliance with this criterion, and the use of the new feature is hence controversial, develop a counteraction plan, where possible.  If it is not possible to counter the negative effects of the use of the new feature, then discard its use where possible, or abandon the requirement to raise the functional level for this forest. Using the above information and approach, evaluate all identified active and passive requirements, to raise the functional level for this forest, against the defined feasibility criteria. Identify all requirements that are unfeasible to implement and all action plan tasks necessary to attain compliance with feasibility criteria.

Page 121 of 122 12:03 a5/p5

Last printed 28/5/2004

© 2004 Mustan Bharmal. All Rights Reserved.

10.9.4. Generation of the Design to Raise the Functional Level for this forest Consider the following information when generating the design to raise the functional level for this forest: • Factor D1: Understanding the format and contents of the design of the process to raise the functional level for this forest ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the active and / or passive requirements to raise the functional level for this forest, and  Wishes to understand the format and contents of the design of the process to raise the functional level for this forest ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology requires that the design for process to select and raise the forest functional level comprise the following format and contents:  A detailed design to select and raise the functional level of this forest, identifying the following:  The following details for all identified active and passive requirements to raise the functional level for this forest: • The attainable functional level to support all identified active requirements for new advanced features • The current and proposed status of this forest to support all passive requirements to raise the forest functional level • The prerequisites that require execution for all active and passive requirements to raise the forest functional level, and the timelines and dependencies for their execution  The following details of the criteria to qualify the feasibility of the identified requirements to raise the functional level for this forest: • The details of the criteria to evaluate the feasibility of proposals and requirements to raise the functional level of this forest • The results of the evaluation of all identified active and passive requirements against the feasibility criteria • The details of all identified action plan tasks that require execution to attain compliance with all defined feasibility criteria  The design of a process to select and raise the functional level for this forest

Page 122 of 122 12:03 a5/p5

Last printed 28/5/2004