© 2004 Mustan Bharmal. All Rights Reserved.

Table of Contents
1. INTRODUCTION TO DOMAIN PLAN...................................................................................... ..........................3 1.1. DOMAIN PLAN SCOPE................................................................................................. ..........................3 1.2. BACKGROUND INFORMATION........................................................................................... .........................3 1.3. DOMAIN PLAN CONCEPTS....................................................................................................................... 3 1.4. DOMAIN PLAN OBJECTIVE............................................................................................ ..........................7 1.5. DOMAIN PLAN APPROACH................................................................................................................... ....8 1.6. DOMAIN PLAN PROCESSES....................................................................................................... ..............8 1.7. DELIVERABLES OF DOMAIN PLAN PROCESSES.......................................................................... ...................9 1.8. INTER-PROCESS DEPENDENCIES...................................................................................... ........................9 1.9. DOMAIN PLAN DESIGN PROCESS...................................................................................... .....................10 2. PARTITIONING A DOMAIN FOR OBJECT & RESOURCE MANAGEMENT............................................................ ......11 2.1. CRITERIA FOR THE EXECUTION OF THIS PROCESS........................................................................... ............11 2.2. PROCESS OBJECTIVE....................................................................................................................... ....11 2.3. BACKGROUND INFORMATION.............................................................................................................. .....11 2.4. PROCESS APPROACH........................................................................................................................ ...12 2.5. PROCESS COMPONENTS.................................................................................................................. .....12 2.6. DELIVERABLES FOR PROCESS COMPONENTS........................................................................... ..................13 2.7. INTER-COMPONENT DEPENDENCIES........................................................................................................ .13 2.8. PROCESS TO PARTITION A DOMAIN FOR OBJECT AND RESOURCE MANAGEMENT........................................... .....13 2.9. PROCESS CONSIDERATIONS.................................................................................................................. .14 3. DESIGN OF AN OBJECT & RESOURCE MANAGEMENT INFRASTRUCTURE.......................................................... ....21 3.1. BACKGROUND INFORMATION........................................................................................ ..........................21 3.2. PROCESS SCOPE...................................................................................................... .........................25 3.3. PROCESS APPROACH........................................................................................................................ ...25 3.4. PROCESS COMPONENTS.................................................................................................................. .....26 3.5. DELIVERABLES OF PROCESS COMPONENTS..................................................................................... ..........26 3.6. INTER-COMPONENT DEPENDENCIES........................................................................................................ .26 3.7. PROCESS TO DESIGN AN ORMI...................................................................................................... ......26 3.8. PROCESS CONSIDERATIONS.................................................................................................................. .26 4. DESIGN OF A GROUP POLICY OBJECT INFRASTRUCTURE.............................................................. ..................44 4.1. PROCESS OBJECTIVE................................................................................................. .........................44 4.2. PROCESS SCOPE...................................................................................................... .........................44 4.3. BACKGROUND INFORMATION........................................................................................ ..........................44 4.4. PROCESS APPROACH........................................................................................................................ ...47 4.5. PROCESS COMPONENTS.................................................................................................................. .....49 4.6. DELIVERABLES OF PROCESS COMPONENTS..................................................................................... ..........49 4.7. INTER-COMPONENT DEPENDENCIES........................................................................................................ .50 4.8. PROCESS TO DESIGN A GROUP POLICY OBJECT INFRASTRUCTURE................................................................ .50 4.9. PROCESS CONSIDERATIONS.................................................................................................................. .50 5. DESIGN OF A DELEGATION OF CONTROL (DOC) INFRASTRUCTURE............................................................... ..103 5.1. PROCESS OBJECTIVES.............................................................................................................. .........103 5.2. PROCESS SCOPE.................................................................................................... .........................103 5.3. BACKGROUND INFORMATION...................................................................................... ..........................104 5.4. PROCESS APPROACH...................................................................................................................... ...105 5.5. PROCESS COMPONENTS................................................................................................................ .....106 5.6. DELIVERABLES OF PROCESS COMPONENTS................................................................................... ..........106 5.7. INTER-COMPONENT DEPENDENCIES...................................................................................................... .106 5.8. PROCESS TO DESIGN A DELEGATION OF CONTROL INFRASTRUCTURE....................................... .....................107 5.9. PROCESS CONSIDERATIONS................................................................................................................ .107 6. DESIGN OF A SECURITY GROUP INFRASTRUCTURE....................................................................................... 144 6.1. PROCESS OBJECTIVE............................................................................................... .........................144 6.2. PROCESS SCOPE.................................................................................................... .........................144 6.3. BACKGROUND INFORMATION...................................................................................... ..........................145 6.4. PROCESS APPROACH...................................................................................................................... ...146 6.5. PROCESS COMPONENTS................................................................................................................ .....148 6.6. DELIVERABLES OF PROCESS COMPONENTS................................................................................... ..........148 6.7. INTER-COMPONENT DEPENDENCIES...................................................................................................... .148 6.8. PROCESS TO DESIGN A SECURITY GROUP INFRASTRUCTURE....................................................................... 149 Page 1 of 354 a5/p5 Last printed 28/5/2004 12:28

© 2004 Mustan Bharmal. All Rights Reserved.

6.9. PROCESS CONSIDERATIONS................................................................................................................ .149 7. DESIGN OF AN ORGANIZATIONAL UNIT INFRASTRUCTURE............................................................................ ...216 7.1. PROCESS OBJECTIVES.............................................................................................................. .........216 7.2. PROCESS SCOPE.................................................................................................... .........................216 7.3. BACKGROUND INFORMATION...................................................................................... ..........................216 7.4. PROCESS APPROACH...................................................................................................................... ...220 7.5. PROCESS COMPONENTS................................................................................................................ .....222 7.6. DELIVERABLES OF PROCESS COMPONENTS................................................................................... ..........223 7.7. INTER-COMPONENT DEPENDENCIES...................................................................................................... .223 7.8. PROCESS TO DESIGN AN OU INFRASTRUCTURE................................................................................ .......223 7.9. PROCESS CONSIDERATIONS................................................................................................................ .223 8. DESIGN FOR DOMAIN CONTROLLERS FOR THIS DOMAIN....................................................................... .........260 8.1. PROCESS OBJECTIVES.............................................................................................................. .........260 8.2. PROCESS SCOPE.................................................................................................... .........................260 8.3. BACKGROUND INFORMATION...................................................................................... ..........................260 8.4. PROCESS APPROACH...................................................................................................................... ...261 8.5. PROCESS COMPONENTS................................................................................................................ .....262 8.6. DELIVERABLES OF PROCESS COMPONENTS................................................................................... ..........262 8.7. INTER-COMPONENT DEPENDENCIES...................................................................................................... .263 8.8. PROCESS TO DESIGN DOMAIN CONTROLLERS FOR THIS DOMAIN.......................................................... ........263 8.9. PROCESS CONSIDERATIONS................................................................................................................ .263 9. DESIGN OF EXTERNAL TRUST RELATIONSHIPS........................................................................................ ....313 9.1. PROCESS OBJECTIVE............................................................................................... .........................313 9.2. PROCESS SCOPE.................................................................................................... .........................313 9.3. BACKGROUND INFORMATION...................................................................................... ..........................314 9.4. PROCESS APPROACH...................................................................................................................... ...316 9.5. PROCESS COMPONENTS................................................................................................................ .....317 9.6. DELIVERABLES OF PROCESS COMPONENTS................................................................................... ..........317 9.7. INTER-COMPONENT DEPENDENCIES...................................................................................................... .317 9.8. PROCESS TO DESIGN EXTERNAL TRUST RELATIONSHIPS.............................................................. ..............318 9.9. PROCESS CONSIDERATIONS................................................................................................................ .318 10. RAISING THE FUNCTIONAL LEVEL OF THIS DOMAIN................................................................. ..................339 10.1. PROCESS OBJECTIVES........................................................................................................... ..........339 10.2. PROCESS SCOPE.................................................................................................. .........................339 10.3. BACKGROUND INFORMATION.................................................................................... ..........................339 10.4. PROCESS APPROACH.................................................................................................................... ...345 10.5. PROCESS COMPONENTS............................................................................................................. ......345 10.6. DELIVERABLES OF PROCESS COMPONENTS................................................................................. ..........346 10.7. INTER-COMPONENT DEPENDENCIES.................................................................................................... .346 10.8. PROCESS TO RAISE THE FUNCTIONAL LEVEL OF THIS DOMAIN................................................ ..................346 10.9. PROCESS CONSIDERATIONS.............................................................................................................. .346

Page 2 of 354 a5/p5

Last printed 28/5/2004 12:28

© 2004 Mustan Bharmal. All Rights Reserved.

1.

Introduction to Domain Plan
This design methodology requires an organisation to generate a single “Domain Plan” for each required production Active Directory domain, within each required forest. Hence, where a Windows Server 2003 Active Directory infrastructure for an organisation consist of three forests supporting only four production domains, then four domain plans are required. Note that it is not necessary to generate a domain plan for test domains or non-production domains, which will not support business processes within an organisation.

1.1.

Domain Plan Scope The “Domain Plan” will assist the owner(s) and participants within this domain to generate a design for only those components of an Active Directory infrastructure that require implementation for an organisation at the domain level and not at any other Active Directory component (forest or site) level, or as part of a migration, change control, or management plan.

1.2.

Background Information Execute the processes within this Domain Plan following the completion of the processes within the respective Forest Plan for this domain, within the Windows Server 2003 Active Directory infrastructure. The results of the following Forest Plan processes provide indications as to intended function(s) of each required domain: • “Determination of the number of domains required” • “Determination of the structure and relationships of multiple domains” • “Determination of the boundaries and content of each domain” As it is possible to identify a number of factors that will influence the requirement for this domain, each domain may be slightly or greatly different to other domains in the forest, or Active Directory infrastructure. Hence, one domain plan may not support all of the design aspects for every required domain within an organisation, and thus the requirement to design a dedicated Domain Plan for each required domain. Note that references to “this domain” or “this Active Directory domain” within the processes within this Domain Plan implicitly refer only to the Active Directory domain that this Domain Plan supports.

1.3.

Domain Plan Concepts This design methodology introduces the concept of an “object and resource management infrastructure”, abbreviated as “ORMI” or “ORMIs” to denote multiple instances of this type of infrastructure. An ORMI is consists of four components dedicated to the management of Active Directory objects, and the management of access control to resources using a security group infrastructure. The Domain Plan will assist an organisation in the generation of a design for the implementation of one or more ORMIs within this domain. A component of the “Active Directory Management Plan” (volume 2 of design methodology) will assist an organisation in generation of a design for the management of one or more ORMIs within this domain. With respect to object management, an Active Directory domain is the largest logical structure within an Active Directory forest within which Active Directory objects (such as user and computer accounts, security and distribution groups, Organizational Units (OUs), printer objects, shared folder objects, and so on) are generated.

Page 3 of 354 a5/p5

Last printed 28/5/2004 12:28

© 2004 Mustan Bharmal. All Rights Reserved.

It is not possible to generate these Active Directory objects within a “forest” or within a “Site”, but only within a domain, which resides within a forest and represented within a Site. Hence, the domain represents the focal point for the management of these objects. The management of resources, as defined by the scope of this Domain Plan, corresponds to their management via the assignment of permissions on a resource to security principals represented within an Active Directory domain. This design methodology hence defines a “resource” as any object, file, service, process, and so on that has an access control list (abbreviated to “ACL”), within which it is possible to generate access control entries (abbreviated to ACEs”) that represent Active Directory security principals. 1.3.1. Object Management within a Domain It is possible to identify the following two aspects to the management of objects within an Active Directory domain: 1. 2. 1.3.1.1. Execution of tasks to create, modify, and delete objects within a domain Management of the computers represented within the domain to control the operation of the computers and the user(s) using the computers Management of Objects by Security Principal Objects Typically, within most organisations, only the “administrators” within a domain are responsible for the execution of the tasks to create, modify, and delete objects within a domain. By default, the majority of these tasks are restricted for execution by only security principals within a domain either explicitly granted the appropriate permissions, or have inherited the appropriate permissions via membership to the appropriate built-in or custom security groups. A Windows Server 2003 Active Directory infrastructure supports the concept of “delegation of control” (abbreviated to “DOC”), which permits the assignment of “appropriate” permissions to “normal” security principals that are not members of any built-in security groups with appropriate rights. For example, a user account that is not a member of the “Domain Admins” built-in security group is unable to create, modify, and delete security principal objects within a domain. Membership to the “Domain Admins” group offers a greater range of rights and permissions than simply generation, modifying, and deleting Active Directory objects. Hence, most domain owner(s) wish to control the membership of this group, and restrict it only to selected trusted security principals. However, where an Active Directory domain is to represent one or more autonomous divisions (autonomous with respect to object and resource management), it is highly unlikely for administrators within these divisions to become members of the “Domain Admins” group, as this would infer rights and permissions beyond the scope of the logical boundary for the autonomous division within the domain. The use of DOC permits the assignment of permissions to “normal” security principals to permit the execution of all or specific tasks on all or specific objects or classes of objects within a domain. Note that the use of DOC permissions is not restricted to domains that represent autonomous divisions, and nor does it depend upon the presence of a decentralised administration model. Even within organisations with a centralised administration model and no autonomous divisions may use DOC permissions. For example, Help Desk personnel within the IT Support department are required to perform “low-level” tasks on user and computer objects within an Active Directory domain, such as only changing passwords or resetting computer accounts, and so on. The IT Support department has disallowed Help Desk personnel from execution of tasks to create or delete user and computers accounts, and execution of any other “modification” tasks on these objects, such as changing group memberships, or altering dial-in attributes and so on. In this scenario, membership to the “Domain Admins” group is not an option for these personnel, but they still require sufficient permissions to execute their routine tasks. Hence, it Page 4 of 354 a5/p5 Last printed 28/5/2004 12:28

© 2004 Mustan Bharmal. All Rights Reserved.

is possible to assign the appropriate permissions, sufficient only to permit the execution of the required tasks, to the normal user account objects for the Help Desk personnel via the “Delegation of Control Wizard”. 1.3.1.2. Management of Objects by Group Policy Objects Group Policy Objects (abbreviated to “GPO” or “GPOs” to denote multiple instances) are vehicles for the delivery of one or more configured Active Directory policies only to user and computer account objects within an Active Directory domain. The functions of the policies are to manage and control specific aspects of the operation and use of computers by users by targeting the appropriate user and computer account objects within a domain. This design methodology hence regards the design of GPOs as a core component of an object management infrastructure. 1.3.1.3. Components of an Object Management Infrastructure This design methodology identifies the following four components for an object management infrastructure for an Active Directory domain: 1. 2. 3. 4. Group Policy Objects (GPOs) Delegation of Control (DOC) permissions Security Group objects Organizational Unit (OU) objects

A security group infrastructure supports the management of objects via the collation of security principals into security group objects. The security groups then support object management via the provision of a vehicle for the: 1. 2. Assignment of DOC permissions to the collated security principals Targeting of policies collated within a GPO

Note that the targeting of DOC permissions and GPOs does not rely upon the presence of a security group infrastructure, as it is possible to apply DOC permissions and GPOs to individual security principals within a domain. However, this is approach is inefficient and costly (with respect to administrative, and hence financial, overheads of this approach) for the long-term management of objects within a domain. Hence, this design methodology regards security groups, and hence a security group infrastructure, as a core component for the efficient operation of any object management infrastructure within an Active Directory domain. Thus, in addition to the management of resources via a security group infrastructure (see below), the only other supported design objective for security groups are those that generate security group infrastructures dedicated to supporting the management of Active Directory objects via targeted DOC permissions and GPOs. An Organizational Unit (OU) infrastructure supports the management of objects via the collation of Active Directory objects (including other OUs) into logical containers. The OUs then support object management via the provision of an implementation point for the following: 1. 2. DOC permissions scoped for application to one or more objects collated into an OU GPOs that contain policies scoped for application to one or more objects collated into an OU

Note that the implementation of DOC permissions and GPOs does not rely upon the presence of an OU infrastructure, as it is possible to implement these components of an object management infrastructure at the root of a domain, an Active Directory Site object, and so on. Page 5 of 354 a5/p5 Last printed 28/5/2004 12:28

© 2004 Mustan Bharmal. All Rights Reserved.

Correspondingly, OUs do not rely upon the implementation of DOC permissions or GPOs to collate objects. However, as this design methodology regards OUs as a critical component in the support for the management of objects, the primary supported design objectives for OUs are ones that generate OU infrastructures dedicated to supporting the management of Active Directory objects via implemented DOC permissions and GPOs. 1.3.2. Resource Management within a Domain Typically, within most domains and organisations, a security group infrastructure is the primary mode for management of resources with the appropriate ACLs. Note that resource management within a domain does not rely upon the use of security groups to control access to resources. It is possible to assign permissions on a resource to security principals using any of the following three following methods: 1. 2. 3. Assign permissions (ACLs) directly to security principals (accounts) Assign permissions (ACLs) directly to a security group that has the security principals as members (account group) Assign permissions (ACLs) directly to a security group (resource group) that has another security group as a member, which has the security principals as members (account group)

On first glance, comparison of these three methods for assigning permissions suggests that the first method, to assign permissions on resources directly to security principals, is the simplest method to implement and the third method overly complicated. However, the differences in short and long-term administrative overheads associated with each of these methods require consideration. The following graph (very) simplistically illustrates this relationship between administrative overhead over time for each of these three methods, and is true for most scenarios that support these methods, but obviously not for all scenarios:
1 2 3 ACLs  Accounts ACLs  Account Groups ACLs  Resource Groups  Account Groups 2 Administrative overhead in management of resource access

1

3

Time

© 2004 MUSTANSHI

R

BH

ARMAL

Figure 30.1: Graph Illustrating Relationship between Administrative Overheads and Different Resource Management Approaches The use of security groups (methods 2 or 3 above) significantly reduces the administrative overheads associated with management of access control for local and network resources.

Page 6 of 354 a5/p5

Last printed 28/5/2004 12:28

© 2004 Mustan Bharmal. All Rights Reserved.

The following table provides a brief overview of the terms mentioned above to describe groups as “account” or “resource” groups. Note that these factors are only applicable to strict “account and resource group” models where a single group does not serve both functions.
Factor Typical Membership Typical Permission Assignment Typical Group Generation Criteria Account Group Security principals and other account groups No permissions assigned on a resource for account groups Security principals are collated into an account group where metadata aspects of the security principals comply with criteria for collation of security principals defined for an account group (by, for example, a group design model) Resource Group Account groups Permissions are assigned on a resource for resource groups Resource groups are generated for compliance with one or both of the following criteria: • Specific resource instance(s) or types • Specific categories of permissions to be assigned to a resource group on a resource type or instance

Table 30.1: Comparison between Account and Resource Groups This design methodology hence regards the design of security groups, and thus one or more security group infrastructures within a domain, as a core component in a resource management infrastructure. Security groups support resource management via the provision of vehicles for collated security principals for the assignment of access control permissions to managed resources. Hence, in addition to the support for object management via DOC permissions and GPOs, this design methodology only supports the design objective for security groups to generate a security group infrastructure that supports the management of access control to appropriate resources. The process “design of an object and resource management infrastructure” details the: • Four components of an object and resource management infrastructure, and • The inter-process dependencies between each of the four processes that comprise the design of an ORMI 1.4. Domain Plan Objective The objective of this Domain Plan is to assist an organisation in the generation of a design for implementation of all of the following components and aspects of this Active Directory domain: • A design for the implementation of the following components of this Active Directory domain: ♦ One or more object and resource management infrastructures, each comprising of the following design components:  The design for a Group Policy Object infrastructure for object management  The design for a Delegation of Control infrastructure for object management  The design for a security group infrastructure for resource and object management  The design for an Organizational Unit (OU) infrastructure for object management ♦ Domain controllers within this domain ♦ Domain-level FSMO roles Page 7 of 354 a5/p5 Last printed 28/5/2004 12:28

© 2004 Mustan Bharmal. All Rights Reserved. • A design for the implementation of the following aspects of this Active Directory domain: ♦ External trust relationships for this domain ♦ Raising the functional level of this domain 1.5. Domain Plan Approach An Active Directory domain may support one or more autonomous divisions within an organisation. An autonomous division, with respect to an Active Directory domain, is one that requires service autonomy for object and resource management. Hence, where it is possible to identify the requirement for autonomous object and resource management for a discrete set of objects in an Active Directory domain, there is a requirement to design a discrete object and resource management infrastructure. Where a domain does not currently, and will not support any autonomous divisions in the future, then there is a requirement to design only one object and resource management infrastructure for the domain. This design methodology proposes the following approach to the design of a Domain Plan for this Active Directory domain: 1. 2. Determine the requirement to define logical partitions within this domain to support autonomous requirements for object and resource management. Where there is a requirement to define logical partitions within this domain for object and resource management, then determine the following: a. The number of logical partitions required within this domain b. The owner(s) of each required logical partition 3. Design, one object and resource management infrastructure (ORMI) for each required logical partition within this domain, each consisting of a design for: a. A GPO infrastructure b. A DOC infrastructure c. A security group infrastructure

d. An OU infrastructure 4. 5. 6. 1.6. Design for domain controllers for this domain Design external trust relationships for this domain Design of process to raise the functional level of this domain

Domain Plan Processes Based upon the defined objective and approach, the Domain Plan is composed of the following processes: • Determination of the requirement to partition a domain for object and resource management • Design of one or more Object and Resource Management Infrastructures (ORMIs) for this domain, each consisting of a design for: ♦ A Group Policy Object (GPO) infrastructure

Page 8 of 354 a5/p5

Last printed 28/5/2004 12:28

© 2004 Mustan Bharmal. All Rights Reserved. ♦ A Delegation of Control (DOC) infrastructure ♦ A security group infrastructure ♦ An Organizational Unit (OU) infrastructure • Design for domain controllers for this domain • Design of external trust relationships • Design of a process to raise the functional level of this domain 1.7. Deliverables of Domain Plan Processes The Domain Plan processes will have the following deliverables: • The determination of the number of required logical partitions for this domain to support service autonomy for object and resource management • The design of one or more ORMIs for this domain, each consisting of a design for the following: ♦ A design for a GPO infrastructure ♦ A design for a DOC infrastructure ♦ A design for a security group infrastructure ♦ A design for an OU infrastructure • The design for domain controllers for this domain • The design for external trust relationships for this domain • The design to raise the functional level of this domain 1.8. Inter-Process Dependencies Each process within the domain plan will have the following inter-process dependencies (Note that the dependencies illustrated below, for the execution of the process to design a security group infrastructure, are from the perspective of the design of a security group infrastructure to support object management, and not from the perspective of resource management):

Page 9 of 354 a5/p5

Last printed 28/5/2004 12:28

© 2004 Mustan Bharmal. All Rights Reserved.

Domain Plan – Inter-Process Dependencies for Domain Plan
Design an Object and Resource Management Infrastructure (ORMI) Design of a GPO infrastructure

START

Determine requirement to partition this domain for object and resource management Design for domain controllers for this domain Design for external trust relationships for this domain Design for raising the functional level of this domain

Design of a Delegation of Control infrastructure

Design of an OU infrastructure

Design of a security group infrastructure

© 2004 MUSTANSHI

R

BHAR

MAL

1.9.

Domain Plan Design Process
Domain Plan – Process to Create Domain Plan
Execute process “Design of an ORMI” Execute process “partitioning a domain for object and resource management” Execute process “design for domain controllers for this domain” Execute process “design of a GPO infrastructure” Execute process “design of a delegation of control infrastructure”

START

Execute process “design of an OU infrastructure”

Execute process “design of a security group infrastructure”

Execute process “design of external trust relationships”

Execute process “design to raise the functional level of this domain”

END
© 2004 MUST
ANSHI R

BHAR

MAL

Page 10 of 354 a5/p5

Last printed 28/5/2004 12:28

© 2004 Mustan Bharmal. All Rights Reserved.

2.

Partitioning a Domain for Object & Resource Management
This process requires execution for all domains within an organisation where it is possible to identify compliance with the following criteria for the execution of this process.

2.1.

Criteria for the Execution of this Process It is only necessary to execute this process where it is possible to identify compliance with both of the following criteria for this process: • This Active Directory domain supports and represents the Active Directory objects for one or more autonomous divisions, and • One or more autonomous divisions represented within this domain have identified the requirement for the service autonomy over the management of the Active Directory objects and resources represented within, and managed by this domain and “owned” or exclusively associated with the autonomous division. Where it is possible to identify the representation of one or more autonomous divisions within this domain, it is important to note that there may not be exclusive representation of that autonomous division by just this domain. Where two or more domains of this Windows Server 2003 Active Directory infrastructure represent an autonomous division, then port the design for an object and resource management infrastructure for this domain (for the autonomous division) to each logical partition within each other Windows Server 2003 Active Directory domain that represent this autonomous division. Where it is not possible to identify compliance with all of the above criteria, then there is the requirement to design just a single object and resource management infrastructure for this domain.

2.2.

Process Objective The objective of this process is to determine the boundaries for two or more logical partitions within this domain that represent the boundaries for two or more: • Autonomous divisions within this domain, and hence • Object and resource management infrastructures for this domain Each logical partition is to support only one object and resource management infrastructure for this domain, which in turn is to support only one autonomous division represented within this domain.

2.3.

Background Information The growth of organisations via mergers and acquisitions of other organisations generates single large logical or actual “parent” organisations with one or more “child” organisations, each typically referred to as a division of the parent organisation. Where these divisions, prior to a merger or acquisition, operated as independent organisations, they have naturally invested in the development and implementation of an IT support infrastructure. Where this existing IT infrastructure is to be included within the scope of the merger or acquisition of an organisation, and the organisation is to retain its unique identify within the parent organisation, then there is typically a requirement to extend this autonomy from the parent organisation to the IT support infrastructure for this autonomous division. Not all autonomous divisions within an organisation gain representation within the Active Directory infrastructure for the parent organisation as a discrete forest, domain, or tree of domains within a forest. Where this is true, then the representation of the autonomous division within the Active Directory infrastructure for the parent organisation is typically as one or more OU infrastructures within a domain owned by the parent organisation. There may even be two or more autonomous divisions represented within the same domain. Page 11 of 354 a5/p5 Last printed 28/5/2004 12:28

© 2004 Mustan Bharmal. All Rights Reserved.

Representation of an autonomous division with a domain owned by the parent organisation does not preclude the ability of the division to exercise service autonomy over the management of Active Directory objects that represent the division, or resources controlled and managed by the division. Thus, in these scenarios, there is a requirement to determine the requirements for two or more “object management infrastructures” for this domain. Although it may seem that the above scenario is built on a large number of “if” and “where the / these / this” statements, these scenarios are very common within organisations that grow via mergers and acquisitions. Hence, where it is possible to identify this scenario within an organisation and within this domain, then the design of this domain is required to support the service autonomy requirements of the autonomous division(s) this domain represents. 2.4. Process Approach Where there is a requirement to execute this process to partition this domain into two or more logical partitions (to support two or more object management infrastructures), the following steps comprise the proposed approach for this process: • Determine the number of autonomous divisions represented within this domain that require service autonomy for object and resource management • Where there is a requirement to define two or more ORMIs within this domain, then: ♦ Determine the requirements to implement any restrictions on object and resource management infrastructures within this domain by the owner(s) of this domain ♦ Where there is a requirement to restrict the scope, then it is necessary to determine:  The specific autonomous divisions that are to receive a restricted scope for an object and resource management infrastructure  The specific components or aspects of each of the four components, which require restriction by the owner of this domain • Determine the boundary and scope of each required object and resource management infrastructure based upon the objects and resources that require management by each autonomous division, to identify the following: ♦ The Active Directory objects each autonomous division is to manage ♦ The resources each autonomous division is to manage for access and use • Where there is no requirement to define two or more ORMIs within this domain, then it is necessary only to design one ORMI for this domain. 2.5. Process Components Based upon the above approach, this process to determine the number of logical partitions required for this domain is composed of the following three executable components: • Determination of the number of autonomous divisions represented within this domain that require service autonomy for object and resource management • Determination of the requirements to implement any restrictions on object and resource management infrastructures within this domain by the owner(s) of this domain • Determination of the boundary and scope of each required object and resource management infrastructure based upon the objects and resources that require management by each autonomous division

Page 12 of 354 a5/p5

Last printed 28/5/2004 12:28

© 2004 Mustan Bharmal. All Rights Reserved. 2.6.

Deliverables for Process Components The process to determine the number of logical partitions required for this domain will have the following deliverables: • The determination of the number of autonomous divisions that this domain represents or will represent • The identification of the autonomous divisions represented within this domain that require service autonomy for object and resource management • The determination of the requirements to restrict the scope of each required object and resource management infrastructure by the owner(s) of this domain • The determination of the restrictions on the scope of each required object and resource management infrastructure that the owner(s) of this domain wish to impose on one or more autonomous divisions within this domain • The determination of the boundary and scope for each required object and resource management infrastructure based upon: ♦ The Active Directory objects that each autonomous division is to manage ♦ The resources each autonomous division is to manage for access and use

2.7.

Inter-Component Dependencies Each component of this process will have the following inter-component dependencies:
Domain Plan - Inter-Component Dependencies for Process to Partition the Domain for Object and Resource Management START
Determination of service autonomy requirements for object and resource management Determination of the requirements to restrict object and resource management Determination of the boundary and scope of each required object management infrastructure
© 2004 MUSTANSHI
R

BHAR

MAL

2.8.

Process to Partition a Domain for Object and Resource Management Domain Plan – Process to Partition a Domain for Object and Resource Management
Are there any requirements to support service autonomy for object and resource management?

START

Execute A1

NO

END
NO

Execute A5

YES Execute A2 – A4

Are there any requirements to restrict the scope of object and resource management?

YES

© 2004 MUSTANSHI

R

BHAR

MAL

Page 13 of 354 a5/p5

Last printed 28/5/2004 12:28

© 2004 Mustan Bharmal. All Rights Reserved. 2.9.

Process Considerations Consider the following information when partitioning this domain for object and resource management. Presented within the following three sections are the considerations for this process: 1. 2. 3. Considerations for the determination of the service autonomy requirements for object and resource management Considerations for the determination of the requirements to restrict object and resource management Considerations for the determination of the boundary and scope of each required object and resource management infrastructure

2.9.1.

Determination of Service Autonomy Requirements for Object and Resource Management Consider the following when determining the requirements for service autonomy over the management of objects and resources, represented within and controlled by, this domain: • Factor A1: Identification of autonomous divisions that require service autonomy ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the presence of one or more autonomous divisions represented within this domain, and  Wishes to determine the requirements for service autonomy by these autonomous divisions ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Not all autonomous divisions represented within an Active Directory domain will require service autonomy for object and resource management. This design methodology provides the following examples of positive criteria where compliance may qualify a division for service autonomy, with respect to object and resource management:  The autonomous division has a dedicated IT support infrastructure, which is either internal or out-sourced from an third party organisation offering managed on-site or remote IT support services.  The IT support infrastructure for the autonomous division is trained, experienced, and capable of managing objects and resources within a Windows Server 2003 Active Directory infrastructure.  There are no current or future plans to consolidate the IT support services within all or some of the autonomous divisions with that of the parent organisation.  The numbers of objects and resources that require autonomous management will not fluctuate greatly as to fall outside of the scope of the management capabilities of the IT support infrastructure within an autonomous division. For example, where the IT support infrastructure for an autonomous division is currently required to manage 500 users and computers and related Active Directory objects, the numbers of these objects will not either:  Fall to such low levels as to make the IT support infrastructure redundant. For example, the numbers of objects within the scope of the IT support infrastructure may drop due to redundancies, consolidation with parallel departments within the Page 14 of 354 a5/p5 Last printed 28/5/2004 12:28

© 2004 Mustan Bharmal. All Rights Reserved.

parent organisation (and hence the objects will fall within the remit of the IT support infrastructure of the parent organisation), and so on.  Rise to such high levels as to exceed the budgetary limitations for the IT support infrastructure Where it is not possible to identify compliance with one or more of the above examples of criteria, or any other similar criteria not stated above, then exclude this autonomous division from reception of a discrete object and resource management infrastructure. Using the above information, execute the following:  Execute an analysis to identify all autonomous divisions that require representation within this domain  Define and document the criteria to qualify the inclusion or exclusion of autonomous divisions from the reception of a discrete object and resource management infrastructure within this domain  Evaluate all identified autonomous divisions against the defined criteria. Using the results of this evaluation, determine and document the following:  The identity of the divisions to receive a discrete object and resource management infrastructure within this domain  The qualifying criterion / criteria for each in-scope autonomous division • Factor A2: Determination of the presence and nature of relationships between identified object and resource management infrastructures ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified one or more autonomous divisions, represented within this domain, to receive a discrete object and resource management infrastructure, and  Wishes to determine the presence of any relationships between each required object and resource management infrastructure ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Where it is possible for an organisation to identify the requirement for the design of two or more object and resource management infrastructures for this domain, then it is important to determine the potential relationships (if any) between each infrastructure. In order to design and effectively operate an object management infrastructure, it is necessary for the infrastructure to have definite and non-disputed boundaries and scopes with respect to the objects and resources that require management. Where it is possible to identify ambiguities in ownership and management requirements between autonomous divisions within this domain, or between the autonomous divisions and the parent organisation, for specific objects and / or resources, then this could lead to access conflicts and issues, incorrectly targeted policies within GPOs, and so on. Using the above information, execute the following:  Execute an analysis to determine whether any of the identified object and resource management infrastructures will have any potential overlaps in objects and resource management, with respect to: Page 15 of 354 a5/p5 Last printed 28/5/2004 12:28

© 2004 Mustan Bharmal. All Rights Reserved.

 Objects and resources that require management  Ownership of objects and resources between autonomous divisions  Access and management rights for objects and resources  Where it is possible to identify any such overlaps, then determine and document the details of the overlap(s), and the necessary course of action to resolve these potential management issues. 2.9.2. Determination of the Requirements to Restrict Object and Resource Management Consider the following information when determining the requirements for the domain owner(s) to restrict all, some, or specific aspects of the four components of an object and resource management infrastructure for an autonomous division: • Factor A3: Understanding the role of the owner(s) of this domain in restriction of object and resource management and determination of the scope of representation of the domain owner(s) ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to:  Understand the influence and role the owner(s) of this domain will assume in the design of each required object and resource management infrastructure, and  Determine the scope of representation of the domain owner(s) within this domain ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: It is important to understand the role of the owner(s) of the domain in this process where it is possible to identify the requirement to support the design of one or more discrete object and resource management infrastructures for autonomous divisions represented within this domain. Note the assumption that the owner of the domain is not an autonomous division assigned a discrete object and resource management infrastructure within this domain, but instead the parent organisation of the autonomous division(s). The influence that the owner(s) of this domain will have on the design of each identified object and resource management infrastructure depends upon the current or planned support role this domain will assume for the owner(s) of the domain. Support for this statement is the fact that the owner(s) of this domain may or may not actually use the domain to support their object and resource management requirements. For example, it is possible for this domain to exist for the sole support of one or more autonomous divisions, although they do receive ownership or management rights over the entire domain. Where this domain does wholly or partially represent and support the owner(s) of this domain, then the design of GPOs infrastructures, security group infrastructures, and DOC infrastructures may have a significant impact on the operation and use of this domain by the owner(s). It is also possible that the GPO infrastructures and DOC infrastructures within this domain to interact with, and influence, other object and resource management infrastructures within other domains of the Windows Server 2003 Active Directory infrastructure for the organisation.

Page 16 of 354 a5/p5

Last printed 28/5/2004 12:28

© 2004 Mustan Bharmal. All Rights Reserved.

However, where this domain does not represent and support the owner(s) of the domain, and it is hence the exclusive domicile for one or more autonomous divisions, then the domain owner(s) may, for example, wish to control only certain aspects of an object and resource management infrastructure that extend beyond the boundaries of this domain. Using the above information, execute the following:  Execute an analysis to determine and document whether this domain wholly or partially represents the owner(s) of this domain.  Where it is possible to define partial representation of the domain owner(s) within this domain, then determine and document the details and nature of this partial representation. • Factor A4: Determination of the requirements to restrict the scope of object and resource management ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the requirements for the owner(s) of this domain to impose restrictions on the scope, design, and operation of one or more object and resource management infrastructures for this domain. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: All object and resource management infrastructures (ORMIs) are comprised of the following four components:  A Group Policy Object (GPO) infrastructure  A delegation of control (DOC) infrastructure  An OU infrastructure  A security group infrastructure Where the owner(s) of this domain require representation and support by this domain, in addition to one or more autonomous divisions, then there may be a requirement by the owner(s) to restrict some, all, or specific aspects of the above four components of an object and resource management infrastructure. When determining the requirements for the owner(s) of this domain to impose one or more restrictions (on the scope, design, and operation of one or more ORMIs for this domain), consider the following:  The foundation for the requirements to restrict the scope and design of these components is the desire to maintain the integrity and operation of this domain. A domain owner may be justified in imposing restrictions based upon one or more of the following examples:  The owner(s) of the domain are exclusively responsible for the provision of, and compliance with, service level agreements (SLAs) for this domain. The delegation of control over object and resource management via GPOs and permissions to, for example, inexperienced IT administrators in autonomous divisions, may compromise the security, integrity, operation, and thus continuity of this domain. For example, an inexperienced IT administrator may generate a GPO with incorrect or conflicting policy settings that result in a disruption to the operation of key users supported by the domain. Removal of the responsibility for the generation of GPOs by these inexperienced or undisciplined IT

Page 17 of 354 a5/p5

Last printed 28/5/2004 12:28

© 2004 Mustan Bharmal. All Rights Reserved.

administrators, although drastic, may ensure continuity and hence compliance with SLAs for this domain.  This domain is to represent multiple autonomous divisions that each operate business critical applications, processes and systems that depend upon the continued operation of this domain. It is possible, for example, for one of these autonomous divisions to implement a set of DOC permissions that inappropriately permit greater access rights. For example, an inexperienced and undisciplined user in the IT support infrastructure for an autonomous division may, with the greater permissions, install and test applications and scripts on the live production domain controllers for the domain that may result in a compromise of the operation of the directory service. The ensuing service outage may affect the entire domain, and hence all of the other autonomous divisions within the domain. Restriction of the rights to grant DOC permissions may hence permit greater control over the domain and compliance with service level agreements.  This domain is, for example, one or many tens of domains within a globally distributed forest for the parent organisation. One or more autonomous divisions within the domain, assigned a discrete object and resource management infrastructure for the domain, are given the rights to generate security groups within this domain for resource management. An IT administrator in one of these autonomous divisions inappropriately generates and populates a Universal security group with many hundreds or thousands of security principals within the division. The membership of this group proves to be unstable and receives frequent (daily) changes of up to twenty percent of the membership, with the result of a large impact on the Global Catalog replication traffic, to support the changes in the membership of this Universal group, to all domain controllers around the world within the forest. A domain owner may hence wish to impose the restriction of the right to generate Universal security groups by an autonomous division, thus enforcing control over Global Catalog replication traffic for the forest.  Where the domain owner(s) wishes to exclude all of the four components that are required for the design of an object management infrastructure, for all autonomous divisions, then there is no support for the requirement to partition this domain. The onus hence lies with the domain owner to design a single object and resource management infrastructure for all autonomous divisions represented within this domain.  Where the domain owner has decided to exclude either part or whole components of an object and resource management infrastructure from one or more autonomous divisions, then the onus lies with the domain owner to either provide the design for these components omitted from the autonomous divisions.  The domain owner(s) may decide to either:  Just restrict the design of an object and resource management infrastructure for an autonomous division, and hence become responsible for the provision of the design for these restricted components, or  Restrict both the design and the operation of the restricted components from the object and resource management infrastructure. Where this is true, then it is important to determine, understand, and accept the financial and operational overheads associated with this decision, which will reside with the owner(s) of the domain. Using the above information, execute the following:

Page 18 of 354 a5/p5

Last printed 28/5/2004 12:28

© 2004 Mustan Bharmal. All Rights Reserved.

 Determine and document the requirements for the domain owner(s) to impose any restrictions on the design and operation of one or more object management infrastructures for this domain by autonomous divisions.  Where it is possible to identify the requirement for the owner(s) of this domain to impose such restrictions, execute the following:  Determine and document the specific restriction(s) that require imposition  Define and document the criteria to qualify the imposition of these restrictions on the scope, design, and operation of one or more object management infrastructures for this domain by autonomous divisions.  Evaluate all in-scope autonomous divisions against the defined criteria, and identify and document the following: • The specific autonomous divisions to receive ORMI design restrictions • The qualifying criterion / criteria that impose and justify the restrictions by the domain owner(s)  Where there is a requirement to impose restrictions on the components of an ORMI for an autonomous division, then determine and document the specific support requirements the owner(s) of the domain are subsequently required to provide. 2.9.3. Determination of the Boundary and Scope for Each Required Object and Resource Management Infrastructure Consider the following information when determining the boundary and scope for each required object and resource management infrastructure for an autonomous division: • Factor A5: Determination of the boundary and scope of each required object and resource management infrastructure ♦ 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 two or more ORMIs within this domain, and  Wishes to determine the boundary and scope for each required object management infrastructure ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Each object management infrastructure for each autonomous division within this domain must have a defined boundary and scope. When determining the boundary for the object and resource management infrastructure for an autonomous division, consider the following:  The objects and resources owned and managed by the autonomous division will define the boundary for the object and resource management infrastructure.  Typically, only the owner(s) of the Active Directory objects manages the objects, as the shared management of Active Directory objects may lead to issues and conflicts in their use and operation.

Page 19 of 354 a5/p5

Last printed 28/5/2004 12:28

© 2004 Mustan Bharmal. All Rights Reserved.

 It is common, however, to find resources shared between, or co-owned by, multiple divisions. Correspondingly, in these scenarios, it is possible to identify the requirements to support the sharing of specific management tasks for these resources, such as managing access control via permissions against security principals from an Active Directory or trusted domain. Where it is possible to identify such scenarios, determine the logical boundary of an object and resource management infrastructure based exclusively upon the ownership of management tasks for the resources. When determining the scope of an object and resource management infrastructure, consider the following:  The permitted components of an object and resource management infrastructure, which an autonomous division is to exclusively design and operate, define the scope of the infrastructure.  Where it is possible to identify the requirement for the owner(s) of the domain to restrict some, all, or specific aspects of the components of an object and resource management infrastructure from an autonomous division, then these components are naturally outside of the scope of this infrastructure. Using the above information, execute the following:  Determine and document the boundary and scope for each required object and resource management infrastructure for this domain  Determine, document, and assign a name to each required ORMI using the name of the owner of the ORMI within a naming formula such as “<Autonomous_Division>_ORMI”, for example “Natsum Gardens_ORMI”.

Page 20 of 354 a5/p5

Last printed 28/5/2004 12:28

© 2004 Mustan Bharmal. All Rights Reserved.

3.

Design of an Object & Resource Management Infrastructure
A minimum of one object and resource management infrastructure (ORMI) is required for each Active Directory domain within an organisation. Where the results of the previous process has positively identified the requirements to define two or more logical partitions within this domain, for autonomous object and resource management, then each partition will require the design for one ORMI, and the owner(s) of each ORMI is required to execute this process.

3.1.

Background Information This design methodology for a Windows Server 2003 Active Directory infrastructure identifies the requirement for the design of the following four core components for each required object and resource management infrastructure: 1. 2. 3. 4. A design for an Group Policy Object (GPO) infrastructure A design for a Delegation of Control (DOC) infrastructure A design for an Organizational Unit (OU) infrastructure A design for a security group infrastructure

The following diagram displays the alignment of each of these four components to the design objectives (for object and resource management) for the Domain Plan:

GPO

DOC

OU

SECURITY GROUPS
RESOURCE MANAGEMENT
© 2 0 0 4 MU S TA N S H I
R

AD OBJECT MANAGEMENT

BHAR

MAL

Figure 32.1: Functions of the Components of an Object and Resource Management Infrastructure (ORMI) This diagram illustrates that: • The design of an object management infrastructure requires the execution of all four processes to design each core component, and • The design of a resource management infrastructure just requires execution of the process to design a security group infrastructure. Thus, the process to design the security group infrastructure will support both of these design objectives, to hence simultaneously support the design of both an object and a resource management infrastructure. Each one of these four components requires execution as a discrete design process within this Domain Plan, and as each of these four processes has either one or two design objectives in common, there are hence dependencies between each of these processes. Thus, it is not possible to initiate, execute, and complete all of these processes independently of each other, and the results of specific tasks within one process are the inputs for other tasks in another process. This design methodology states the following primary design objectives for each of these four components as part of the design of an object management infrastructure: • The primary design objectives for the GPO infrastructures are to define:

Page 21 of 354 a5/p5

Last printed 28/5/2004 12:28

© 2004 Mustan Bharmal. All Rights Reserved. ♦ The specific policies and configuration policies that are required within a GPO based upon the scope of application of the GPO ♦ The scope of application of each required configuration for a required policy, and thus defining the user and computer objects to be managed by one or more GPOs • The primary design objectives for the DOC infrastructures are to define: ♦ The Active Directory domain objects that require management via delegation of control permissions, defined as:  Specific instances of objects, and / or aspects of these objects  Specific object classes, and / or aspects of these object classes ♦ The non-security group security principals that are to be assigned the tasks for managing the identified objects and / or the specific aspects of the objects ♦ The permissions required by these identified security principals to permit the execution of the assigned tasks • The primary design objectives for the OU infrastructures are to define the number and structure of OUs within an OU infrastructure to support the implementation of the object management requirements for the GPO infrastructures and the DOC infrastructures. • The primary design objectives for the security group infrastructures, with respect to object management, are to define the number and scopes of security groups required to support targeting of the object management requirements for the GPO infrastructures and the DOC infrastructures. During the execution of each process, for the design of an object management infrastructure, it is necessary to gather information from the results of one or more tasks in one or more of the other three processes, and so it may seem that all four processes require simultaneous execution. However, there is a specific sequence for execution of these processes based upon the specific dependencies between the processes. Each process is composed of many steps that both generate and have dependencies upon each other within the process (intra-process dependencies). However, in order to design an “object management” infrastructure, it is necessary for all of these four processes to work together, and hence there are dependencies between the four processes (inter-process dependencies). The foundations for the inter-process dependencies are the dependencies between only a few specific steps within each process (out of the many steps that comprise each process). The dependencies reflect the information output from a step within a process (information gathered, such as, “know (have determined) the names of the required security groups”) and the required information input for a step within a process (information required, such as “need to know names of security groups”). The following diagram depicts, at a very high level, the steps associated with the design of one ORMI for a domain, and the dependencies between the four components of this infrastructure. Note that it is not necessary to attempt to analyse and understand all of the content of the following diagram at this stage in the design of a Domain Plan. Each of the four processes will explain all of the relevant terms and concepts shown within this diagram. The aim of this diagram is to highlight that this design methodology for a Windows Server 2003 Active Directory infrastructure requires the collaboration of these four processes to support one design objective (the design of an object and resource management

Page 22 of 354 a5/p5

Last printed 28/5/2004 12:28

© 2004 Mustan Bharmal. All Rights Reserved.

infrastructure) and that there is hence a series of dependencies between these four processes.

Page 23 of 354 a5/p5

Last printed 28/5/2004 12:28

© 2004 Mustan Bharmal. All Rights Reserved.

HIGH-LEVEL OVERVIEW OF THE STEPS AND DEPENDENCIES WITHIN THE PROCESS TO DESIGN AN OBJECT AND RESOURCE MANAGEMENT INFRASTRUCTURE
START
Identify all of the Active Directory objects within the scope of the object and resource management infrastructure that require management using GPOs and DOC permissions Determine generic categories, and their priorities and sequence for use, for the in-scope types of Active Directory objects, based upon object metadata

LEGEND
Result or requirement of task within process “Design of Security Group Infrastructures”

Inter-Process Task Dependency
Result or requirement of task within process “Design of a GPO Infrastructure” Result or requirement of task within process “Design of Delegation of Control Strategies”

Intra-Process Task Dependency
Result or requirement of task within process “Design of an OU Infrastructure” Steps within process to “Design Object and Resource Management Infrastructure”

PROCESS TO DESIGN A SECURITY GROUP INFRASTRUCTURE
Identify the resource access requirements for "local" and "nonlocal" resources by "local" and "non-local" security principals Identify the "local" and "non-local" security principals to be managed (for resource access) by a security group infrastructure Identify the "local" and "non-local" resources to be managed by a security group infrastructure Determine the categories for the collation of security principals into security groups for resource management and for object management via GPOs and DOC permissions Know the locations for “local” and “non-local” resources and security principals and know the required categories for the collation of security principals into security groups Need to know the categories, priorities for categories, and sequence for categorisation of users and computers for management via GPOs and DOC permissions Need to know the security principals to which DOC permissions are targeted Need to know the security principals to which GPOs are targeted Use the identified security group design model(s) to collate the required security principals into the appropriate security groups and (where appropriate) nest the required security groups Need to know which objects require management, as objects and for resource access, via a security group infrastructure

PROCESS TO DESIGN A GPO INFRASTRUCTURE

PROCESS TO DESIGN A DOC INFRASTRUCTURE
Identify the administrators to receive the DOC permissions for each aspect of an object that requires management

PROCESS TO DESIGN AN OU INFRASTRUCTURE
Identify requirements to partition the object administration profiles, and determine the final number of profiles required

Need to know which user and computer account objects required management via GPOs

Know the policies that are hence required

Know what types of Active Directory objects require management via DOC permissions For each required policy, identify the required configuration(s) and the fixed / variable scope(s) of application for each required configuration based upon the defined generic categories for types of users and computers Identify all of the IT administrators to receive delegation of control permissions to manage in-scope Active Directory objects Identify and categorise all the aspects of all Active Directory objects that require management via DOC permissions

Analyse the identified GPO policy and DOC permission requirements to identify the

Select a type of OU design model

Identify all of the GPO policies that are not required based upon the known scope of users and computers

Identify groups of similar DOC permissions based upon the defined categories for Active Directory objects

Determine the threshold criteria for maximum numbers of GPOs and DOC permissions that may be implemented at OUs Know the number, type (admin / placeholder), structure, and function of the required OUs Use the selected type of OU design model to design the OU infrastructure

Determine the security group and WMI filter requirements to target the GPOs

Know the User and Computer objects to receive each required policy and each required configuration Use the identified type of GPO design model to collate the required policies and generate the required GPOs

Know the IT administrators to receive DOC permissions and the groups, classes, and aspects of Active Directory objects they are to manage

Need to know the Active Directory objects to be managed by DOC permissions Need to know the users and computers to be managed by GPO policies

Determine the precise (current) content for each required OU in the OU infrastructure

Know the precise content for each required OU

Identify the required security group design model(s) that will support the identified requirements for object and resource management

Know the number of GPOs required and the target users and computers for each GPO

Select a type of GPO Design Model

OrganisationWide Security Group Object Naming Model

Generate the names for each required security group

Determine the required primary and secondary points of implementation of the GPOs

Need to know precise content for each OU in the supporting OU infrastructure OrganisationWide GPO Object Naming Model

Generated design for an OU infrastructure

Know the names for each required OU

Determine the names for each required OU

Determine the names for each required GPO

Determine the configuration requirements for each required GPO

Need to know the names of the security groups to be used as the vehicles for targeting the required DOC permissions Need to know the points of implementation of the required DOC permissions

Determine the specific permissions that are required by the specific administrators to perform their assigned management tasks

OrganisationWide OU Object Naming Model

Determine and assign any specific permissions dictated for the OUs by an OU design model

END

Know the names for each required security group

Need to know the names of the security groups to target the application of the required GPOs

END

END

END

Figure 32.2: High-Level Overview of Steps and Dependencies within Process to Design an ORMI

Page 24 of 354

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

© 2004 Mustan Bharmal

3.2.

Process Scope The results of the previous process, to determine the requirements for the partitioning of this domain to support autonomous object and resource management, will define the scope of this process. Where a domain owner(s) has identified the requirement to restrict one or more components, or aspects of a component, of an ORMI, then it is necessary to exclude them from the scope of this process. Note that the onus lies with the domain owner to design the excluded components / aspects of components omitted from one or more ORMIs within this domain.

3.3.

Process Approach The following approach for the execution of this process assumes that there are no restrictions imposed by the owner(s) of a domain on the design any of the required ORMIs within this domain. Where this assumption is invalid, exclude the restricted component(s) / aspect(s) from this proposed approach. The process to design an ORMI for a domain requires methodical execution to ensure respect for all of the inter-process dependencies for this process. The flow diagram above illustrates these inter-process dependencies and highlights the (high-level) steps in the design of an ORMI for an Active Directory domain. The process to design an ORMI for a domain initiates with the execution of two analysis tasks. The result from these analysis tasks represents the input for the: • Initiation of the two “sub-processes” to design a GPO and DOC infrastructure • Continuation of the “sub-processes” to design an OU and security group infrastructure Although this Domain Plan presents the considerations for the design of each of the four components of an ORMI as discrete processes, each process will highlight the dependencies between itself and the other three processes, where relevant. The following high-level approach for the process to initiate the design of each required object and resource management infrastructure for this domain is proposed: 1. 2. From the results of the process to partition a domain for object and resource management, determine the boundary and scope of each required ORMI. Within the boundary and scope of each ORMI, execute an analysis to: a. Identify all the Active Directory objects that will require management via GPOs and DOC permissions b. Determine generic categories for types of Active Directory objects (including user and computer account objects), based upon object metadata, to support the following: i. ii. Determination of the scope of application for configuration(s) of GPO policies Determination of the scope of application of DOC permissions

iii. Determination of the number and content of OUs via the collation of Active Directory objects into OUs, using the defined generic categories of Active Directory objects iv. Determination of the structure of multiple OUs within an OU infrastructure for an ORMI, to support administrative and non-administrative requirements for the Active Directory objects v. Generation of GPOs (via the collation of GPO policies) post-implementation of an ORMI

Page 25 of 354

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

© 2004 Mustan Bharmal

vi. Implementation of DOC permissions post-implementation of an ORMI 3. Then, for each required ORMI, execute the processes to design: a. A GPO infrastructure b. A Delegation of Control infrastructure c. A security group infrastructure

d. An OU infrastructure 3.4. Process Components Based upon the above approach and following the determination of the boundary and scope of the ORMI, this process to design an ORMI is composed of the following executable components: • Determination of the object scope for GPO and DOC infrastructures • Determination of generic categories for types of Active Directory objects Following completion of the execution of these components, commence the execution of the four processes that constitute the design for an ORMI. 3.5. Deliverables of Process Components The process to initiate the design of an ORMI will have the following deliverables: • The identification of all Active Directory objects that: ♦ Currently or will reside within the boundary of an ORMI for this domain, and ♦ Will require management via GPOs and / or Delegation of Control permissions • The identification of generic categories for Active Directory objects, based upon their metadata, which will assist in the design for implementation of an ORMI, and the postimplementation management of an ORMI. 3.6. Inter-Component Dependencies Each component of this process will have the following inter-component dependencies:
Domain Plan – Inter-Component Dependencies for Process to Design an ORMI

START

Determination of object scope for GPO and DOC infrastructures

Determination of generic categories for types of Active Directory objects
© 2004 MUSTANSHI
R

BHARMAL

3.7.

Process to Design an ORMI
Domain Plan – Process to Design an ORMI START
Execute A1 Execute B1 Execute A2 – A3 Execute B2 Execute A4 – A6

END
© 2 0 0 4 MU S TAN SH I R B H AR MA L

3.8.

Process Considerations Consider the following information, when initiating the design for an ORMI, to determine the Active Directory objects that will require management via GPOs and DOC permissions:

Page 26 of 354

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

© 2004 Mustan Bharmal

Presented within the following two sections are the considerations for this process: 1. 2. 3.8.1. Considerations for the determination of the scope of management of Active Directory objects by the GPO and DOC infrastructures within an ORMI Considerations for the determination of generic categories for the types of Active Directory objects, based upon their metadata

Determination of the Object Scope for the GPO and DOC Infrastructures Consider the following information when determining the object scope for the GPO and DOC infrastructures for an ORMI: • Factor A1: Determination of the scope of an ORMI to reflect types of Active Directory objects ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the design of one or more ORMIs within this domain  Has identified the boundary and scope for each required ORMI  Wishes to determine the scope of an ORMI, with respect to the types of Active Directory objects that will definitely be generated and hence require management via GPO policies and DOC permissions ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The processes to design a GPO, DOC, and security group infrastructure for an ORMI all depend upon knowledge of the objects to be managed using GPOs and DOC permissions. The types of Active Directory objects that require management will hence define the scope of each of these three processes, and the process to design an OU infrastructure for the ORMI. When determining the scope of an ORMI, with respect to the types of Active Directory objects, which will definitely require generation and hence require management via GPOs and DOC permissions, consider the following:  At this stage in the design of an Active Directory infrastructure, it may not be possible to determine the specific instances of Active Directory objects that require management via GPOs and DOC permissions. Hence, where it is not possible to identify specific objects, then it is only necessary, at this stage, to define the classes of objects that will definitely require management.  However, where the precise content of an Active Directory domain, which resides within the boundary of an ORMI, is known at this stage (for example, all objects are to be migrated from a legacy (Windows NT 4.0 or Windows 2000) domain), then determine the specific object classes and instances of objects to be within the scope of the ORMI.  Not all Active Directory objects that typically require management by GPOs and DOC permissions will be within the scope of all ORMIs within this domain. For example, an autonomous division represented within a domain has no intention to publish print queues or shared folder objects within the Active Directory domain. Hence, it will not be necessary to design the DOC permissions to permit the generation, modification, and deletion of these Active Directory objects within the scope of the ORMI for this autonomous division. This may even be granular where, for example, an autonomous division is explicitly not to generate Universal security

Page 27 of 354

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

© 2004 Mustan Bharmal

groups, and hence the management of these security groups is outside of the scope of the appropriate ORMI.  This design methodology for a Windows Server 2003 Active Directory infrastructure supports specific Active Directory object classes, as being within the scope of management of GPOs and DOC permissions. The object classes supported by this design methodology are presented within the following table:
Object Class Object Class Name in Default Windows Server 2003 Active Directory Schema computer user inetOrgPerson contact group printQueue volume organizationalUnit groupPolicyContainer Object Class Fall Under Scope of Management of: GPOs & DOC permissions GPO & DOC permissions GPO & DOC permissions DOC permissions DOC permissions DOC permissions DOC permissions DOC permissions DOC permissions

Computer User InetOrgPerson Contact Group Printer Shared Folder Organizational Unit Group Policy Object

Table 32.1: Object Management via DOC and GPO Infrastructures Using the above information, execute the following:  Where it is not possible to identify specific instances of Active Directory objects for inclusion or exclusion from the scope of an ORMI, then determine and document the object classes, supported by this design methodology, which require inclusion and exclusion from the scope of management of GPOs and DOC permissions within an ORMI.  Where it is possible, at this stage, to identify the specific instances of Active Directory objects that currently or will reside within the scope of an ORMI, then determine and document the specific object instances that require inclusion and exclusion from the scope of management of GPOs and DOC permission within an ORMI. 3.8.2. Determination of Generic Categories for Types of Active Directory Objects Execute the following task following the determination of the objects within the scope of management of the GPO and DOC infrastructure. Consider the following information when determining the generic categories for all in-scope Active Directory objects, based upon their metadata, to facilitate the design for implementation and management of an ORMI: • Factor B1: Understanding the requirements to define generic categories for Active Directory objects ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:

Page 28 of 354

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

© 2004 Mustan Bharmal

 Has identified the requirement for the design of one or more ORMIs within this domain, and  Wishes to understand the requirements to define generic categories for Active Directory objects ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: It is necessary to determine generic categories for Active Directory objects to permit categorisation of the corresponding objects to reflect their management requirements. The categorisation of Active Directory objects for the design of an ORMI is imperative to support the following aspects and components of an ORMI:  To support the determination of the scope of application (user and computer account objects only) of specific required configuration(s) of GPO policies. When determining which policy configuration setting requires application to which users and computers, it is simpler to assign a required policy configuration to one or more categories of users and / or computers, rather than to individuals or groups of users and computers. For example, there is a requirement to determine the scope for application of a required configuration setting for a GPO policy that, for example, hides all desktop icons. Because this restricts the functionality of the desktop for the users that will use the computers targeted to receive this policy, the organisation may decide to only target this configuration setting to “light users” of computers, such as receptionists and security guards. Hence, the organisation uses the generic category of “light users” to scope the application of the required configuration setting. This, and other categories, thus require definition prior to determination of GPO policy requirements.  To support the determination of the scope of management of Active Directory objects via the assignment and use of DOC permissions. The target Active Directory objects for DOC permissions require categorisation to facilitate the identification and collation of DOC permissions for assignment to the appropriate management security principals. Grouping Active Directory objects, based upon pre-defined categories, is essential in targeting and grouping DOC permissions. For example, where an organisation has an IT security department, responsible for the management of an IT security infrastructure (policies, permissions, rights, and so on), then there may be individuals within this department assigned management rights only for specific types of Active Directory objects. Grouping the target objects into categories, based upon one or more of their metadata aspects, facilitates the assignment and management of the DOC permissions.  To support the determination of the number and content of OUs via the collation of Active Directory objects into OUs, using the defined generic categories of Active Directory objects. The primary objectives for the design of an OU infrastructure (see later) within an ORMI is to support the GPO policy and DOC permission requirements for the ORMI. Hence, the process to collate objects into OUs, and structure multiple OUs into an OU infrastructure will use the same defined categories for Active Directory objects to permit identification of patterns of variances in object management.  To support the determination of the structure of multiple OUs within an OU infrastructure for an ORMI, to support administrative and non-administrative requirements for the Active Directory objects.  To support the generation of GPOs (via the collation of GPO policies), postimplementation of an ORMI  To support the implementation of DOC permissions, post-implementation of an ORMI

Page 29 of 354

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

© 2004 Mustan Bharmal • Factor A2: Determination of the scope of Active Directory objects to be categorised ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the scope of the Active Directory objects that require categorisation to support the design of an ORMI. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: It is only necessary to determine the required generic categories for an Active Directory object if it falls within the scope of management of an ORMI, via the use of GPO policies and / or delegation of control (DOC) permissions. When determining the scope of Active Directory objects that require categorisation, consider the following:  It is important to define criteria for the inclusion or exclusion of an Active Directory object from this process to determine generic categories. Although the onus is with the organisation to define their criteria, this design methodology provides the following examples of such criteria:  There is a requirement to generate and use a class of Active Directory object within the boundary of an ORMI within this domain.  A class of Active Directory object is to be the target for one or more GPO policies (and hence a user or computer account object) and / or delegation of control permissions  There will be more than a specified number of instances of an object class within the boundary of an ORMI. For example, it is not necessary to determine generic categories for an Active Directory object class where only one or two instances of that object class will exist within the boundary of an ORMI.  Within some domains, such as a placeholder root domain, the domain will never host “normal” user or computer account objects, but may be required only to function as a security boundary for file and other network resources. Hence, for this type of domain, although there is a requirement to design a resource management infrastructure, there is no requirement to define any categories for user and computer account objects, as there is no compliance with the first and second criteria above. Even if the placeholder domain was to host only a very few user and / or computer account objects, the numbers would not permit compliance with the third criteria, and hence negate the requirement to define generic categories for these Active Directory object classes.  Within some domains, an organisation may never identify the requirement for the creation and subsequent management of specific Active Directory object classes via delegation of control permissions, and hence will not comply with the first or second criteria above. For example, an organisation may not wish to publish print queues or shared folders to the Active Directory, and hence there will be no requirement to manage these objects or delegate their management via DOC permissions. Hence, there is no requirement to define generic categories for these Active Directory object classes. Using the above information, execute the following:  Define and document the criteria to qualify the inclusion and exclusion of Active Directory object classes from the scope of this process  Evaluate all in-scope Active Directory object classes against the defined criteria to identify and document all object classes that require exclusion from this process, to

Page 30 of 354

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

© 2004 Mustan Bharmal

determine generic categories, and hence the in-scope Active Directory object classes that require categorisation. • Factor A3: Understanding supported metadata aspects of object classes and determination of required metadata aspects ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to:  Understand the metadata aspects of Active Directory object classes supported by this design methodology, and  Determine the required metadata aspects for the in-scope Active Directory objects that will form the basis for inter- and intra-object class differentiation for management via GPO policies and / or DOC permissions ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Every object within an Active Directory domain has metadata aspects that describe the object. This design methodology supports specific categories of metadata for Active Directory objects, which form the basis for the determination of categories for the Active Directory objects. Following definition of the categories, it is subsequently possible to use these categories to describe an entire object class, or specific objects within an object class. The metadata for an object can belong to one or both of the following:  Information about the physical object that an Active Directory object represents (such as a person represented by a user account object, or a laptop computer represented by a computer account object)  Information about the Active Directory objects within the domain, such as the class of the object, the value of attributes of the object, and so on. This design methodology supports the generation of categories for types of Active Directory objects based only on the:  Default metadata aspects of the Active Directory objects retrievable from the representative objects in an Active Directory domain, or (where appropriate)  Information about the physical objects / persons, represented by the Active Directory objects, that is non-variable and pertinent to the management of the Active Directory objects via a GPO and DOC infrastructure. Note that this design methodology does not support the use of metadata aspects of the actual persons and objects, which the Active Directory objects represent, which at the time of generation of the objects is:  Unknown  Variable in nature  Not pertinent to the management of the corresponding Active Directory object via GPO policies and / or DOC permissions Note that the onus is with the organisation to:  Interpret the meaning of “pertinent” information, with respect to the management of an Active Directory object. For example:

Page 31 of 354

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

© 2004 Mustan Bharmal

 Knowledge of the model and version of a laptop computer may not be pertinent information for one organisation, but pertinent to another organisation which will use GPOs to deliver specific software only to specific versions and models of laptop computers. This information is readily retrievable and employable in the targeting of policies within GPOs via the use of Windows Management Instrumentation (WMI) filters for GPOs and the Group Policy Management Console (GPMC).  Use of a physical characteristic of a person, such as their shoe size, may (for the majority of organisations) be “non-pertinent” information for the management of that person (via distinction of a person from other persons in the organisation) using GPOs and / or DOC permissions. However, as an extreme example, an organisation may be a high-tech shoe manufacturer, and distribute shoe-testing software, calibrated against shoe size, to pilot users of new high-tech shoes. Hence, knowledge of the shoe size of the pilot testers permits distinction between other pilot testers to permit targeting of GPO policies that distribute the calibrated shoe-testing software. Note that it is possible to extend the Schema to incorporate an attribute of “shoe size” against the user and / or inetOrgPerson object class.  Interpret the meaning of “non-variable” information, with respect to the management of an Active Directory object. For example, the Windows operating system version of a desktop computer is not actually static as it is possible to upgrade it (where there is a newer version). However, for the application of policies to a desktop computer based upon its current version of Windows operating system, this may be regarded as a non-variable metadata aspect of the desktop computer as it is highly unlikely the Windows operating system for the computer will be upgraded on a frequent basis to a newer version of operating system. The metadata aspects for Active Directory objects supported by this design methodology are only those that permit the determination of patterns of variances in management of the Active Directory objects. More specifically, this design methodology will only support metadata aspects of Active Directory objects (or the physical objects / persons represented by the Active Directory objects) that support distinction between object classes or multiple instances of that object class as targets for GPO policies and / or DOC permissions. Although the onus is with the organisation to define their categories of metadata aspects, this design methodology provides examples of such categories. The following examples of categories of metadata aspects of Active Directory objects represent, for the majority of organisations, pertinent information to permit distinction between object classes and / or multiple instances of an object class, for the targeting of GPO policies and / or DOC permissions:  For Active Directory user account objects, the following example metadata aspects support the determination of management categories for this object class:  Logical characteristics of the actual users within an organisation, and the user account objects that represent the actual users within the Active Directory, such as: • The function / job / role of the actual users within an organisation • The membership or alignment of the actual user to a divisional structure within an organisation (autonomous and non-autonomous), such as “sales” department, “development” team, and so on • Attribute data of the Active Directory user account objects  Physical characteristics of the actual users, such as:

Page 32 of 354

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

© 2004 Mustan Bharmal • The actual physical characteristics of users (such as height, shoe size, and so on) where relevant to their job function / role / position and so on within an organisation • The working environment of the actual user where relevant to their job function / role / position and so on within an organisation (for example, a user that works predominantly on a factory floor, or a user that works predominantly out in the field as an account manager, engineer, or consultant, and so on) • The network connectivity of the user (via their computer) to the domain controllers for this domain (based upon point of network connectivity, levels of available bandwidth, and so on)  For Active Directory computer account objects, the following example metadata aspects support the determination of management categories for this object class:  Logical characteristics of the actual computers, and the computer account objects that represent the actual computers within the Active Directory, such as: • The association / owner of the actual computers with divisional structures within an organisation, such as departments and teams • The function or role of the actual computer within an organisation • The attribute data of the Active Directory computer account objects  Physical characteristics of the actual computers, such as: • The model, manufacturer, type of actual computer, and so on • The presence and configuration of hardware components and devices within and attached to the actual computer • The version of Windows operating system, service pack, hot fix installed on the actual computers • The software applications, and their versions, installed on the actual computers • The network connectivity of the actual computers to the domain controllers for this domain (based upon point of network connectivity, levels of available bandwidth, and so on)  Note that it is not possible to target GPO policies to domain security groups (although they may serve as the vehicles for targeting GPO policies to user and computer account objects), even though it is possible, however, to manage local security groups on a computer using GPO policies. Hence, Active Directory security group objects will only be the recipients of management via DOC permissions. Hence, for Active Directory security group objects, the following example metadata aspects support the determination of management categories for this object class:  The owner(s) (as actual users / divisional structures within an organisation) of security groups  The scope of security groups (Universal, Domain Local, Global)  The function / role of the security groups within this domain, such as: • To support the management of access control to local and network resources

Page 33 of 354

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

© 2004 Mustan Bharmal • To support the targeting of GPO policies to user and computer accounts • To support the assignment of DOC permissions to management security principals  For Active Directory printer objects, the following example metadata aspects support the determination of management categories for this object class:  Logical characteristics of the actual print devices, and the print queue objects that represent print queues for the actual print devices within the Active Directory, such as: • The technical capabilities of the print devices • The role and function of the print devices within an organisation • The security access control requirements for the print queues • The association / owner of the actual print devices with divisional structures within an organisation, such as departments and teams  Physical characteristics of the actual print devices, such as: • The make, model, manufacturer of the print device • The presence and configuration of internal and external hardware components and parts of the print device  For Active Directory shared folder objects, the following example metadata aspects support the determination of management categories for this object class:  The association / owner of the actual file share with divisional structures within an organisation, such as departments and teams  The role and function of the file share within an organisation  The actual computers the file shares reside upon Note that the “location” (physical or logical) of Active Directory objects (within a domain / OU infrastructure) or the actual users or objects within an organisation, is typically not pertinent to the management of those users or objects. For example, a metadata aspect for a user, which is that a user is in physical location for an organisation, such as “New York”, does not directly, or solely, support distinction between that user and her peer in “London”. Based solely upon the physical locations, there is no basis for the user in “New York” to receive a different GPO policy to the user in “London”. The user in “New York” may instead receive a different GPO policy from her peer in “London” because she belongs to a department that is different to her peer and that department happens to be located in “New York” and not “London”. Hence, the association of the user in New York to a divisional structure is the basis for the distinction in management of that user from her peer in London, and not the actual physical locations. However, only where it is possible to identify physical or logical locations for objects, as the sole basis for the distinction of their management, is that metadata aspect is valid, and can hence support the generation of categories for the grouping of these objects. Using the above information, execute the following:  Execute an analysis to determine the metadata aspects for each object class that will support inter-object class and intra-object class differentiation, based upon

Page 34 of 354

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

© 2004 Mustan Bharmal

current and proposed management requirements for these objects, using GPO policies and / or DOC permissions.  Determine the requirements to define and use multiple metadata aspects, which will form categories for inter- and intra-object class differentiation.  Where there are requirements to define and use multiple metadata aspect, then define, document, and assign priorities to each category as the basis for intra-object class differentiation (see later for details). • Factor B2: Review examples of generic categories for users and computers ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to review examples of generic categories for the types of in-scope users and computers. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When determining the generic categories for types of users and computers, consider the following:  It is important only to define those categories that support patterns of variances in the administration of the user and computer account objects using GPO policies and / or DOC permissions. For example, it is possible to segregate computer accounts for servers into groups based upon the manufacturer of the servers. However, this segregation does not support the collation of the GPO policies for these servers into discrete GPOs for discrete application unless the servers from different manufacturers have different management requirements because they are from different manufacturers.  When determining the required categories, it is important to ensure compliance with natural reflective criterion for compliance in the application of each defined category. For example, where an organisation wishes to define categories of computer accounts for desktop computers based upon the manufacturer of the desktop computers, then it must be possible to identify within the organisation the presence of two or more desktop computers from two or more manufacturers.  Base the generic categories for types of users and computers upon existing management requirements for the users and computers and not upon future management requirements. An organisation with an existing structured approach towards the management of their users and computers will be more likely to understand and define generic categories at this stage.  The categories for the types of users and computers must support multiple management aspects and not only one management aspect. For example, there is no point in defining and using a category such as “light users” and grouping security guards, receptionists, switchboard operators, and so on into this category if the only management requirement they have in common is that they do not require desktop icons on their computers. If however, all members of this category also require management of, for example, their security settings, lockdown of applications common to all members of this category, and so on, then this category is valid. The following are examples of potential categories for “types” of users supported by this design methodology:  User accounts exclusively for users and:  Exclusively for use by a single user  For use as a “shared” account by two or more users

Page 35 of 354

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

© 2004 Mustan Bharmal

 User accounts not for users, but instead for use by:  Services  Applications  Resource mailboxes within a supported Exchange messaging infrastructure Within most organisations, it is possible to identify many “types” of users that have different administrative requirements based upon their role within an organisation. An organisation may wish to define many different categories to reflect the different roles and management requirements for their users. However, provided below are a few examples of the typical “roles” that users within an organisation can assume, and that can hence form the basis for policy collation into GPOs:  IT Administrators: these users are the administrators of an IT infrastructure for an organisation / autonomous division. These users are typically required to manage one or more aspects of the IT infrastructure for an organisation, and hence have a greater range and depth of rights and permissions than non-administrators within an organisation.  Software Developers: these users are not typically “administrators”, as are not assigned administrative duties. However, these users typically require greater administrative rights and permissions than non-administrative users, but within a scope limited to their own personal desktop and / or laptop computers, or a group of computers shared amongst several developers that may serve as test machines and so on. The requirements for the greater administrative rights and permissions on their computers is a reflection of the level of interaction these users need with the operating system and applications to, for example, install and modify applications, services, devices, and so on.  Power users: these users are not administrators or software developers, but instead are (typically) proficient and have a greater understanding and need to support the use of their computers, operating systems, applications, and computer peripherals. These users may not require, for example, administrative rights on their computers, but certainly require higher rights and permissions than normal users. It is possible to identify these users via the categorisation of these users even further based upon the metadata aspects of these users and their computers, such as:  The job titles for these users, such as: • Consultant • Analyst • Director  The applications installed on their computers: • The number of applications they require access to, and use concurrently on a routine basis • The types of applications they have access to and use on a routine basis  Hardware: • The number of computers the users are assigned (such as one or more laptops and desktop computers)

Page 36 of 354

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

© 2004 Mustan Bharmal • The specifications of their computers, which exceed those of other “normal” users within an organisation • The peripherals associated with their computers, such as external hard disk drives, and so on  Routine participation in pilots for projects as they represent a user that will use the aspect of the pilot to a greater degree than a “normal” user, and so on  Note that these users may even be outside of the scope of management of an IT infrastructure and prefer a degree of independence. For example, IT consultants within a systems integrator may require total autonomy over their laptop computers to be able to install their own applications and operating systems for which they provide consultancy services. These users may be self-sufficient with respect to operating systems and certain applications, but still rely on the IT administrators of the organisation for support around line of business applications and hardware.  Normal users: this category represents the majority of users within an organisation, represented within an Active Directory domain as user account objects, that do not fit with any of the other profiles listed here. These users typically rely heavily upon the services of IT administrators for the organisation, and typically have very little, if any, rights and permissions that permit autonomy over the management of their computer and the operating system and applications on the computer.  Light users: this category represents users within an IT infrastructure for an organisation such as:  Users that access and use a computer on a regular basis, but only to access a small number of specific applications or resources, such as e-mail or databases. For example, receptionists or switchboard operators may be categorised as “light users”.  Users that access and use a computer only very occasionally, and when they do, it is only to access only one or two specific applications or resources. For example, a warehouse operator or security guard may also be categorised as a “light user”. The physical location(s) of the users within an organisation may influence their management requirements. However, only consider the use of this category where it is possible to identify variances in user administration between physical locations. Note that where there is a requirement to use this category, only select it where the physical location of a user is a long term (for example, more than 6 months) static variable, and not a frequently (for example, less than 6 months) changing variable. Note that the process to design an OU infrastructure will elaborate and further define categories for physical locations for the collation of Active Directory objects into OUs. The department or divisional structures the users work within may influence their management requirements. However, only consider the use of this category where it is possible to identify variances in user administration between departments / divisional structures. Note that where there is a requirement to use this category, only select it where the department for a user is a long term (for example, more than 6 months) static variable, and not a frequently (for example, less than 6 months) changing variable. Note that the process to design an OU infrastructure will elaborate and further define categories for “departments / divisional structures” for the collation of Active Directory objects into OUs.

Page 37 of 354

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

© 2004 Mustan Bharmal

The following are examples of potential categories for “types” of computers supported by this design methodology:  Computer accounts for servers  Computer accounts for non-server computers, which may be further sub-divided into computer accounts for:  Desktop computers  Laptop computers Within most organisations, it is possible to identify many “types” of computers that have different administrative requirements based upon their role within an organisation. An organisation may wish to define many different categories to reflect the different roles and management requirements for their computers. However, provided below are a few examples of the typical “roles” that computers within an organisation can assume, and that can hence form the basis for policy collation into GPOs:  Server computers: It may be possible to identify within an organisation many different categories or roles for Windows servers that support patterns of variances in management via GPO policies. For example, it may be possible to define generic categories for server roles such as:  Application servers, which may be further subdivided into categories such as: • Security application servers, such as firewall and virus servers • Remote access application servers • Enterprise management application servers, and so on  Terminal servers  Database servers  Messaging servers  Infrastructure servers (providing DHCP, WINS, DNS services, and so on), and so on  Desktop computers: It may be possible to identify multiple categories for types of desktop computers within an organisation based upon their role, such as:  Desktop computers for regular use by users within an organisation  Desktop computers exclusively used by selected users for testing of applications and services, and so on The physical locations of the computers within an organisation may influence their management requirements. However, only consider the use of this category where it is possible to identify variances in computer administration between physical locations. Note that where there is a requirement to use this category, only select it where the physical location of a computer is a long term (for example, more than 6 months) static variable, and not a frequently (for example, less than 6 months) changing variable. The department or divisional structures the computers support / are owned by may influence their management requirements. However, only consider the use of this

Page 38 of 354

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

© 2004 Mustan Bharmal

category where it is possible to identify variances in computer administration between departments / divisional structures. Note that where there is a requirement to use this category, only select it where the department a computer exclusively supports, or is owned by, is a long term (for example, more than 6 months) static variable, and not a frequently (for example, less than 6 months) changing variable. • Factor A4: Determination of the required scope and scale for metadata granularity ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement to employ multiple metadata aspects of Active Directory objects as the basis for intra-object class differentiation of objects (for management via GPO policies and / or DOC permissions), and  Wishes to determine the scope and scale of granularity for the multiple metadata aspects of Active Directory objects ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Prior to the determination of the final categories that will form the basis for inter- and intra-object class differentiation, it is necessary to define granularity (using scope and scale) for the required metadata aspects. For example, where there is a requirement to use “association with divisional structures” as a metadata aspect of users, to support intra-object class differentiation, it is necessary to define the scope and scale for “divisional structures” within an organisation, such as:  A scope defined by the logical boundary of autonomous divisions within an organisation  A scale, within this defined scope, of departments and then teams, such as “IT support” department, and then “Help Desk Support” team. When determining the scope and scale for identified metadata aspects, consider the following:  The required scope and scale for a metadata aspect must only reflect actual identifiable differences for management. For example, if computer accounts for web servers are not to receive different policies or DOC permissions to computer accounts for database servers, then there is no requirement to define categories for computers that differentiate between the web servers and database servers.  Examples of scales for Active Directory objects are:  For computer account objects, it is possible to use categories such as “servers, desktops, laptops” as the top-level categories. The “servers” category may then be further subdivided into computer accounts for (for example) “application servers”, “database servers”, “remote access servers”, “web servers”, “file and print servers”, “messaging servers”, and so on. This hence produces a “scale” for the computer object class to support variances in intra-object class administration. For example, “web servers” may require a greater focus on the application of security policies than “file and print servers”, and so on, and hence may justify the creation of a category for just the computer account objects for “web servers”.

Page 39 of 354

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

© 2004 Mustan Bharmal

 For user accounts, it is possible to use categories such as “normal user accounts”, “service user accounts”, and “application user accounts”, and so on.  For group objects, it is possible to use categories such as “security groups” and “distribution groups” as top-level categories. Further subdivision of these groups could reflect the scope of the groups. For example, it is possible to subdivide “security groups” into “universal security groups”, “global security groups”, and “domain local security groups”. Note again, there is only a requirement to establish these scales of granularity where it is possible to identify variances in intra-object class administration.  For printer objects, it is possible to subdivide the “printers” category into “black and white printers” and “colour printers” or “laser printers” and “thermal printers” and so on.  For shared volume objects, it is possible to subdivide the “shared volumes” category into “business confidential” and “public”, or “department xyz”, “department abc”, and so on. Use the above information to determine and document the required scope and scale for the identified metadata aspects of the in-scope Active Directory objects. • Factor A5: Determination of required generic categories for Active Directory objects ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the generic categories for Active Directory objects, to form the basis for inter-object class and intra-object class differentiation, for management of the Active Directory objects via GPO policies and DOC permissions. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: To permit differentiation between Active Directory objects, for the targeting of GPO policies and DOC permissions, it is necessary to define generic categories for the objects. Base the categories upon the metadata aspects of the Active Directory objects that support patterns of variances in object administration. Use the information supplied so far to execute an analysis to determine and document the required generic categories for Active Directory objects that will support patterns of variances in object administration via GPO policies and / or DOC permissions. • Factor A6: Determination of the requirement to define prioritisation amongst multiple categories ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has defined multiple categories for Active Directory objects as the basis for intraobject class differentiation of objects (for management via GPO policies and / or DOC permissions), and  Wishes to define and assign priorities for the use of each required category for intraobject class differentiation. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: It is possible for an organisation to define multiple categories for intra-object class differentiation.

Page 40 of 354

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

© 2004 Mustan Bharmal

For example, it is possible to differentiate between the GPO policy requirements for user 1 and user 2 using the following three categories (based upon metadata aspects of user 1 and user 2):  The association of the users to divisional structures (departments), where:  User 1 is associated with the Sales department, and  User 2 with the Legal department  The role of the user within the department, where:  User 1 is a manager of a team of people in the Sales department  User 2 is a personal assistant to the director of the Legal department  The type of user, with respect to their use of a computer, where:  User 1 is a “power” user, and uses many applications and hence has a high hardware resources utilisation profile.  User 2 is a “normal” user, and uses on a few applications concurrently, with a “normal” hardware resource utilisation profile. When determining the GPO policy requirements, for example, for User 1 and User 2, it is possible to differentiate the scope the application of the policies based upon any of these three categories, as they will all permit differentiation between User 1 and User 2. However, to reduce complications during the exercise to scope the application for required GPO policies, it is possible to prioritise these categories for use in differentiation. This design methodology provides the following examples of the criteria for the prioritisation of the required categories (for intra-object class differentiation:  The number of Active Directory objects aligned, within an object class, which require prioritisation against another category. The higher the number of objects within a category, the harder it becomes to establish differentiation between multiple instances of the object class. For example, using just two categories, such as “normal accounts” and “service accounts” (for user account objects) only typically permits differentiation between a few service / application user accounts, compared with a large number of “normal” user accounts. However, where there is a high requirement to differentiate between normal and non-normal user accounts, then this category may represent a top priority.  The number of management requirements for a category, via GPO policies and DOC permissions. Where only few numbers of GPO policies and / or DOC permissions require assignment to a category, when compared to a peer category, then there is a lower requirement to prioritise between the categories. For example, if the only GPO policy assignment differences between users in the category “Sales department members” and users in the category “power users” is one or two policies, then there is no requirement to define priorities between these categories. However, if there is a requirement to target more GPO policies to the category “power users” than the “Sales department members” category, the category “power users” should have a higher priority for intra-object class differentiation.  At this stage, it may not be possible to determine the precise priorities between the identified categories, until the organisation commences the processes to design a GPO infrastructure and a DOC infrastructure.

Page 41 of 354

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

© 2004 Mustan Bharmal

For example, an organisation has define the following categories for user account objects, and wishes to determine the priorities for use of the categories to support intraobject class (user object class) differentiation:  Categories for types of user accounts, such as normal user accounts; user accounts for services; user accounts for applications; user accounts for resources (such as resource mailboxes in Exchange)  Categories for types of users, such as normal users; power users; advanced users; light users  Categories for association of users to divisional structures within an organisation, such as user accounts in Sales department; Marketing department; Legal department; IT support department; HR department; Finance department; Development department; Consultancy practice, and so on.  Categories for job titles for user accounts such as directors, personal assistants, consultants, analysts, and so on Using the example criteria for prioritisation between the identified categories, the following table illustrates the determined priorities, and sequence for their use:
Category Normal User Accounts Service User Accounts Application User Accounts Resource User Accounts Normal Users Power Users Advanced Users Light Users User accounts in Sales Department User accounts in Marketing Department User accounts in Legal Department User accounts in IT Department User accounts in HR Department User accounts in Finance Department User accounts in Development Department User accounts in Consultancy Practice User accounts for Directors User accounts for Personal Assistants User account for Consultants User accounts for Analysts User accounts for Developers Priority 1 1 1 1 2 2 2 2 3 3 3 3 3 3 3 3 4 4 4 4 4

Table 32.2: Example of Category Prioritisation

Page 42 of 354

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

© 2004 Mustan Bharmal

In the above example, an organisation has decided to prioritise between types of metadata aspects, rather than specific categories, as each specific category within a type of metadata aspect has the same priority. Where there is a requirement to define a fewer number of categories, then it may be feasible to prioritise between specific categories. Using the above information, execute the following:  Define and document the criteria to qualify the prioritisation between the identified categories for types of Active Directory objects  Evaluate all required categories against the defined criteria to determine and document the high-level priorities between the identified categories. These categories are required to support intra-object class differentiation for object management via GPO policies and / or DOC permissions.

Page 43 of 354

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

© 2004 Mustan Bharmal

4.

Design of a Group Policy Object Infrastructure
All organisations considering the design and deployment of a Windows Server 2003 Active Directory domain must consider the design and use of Group Policy Objects (GPOs) for object management. This process requires execution a minimum of once for this domain, or once for each required object and resource management infrastructure for this domain.

4.1.

Process Objective The objective of this process is to assist an organisation in the generation of a design for the implementation of a GPO infrastructure, for each required object and resource management infrastructure (ORMI) this Windows Server 2003 Active Directory domain is to support. This process hence requires execution once for each required ORMI within this domain, as each ORMI will support only a maximum of one GPO infrastructure. The design for the management of an ORMI, and hence the component GPO infrastructure, is a component of the Active Directory Management Plan. The design of a GPO infrastructure for an Active Directory domain must address several variables. A GPO design model addresses and supports specific variables in the design, and hence permits the generation of a consistent and understandable design for all GPOs within a GPO infrastructure. The remaining variables that require addressing must be determined during the execution of this process. The background information section below discusses the variables that this process addresses.

4.2.

Process Scope The following factors define the scope of this process: • The boundary of an object and resource management infrastructure within this domain will dictate the scope for the supporting GPO infrastructure, and hence impose a restriction on the selection and use of one or more of the following primary or secondary points of implementation of GPOs: ♦ At the root of this domain ♦ On one or more default or custom Organizational Units (OUs) within this domain ♦ At one or more Active Directory Sites that host one or more domain controllers for this domain • The users and computers that reside within the scope of the object and resource management infrastructure will dictate the GPO policies this GPO infrastructure will be required to support, and the scope of application of these policies. • The GPO policies and policy configurations available within a default Windows Server 2003 Active Directory GPO object. The design for implementation and management of custom GPO policies from imported *.adm files is a component of the “Active Directory Management Plan” process “Design of an ORMI Management Plan”.

4.3.

Background Information Prior to the execution of this process, it is important to understand the following three specific concepts associated with this process: 1. What “object management” means with respect to GPOs and their configured policies

Page 44 of 354

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

© 2004 Mustan Bharmal

2. 3. 4.3.1.

What defines a “GPO infrastructure”, and the relationships of GPO infrastructures to “GPO design models” The variables associated with the design of any GPO infrastructure for a Windows Server 2003 Active Directory domain, generated using a GPO design model

Object Management Using GPOs Group Policy Objects (GPOs), as their name suggests, are groups of policies collated together to support a specific requirement or set of requirements. Note however, regardless of the requirements that support the generation of GPOs, all GPOs have the following aspects in common: • All policies within all GPOs support only one of two Active Directory object classes (users and computers), as it is only possible to target (directly or indirectly) a GPO to the Active Directory objects within a domain that represent the target user(s) and / or computer(s). • All actions performed by all policies within any GPO are exclusively for the “management” of one or more aspects of the target user or computer, ranging from application manipulation, software management, to desktop environmental control, and so on. • The Active Directory user and computer account objects, that represent the actual users and computers, are the targets for the components of an object management infrastructure, which permits the management of these users and computers from a centralised and / or remote logical location. • Configured policies within a GPO can influence one or more operational aspects of a target user or computer via manipulation of, for example, the Windows registry on the computers, the local security account database on a computer, and so on. Because the exclusive objectives for all GPOs are to manage multiple aspects of users or computers, GPOs are hence key components of any design for an object management infrastructure.

4.3.2.

Definition of a GPO Infrastructure This design methodology defines a “GPO infrastructure” as a collection of Group Policy Objects (GPOs) generated within an object and resource management infrastructure for a domain, via the use of a type of GPO design model. As a domain can support multiple GPO infrastructures, it is hence possible to support the use of multiple types of GPO design models within a domain. The design for the supporting OU infrastructure influences the selection of the type of GPO design model that will support a GPO infrastructure for the ORMI within this domain. The selection of a type of GPO design model will influence the design and use of a GPO infrastructure to support the following: • The implementation of this GPO infrastructure to support identified GPO policy requirements for an ORMI in this domain • The management of GPO policy requirements for this GPO infrastructure, postimplementation of an ORMI in this domain The following logical steps provide the foundation for this dependency between selection of GPO design models and the design for an OU infrastructure: • The processes to design the GPO and OU infrastructures for an ORMI have interdependent steps, as highlighted in the background information section of the process for the “design of an object and resource management infrastructure”.

Page 45 of 354

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

© 2004 Mustan Bharmal • The process to design the GPO infrastructure will define the required GPO policies, and the target user and computer objects (based upon the identified generic categories) of the required configuration(s) for each required policy. • The process to design the OU infrastructure will take these GPO policy management requirements, in conjunction with the DOC permission requirements, and design a supporting OU infrastructure that facilitates the targeting and implementation of the GPOs and DOC permissions • The process to design the GPO infrastructure will then select a type of GPO design model, which reflects and supports the required OU infrastructure, to collate the required policies into GPOs The approach proposed by this design methodology ensures that: • There is no compromise to the number of GPO infrastructures this domain may support • A minimal number of types of GPO design models are employed within this domain to generate the required GPOs (one type of GPO design model to one GPO infrastructure) • The resulting GPO infrastructure(s) are less complex, and easier to understand and manage 4.3.3. Variables in the Design of a GPO Infrastructure The design for any GPO infrastructure, when facilitated by a type of GPO design model, and as a component of an ORMI for an Active Directory domain, is required to identify and support the following ten variables: 1. 2. 3. 4. Identification of the Active Directory domain in which the GPOs require generation Determination of the policies within a GPO required and not required Determination of the configuration requirements for each in-scope policy setting Determination of the scope of application (target user(s) and computer(s)) to identify the in-scope and out-of-scope user and computer objects for each required policy configuration. Determination of the required type of GPO design model for a GPO infrastructure Determination of the design requirements for the vehicle(s) (security groups and WMI filters) required to scope and target the GPOs within a domain Determination of the primary point of implementation of GPOs within a domain Determination of the requirements to link GPOs to multiple secondary points of implementation within the domain, and where there is a requirement to permit the linking of GPOs to one or more secondary points of implementation, then identification of: a. The specific GPO(s) allowed to be linked to one or more secondary points of implementation b. The specific GPOs disallowed from being linked to one or more secondary points of implementation c. The potential in-scope secondary points of implementation within a domain where the identified GPOs may be linked

5. 6. 7. 8.

d. The potential out-of-scope secondary points of implementation within a domain where the identified GPOs may not be linked

Page 46 of 354

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

© 2004 Mustan Bharmal

e. The actual in-scope secondary points of implementation within a domain where the allowed GPOs are to be linked 9. Determination of the configuration requirements for the identified GPOs within a domain

10. Determination of the name for each required GPO within a GPO infrastructure for a domain 4.4. Process Approach When executing the process to design a GPO infrastructure to support an ORMI within this domain, the recommended approach is to “keep it simple”. This hence implies the following: • The design of a simple and intuitive GPO infrastructure that is easy to manage, operate, and troubleshoot • The design of a minimal number of GPOs for implementation within the GPO infrastructure • The minimal use of secondary points of implementation for GPOs within an ORMI It is important to respect the presence of inter-process dependencies between the four components of an ORMI. Hence, to compliment these dependencies, this design methodology proposes execution of the following approach for this process, to design a GPO infrastructure: 1. Use the results from the process to “design and object and resource management infrastructure” for this domain to determine the: a. Scope for this GPO infrastructure, and hence identify the in-scope users and computers that require management using GPO policies b. Generic categories for the types of in-scope users and computers within this ORMI, based upon metadata aspects of the actual users and computers, and their avatar Active Directory objects in the domain 2. 3. Determine the GPO policies outside of the scope for application to the defined in-scope users and computers supported by this GPO infrastructure For the in-scope GPO policies, determine the requirements for the design of two or more configurations for each required policy, based upon the scope of application of the policy. Where it is possible to identify the requirements for two or more configurations for required policies, determine the: a. The number of configurations required for a GPO policy and the scope of application of each required configuration, hence identifying the user(s) or computer(s) to receive the configured policies, and (where applicable) those users and computers to explicitly not receive the policy/ policy configuration. (Note that this is the point of dependency for specific steps within the processes to design the OU and Security Group infrastructures for this domain). b. The actual required configuration values for a GPO policy. Note also that a configuration for a GPO policy may be: i. ii. A default (not configured) policy setting for a GPO policy An “enabled” policy setting, with a custom or default value for the “enabled” policy

iii. A “disabled” policy setting, with a custom or default value for the “disabled” policy iv. A specific custom value for the GPO policy other than the “default” value

Page 47 of 354

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

© 2004 Mustan Bharmal

c.

Where it is not possible to identify the requirements for multiple configuration values for a GPO policy, then determine the single required configuration value and the: i. ii. In-scope user(s) or computer(s) to receive the policy / policy configuration Out-of-scope users and computers (where applicable) to explicitly not receive the policy/ policy configuration

4.

Pass the following determined information to the process to design an OU infrastructure for this ORMI, in this domain: a. The list of required GPO policies b. The list of required configuration(s) for each policy, and the scope of application of each required policy / policy configuration

5.

Take the following results from the process to design an OU infrastructure: a. The identified object administration profiles, which support object management using the identified GPO policies and DOC permissions, and the corresponding “admin OUs” b. The design of the OU infrastructure that will support this GPO infrastructure, and the DOC infrastructure for the ORMI c. The names and contents of each required OU within the supporting OU infrastructure for the ORMI

d. The type of OU design model used to generate the OU infrastructure 6. Analyse the design of the OU infrastructure to determine whether the contents of the OUs within the supporting OU infrastructure match the scope of application of each required configuration for each required policy. Where the contents of the OUs match the scope of application of each required configuration for each required policy, then proceed to step eight below. Where the contents of the OUs do not match the scope of application of each required configuration for each required policy, determine the pattern of distribution of the in-scope target users and computers for the required GPO policies against the OU contents. Select a type of GPO design model that reflects and supports the design of the supporting OU infrastructure for the ORMI, and collate the required policies into GPOs using the selected type of GPO design model. Determine the following design requirements for each required GPO: a. Determine the vehicles for targeting the required GPOs, based upon the determined scopes of application of the required policies now collated into GPOs. (Note that this is the point of dependency upon a deliverable of the process to design a security group infrastructure for this domain). b. Determine the most efficient primary point of implementation of each required GPO within a domain, at the domain or Site level, or at an OU. c. Determine the requirements to link required GPOs to one or more secondary points of implementation within the boundary for the GPO infrastructure. Where possible to identify this requirement, then determine the: i. The specific GPO(s) disallowed from being linked to one or more secondary points of implementation, and hence the allowed GPO(s)

7.

8.

9.

Page 48 of 354

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

© 2004 Mustan Bharmal

ii.

The potential in-scope secondary points of implementation within a domain where the identified GPOs may be linked, and hence the out-of-scope secondary points of implementation

iii. The actual in-scope secondary points of implementation within a domain where the allowed GPOs are to be linked d. Determine the configuration requirements for the GPOs, as dictated by the selected GPO design model for this GPO infrastructure. e. Determine the name for each required GPO in the GPO infrastructure using the organisation-wide naming convention. It is important to note the following about the approach proposed by this design methodology for the design of a GPO infrastructure: • The primary objective of this process is to generate a design for a GPO infrastructure, for immediate implementation, and not for the ongoing management of a GPO infrastructure. • The primary objective for a GPO design model is to facilitate the ongoing management of a GPO infrastructure via the provision of rules and constraints for the continued generation of GPOs within an implemented GPO infrastructure. • Hence, the design of a GPO design model is outside of the scope of this process to generate a design for the implementation of a GPO infrastructure. However, this process relies upon the concepts of GPO design models to permit the collation of GPO policies, identified during this process, into GPOs for immediate implementation. • Hence, this process only introduces the concepts of GPO design models and an illustration of the types of standard and hybrid design models supported by this design methodology. The process to “design an ORMI management plan” (a component of the “Active Directory Management Plan” in volume 2 of this design methodology) contains a sub-process to design each required type of GPO design model for the organisation. 4.5. Process Components Based upon the above approach, this process to design a GPO infrastructure for an ORMI in this domain is composed of the following five executable components: 1. 2. 3. 4. 5. 4.6. Determination of the GPO policy requirements for an ORMI for this domain Understanding the concepts and types of standard and hybrid GPO design models Selection of a type of GPO design model and collation of required policies into GPOs Determination of the design requirements for the required GPOs Design of the GPO infrastructure

Deliverables of Process Components The process will have the following deliverables: • The determination of the specific GPO policies that are required, and not required, from within a standard Windows Server 2003 Active Directory Group Policy Object • The determination of the number of, and value for, each required configuration settings for each required policy • The determination of the user and computer account objects within, outside, and explicitly out-of-scope of application of each required configuration for each required policy

Page 49 of 354

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

© 2004 Mustan Bharmal • The determination of the type of GPO design model required to support the collation of policies into GPOs • The determination of the Group Policy Objects that are to be created or modified based upon the rules for policy collation defined within the selected type of GPO Design Model • The determination of the design requirements for the vehicle(s) for targeting the required GPOs (WMI filters / security groups) • The determination of the primary point for creation and implementation, and the secondary point(s) for linking of the GPOs identified for creation • The determination of the configuration requirements for the GPOs identified for creation • The determination of the name for each required GPO • The generation of the design for a GPO infrastructure for an ORMI 4.7. Inter-Component Dependencies Each component of this process will have the following inter-component dependencies:
Domain Plan – Inter-Component Dependencies for Process to Design a GPO Infrastructure
Determination of the GPO policy requirements

START
Understanding the concepts and types of GPO design models Selection of a type of GPO design model & collation of required policies into GPOs Determination of the design requirements for the required GPOs Design of GPO infrastructure
© 2004 MUST
ANSHI R

BHAR

MAL

4.8.

Process to Design a Group Policy Object Infrastructure
Domain Plan – Process to Design a GPO Infrastructure

START

Execute B1

Execute A1 – A3

Execute B2

Execute A4 – A5

Pass determined information to process to design OU infrastructure Execute process “design of an OU infrastructure”

Execute A7 – A10

Execute B5

Execute A6

Execute B3 – B4

Receive determined information from process to design OU infrastructure Execute A12 – A14 Execute D1

Execute B6

Execute A11

Pass determined information to process to design security group infrastructure

END
© 2004 MUSTANSH
I R

BHAR

MAL

4.9.

Process Considerations Consider the following information when designing a Group Policy Object (GPO) infrastructure for an ORMI for this domain. Presented within the following five sections are the considerations for this process: 1. 2. Considerations for the determination of the GPO policy requirements for this GPO infrastructure Considerations to assist in the understanding of the concepts and types of standard and hybrid GPO design models supported by this design methodology

Page 50 of 354

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

© 2004 Mustan Bharmal

3. 4. 5. 4.9.1.

Considerations for the selection of a type of GPO design model, and collation of required policies into GPOs using the selected GPO design model Considerations for the determination of the design requirements for the required GPOs Considerations for the design of a GPO infrastructure

Determination of the GPO Policy Requirements for this GPO Infrastructure Consider the following information when determining the GPO policy requirements for this GPO infrastructure. Presented within the following three sections are the considerations for the execution of this step within this process: 1. 2. 3. Considerations for the determination of the scope for the GPO infrastructure, based upon the identified in-scope user and computer account objects that require management Considerations for the determination of the out-of-scope GPO policies for this GPO infrastructure based upon the scope of this GPO infrastructure Considerations for the determination of the: a. Configuration requirements for each required GPO policy, based upon the scope of application, and the values for each required policy configuration state b. The fixed / variable in-scope Active Directory objects for the required policy / policy configuration c. The fixed / variable out-of-scope Active Directory objects for the required policy / policy configuration

4.9.1.1.

Determination of the Scope for the GPO Infrastructure It is necessary to determine the scope of a GPO infrastructure within this domain whether an organisation has determined the requirement for the design of one or more ORMIs within this domain. A single ORMI, and hence a single GPO infrastructure, does not necessarily dictate that all user and computer account objects within the domain are within the scope of a GPO infrastructure. Hence, consider the following when determining the scope of a GPO infrastructure within an ORMI for this domain: • Factor B1: Understanding the components of the scope for a GPO infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the design of one or more ORMIs within this domain, and  Wishes to understand the components of the scope of a GPO infrastructure ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The objective of a GPO infrastructure is to manage user and computer account objects using GPO policies. Hence, the components of the scope of a GPO infrastructure are user and computer account objects. However, not all user and computer account objects within this domain, or the boundary of an ORMI, are necessarily within the scope of a GPO infrastructure.

Page 51 of 354

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

© 2004 Mustan Bharmal

The types of user and computer account objects may define the components of the scope of a GPO infrastructure. For example, it may be possible to identify two or more types of user accounts, such as user accounts for normal users, and user accounts for services and applications. • Factor A1: Determination of the scope of a GPO infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the design of one or more ORMIs within this domain, and  Wishes to determine the scope of a GPO infrastructure ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The scope for a GPO infrastructure must reflect only those user and computer account objects that explicitly require management by one or more GPO policies. Where it is possible to identify any user and computer account objects not to receive any of the possible GPO policies within a Windows Server 2003 Active Directory GPO, then exclude these objects from the scope of a GPO infrastructure. Use the above information to execute an analysis to determine and document the different types of user and computer account objects that reside within the scope of an ORMI for this domain. 4.9.1.2. Determination of the Out of Scope GPO Policies for this GPO infrastructure Consider the following when determining the specific GPO policies not required for use within this GPO infrastructure: • Factor A2: Determination of the requirements to exclude GPO policies from the scope of a GPO infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the design of one or more ORMIs within this domain, and  Wishes to understand the requirements to exclude GPO policies from the scope of a GPO infrastructure, and define the criteria to qualify the exclusion of GPO policies ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: A default Windows Server 2003 Active Directory GPO, using just the default “.adm” files, has approximately 745 different policy settings, in addition to the other GPO functions not policy-based, such as software management, file, service, and group management, and so on. Within most organisations, it is simpler to exclude all of those policies not required for application within this GPO infrastructure first, before defining the required policies, as most policies are required, and hence fewer policies explicitly not required. The objective of this step, in the process to design a GPO infrastructure, is to reduce the number of GPO policies that require configuration and application. This objective is

Page 52 of 354

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

© 2004 Mustan Bharmal

attainable via identification of all GPO policies an organisation wishes to exclude from configuration and application. Note that the GPO policies that require identification during this step must not include those policies an organisation wishes to restrict. For example, where an organisation wishes to restrict the use of Windows Media Player, do not “exclude” the GPO policies for this Windows Media Player from configuration and application, but instead include them and configure the policies as appropriate to disable this application. Although the onus is with the organisation to define their criteria, this design methodology provides the following examples of criteria, to qualify the exclusion of GPO policies from the scope of a GPO infrastructure:  The GPO policies are intended to configure a software application or feature on a target computer that is already configured (or will be managed by) another mode, such as a standard operating system build, or a script and so on. For example, an organisation may wish to exclude the configuration of Windows Internet Explorer, as there is a requirement to manage the configuration for this application, for example, an IEAK package, or a standard operating system build.  A GPO policy or set of policies are redundant as the target computers will not have the software application or feature installed. For example, a standard operating system build will remove Microsoft Windows Media Player, and hence the GPO policies for configuration of Microsoft Windows Media Player are redundant and hence require exclusion from the scope of this GPO infrastructure. Use the above information to define and document the criteria to qualify the exclusion of GPO policies from configuration and application. • Factor A3: Determination of the GPO policies that require exclusion from the scope of a GPO infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the criteria for the selection of GPO policies that require exclusion, and  Wishes to determine the categories of GPO policies and specific GPO policies that require exclusion from the scope of a GPO infrastructure ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When determining the specific GPO policies not required for inclusion within the scope of this GPO infrastructure, consider the following:  When determining the GPO policies not required, this design methodology proposes the following approach:  First, determine the high-level categories for GPO policies not required for configuration and application for any of the in-scope user and computer accounts objects for this GPO infrastructure. A Windows Server 2003 Active Directory GPO groups most policies into high-level categories as they share a common function. For example: • All policies for Microsoft NetMeeting are within the category “Administrative Templates\Windows Components\NetMeeting”. • All policies for Microsoft Windows Media Player are within the category “Administrative Templates\Windows Components\Windows Media Player”.

Page 53 of 354

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

© 2004 Mustan Bharmal • An organisation may wish to configure all instances of Windows Internet Explorer via Internet Explorer Administration Kits (IEAKs), or pre-configured as part of a standard operating system build, and hence not wish to use GPO policies. Thus may wish to exclude all policies within the category “Administrative Templates\Windows Components\Internet Explorer”.  Secondly, determine the specific GPO policies not required for configuration and application for any of the in-scope user and computer account objects for this GPO infrastructure. Be aware that many GPO policies have parent-child dependencies and relationships. Thus, deselecting one specific policy from configuration and application may logically invalidate (for configuration and application) multiple “child” policies. For example, where an organisation wishes to exclude from configuration and application a GPO policy that controls the configuration of the “Display” Control Panel applet, then this may also invalidate all other GPO policies for the “Display” Control Panel applet. Using the above information, execute the following:  Identify the specific categories of GPO policies that require exclusion from configuration and application  Identify the specific GPO policies that require exclusion from configuration and application  Evaluate the identified categories and specific policies against the defined criteria, to determine and document the exclusion list of GPO policies. 4.9.1.3. Determination of the Configuration Requirements for Required GPO Policies Consider the following when determining the configuration requirements for the GPO policies required for application within this GPO infrastructure: • Factor B2: Understanding GPO policy configuration ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the GPO policy configuration. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Within the scope of ORMI, a single GPO policy may require different configuration settings depending upon the scope of application of the policy. Hence, this design methodology directed the requirement to define generic categories for types of users and computers to permit deduction of the scope of application for a policy configuration state. When attempting to understand GPO policy configuration, consider the following:  Requirements for multiple configuration states for a GPO policy will hence support the requirement for multiple GPOs to collate each required configuration state for a GPO policy.  Every GPO policy with the default Windows Server 2003 Active Directory GPO has the default configuration state of “not configured”, which implies that the policy will have no action once applied to a target user or computer.  Most GPO policies only support the following three permissible configuration states:  Not configured (the default state)

Page 54 of 354

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

© 2004 Mustan Bharmal

 Enabled  Disabled  For these GPOs, it is hence only possible to support the generation of two GPOs where one contains an enabled GPO policy, and one a disabled GPO policy.  However, some GPO policies support more granular configuration for the “enabled” policy configuration state. For example, following the enabling of such a GPO policy, it is necessary to define a variable for that policy, or select a value from a predefined list of variables. The number of potential variables for a GPO policy will hence define the maximum number of GPOs required to support each required value, as each GPO can only support one configuration state and value for a GPO policy.  For each GPO policy that requires configuration, it is important to associate each required configuration with either a category for a type of user or computer, as appropriate to the type of policy, or a specific set of users and / or computers. Use the generic categories defined earlier for types of in-scope users and computers that support patterns of variances in their management.  It is very important to understand the wording of a GPO policy prior to selection of a configuration state for the policy. For example, setting the configuration state for the GPO policy “Turn off System Restore” to “disabled” will turn ON and enforce System Restore on a target computer. Enabling this policy setting will turn OFF System Restore on a target computer. • Factor A4: Determination of GPO policy configuration requirements ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the configurations for each required GPO policy. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When determining the configuration requirements for each required GPO policy, consider the following:  The Microsoft Windows Server 2003 Resource Kit contains a very useful Microsoft Excel spreadsheet that lists all of the default GPO policies and the following information for each available policy:  The source “.adm” file as the source for a policy  The target for a policy (machine or user)  The full name for a policy, as it appears inside a GPO policy object  The scope of application of a policy (operating system, application)  The explanation text for a policy  The registry settings targeted by a policy  Note that it is possible to extend a Windows Server 2003 Active Directory GPO via the import of custom / customised “.adm” files. For example, an organisation may wish to use GPOs to manage applications on a target computer, and so on. Where there is a requirement to import custom policies into a GPO, concurrently determine the configuration requirements for each of these extra policies.

Page 55 of 354

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

© 2004 Mustan Bharmal

When determining the configuration requirements for each required GPO policy, this design methodology proposes the following approach:  First determine, for each required GPO policy, the following information:  The criteria for the application of the policy based upon the target operating system, application, and so on. For example, some policies have a minimum requirement for application, such as an operating system or application version or service pack.  The number of potential configuration states and options available for each required GPO policy  The potential values for each identified potential configuration state  Then determine, for each required GPO policy, the following information:  Determine the number of instances of each potential configuration state required, based upon its value and the potential / ideal scope of application of the GPO policy configuration. See below for considerations associated with the determination of the scope of application of the required policies / policy configurations.  The requirement to enforce this policy, where the boundary of the ORMI is hierarchically above one or more other ORMIs within this domain  A profile of the target users / computers for the policy / policy configuration, based upon one or more of their metadata aspects  Then, map the profile for the required configuration state for a policy to one or more of the generic categories for target users and computers, defined within the process “design of an ORMI”.  Note that if it is not possible to map the required configuration state to one or more of the predefined generic categories of target users / computers, then identify the following details for the target profile of the policy / policy configuration:  The metadata aspects of the target users / computers that will comply with the desired scope of application of a GPO policy / policy configuration, such as an operating system or application version or service pack, and so on.  The required presence, value, or minimum / maximum value for each identified metadata aspect of a target user / computer, such as “Microsoft Windows XP Professional” or “Microsoft Internet Explorer version 6.03790”  The source of the metadata aspects of the target users / computers, such as the logical Active Directory object, or the physical actual object  Note that it is important to develop a strategy for the use of GPO policies, based upon the target user and / or computer account objects. For example, certain policies are duplicated for users and for computers, and the organisation must hence decide, prior to determination of the policy requirements, whether to:  Apply that policy configuration to just computers, for all / specific computers  Apply that policy configuration to just users, for all / specific users  Apply that policy configuration to users and computers, for all / specific users  When determining these types of requirements, it is important to understand the sequence of implementation of the policies. When a computer boots up, it will

Page 56 of 354

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

© 2004 Mustan Bharmal

contact an appropriate local domain controller and retrieve all of the policies assigned to it. Then, when a user logs on to that computer, the computer retrieves all the user’s policies from the authenticating domain controller and applies them. Hence, where there is a conflict between a policy configuration assigned to a computer (applied first) and the same policy configuration assigned to a user logging on using that computer, the policy configuration assigned to the user take precedence. A feature known as “loopback processing” permits the reapplication of the computer policies following application of the user policies, hence reestablishing the policy configurations assigned to the computer. When determining the configuration requirements for policies, this design methodology proposes the following approach:  A GPO object groups its policies together based upon their inter-policy dependencies and their association with a common target component / aspect of the operating system. Hence, do not determine the configuration requirements for policies individually, but for the common target component / aspect of the operating system.  It is hence necessary to execute the following strategy for the management of the target component / aspect of the operating system:  Understand the objectives of the policies grouped to manage a specific component / aspect of the operating system  Understand the function and objective of each policy within the group of policies, by ensuring a thorough understanding of the wording of the policy. It is very easy to become confused when understanding the wording of a policy and correlating this to the configuration options to enable or disable the policy. For example, the policy “Turn Off System Restore” means that if the policy configuration option “enabled” is selected, this turn off (or disables) system restore, and vice versa if select the “disabled” option.  Ensure a thorough understanding of the consequences associated with each policy configuration option  Identify the scope of application (as potential categories of users and computers) of the group of policies based upon the objective(s) of the policies  Identifying any opportunities for variances in the identified categories of potential target users and computers for the component / aspect of the operating system that requires configuration using the GPO policies  Identifying the strategy for the management of that component / aspect for each category of target user / computer using the policies  Identifying the GPO policies that will support each required strategy  Defining the configuration requirements for the policies for each target category of user / computer  For example, the policies to manage the Control Panel on target computers are only available for target users and not computers. The objectives of the policies to manage the Control Panel restrict the access to the Control Panel and the applets within the Control Panel. An organisation may hence identify the following strategy for determination of the policy configuration requirements for these policies:  As the objectives of these policies are to restrict access to the Control Panel and its applets, the organisation wishes to exclude all user account objects assigned to IT administrators within the organisation from these policies.

Page 57 of 354

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

© 2004 Mustan Bharmal

 The scope of application of these policies is hence all user account objects not assigned to IT administrators. However, among the non-IT administrator users, the organisation has identified categories of users such as developers, power users, normal users, light users, roaming users. Amongst these categories of potential targets for these policies, the organisation can identify the potential for variance in policy configurations to support different management requirements for these categories of users. The organisation has hence developed the following strategy for the determination of the configuration requirements for these policies: • All developers will have full access to the Control Panel applets except specific applets, such as the administrative tools, and local user and computer account management and so on. • All power users will have access to the Control Panel, but only specified applets • All normal users will have access to the Control Panel, but only specified applets (fewer than for power users) • All light users will have no access to the Control Panel at all • All roaming users will have access to the Control Panel, but only specified applets (as for normal users, but in addition to the Display applet)  It is very important to determine whether there is a requirement for each policy configuration option, and not simply whether there is a positive requirement to employ the policy. This is a very common mistake, and consequently most organisations only utilise a small percent of the potential for GPO policies. This is because, for most policies, the “disabled” option or “enabled” option is not the same as “not configured”. Note that selection of the “not configured” option may not support or prevent the user executing the opposite task of the policy, and hence there may be a requirement to enforce the negative objective of the policy and not just ignore it by leaving it as “not configured”. This is especially true to prevent policy conflicts generated by group membership changes, and so on. Using the above approach, for each required GPO policy, execute the following:  Define the criteria for the application of the policy to the target user / computer  Determine the number of potential configuration states / options available for the required GPO policy  Determine and document the required configuration state(s) / value(s) for the GPO policy  Determine and document the requirements to enforce this policy  Determine and document the profile for the ideal / required target users / computers for the policy / policy configuration  Define and document the mapping of the target profile for the policy / policy configuration to one or more of the predefined generic categories of target users / computers  Where it is not possible to map the target profile to a generic category, identify the required details for the profile. Pass the results of these steps to the step below, as an input to identify the scope of application of a GPO policy / policy configuration.

Page 58 of 354

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

© 2004 Mustan Bharmal • Factor A5: Determination of the scope of application of a policy / policy configuration ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has determined the required configuration requirements for each in-scope GPO policy, and  Wishes to determine the scope of application for each required GPO policy ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Each required policy / policy configuration must have a target user or computer, represented as either an Active Directory account object, or an actual user or computer device. It is important to note that it may not be possible, for each required policy / policy configuration, to identify the specific target users and / or computers. For example, a policy configuration may have a scope of application of a group of users and / or computers, collated into a virtual group to reflect a common metadata aspect, such as membership to a divisional structure within the organisation. In these scenarios, the specific target users and / or computers, and their numbers, are subject to fluctuations to accommodate natural changes within an organisation. It is hence possible to express the scope of application of a policy / policy configuration as one or more of the following examples:  A specific set or group of users or computers  “All users” or “all computers” within the scope of the ORMI the GPO infrastructure supports  A specific generic category of target objects, as defined earlier for types of users and computers within the scope of an ORMI, based upon one or more metadata aspects of the objects / actual users and computers These expressions are examples of “fixed” and “variable” scopes for a GPO policy / policy configuration. The criteria for the determination of whether the scope for a policy / policy configuration is fixed or variable are:  Knowledge of the specific logical or physical objects that will constitute the scope for the GPO policy / policy configuration  The number of logical or physical objects that will constitute the scope for the GPO policy / policy configuration, measured over a defined period of time, and against a permitted variance in-scope, expressed as a percentage of the total number of objects.  The defined period of time to measure the number of objects within the scope of a GPO policy / policy configuration  The numerical measure of fluctuation (expressed as a percentage of the total scope) in the numbers of logical or physical objects over the defined period of time Where it is not possible to identify the specific logical or physical objects that will define the scope for a GPO policy / policy configuration, then this is a “variable” scope. Where the number of logical or physical objects will fluctuate above or below the defined percentage of the total scope, over the defined period of time, then this is a “variable” scope.

Page 59 of 354

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

© 2004 Mustan Bharmal

A “fixed” scope for a GPO policy / policy configuration hence has the following characteristics:  The specific targets for a GPO policy / policy configuration, as either the logical or physical objects, are known individually in advance, and do not require definition at each application of the policy.  The numbers of target objects, as the logical or physical objects, do not fluctuate above or beyond the defined numerical threshold over a defined period. For example, a GPO policy has 100 objects defined as the scope, the percentage variance in-scope is 10 percent, and the defined period is six months. If an organisation expects the total number of objects within the defined scope for a GPO policy to vary by more than ten objects within a continuous six-month period, then the scope requires classification as a “variable” and not “fixed” scope. It is important to determine whether the scope for a GPO policy / policy configuration requires classification as a “fixed” or “variable” scope, as this is influential in the determination of the mode and vehicle(s) for targeting the GPO that holds the configured policy. When determining the scope of application of a required policy / policy configuration, consider the following:  The objectives of this step are as follows:  Determination of the fact that the scope of application of a GPO policy / policy configuration is either fixed or variable, based upon the intended function of the policy / policy configuration  Where it is possible to classify the scope of a GPO policy / policy configuration as being a “fixed” scope (via compliance with defined criteria), then determination of the following: • The identification of the specific target (logical (as Active Directory objects) or actual) users or computers that define the scope of application of a GPO policy / policy configuration • The identification of one or more aspects of object metadata common to all target objects that define the scope of application of a GPO policy / policy configuration. This information is valuable in the design of a supporting OU infrastructure and the determination of the design requirements for the vehicle(s) to target GPOs.  Where it is not possible to classify the scope of a GPO policy / policy configuration as being a “fixed” scope, and hence a “variable” scope, then determination of the following: • The identification of the metadata aspects of the target user and / or computer objects that will permit the definition of the scope for the GPO policy / policy configuration • The identification of the required or minimum / maximum acceptable value(s) for the metadata aspects of the target objects • The identification of the source of the object metadata from the target object (logical or actual object)  It is important to identify, in addition to all in-scope users and / or computers for each required policy configuration, all of the users and computers that require explicit exclusion from the scope of application of the required policy configuration. This

Page 60 of 354

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

© 2004 Mustan Bharmal

information is critical to the partitioning of the object administration profiles within the process to design an OU infrastructure. Based upon the defined objectives, this design methodology proposes the following approach to determine the scope of application of each required GPO policy / policy configuration:  Receive from the previous step the following information:  The list of required GPO policies / policy configurations  The criteria for the application of the policy based upon the target operating system, application, and so on.  The value(s) for each required GPO policy / policy configuration  The profile for the target users / computers, based upon their metadata  The mapping of target profile for the required configuration state for each required policy to one or more of the generic categories for target users and computers  Then, it is necessary to define the following:  The percentage value of the total number of target objects that will represent the variance threshold for the scope of a GPO policy / policy configuration  The period (in time) during which the scope must be static to permit classification as a “fixed” scope  Then, execute the following for each required policy / policy configuration:  Where the previous step has successfully mapped a required configuration state for a GPO policy to one or more predefined generic categories for target users / computers, then: • Attempt to identify the target users / computers for the policy / policy configuration via a translation of the mapped generic category to specific users and computers within the scope of the ORMI. • Evaluate the identified scope of target users / computers against the criteria for a “fixed” scope GPO policy / policy configuration  Where it is possible to attain compliance with the criteria for a “fixed” scope GPO policy / policy configuration, then: • List the identities of the specific users / computers that comprise the fixed scope of application of the GPO policy configuration • Identify the requirement(s) to limit the scope of application of a GPO policy / policy configuration. Where it is possible to identify this requirement, then identify, as a fixed or variable scope, the specific or categories of users / computers that require explicit exclusion from the scope of application of the GPO policy / policy configuration.  Where it is possible to identify specific users / computers, but not possible to attain compliance with both criteria for a “fixed” scope, and hence the number of target users / computers may fluctuate, then: • List the identities of the specific users / computers that comprise the fixed scope

Page 61 of 354

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

© 2004 Mustan Bharmal • State the requirement to abstract above the variable population size of the scope of application of a GPO policy / policy configuration via the use of a custom security group. The membership of the custom security group may fluctuate without compromising the application of the GPO policy / policy configuration. Note that the requirement to abstract above the variances inscope population via a custom security group requires consideration during the collation of the policy with other policies into a GPO. • Identify the requirement(s) to limit the scope of application of a GPO policy / policy configuration. Where it is possible to identify this requirement, then identify, as a fixed or variable scope, the specific or categories of users / computers that require explicit exclusion from the scope of application of the GPO policy / policy configuration.  Where the previous step is unable to map the required configuration state to one or more predefined generic categories for target users / computers, and this is hence a “variable” scope, then: • Identify the source of the variance in the scope of application of the GPO policy configuration. The source of the variance may be the requirement to define a variable set of target computer or user accounts. • Using the identified metadata aspects for the target users / computers (and the required value(s) for the metadata aspects), determine the most appropriate mode for defining the scope of application of a GPO policy / policy configuration. For example, where the identified metadata aspects for a target computer are the operating system it uses or amount of free hard disk space, then the most appropriate mode for defining the scope would be to use a WMI query to extract the information from the target computer. Where the identified metadata aspects are, for example, the membership of a user to a divisional structure, then a custom security group that reflects this function may be the most appropriate mode for defining the scope of the GPO policy / policy configuration. • Identify the requirement(s) to limit the scope of application of a GPO policy / policy configuration. Where it is possible to identify this requirement, then identify, as a fixed or variable scope, the specific or categories of users / computers that require explicit exclusion from the scope of application of the GPO policy / policy configuration. As stated and discussed in detail later, there are five factors that can influence the scope of application of a GPO and hence all of the configured policies within the Group Policy Object. These are as follows:  The manual identification of a fixed or variable scope representing users and / or computers that require explicit exclusion from the scope of application of a GPO policy / policy configuration  The logical boundary represented by the immediate container (Site, domain or OU) where a GPO is implemented, and the hierarchy directly beneath that container (where applicable), such as an OU hierarchy within a domain.  The use of “block inheritance” on a domain or OU container to prevent the inheritance of all GPOs linked above the domain (at a Site container), or linked / implemented at the domain level, or ordinate OUs.  The use of the “Read” (R) and “Apply Group Policy” (AGP) GPO permissions  The use of a WMI filter linked to a GPO

Page 62 of 354

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

© 2004 Mustan Bharmal

The identification of the first factor will influence the partitioning of “object administration profiles” within the process to design an OU infrastructure (see later). This process will also provide support for the second mode of control over the scope of application of GPOs implemented at OUs via the design of the supporting OU infrastructure. The process “design of an OU infrastructure” determines the requirement to configure “block inheritance” on one or more OUs within the OU infrastructure. The use of GPO permissions (R & AGP) is an effective method of controlling the scope of application of a GPO. It is possible to target the permissions, applied on a GPO object, to individual user and computer account objects, or to custom / built-in security groups with user and computer account members. Where the identified scope of application of a GPO is more than five to ten user and / or computer account objects, it is advisable to use a custom security group. The use of security groups, as discussed at the beginning of the Domain Plan, is a more efficient method to control the scope of application of a GPO than the assignment of GPO permissions to individual user and computer account objects. It is possible to control the scope of application of policies / policy configurations that computers running Windows XP Professional or Windows Server 2003 require via the use of a WMI filter linked to a GPO. This provides a greater degree of control over the application of policies, and hence management of the target users and computers via the use of attribute values from their physical / logical metadata. Hence, the use of WMI filters permits the stipulation of business and technical criteria for the application of that policy, which the target user / computer must comply with (via physical / logical metadata) to receive a policy / policy configuration. For example, it is possible to stipulate the following criteria (retrievable via a WMI query in a WMI filter) to control the scope of application for the delivery and management of a software package to target computers:  The target computers must have a minimum amount of free hard drive space on a specific partition  The target computers must have a minimum amount of physical memory (RAM)  The target computers must be manufactured by a specific manufacturer and be a specific model of computer, and so on. The use of WMI filters (discussed later in detail) hence permits dynamic control over the scope of application of GPO policies / policy configurations, and hence not limited by the membership of a custom security group. Only computers assigned the “Read” and “Apply Group Policy” permissions on a GPO may evaluate queries within WMI filters. Hence, as WMI filters permit a finer degree of control than achievable via the use of security groups alone, the security group assigned “R & AGP” permissions on a GPO does not have to have a narrow scope of application. Note that the use of WMI queries within WMI filters can extract both user and computer metadata to dynamically define the scope of application of a GPO. The user data will typically represent limited Active Directory metadata aspects of the user logged onto a computer that evaluates the applied WMI filter. It is advisable to review all of the possible metadata information a WMI can retrieve from a Windows XP Professional or Windows Server 2003 computer, and use this information to define criteria for the application of policies / policy configurations. Once all of the configuration requirements for all required (default and custom) GPO policies have being determined, along with the required scope of application for each required policy configuration, and the requirement to enforce specific policies (where

Page 63 of 354

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

© 2004 Mustan Bharmal

possible and appropriate), pass this information to the process to design an OU infrastructure. Using the above information, for each required GPO policy, execute the following:  Execute an analysis to determine and document whether the scope of application of a GPO policy / policy configuration is fixed or variable, to reflect the intended function of the policy / policy configuration.  Where it is possible to classify the scope of a GPO policy / policy configuration as being a “fixed” scope (via compliance with defined criteria), then execute the following:  Determine and document the identity of the specific target (logical (as Active Directory objects) or actual) users or computers that define the scope of application of a GPO policy / policy configuration  Determine and document the requirements for the use of one or more aspects of object metadata common to all target objects that define the scope of application of a GPO policy / policy configuration. This information is valuable in the design of a supporting OU infrastructure and the determination of the design requirements for the vehicle(s) to target GPOs.  Where it is not possible to classify the scope of a GPO policy / policy configuration as being a “fixed” scope, and hence a “variable” scope, then execute the following:  Determine and document the metadata aspects of the target user and / or computer objects that will permit the definition of the “variable” scope for the GPO policy / policy configuration  Determine and document the required or minimum / maximum acceptable value(s) for the metadata aspects of the target objects  Determine and document the identity of the source of the object metadata from the target object (logical or actual object)  Execute an analysis to determine all of the users and computers that require explicit exclusion from the scope of application of the required policy configuration. This information is critical to the partitioning of the object administration profiles within the process to design an OU infrastructure. 4.9.2. Understanding GPO Design Models Consider the following information to understand the role of a GPO design model in the process to design a GPO infrastructure, and the different types of GPO design models that this design methodology supports: • Factor B3: Understanding the role of GPO design models in the process to design a GPO infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the role of GPO design models within this process to design a GPO infrastructure. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: As stated earlier, in the background information section for this process, the objective of this process is to design a GPO infrastructure for immediate implementation, and the objective of a GPO design model is to facilitate the ongoing management of a GPO infrastructure, post-implementation.

Page 64 of 354

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

© 2004 Mustan Bharmal

However, GPO design models do have an important role to play in the process to implement a GPO infrastructure. Before explaining the role for a GPO design model, it is necessary to understand the objectives for the design and use of GPO design models. The objectives of all GPO design models are to support the generation of a consistent and understandable GPO infrastructure, which is simple to manage and troubleshoot. The primary variable associated with the generation of a GPO is the selection of policies to configure within a GPO. This design methodology proposes an approach to first identify the required policies, and their configuration(s), and then determine how to collate them into GPOs. This approach permits the generation of GPOs that comply with common objectives and requirements within an organisation. A GPO design model hence provides guidance for the collation of the policies into GPOs for application within a Windows Server 2003 Active Directory infrastructure. Following the rules within a GPO design model, a domain or GPO administrator may hence generate GPOs that are consistent, stable, and simpler to troubleshoot. The following are examples of factors that support the requirement for the design of one or more GPO design models:  Group Policy Objects (GPOs) are Active Directory objects that require frequent (monthly, quarterly, bi-annually, annually, and so on) creation, modification, deletion, and so on, depending upon the size and nature of an organisation, and the functions of the GPOs. Hence, a design model that controls the design of a GPO infrastructure permits the generation of stable and consistent Group Policy Object infrastructure for each domain within each forest of the Windows Server 2003 Active Directory infrastructure.  The design of Group Policy Objects requires careful consideration to avoid postdeployment user and computer management issues and complex policy troubleshooting exercises in the event of policy conflicts. GPO design models support the variables for the design of a GPO infrastructure via the provision of a process. The process will accept information collected during the process to design a GPO and OU infrastructure, and subsequent post-implementation GPO management processes, to guide the generation of GPOs using one or more of the types of designed GPO design models. This design methodology guides the generation of GPOs (during execution of the processes to design the implementation of a GPO infrastructure and postimplementation management of a GPO infrastructure) using the following sequence of (very high level) steps:  Identify the required policies within a GPO  Identify the following:  The required configuration or configurations for each required policy and  The fixed / variable scope of target objects (users and computers) that define the scope of application of the required policy configuration(s)  The explicit out-of-scope users and computers, defined as a fixed or variable scope, for the required policy configuration(s)  Select a type of GPO design model that reflects and supports the design of the OU infrastructure for the ORMI  Collate the required policies into GPOs using the selected type of GPO design model

Page 65 of 354

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

© 2004 Mustan Bharmal

 Determine the following design requirements for the GPOs and the GPO infrastructure:  The vehicle(s) / modes for targeting the application of GPOs within this domain  The most efficient point of creation and implementation for the GPOs, to ensure appropriate coverage of the required scope of application of all collated policies  The requirements to define and use secondary points of implementation of GPOs  The configuration requirements for the GPOs  The GPO names, assigned via the Organisation-Wide GPO naming model  Generate the GPOs at the required point of implementation and configure the required policies and the GPOs as appropriate Note that this design methodology does not support the generation of GPOs using an alternative approach to execute just the following sequence of steps:  Generate a GPO at a permissible point of implementation  Identify and configure the required policies with the GPO based upon the permissible scope of application represented by the desired point of implementation The Active Directory Management Plan (in volume 2 of this design methodology) process, “design of an ORMI management plan”, contains the sub-process to design each required type of GPO design model for an organisation. During the execution of this sub-process, the design for the types of required GPO design models must not address all of the variables, as this would produce an inflexible and static design for a GPO infrastructure, and cannot address some variables, as they are unknown at this stage. The execution of this sub-process can only hence address and define variables associated with the design of a GPO infrastructure that meet the following criteria:  Addressing a selected variable does not rely upon currently unknown (at this stage in the design of an Active Directory infrastructure) information specific to the management of the users and computers within an organisation, but instead just supports the known objectives and requirements of the organisation.  The rules provided by this process to address a selected variable will have an organisation-wide application, and not be restricted to the support of only one or more specific domains within the Active Directory infrastructure. Based upon these criteria, the only two variables, which the sub-process to design GPO design models may address, which comply with both of these criteria are:  The identification of the requirements and objectives to support the collation of the required configured policies into GPOs  The identification of the name for each required GPO within a GPO infrastructure for a domain The Organisation-Wide Active Directory Plan generates a GPO object-naming model that addresses the naming of GPOs generated within the GPO infrastructure. Hence, the sub-process of the Active Directory Management Plan to design GPO design models will only support the first variable associated with the design of a GPO infrastructure via the provision of guidance (via one or more GPO design models) for the collation of required configured policies into GPOs.

Page 66 of 354

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

© 2004 Mustan Bharmal

Within this design methodology, the objectives that support and guide the collation of policies into GPOs represent the foundation for the different types of GPO design models. Hence, this process to design a GPO infrastructure, selects a GPO design model (based upon the policy collation objectives of a type of GPO design model) to support the collation of the identified policies and their configuration(s) based upon their scope of application. Following this initial selection of a GPO design model to support a GPO infrastructure, there is a requirement to complete the design for the selected types of GPO design model(s) (depending upon the number of types of models selected where there is a requirement to design multiple GPO infrastructures) during the execution of the “Active Directory Management Plan”. The rules for the collation of policies into GPOs may reflect one or more of the following metadata aspects of GPOs:  The types of policies that require collation into GPOs  The primary and secondary points of implementation of a GPO within an Active Directory infrastructure  The fixed or variable scope of application of a GPO (to user and computer account objects)  The configuration of GPOs (specifically, the configuration of a GPO to “enforce” the policies within the GPO via the use of the “no override” option) This design methodology identifies and supports the use of three types of “standard” GPO design models that collectively permit reflection and support for all typical GPO requirements within an organisation. However, it is possible to design a hybrid GPO design model to cater for specific GPO design requirements not accurately supported by any one of the three standard models. Details of the three standard models, their primary structural components based upon the aspects of a GPO they utilise, and the hybrid GPO design models are discussed below. • Factor B4: Understanding the types of “standard” GPO design models ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the types of “standard” GPO design models this design methodology supports. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: As stated earlier, the objective(s) for the collation of policies into GPOs define the “type” of a GPO. Although it is possible to define many different possible objectives for the collation of policies into GPOs, all objectives must reflect one or more of the metadata aspects of a GPO, which in turn form the structural components of all GPO design models. Note that it is possible to collate policies into GPOs to reflect the:  Categories for the type or types of required GPO policies  The fixed or variable scope of application of the required policies  The point of implementation of the required policies

Page 67 of 354

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

© 2004 Mustan Bharmal

 The configuration requirements of the GPOs (specifically, the configuration of a GPO to enforce the policies within the GPO) However, this design methodology proposes that the point of implementation of the required policies, and the configuration requirements of the GPOs are not supported objectives for collation of policies into GPOs. This is explained below:  As it is only possible to create and link (as opposed to only link) a GPO to the root of a domain or an Organizational Unit (OU), unless the scope of a GPO infrastructure (and hence the ORMI) encompasses the root of the domain, then the “point of implementation” refers exclusively to OUs. Because this design methodology requires the design of an OU infrastructure to support the implementation of a GPO infrastructure, the process to design the OU infrastructure has already primarily collated the target user and computer account objects into OUs to support specified GPO requirements, prior to the collation of the policies into GPOs. Hence, the approach proposed for this design methodology invalidates the objective for policy collation of the use of the point of implementation of a GPO.  This design methodology does not support the use of the configuration requirements of the GPOs, specifically the requirement to enforce policies, as the objective for policy collation. This objective for policy collation requires the collation of all policies that require enforcement into one or more GPOs. There is not support for this objective by this design methodology, as the considerations for the design of the OU infrastructure include the requirements to enforce GPO policies, where the boundary of the ORMI is hierarchically above that of one or more other ORMIs within this domain. Hence, a combination of point of implementation, GPO configuration to enforce policy settings, and the use of policy inheritance will support these requirements. This design methodology hence only supports the type(s) of GPO policies and the scope of application of the policies as the objectives for the collation of GPO policies into GPOs. This design methodology hence proposes the following three “standard” GPO design models that support specific instances or combinations of the above supported metadata aspects of a GPO as the basis for the collation of policies into GPOs. The three standard GPO design models are termed:  Functional (reflecting both the type(s) of GPO policies, and the intended scope of application of the policies and configuration(s))  Monolithic (only reflecting type(s) of GPO policies)  Monolithic (only reflecting the scope of application of GPO policies) The following diagram illustrates the relationships between each of these three models and the two supported metadata aspects of a GPO:

Page 68 of 354

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

© 2004 Mustan Bharmal

Collates all required policies into “monolithic” GPOs based upon the type(s) of GPO policies

Type of Policies

Scope of Application

MONOLITHIC

MONOLITHIC

FUNCTIONAL

Collates all required policies into “monolithic” GPOs based upon the intended scope for application of the GPO policies and configuration(s)

Collates all required policies into a GPO based upon the type of the policy and the intended scope of application of the GPOs

© 2004 MUSTANSHI

R

BHAR

MAL

Figure 33.1: Relationships between the Three Standard GPO Design Models The objective for a “functional” GPO design model is to collate policies into GPOs to reflect the “function” of the policies. This hence requires reflection via the types of the policies and the scope of application of the policies. The functional GPO design model may also collate policies into GPOs to reflect a requirement to “layer” policy application hierarchically within an ORMI. The objective for a “monolithic” GPO design model based upon types of policies is to use defined categories for types of GPO policies as the basis for their collation into large, “monolithic” GPOs. The objective for a “monolithic” GPO design model based upon scope of application of the policies is to use the pre-defined generic categories for types of target users and computers as the basis for the collation of the policies into large, “monolithic” GPOs. 4.9.3. Selection of a GPO Design Model and Collation of Policies into GPOs Execute this step in the process to design a GPO infrastructure for an ORMI for this domain following receipt of the design for the supporting OU infrastructure for an ORMI. The process to design an OU infrastructure will identify object administration profiles that reflect the object management requirements using both GPOs and DOC permissions. The object administration profiles translate into “admin OUs”, and thus collate the Active Directory objects within the profiles into OUs. Consider the following when selecting a type of GPO design model to support the collation of required GPO policies into GPOs: • Factor A6: Determination of the requirement for the selection of a “functional” GPO design model ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the requirements for the selection of a “functional” GPO design model to guide the collation of policies into GPOs for a GPO infrastructure. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: As stated earlier, the objective of a functional GPO design model is to collate policies into GPOs that reflect the specific types of the policies for application to specific types or groups of objects. For example, a functional GPO design model may contain rules that dictate the collation of policies into a GPO to apply:

Page 69 of 354

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

© 2004 Mustan Bharmal

 All security settings (such as user account management, auditing, user rights, and so on) within a GPO to all computers, or  All software installation policies to all users, and so on Note the following facts about the “functional” GPO design model:  The number of categories defined for the “types” of policies, combined with the number of categories defined for the scope of application of GPOs, will determine the number of GPOs generated by a functional GPO design model.  Because it is possible to apply GPOs generated by a “functional” GPO design model at any of the three permissible points of implementation of a GPO (Sites, domains, and OUs), this design methodology regards the point of implementation of these GPOs as a secondary structural component of this design model. When determining the requirement for the selection of a “functional” GPO design model, consider the following:  The initial selection of a functional GPO design model to support the design of a GPO infrastructure depends upon compliance with the following criteria:  The scope of the GPO infrastructure a “functional” GPO design model is to support must contain more than one type of target user or computer, where the type reflects the selected metadata aspects of the target users and computers. For example, it is possible to identify, within the scope of the GPO infrastructure: • Different “types” of user accounts, such as user accounts for normal users and user accounts for services, applications, processes, and so on • Different “types” of computer accounts, such as computer accounts for servers, workstations, laptops, and so on  Where it is not possible to identify any patterns of variances in object administration (represented as object administration profiles) between in-scope user and computer accounts, then it may not be possible to employ a “functional” GPO design model within this GPO infrastructure.  The scope of the GPO infrastructure a “functional” GPO design model is to support must permit the identification of patterns of variances in the management of users and computers, based upon the types of required policies correlated with types of target objects. For example, it is possible to identify patterns of policy types, such as “all software installation policies”, or “all security settings for computers” against patterns of target objects, such as “all users in department A”, or “all computer account objects for application servers”, and so on.  The use of a “functional” GPO design model has the following advantages:  The collation of policies into GPOs to reflect the function(s) of the policies (based upon the scoping of specific types of policies against specific types of targets) is the most commonly employed objective for policy collation. This is because the GPOs generated by a “functional” GPO design model are correspondingly simple to understand and hence troubleshoot.  An OU infrastructure, generated to support the implementation of policies collated to reflect their function, is also simple to understand and manage.  The use of a “functional” GPO design model has the following disadvantage:  Depending upon the rules for policy collation defined for the functional GPO design model, there may be many permitted categories of “function” to support

Page 70 of 354

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

© 2004 Mustan Bharmal

the collation of policies into GPOs. Where this is the case, there may be a correspondingly large number of GPOs generated, which in turn may increase the administrative overheads for the GPO infrastructure. The following table list examples of categories of types of policies against types of potential targets for policies within a Windows Server 2003 Active Directory GPO. Within the table below, a check () against a potential target implies that the policy category may be applied to this target, and a cross () implies that the policy category may not be applied to this category of target (as guidance). Note the following:  This example table is only a guide and not a recommendation for policy targeting.  The following abbreviations are used in the table below for the categories of types of target users and computers for the policies:  User accounts: • Normal user accounts (user accounts created for everyday use by users within an organisation) • Service user accounts (user accounts created specifically for services and applications that require a security context for operation within an organisation)  Computer accounts: • Desktop computer accounts, using the following operating systems: • Windows 2000 Professional (abbreviated in table below as “W2K") • Windows XP Professional (abbreviated in table below as “WXP") • Laptop computer accounts, using the following operating systems: • Windows 2000 Professional (abbreviated in table below as “W2K") • Windows XP Professional (abbreviated in table below as “WXP") • Server computer accounts, using the following operating systems: • Windows 2000 (Server / Advanced Server) (abbreviated in table below as “W2K") • Windows Server 2003 (Standard Edition / Enterprise Edition / Web Edition / Datacenter Edition) (abbreviated in table below as “W2K3")  The numbers within the table refer to notes supplied after the table.  With Windows Server 2003 Active Directory GPOs, and the use of the Group Policy Management Console (GPMC), it is possible to extend the scope for policy targeting to reflect the results of WMI queries.

Page 71 of 354

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

© 2004 Mustan Bharmal

Policy Function Categories

Function Sub-Categories (only second-level categories shown)

User Accounts Normal Service

Computer Accounts Desktops W2K WXP                         Laptops W2K                         WXP                         Servers W2K                         W2K3                        

Software installation Scripts Remote Installation Services Folder Redirection Application Data Desktop My Documents Start Menu Internet Explorer Maintenance Browser User Interface Connection URLs Security Programs Advanced (only viewable in “Preference Mode”) Security Account Policies Local Policies Event Log Restricted Groups System Services Registry File System Wireless Network (IEEE 802.11) Policies Public Key Policies Software Restriction Policies IP Security Policies on Active Directory

                       

                       

                       

Page 72 of 354

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

© 2004 Mustan Bharmal

Policy Function Categories

Function Sub-Categories (only second-level categories shown)

User Accounts Normal Service

Computer Accounts Desktops W2K WXP           12 1 10    
10,15 11

Laptops W2K                  WXP           12 1 10    
10,15 11

Servers W2K           8,12      
10,15

W2K3     11 3     3, 9,12  10 3   

Software installation Scripts Windows Components NetMeeting Internet Explorer Application Compatibility Internet Information Services Help and Support Centre Windows Explorer MMC Task Scheduler Terminal Services Windows Installer Windows Messenger Windows Media Digital Rights Management Windows Media Player Windows Update Start Menu and Taskbar System System User Profiles Scripts Ctrl + Alt + Del Options Logon Disk Quotas Group Policy Power Management Net Logon Remote Assistance System Restore Error Reporting Windows File Protection Remote Procedure Call Windows Time Service

   14   3    12  10   
10 1,3,10 11

          12  10           10        
1,2,10

                 

3,10,11

6,10       10 10       
1, 2,10

10,15

10,15

3,10 7  

7     10        
2,10

7     10  
10 10

7     10        
2,10

7     10  
10 10

7     10        
2,10

10  3,10  3,10 10  3,10  3,10,11 10

10 1   10,11 10
10

10 1   10,11 10
10

Page 73 of 354

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

© 2004 Mustan Bharmal

Policy Function Categories

Function Sub-Categories (only second-level categories shown)

User Accounts Normal Service

Computer Accounts Desktops W2K WXP   10 1,10 10 10 10 10 10,13          Laptops W2K     10 4   10,13          WXP   10 1,10 10 10 10 10 10,13          Servers W2K    10 10 4   10,13          W2K3   10 10 10 10 10 10 3,10,13         

Software installation Scripts Network Network DNS Client Offline Files Network Connections QoS Packet Scheduler SNMP Printers Desktop Desktop Active Desktop Active Directory Control Panel Control Panel Add or Remove Programs Display Printers Regional and Language Options Shared Folders

    10 4,10    5,10  
2

     4,10    5        

    10 4   10,13         

10 6    10
4,10

11

Table 33.1: Examples of Categories of Types of Policies against Types of Potential Targets for Policies The following notes accompany this table: 1. 2. 3. 4. 5. 6. 7. 8. = There are some policies within this function only supported on Windows XP Professional
1 2

= There are some policies within this function only supported on Windows 2000

= There are some policies within this function only supported on at least Windows Server 2003
3

4

= There are some policies within this function only supported on at least Windows 2000 SP1 and later
5

= There are some policies within this function only supported on at least Windows 2000 SP3 and later
6

= There are some policies within this function only supported on at least Windows 2000 SP3 or Windows XP Professional SP1
7

= There is one policy within this function only supported on Windows 2000 SP4, Windows XP Professional SP1 and later, and Windows Server 2003
8

= There are some policies within this function only supported on at least Windows 2000 Terminal Services

Page 74 of 354

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

© 2004 Mustan Bharmal

9. 10. 11. 12. 13. 14. 15.

9

= There are some policies within this function only supported on Windows Server 2003 Enterprise Edition
10

= There are some policies within this function only supported on at least Windows XP Professional or Windows Server 2003 and later
11

= There are some policies within this function only supported on at least Windows XP Professional SP1 or Windows Server 2003 and later
12

= There are some policies within this function only supported on at least Windows XP Terminal Services
13

= There is one policy within this function only supported on Windows 2000 or later, running IIS (not supported on Windows Server 2003)
14

= There are some policies within this function only supported on at least Internet Explorer 6.0
15

= There are some policies within this function only supported on at least Internet Explorer 6.0 SP1

Use the above information to execute an analysis to determine and document the requirement for the selection and use of a “functional” GPO design model. • Factor B5: Understanding examples of the potential categories for types of policies ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement to select one or more GPO design models that use categories of the types of policies as the basis for their collation into GPOs, and  Wishes to understand and review examples of potential categories for the types of GPO policies within a default Windows Server 2003 Active Directory GPO ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology supports the categorisation of policies available within a default Windows Server 2003 Active Directory GPO based only upon one or more of the following:  The default metadata aspects of policies within a Windows Server 2003 Active Directory GPO, such as:  The minimum application criteria for a policy, defined by, for example: • The version of Windows operating system • The version of Internet Explorer • The version of Windows Media Player • The version of service pack for Windows operating systems or applications  The default policy files that supply the policies: • Conf.adm for NetMeeting policies • Inetres.adm for Internet Explorer policies

Page 75 of 354

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

© 2004 Mustan Bharmal • Wmplayer.adm for all Windows Media Player policies • Wuau.adm for all Windows Update policies • System.adm for all other policies contained within a default Windows Server 2003 Active Directory GPO  The scope of application of the policies, based on machine or user  The function of the policies The use of the minimum application criteria for policies is very useful in the collation of the required policies into GPOs, especially when combined with the corresponding categories of computers that reflect these criteria. See later for a comparison of policy type against criteria for the minimum application of policies. The use of the “scope of application” of the policies, without application to specific user and computer account objects, only permits the generation of two large categories (users and machines) and hence is not suitable. The exclusive use of just these categories would generate monolithic GPOs that do not reflect the objective of the design model to generate “functional” GPOs. The use of the function (irrespective of target) of each policy within a Windows Server 2003 Active Directory GPO is the preferred metadata aspect of a policy to generate categories of types of policies. The use of the function of a policy permits the identification of the following categories, each of which may form the basis for the collation of policies into GPOs. The following table illustrates examples of categories for the functions of policies:
Policy Function Categories Policy Function Sub-Categories

Software installation Scripts Remote Installation Services Folder Redirection Application Data Desktop My Documents Start Menu Internet Explorer Maintenance Browser User Interface Connection URLs Security Programs Advanced (only viewable in “Preference Mode”)

Page 76 of 354

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

© 2004 Mustan Bharmal

Policy Function Categories Security

Policy Function Sub-Categories Account Policies Password Policy Account Lockout Policy Kerberos Policy Local Policies Audit Policy User Rights Assignment Security Options Event Log Restricted Groups System Services Registry File System Wireless Network (IEEE 802.11) Policies Public Key Policies Encrypting File System Automatic Certificate Request Settings Trusted Root Certification Authorities Enterprise Trust Software Restriction Policies IP Security Policies on Active Directory

Page 77 of 354

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

© 2004 Mustan Bharmal

Policy Function Categories Windows Components

Policy Function Sub-Categories NetMeeting Application Sharing Audio and Video Options Page Internet Explorer Internet Control Panel Offline pages Browser Menus Toolbars Persistence Behaviour Administrator Approved Controls Application Compatibility Internet Information Services Help and Support Centre Windows Explorer Microsoft Management Console Common Open File Dialog Restricted / Permitted SnapIns Extension snap-ins Group Policy (Group Policy snapin extensions; Resultant Set of Policy snap-in extensions)

Task Scheduler Terminal Services Client / Server data redirection Encryption and Security Licensing Temporary Folders Session Directory Sessions Windows Installer Windows Messenger Windows Media Digital Rights Management Windows Media Player User Interface Playback Networking Windows Update Start Menu and Taskbar RPC Security Policy

Page 78 of 354

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

© 2004 Mustan Bharmal

Policy Function Categories System

Policy Function Sub-Categories User Profiles Scripts Ctrl + Alt + Del Options Logon Disk Quotas Group Policy Power Management Net Logon Remote Assistance System Restore Error Reporting Advanced Error Reporting Settings DC Locator DNS Records

Windows File Protection Remote Procedure Call Windows Time Service Network DNS Client Offline Files Network Connections QoS Packet Scheduler DSCP value of confirming packets DSCP value of non-conforming packets Layer-2 priority value SNMP Printers Desktop Active Desktop Active Directory Control Panel Add or Remove Programs Display Printers Regional and Language Options Shared Folders Desktop Themes Time Providers

Table 33.2: Examples of Categories for the Functions of Policies • Factor A7: Determination of the requirement for the selection of a “monolithic” GPO design model reflecting just the different type(s) of GPO policies ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the requirements for the selection of a “monolithic” GPO design model reflecting just the different type(s) of GPO policies. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation:

Page 79 of 354

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

© 2004 Mustan Bharmal

As stated earlier, the objective of a monolithic GPO design model is to collate all required policies together into a few large “monolithic” GPOs that reflect just the type(s) of GPO policies. The examples for categories for types of policies illustrated in table 33.1 above form the foundation for this type of GPO design model. Note the following facts about this type of “monolithic” GPO design model:  The number of categories defined for the “types” of GPO policies will have a major influence on the number of GPOs generated by this type of monolithic GPO design model.  Because it is possible to apply GPOs generated by a “monolithic” GPO design model at any of the three permissible points of implementation of a GPO (Sites, domains, and OUs), this design methodology regards the point of implementation of these GPOs as a secondary structural component of this design model. When determining the requirement for the selection of a “monolithic” GPO design model, consider the following:  The initial selection of this type of monolithic GPO design model to support the design of a GPO infrastructure depends upon compliance with the following criteria:  The selection of a category for a type of GPO policy requires compliance with the identification of the requirement to implement a minimum number of instances of that type of policy the category represents. For example, where an organisation selects a policy category such as “User Configuration – Administrative Templates – Windows Components – Terminal Services (all)”, then there must be a minimum number of the corresponding policies / instances of policies within this category to justify its definition and use to collate policies into GPOs.  The onus is with the organisation to define a value for the minimum number of instances of a type of policy for support by a category.  The fewer the categories for types of GPO policies defined, the fewer the number of GPOs generated. It is possible to collate defined categories together, so that a “super-category” will collate policies from multiple “sub-categories” to generate a GPO.  Analyse the object administration profiles generated by the design for an OU infrastructure to understand the distribution of the target users and computers for the required policies. This information will assist in the determination of the required categories for types of GPOs policies, via the execution of the following approach:  Analyse the identified object administration profiles, generated by the process to design an OU infrastructure, to determine the distribution of the target Active Directory objects for the required policies / policy configurations among the “admin OUs”.  Use the distribution of the target objects to identify any common categories for types of GPO policies within and between the “admin OUs”, with the objective of defining a minimal number of categories.  Define the required categories for types of GPO policies  The use of this type of “monolithic” GPO design model has the following advantage:  The collation of policies into GPOs based upon their type generates a GPO infrastructure that is simple to manage and troubleshoot. This is because the execution of routine tasks to, for example, locate and modify a type of policy is simplified via the grouping of policy types into GPOs.

Page 80 of 354

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

© 2004 Mustan Bharmal

 The use of a “monolithic” GPO design model has the following disadvantages:  Where an organisation has defined a very granular series of categories for types of GPO policies, the use of this type of monolithic GPO design model may result in a very large number of GPOs.  It is uncommon for the use of types of GPO policies as the basis for object administration, and hence the supporting OU infrastructure will rarely reflect this object administration perspective. Where the supporting OU infrastructure distributes the target objects for types of GPOs across multiple OUs, there is the requirement to either : • Link GPOs to all appropriate OUs where the same policy configuration is required for all distributed target objects, or • Generate multiple GPOs for implementation at the appropriate OUs where the target objects require the same type of policy, but differing configuration values Use the above information to execute an analysis to determine and document the requirement for the selection and use of a “monolithic” GPO design model, which collates policies into GPOs based upon policy type. • Factor A8: Determination of the requirement for the selection of a “monolithic” GPO design model reflecting just the scope of application of the GPO policies ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the requirements for the selection of a “monolithic” GPO design model reflecting just the scope of application of the GPO policies. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: As stated earlier, the objective of this type of monolithic GPO design model is to collate policies into GPOs that reflect just the scope of application of the policies, based upon categories for target users and computers. The generic categories for users and computers defined earlier, within the process “design of an ORMI”, will support the segregation and collation of policies into GPOs for this type of monolithic GPO design model. Note the following facts about this type of “monolithic” GPO design model:  The number of categories defined and used for the target users and computers will determine the number of GPOs generated by this type of “monolithic” GPO design model.  Because it is possible to apply GPOs generated by this type of “monolithic” GPO design model at any of the three permissible points of implementation of a GPO (Sites, domains and OUs), this design methodology regards the point of implementation of these GPOs as a secondary structural component of this design model. When determining the requirement for the selection of this type of “monolithic” GPO design model, consider the following:  The initial selection of this type of “monolithic” GPO design model to support the design of a GPO infrastructure depends upon compliance with the following criteria:

Page 81 of 354

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

© 2004 Mustan Bharmal

 The scope of the GPO infrastructure a “monolithic” GPO design model is to support must contain more than one type of target user or computer, where the type reflects the selected metadata aspects of the target users and computers. For example, it is possible to identify, within the scope of the GPO infrastructure: • Different “types” of user accounts, such as user accounts for normal users and user accounts for services, applications, processes, and so on • Different “types” of computer accounts, such as computer accounts for servers, workstations, laptops, and so on  Where it is not possible to identify any patterns of variances in object administration (represented as object administration profiles) between in-scope user and computer accounts, then it may not be possible to employ this type of “monolithic” GPO design model within this GPO infrastructure.  The scope of the GPO infrastructure this type of “monolithic” GPO design model is to support must permit the following: • The identification of patterns of variances in the management of users and computers, based upon the categories of types of target objects • The identification of patterns between “fixed” and “variable” scopes for GPO policies / policy configurations  Where the scope of a GPO policy is “fixed”, then it is possible to collate multiple GPO policies with “fixed” scopes of application, which match each other with respect to content of the “fixed” scope, into a GPO.  Where the scope of a GPO policy is “variable”, then it is only possible to collate multiple GPO policies with “variable” scopes of application into a GPO where the metadata aspects of the target users / computers, which define the scope, exactly match.  The use of this type of “monolithic” GPO design model has the following advantages:  The collation of policies into GPOs to reflect categories of their scope of application is a commonly employed objective for policy collation. Most target objects for GPO policies require management to reflect one or more aspects of their object metadata, and hence the process to design an OU infrastructure groups the target objects into object administration profiles. This hence reduces the number of GPOs generated, as it is possible to collate the categories for types of objects together and thus collate the corresponding policies into fewer GPOs.  The resulting GPO infrastructure is simple to manage and troubleshoot where the supporting OU infrastructure also reflects the requirement to manage the target users and computers based upon one or more aspects of their object metadata.  The supporting OU infrastructure will have a closer alignment to this perspective for object administration, as it mimics the requirements to support DOC of control. Hence, the supporting OU infrastructure will facilitate the collation of policies into GPOs, and their subsequent implementation.  The use of a “monolithic” GPO design model has the following disadvantage:  It is possible to generate a large number of GPOs to support this type of GPO design model where the requirements for object management do not reflect their object metadata.

Page 82 of 354

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

© 2004 Mustan Bharmal

Use the above information to execute an analysis to determine and document the requirement for the selection and use of a “monolithic” GPO design model, which collates policies into GPOs to reflect categories for types of target users and computers. • Factor A9: Understanding the types of “hybrid” GPO design models, and determination of the requirements for the design and use of one or more hybrid GPO design models ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to:  Understand the types of hybrid GPO design models supported by this design methodology, and  Determine the requirements for the design and use of one or more hybrid GPO design models ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Hybrid GPO design models support combinations of objectives for the collation of policies that do not match any of the combinations of objectives supported by the standard GPO design models. For example, an organisation may require the design of a single GPO, that does not build upon any GPOs higher up a hierarchy, that applies all required security policies to a specific point of implementation, such as an Organizational Unit designed to hold only computer accounts for member servers. None of the standard GPO design models caters for this specific GPO design requirement. The following figure illustrates just two examples of the types of hybrid GPO design models an organisation may design, supported by this design methodology. This design methodology will only support types of hybrid GPO design models that employ one or more of the following metadata aspects of GPOs.

Type of Policies

Configuration of GPOs

(For example) collates all types of required policies into GPOs based upon a combination of the intended scope of application and point of implementation of the GPOs

(For example) collates all types of required policies into GPOs based exclusively upon the intended point of implementation of the GPOs

HYBRID
Scope of Application Point of Implementation
© 2004 MUSTANSHI
R

Figure 33.2: Examples of Hybrid GPO Design Models When determining the requirements for the design and use of one or more hybrid GPO design models, consider the following advantages to this approach:

ID R YB H

BHAR

MAL

Page 83 of 354

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

© 2004 Mustan Bharmal

 The hybrid GPO design model permits an organisation to design GPOs that meet their business and technical requirements without the constraints of a standard GPO design model.  The GPOs created can have a broad or granular scope of application and content as required. When determining the requirements for the design and use of one or more hybrid GPO design models, consider the following disadvantages to this approach:  The use of a hybrid GPO design model permits the generation of a complex structure for the design model to meet specific singular or multiple business and technical requirements. The design of such complex design models requires the concurrent training in use of the design model, to enforce and assure compliance with the rules of the model.  Complex design models can generate GPOs that are difficult to troubleshoot without clear knowledge and understanding of the design model to ascertain the function of GPOs generated.  The design of a simple hybrid GPO design model may require concurrent support by one or more other standard or more complex hybrid GPO design models. The larger the number of design models required, the greater the administrative overhead becomes for GPO management. Using the above information, execute the following:  Execute an analysis to determine the requirements for the design of one or more hybrid GPO design models, via investigations to identify any objectives for policy collation not supported by any of the standard GPO design models.  Where there is a requirement to design one or more hybrid GPO design models, then determine and document the potential metadata aspects of a GPO that will represent the primary structural components of each required hybrid GPO design model, and hence define the “type” for the model. • Factor A10: Collation of policies into GPOs using the selected type of GPO design model ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has selected a type of standard or hybrid GPO design model, and  Wishes to collate the required policies into GPOs using the selected type of GPO design model ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Following the selection of a type of GPO design model, the next step is to use the type of design model to collate the required policies into GPOs. This step is the most critical in the design of a GPO infrastructure, as it will define whether the resulting GPO infrastructure is a “good or bad” design. This design methodology proposes the following criteria to qualify a design for a GPO infrastructure as a “good” or “bad” design for a GPO infrastructure:  A “good” design for a GPO infrastructure is simple, intuitive to use, and administer the target users and computers

Page 84 of 354

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

© 2004 Mustan Bharmal

 A “good” design for a GPO infrastructure facilitates the management and troubleshooting of GPOs and GPO policies by making the policies simple to locate and analyse.  A “good” design for a GPO infrastructure employs a minimal number of GPOs that take full advantage of inheritance of policies down an OU hierarchy  A “good” design for a GPO infrastructure avoids the implementation of large numbers of GPOs at any single container  A “good” design for a GPO infrastructure employs a minimal use of the linking of GPOs across multiple OUs (secondary points of implementation), as this may complicate the operation of the GPO infrastructure and execution of troubleshooting tasks. When collating the required policies into GPOs, in addition to the above criteria for a “good” design for a GPO infrastructure, consider the following:  Avoid the generation of too few GPOs with very large numbers of policies with a broad scope of application  Avoid the generation of too many GPOs with only a few configured policies within each GPO  Collate all policies that require enforcement down a container hierarchy into as little a number of GPOs as possible. This will facilitate the configuration of GPOs with the “no override” option, to enforce the application of the policy configurations within the GPO. Consider and use the above information to collate the required GPO policies into GPOs, using the selected type of GPO design model. 4.9.4. Determination of the Design Requirements for the Required GPOs and GPO Infrastructure Consider the following when determining the design requirements for the required GPOs and GPO infrastructure: • Factor B6: Understanding the remaining design requirements that require determination ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the design requirements for the required GPOs and GPO infrastructure that still require determination. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: From the list of ten variables in the design of a GPO infrastructure, stated earlier in the “Background Information” section of this process, this process has so far addressed the following five variables:  The identity of the specific Active Directory domain where the GPO infrastructure requires generation, as “this domain” that this Domain Plan supports  The following variables were determined during the execution of the step “determination of the GPO policy requirements for this GPO infrastructure” within this process:  The determination of the policies within a GPO that are required and those not required were

Page 85 of 354

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

© 2004 Mustan Bharmal

 The determination of the different configurations required for each required policy setting  The determination of the scope of application (target user(s) and computer(s)) to identify the in-scope and out-of-scope user and computer objects for each required policy configuration.  The selection of the required type of GPO design model for the GPO infrastructure was determined during the execution of the step “selection of a GPO design model and collation of policies into GPOs” Hence, the execution of this step, to determine the design requirements for the GPOs and GPO infrastructure, will address the following remaining five variables:  Determination of the design requirements for the vehicle(s) (security groups and WMI filters) required to scope and target the GPOs within this domain  Determination of the primary point of implementation of GPOs within this domain  Determination of the requirements to link GPOs to multiple secondary points of implementation within the domain, and where there is a requirement to permit the linking of GPOs to one or more secondary points of implementation, then identification of:  The specific GPO(s) allowed to be linked to one or more secondary points of implementation  The specific GPOs disallowed from being linked to one or more secondary points of implementation  The potential in-scope secondary points of implementation within this domain where the identified GPOs may be linked  The potential out-of-scope secondary points of implementation within this domain where the identified GPOs may not be linked  The actual in-scope secondary points of implementation within this domain where the allowed GPOs are to be linked  Determination of the configuration requirements for the identified GPOs within this domain  Determination of the name for each required GPO within the GPO infrastructure for this domain. Note that the object-naming model for GPOs, generated in the “Organisation-Wide Active Directory Plan” process “design of object naming models”, will provide the formula to generate the name for each required GPO. • Factor A11: Determination of the design requirements for the vehicle(s) required to scope and target the GPOs ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the design requirements for the vehicle(s) required to scope and target the GPOs. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: It is necessary to determine the mode and vehicle(s) required to control the scope of application of a GPO following the identification of the following:  The required GPO policies

Page 86 of 354

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

© 2004 Mustan Bharmal

 The fixed / variable scope representing the target users and computers for each required policy / policy configuration, and  The collation of the policies into GPOs This design methodology identifies the following five methods to control the scope of application of a Windows Server 2003 Active Directory GPO:  The manual identification and explicit exclusion of a fixed or variable scope of users and / or computers, from the scope of application of a GPO policy / policy configuration, is the first level of control over the scope of application of GPOs within a forest.  The use of containers that represent points of implementation of GPOs (such as Sites, domains, OUs and OU hierarchies) to provide a logical boundary for the application of GPO policies within a forest. This represents the second level of control over the scope of application of GPOs within a forest.  The use of “block inheritance” at a domain or OU container, to prevent the inheritance of all GPOs (linked above a domain (at a Site container), or implemented / linked at the domain or ordinate OU, respectively), and application by the contents of the domain / subordinate OUs.  The use of the GPO “Read” and “Apply Group Policy” (AGP) permissions on a GPO, assigned either directly to the target users and / or computers, or to built-in and custom security groups that represent the target security principals. The use of GPO “Read” and “AGP” permissions represents the fourth level of control over the scope of application of GPOs within a forest.  The use of Windows Management Instrumentation (WMI) filters that dynamically define the scope of application of a GPO to target user and computer account objects. This represents the fifth level of control over the scope of application of GPOs within a forest. The identification of a fixed or variable scope representing users / computers, which require explicit exclusion from the scope of application of a GPO policy / policy configuration, supports the partitioning of object administration profiles within the process to design an OU infrastructure. See the Domain Plan process, “design of an OU infrastructure”, for details of “object administration profiles”. The design of the Site and domain infrastructure within the forest, and the OU infrastructure within this domain, has provided the second method to control the scope of application of GPOs. Although this method can control the scope of application of GPOs in isolation of the use of custom or built-in security groups and WMI filters, it does not provide a very granular level of control. This is because, for example, the primary influence in the design of an OU infrastructure is support for controlling the scope of application of DOC permissions (as the most granular filter for DOC permissions is the use of object class and logical boundaries such as OUs and OU hierarchies), and not to control the scope of application of GPOs. Hence, the design of an OU infrastructure should not entirely support the requirement to control the scope of application of GPOs, but requires support via the use of built-in / custom security groups, and (where applicable) WMI filters. Note that the process “design of an OU infrastructure” discusses the use of “block inheritance” to control the scope of application of a GPO, as it is a configuration aspect for an OU, and not a GPO.

Page 87 of 354

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

© 2004 Mustan Bharmal

This step will determine the remaining two factors that control the scope of application of GPOs. However, prior to the determination of the design requirements for the use of GPO permissions and WMI filters, it is necessary to note and understand the following facts and concepts about filtering and targeting the application of GPOs:  To target and apply the policies within a GPO to the required target security principals (users and computers), it is necessary to add the target security principals (directly or via security groups) to the access control list (ACL) of the GPO object itself. The target security principal (user, computer, or security group that represents the target users and / or computers) requires two permissions to apply the policies within the GPO. These are:  Read (R) permission to be able to read the configured policies within the GPO  Apply Group Policy (AGP) permission to be able to apply the configured policies within the GPO to itself / group members  It is possible to assign the “Read” permission only to a security principal to permit, for example, that security principal to just read (but not apply) the configured policies within a GPO object. However, to apply the GPO policies, it is necessary to configure both the Read and AGP permissions. Assigning just the AGP permissions, without the Read permission, does not permit the target security principal to apply the configured policies, as it cannot read them.  A newly generated GPO is, by default, configured with the Read and AGP permissions for the built-in security group “Authenticated Users” (which includes all domain user and computer account objects), and does not have any WMI filters linked to it.  The assignment of Read and AGP permissions to target users and computers on a GPO does not ensure, on its own, that the target users and computers will read and apply the configured policies within the GPO. The GPO also requires implementation at a container in which either the target users or computers reside, or at a container that is hierarchically above the container for the target users or computers. For example, a GPO implemented at the domain level will apply to all inscope target security principals within all OUs in the domain.  It is not possible to implement or link any GPOs directly to the target users and computers, or security groups that represent them. It is only possible to implement or link a GPO at a domain or OU, and only link (not implement) a GPO to a Site within a forest.  Where a custom security group represents the vehicle to target the in-scope users and / or computers for a GPO, that security group does not need to reside logically within the scope of application of the GPO. For example, a GPO contains the Read and AGP permissions for a custom security group named “Marketing Users”, and implemented at an OU named “Marketing Users”. The security group “Marketing Users” does not need to reside within the OU “Marketing Users”, any child OUs of this OU, or even within the same domain, or even the same forest. The security group “Marketing Users” may even reside within a trusted legacy Windows NT 4.0 domain, depending upon the type of the security group and direction of trust relationships, and so on.  Windows Management Instrumentation (WMI) filters allow the dynamic definition of the scope of application of GPOs. WMI filters can retrieve object metadata from both users and computers. The metadata retrieved for users represents the Active Directory object metadata for the user account of a user logged on to a target computer. The metadata retrieved for computers represents both the logical Active Directory object metadata and the values for the metadata attributes of the actual physical computers. Discussed below are the specific rules for the use of WMI filters to filter the scope of application of a GPO.

Page 88 of 354

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

© 2004 Mustan Bharmal

 Note the following about the role of WMI in targeting the application of GPOs:  Windows Management Instrumentation (WMI) exposes and provides data on physical computers and logged on users for use in the administration of the computers. For example, in addition to the use of WMI for targeting the application of GPOs, the information retrievable via the WMI interface represents the input for hardware and software inventory applications, scripts, batch files, and so on.  The WMI infrastructure exists as classes, objects, and instances that reside within virtual locations known as namespaces. A WMI class is a definition of WMI objects, which are an implementation of an instance, which is a specific piece of data.  The WMI infrastructure provides default namespaces within the WMI schema, and the ability to import / define custom namespaces and attributes. Queries using the WMI infrastructure require direction against a namespace, and the default namespace, for all queries that do not have a namespace defined, is the “root\CIMv2” namespace.  The WMI interface is accessible via APIs and a command-line interface (WMIC) on Windows XP Professional and Windows Server 2003. It is possible to combine WMI queries, formatted using the WMI Query Language (WQL) (a SQLlike language), with the logical operators “AND” and “OR” to permit very granular control over the results of the query. It is possible to collate defined queries into “WMI Filters” for targeting the application of GPOs.  The data WMI makes available for administrative use on the target computers includes: • Software and hardware inventory, settings, and hardware configuration information (such as processor, disk space, memory, and so on) • Software information from the operating system (such as registry settings, file system, drivers, and so on) • Information about the users logged onto the target computer for a WMI filter  Note that it is not possible to use WMI filters in isolation of GPO permissions, as the target computer(s) for the WMI filter must have the Read and AGP permissions on the GPO first. Hence, WMI filters represent the fifth level of control over the scope of application of a GPO, and not a parallel form of control to the use of Read and AGP permissions on a GPO.  The use of a WMI filter requires careful consideration, as it can reverse the application of a GPO. For example, a target computer assigned the appropriate “Read” and “Apply Group Policy” permissions, is then required to evaluate a linked WMI filter. The evaluation to “false” of the queries within the filter will result in the computer not applying the policies within the GPO, where it would have done so without the linked WMI filter to the GPO.  It is only possible to use WMI filters where one or more Windows Server 2003 domain controllers are present within an Active Directory infrastructure. An Active Directory infrastructure with only Windows 2000 domain controllers does not support the use of WMI filters to control the scope of application of GPOs.  It is only possible to use WMI filters to filter the scope of application of a GPO where the target computer is running Windows XP Professional or Windows Server 2003. Hence, target computers running Windows 2000 do not evaluate WMI filters and thus apply all configured policies within GPOs with linked WMI

Page 89 of 354

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

© 2004 Mustan Bharmal

filters, if the Windows 2000 computer has the Read and AGP permission on the GPO.  A WMI filter may be linked to multiple GPOs (using the Group Policy Management Console (GPMC)), but a GPO can only be linked to a single WMI filter. When a target computer applies a GPO within a linked WMI filter, the computer evaluates the WMI query / queries within the filter. If the results are false, then the configured policies within the GPO are not applied.  A WMI filter may consist of one or more WMI queries that retrieve object metadata from one or more WMI namespaces. Each WMI query may be a combination of two or more query strings, concatenated via logical “AND” / “OR” operators where required.  It is important to note the following seemingly obvious facts: • The use of WMI filters relies on the presence of the actual target computer. Hence, it is necessary for the target computer to be running and connected to the network, as it is the actual physical computer, and not the avatar Active Directory object for that computer, which evaluates the WMI filter. • The use of WMI filters for users relies upon the presence of a logged on user to permit retrieval of the required user metadata.  Similar to GPO objects, WMI filters are stored on a per-domain basis, and hence a WMI filter and the GPO it is linked to must be in the same domain. The following diagram illustrates the relationships between the five factors listed above that govern the scope of application of configured GPO:

Page 90 of 354

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

© 2004 Mustan Bharmal

GPO Policy / Policy Config

Policy collation into GPO

1 Identification of explicit out-ofscope users / computers for a GPO policy / policy configuration GPO OU

GPO OU GPO OU OU 3 OU OU OU

GPO 2 Boundaries of containers (such as OUs) to restrict the scope of application of implemented GPOs

Configuration of “block inheritance” on an OU to prevent reception of GPO policies from above

GPO

GPO

GPO

Linked WMI Filter Read (R) Apply Group Policy (AGP)

4

Use of GPO Permissions to control scope of application

Custom Security Groups 128 Mb 256 Mb 512 Mb Root\CimV2; Select * from Win32_ComputerSystem where TotalPhysicalMemory = 536203264 5 Use of WMI queries within WMI filter to control scope of application

© 2004 MUSTANSHI

R

BHAR

MAL

Figure 33.3: Illustration of the Five Methods to Scope the Application of GPOs When determining the design requirements for the assignment of the “Read” and “Apply Group Policy “ GPO permissions to target users and computers, consider the following:  As a GPO is a collection of one or more configured GPO policies, the combination of the scope of application for each constituent configured policy represents the total scope of application of a GPO. Hence, the selection of the type of GPO design model and the subsequent collation of the required policies / policy configurations into GPOs will influence the total scope of application of a GPO. As the scope of application of each constituent GPO policy within a GPO may have a fixed or

Page 91 of 354

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

© 2004 Mustan Bharmal

variable scope, then the total scope of application of a GPO may also have a fixed or variable scope, where:  A “fixed” scope for a GPO is one where all constituent configured GPO policies each have a fixed scope of application.  A “variable” scope for a GPO is one where not all of the constituent configured GPO policies have a fixed scope of application. There are hence one or more constituent GPO policies with “variable” scopes of application.  Where a GPO has a fixed scope of application, it is only necessary to use a custom security group to represent the scope, as there is no requirement to employ the use of WMI filters to define the scope of application dynamically. The identification of a variable scope GPO requires targeting support via the use of default or custom security groups and / or WMI filters.  Note that not all ORMIs within a domain may use one or more of the built-in security groups to define and control the scope of application of GPOs via GPO permissions. Typically, only the ORMI belonging to the domain owner may use one or more of the built-in security groups to scope the application of GPOs. Hence, where this GPO infrastructure is for an ORMI that does not have permission to use built-in security groups, such as “Domain Administrators”, then it is necessary to use custom Domain Local security groups.  When defining the design requirements for the assignment of the GPO permissions to target users and computers, this design methodology proposes the following approach:  The collation of the configured policies into GPOs defines the total scope of application for that GPO, which requires reflection via the assignment of the “R & AGP” GPO permissions to the target user and computer account objects. Hence, using the scope of the constituent GPO policies, determine the: • Total scope of application of a GPO, and • Whether it is a “fixed” or “variable” scope  Determine the threshold criteria for the use of a custom / built-in security group to support the assignment of the GPO permissions. Where the total scope of application of a GPO is represented by a very few (for example, less than ten) user and / or computer objects, then it is feasible to assign the GPO permissions individually to each target object. The objective of the threshold criteria is to support this decision to assign GPO permissions directly to individual target objects, or indirectly via the collective assignment of the permissions to a built-in or custom security group.  Where there is a requirement to use a custom or built-in security group to control the assignment of GPO permissions, determine the required scope for the security group. Where the scope of application of a GPO is “fixed”, then the scope of the selected security group can be narrow and specifically reflect the scope of the GPO.  However, where the scope of a GPO is “variable”, then determination of the scope of the supporting security group depends, in part, upon the source of the variance(s) in the scope of the GPO. For example: • Where the scope of a GPO is “variable” because one or more policies that target computer account objects have a variable scope, and where it is possible to target the GPO to specific computers using a WMI filter, it is not necessary to have a narrow scope for the custom security group. The use of a WMI filter in this case will narrow the scope of application of the GPO and

Page 92 of 354

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

© 2004 Mustan Bharmal

hence does not rely upon, but compliments the use of the security group, as this is the fourth method of controlling the scope of a GPO. For example, a GPO contains a policy to deliver a software package to a variable scope defined as “only to desktop computers that have 512Mb of RAM installed”. Hence, it is possible to target the “Read” and “Apply Group Policy” permissions on the GPO via a security group with a broad scope, such as “all desktop computers”, and then use a WMI filter, linked to the GPO, to narrow the scope further via a WMI query to determine the amount of RAM installed. Hence, only those target computers within the custom security group “all desktop computers” that have 512Mb of RAM installed will successfully evaluate the WMI query and apply the policy. Note that it is necessary to ensure that the use of a “broad” scope of application for a security group does not compromise the collective scope of application (in and out-of-scope) of the GPO by including target users / computers previously defined as being explicitly out-of-scope of the policies within the GPO. It is imperative to ensure this, even if the OU infrastructure will guarantee that the out-of-scope objects are in parallel containers within the domain, and will hence not receive by inheritance the GPO policies. This is because it is very simple to move implemented OUs (and hence their GPOs) between OU hierarchies within a domain, and hence generate policy conflicts via the use of security groups with a broad scope of application. • Where the scope of a GPO is “variable” because one or more policies that target user account objects have a variable scope, it is possible to define dynamically the scope via the use of a WMI filter. The use of a WMI filter is only possible where the required user object metadata is retrievable from user logged on to a target computer. The GPO permissions hence require assignment to the target computer a user logs onto, even if the GPO does not contain any GPO policies for the target computer. This has implications on the distribution of implementation of the GPOs, where the user and computer account objects are not in the same OU containers, and so on. • Where it is not possible to retrieve the required user object metadata via a WMI query against a user logged onto a target computer, it is necessary to employ exclusively a custom security group. The custom security group must have a narrow scope of application to serve as the vehicle for assignment of the GPO “Read” and “Apply Group Policy” permissions. For example, a GPO policy contains a set of policies to assign a discrete password management infrastructure to all users within a department of the organisation. The members of the department change on a regular basis, but whilst members, must adhere to strict security policies, supplemented and enforced by the GPO password policies. The variable scope of application of this set of GPO policies is definable by a metadata aspect of the target users (their membership (temporary or permanent) to the department), and there is a requirement to prevent the application of these policies outside of this scope, then a custom security group is required. This group will hence be required to explicitly reflect the membership of the department and hence control and support the scope of application of the GPO.  Where there is a requirement to assign GPO permissions to individual target users / computers, then it is necessary to identify, and list all target users and computers. When determining the requirements for the design of the WMI filters to define and control the scope of application of a GPO, consider the following:  The objective for the use of WMI filters is to “dynamically define the scope of application of a GPO based upon one or more physical / logical metadata aspects of target users / computers (running Windows XP Professional, Windows Server 2003, or later Windows operating systems)”.

Page 93 of 354

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

© 2004 Mustan Bharmal

 It is only possible to link a WMI filter to an “in-scope” GPO, which is a GPO that complies with the following specific criteria:  The scope of a GPO is identified as being “variable” and the variance in-scope is based upon target users and / or computers  One or more metadata aspects retrievable from the physical or logical objects that represent the target users / computers may define the scope of the GPO, and the required metadata aspects reside within the scope of the Microsoft Windows Management Infrastructure.  The target computers are running Windows XP Professional or later operating systems  The target computers for the WMI queries are assigned the GPO “Read” and “Apply Group Policy” permissions  There is one or more Windows Server 2003 domain controllers within the Active Directory infrastructure for the organisation  Where it is possible to attain compliance with all of the above criteria for the design and use of WMI filters, then consider the following design considerations:  It is possible to link a WMI filter to multiple GPOs, but a single GPO may only have one WMI filter linked to it. It is not possible to link multiple WMI filters to a GPO, with each one retrieving different metadata from the target computers. This hence implies that the single WMI filter linked to a GPO must be able to exclusively support and define the variances in the scope of application of all “variable” scope policies within the entire GPO.  Although it is possible to link a single WMI filter to multiple GPOs, this may not realistically be possible. This is because it may not be possible to identify patterns of variances between the scope of application of GPOs, based upon the metadata aspects of the target computers and the required values of the retrieved metadata aspects. Where it is not possible to identify exactly similar dynamic scope requirements for two or more GPOs, exactly supported by a single WMI filter, then it is not possible to link the WMI filter to more than one GPO, and hence it may be necessary to design unique WMI filters for each inscope GPO.  When determining the design requirements for WMI filters, consider the following: • The following represent the design components for WMI filters: ♦ The identification of the WMI namespaces, classes, objects, and instances that the WMI query / queries within the WMI filter are to use ♦ The values for the metadata aspects the WMI queries must retrieve ♦ The name for the WMI filter (determined via the use of the OrganisationWide WMI Filter Naming Model) ♦ The description of the WMI filter • The number of queries within a WMI filter will influence the time required to process the entire WMI filter by a target computer, during each evaluation of a GPO for application. If a computer is to receive multiple GPOs, each with a linked WMI filter, and each WMI filter with many WMI queries that require processing and evaluation, then this may impair the performance of the target computer each time the GPOs are applied.

Page 94 of 354

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

© 2004 Mustan Bharmal • The target computer for a WMI filter does not process multiple WMI queries within a WMI filter in any specific order. However, all of the queries within a WMI filter collectively require evaluation to TRUE to permit the application of the GPO policies. • The metadata targets for the WMI queries within a WMI filter must be nonvariable in nature, to permit consistent targeting and application of GPO policies. For example, a WMI query must not look for a hardware device that is attached to a laptop docking station, which although may appear as “part” of a computer device, may not be present if the laptop is connected to network directly, and not via the docking station.  The Group Policy Management Console (GPMC) permits the export and reimport of WMI filters for application within different forests.  The following table illustrates some sample WMI queries that may be used within a WMI filter to dynamically define and control the scope of application of a GPO to target users and computers:
Criterion Configuratio n Hot fix Objective for WMI Filter Avoid application of a GPO where the BIOS version is not a specific value Apply a policy on computers that have a specific hot fix or QFE. Assign software only on computers already having either of two software packages. Only target computers running Windows XP Professional Apply policy on all computers located in the United Kingdom. Target only servers with 512Mb of RAM installed Target Compaq Evo N600C or N610C laptop computers Apply policy only to a user with an account that expires at the end of 19 Jan 2005 WMI Filter Select * from Win32_BIOS where SMBIOSBIOSVersion = “68P4F v2.49 F.15” Root\cimv2 ; Select * from Win32_QuickFixEngineering where ServicePackInEffect = “KB823559” Root\cimv2;Select * from Win32_Product where name = "MSIPackage1" OR name = "MSIPackage2" Root\CimV2; Select * from Win32_OperatingSystem where Caption = "Microsoft Windows XP Professional" Root\cimv2 ; Select * from win32_timezone where bias =-60 Root\CimV2; Select * from Win32_ComputerSystem where TotalPhysicalMemory = “536203264” Root\CimV2; Select * from Win32_ComputerSystem where manufacturer = "Compaq" and Model = "Evo N600c" OR Model = " Evo N610c" Root\CimV2; Select * from Win32_NetworkLoginProfile where AccountExpires = “20050120000000.000000+000”

Software inventory Operating system Time zone Resources Make or model User metadata

Table 33.3: Examples of WMI Queries for Use within WMI Filters Using the above information, execute the following for each required GPO:  Determine and document the total scope of the GPO, as a collective representation of the scope of application for each constituent GPO policy within the GPO  Determine and document the threshold criteria for the use of a custom or built-in security group to act as a vehicle for targeting the assignment of the GPO “Read” and “Apply Group Policy” permissions  Determine and document the nature of the total scope of a GPO, as being either a “fixed” or “variable” scope of application

Page 95 of 354

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

© 2004 Mustan Bharmal

 Where there is a requirement to use security groups, determine and document the scope for the security group, based upon whether the GPO scope is fixed or variable, and whether the variance in-scope is addressable via WMI queries  Where there is a requirement to design and use WMI filters, and it is possible to attain compliance with the criteria for the use of WMI filters, then execute the following:  Determine and document the metadata aspects of the target users and / or computers that will define the scope of application of a GPO  Determine and document the value(s) of the metadata aspects of the target users and / or computers that will define the scope of application of a GPO  Determine and document the design requirements for the WMI queries that will retrieve the required information from the target computers / logged on users  Determine the design requirements for the collation of two or more WMI queries into a WMI filter, and the assignment of a name and description to the WMI filter  Identify the GPO(s) to be linked to each required WMI filter Note that the information determined for the scope and memberships of the custom / built-in security groups required to support the GPO infrastructure represents an input for the process to design a security group infrastructure for the ORMI. • Factor A12: Determination of the primary point of implementation of GPOs within this domain ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the design requirements for the primary point of implementation of GPOs within this domain. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The creation and implementation of a required GPO at a container (root of this domain or an OU within this domain) represents the primary point of implementation of the GPO. Note that a Site object does not represent a primary point of implementation, as it cannot support the creation of a GPO, but just the linking of an existing GPO. A Site container is hence a potential “secondary” point of implementation for existing implemented GPOs. When determining the design requirements for the primary point of implementation for each required GPO, consider the following:  This design methodology proposes the following approach for the determination of the primary point of implementation of each required GPO within this GPO infrastructure:  Identify all potential primary points of implementation (root of the domain or an OU) for the required GPOs based upon the ownership and boundary of the ORMI this GPO infrastructure is to support. Note that this design methodology only supports the identification of potential points of implementation owned by the owner of the ORMI, and hence reside within the boundary of the ORMI.  Understand the threshold criteria for the maximum number of GPOs supported at a potential primary point of implementation (this value is determined in the process “design of an OU infrastructure”).

Page 96 of 354

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

© 2004 Mustan Bharmal

 Analyse the distribution of the target user and computer objects amongst the potential primary points of implementation (domain and OU containers, as applicable)  Prior to the determination of the most efficient primary point of implementation for each required GPO, consider the following: • To support this design methodology’s recommendations for the design of a “good” GPO infrastructure, there must be a minimal use of secondary points of implementation of GPOs, to prevent the generation of a confusing GPO infrastructure. Hence, the primary point of implementation of a GPO must ideally be a reflection of the entire scope of a GPO, but without compromising the scope of application of the GPO via the use of broad scope security groups and so on. • The use of inheritance of GPO policies down a directory container hierarchy will achieve maximum exposure of the GPO, and minimal use of linking of the GPO. The design of the supporting OU infrastructure will also support this requirement. • The number of GPOs implemented at any single supported point of implementation must not exceed the defined threshold criteria for the maximum number of GPOs  Determine the primary point of implementation of each required GPO via the execution of the following steps: • Evaluate all identified potential primary points of implementation and select two or more potential points based upon: ♦ Coverage afforded by point of implementation of the fixed / variable scope of the GPO ♦ Compliance with threshold criteria for the maximum permitted number of GPOs implemented at an OU • Select one primary point of implementation that affords the greatest coverage in-scope, but permits compliance with the threshold criteria. • Determine whether the coverage in-scope afforded by the selected primary point of implementation is total (one hundred coverage, and hence all target users and computers within the scope of application of a GPO will receive the GPO via the selected point of implementation) or partial. Where the scope is total, then there is no requirement for the selection of any secondary point(s) of implementation for the GPO. • Where the scope afforded by the primary point of implementation is partial, then there is a requirement for the selection of one or more secondary points of implementation for the GPO, to permit one hundred percent coverage.  Following the identification of the primary point of implementation for all required GPOs, re-evaluate against the threshold criteria for the maximum number of permitted GPOs at each OU within the OU infrastructure. Where the number of implemented GPOs exceeds the threshold value, identify those GPOs for which it is possible to relocate their primary point of implementation, but retain the same level of coverage of their total scope of application. The objective is to avoid the use of secondary points of implementation where possible.

Page 97 of 354

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

© 2004 Mustan Bharmal

 Re-evaluate the design for the supporting OU infrastructure based upon the known number of GPOs that require a primary point of implementation and the value for the threshold criteria for the maximum number of implemented GPOs.  Re-evaluate the security group requirements to identify any “duplicate” security groups, based upon the now identified primary points of implementation of the GPOs, and their corresponding boundaries. Where it is possible to identify “duplicate” security groups, consider the consolidation of the groups, where possible. Use the above information to execute an analysis to determine and document the primary point of implementation for each required GPO within this GPO infrastructure. • Factor A13: Determination of the secondary points of implementation of GPOs within the domain ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the determination of secondary points of implementation for one or more GPOs, as their primary point of implementation only permits partial coverage of the intended scope of application of the GPO, and  Wishes to identify the potential and actual secondary points of implementation for these GPOs ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Where it is possible to identify the requirement for the linking of GPOs, as their primary point of implementation does not permit one hundred percent coverage of the intended scope of application of the GPO, then consider the following:  The implementation of a shortcut pointing to a GPO represents a “secondary” point of implementation for the GPO. A GPO may be thus linked to any of the three following types of containers within an Active Directory forest:  A Site container  A domain container  An OU container  The linking of GPOs to one or more secondary points of implementation requires careful consideration where:  The vehicle used to target the scope of application of a GPO is a custom or builtin security group with a large variable scope of application. For example, where a GPO uses the built-in group “Authenticated Users” to target its application, then users and computers outside of the scope of application of the GPO will evaluate and apply the policies within the GPO.  A GPO with policies intended for a variable scope of target computers employs a broad scope custom or built-in security group, but the WMI filter linked to the GPO (to dynamically refine and define the scope) does not exclude computers explicitly outside of the intended scope of application of the GPO.  Where a GPO is targeted using a security group with a fixed or narrow scope of application, and does not employ WMI filters, then the linking of that GPO to one or more secondary points of implementation has a reduced risk of causing any

Page 98 of 354

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

© 2004 Mustan Bharmal

unintentional policy application to users and / or computers outside of the intended scope of application.  This design methodology proposes the following rules for the linking of GPOs to one or more secondary points of implementation:  This design methodology only supports the linking of a GPO to one or more secondary points of implementation where they explicitly reside within the boundary of the ORMI the GPO infrastructure is to support.  Due to the potential large scope of application afforded by a Site container, this design methodology recommends that it is only possible for the forest owner that owns this domain to employ Site containers as secondary points of implementation. This design methodology does not recommend the linking of GPOs to Site containers, unless there is an explicit justifiable requirement. A single Site may support multiple domains within a forest, and it is hence possible for the application of a GPO to exceed its intended scope, as defined by the boundaries of the ORMI it supports.  This design methodology recommends that only the owner of this domain may link one or more GPOs to the root of this domain. Based upon the above considerations, this design methodology proposes the following approach for the determination of the secondary points of implementation of GPOs:  Identify all of the GPOs that, via their selected primary point of implementation, fail to achieve one hundred percent coverage of the total intended scope of application of the GPO.  From this list of GPOs identify those GPOs that require exclusion from linking to one or more secondary points of implementation, due to the nature of the policies contained within, or the vehicle(s) used to target and control the scope of application of the GPO.  List the permitted GPOs that require linking to one or more secondary points of implementation.  Using the boundary and ownership details of the ORMI, identify all permissible secondary points of implementation of GPOs for the GPO infrastructure. For the majority of ORMIs within a domain, these will be OUs within the boundary of the supporting OU infrastructure.  To permit compliance with the objective to minimise the number of secondary points of implementation for GPOs, from the list of permitted containers, identify the most efficient location(s) for the linking of each permitted GPO. The selection of the most efficient location(s) must comply with the criteria that the selected secondary point of implementation will cover all or the majority of in-scope target users / computers not covered by the primary point of implementation. Using the above approach, execute the following:  Determine and document the list of permitted GPOs that may be linked to one or more secondary points of implementation  Determine and document the list of permitted secondary points of implementation  Determine and document the selected secondary point(s) of implementation for each permitted GPO • Factor A14: Determination of the configuration requirements for the identified GPOs

Page 99 of 354

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

© 2004 Mustan Bharmal ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the configuration requirements for the required GPOs within the GPO infrastructure for this domain. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: It is possible to implement the following configurations on a GPO:  The enabling of all settings (policies) within a GPO (this is the default configuration)  The disabling of all settings within a GPO  The disabling of just the computer configuration settings of a GPO  The disabling of just the user configuration settings of a GPO  The configuration of “no override” for the GPO When determining the requirements for the selection of the configuration option to disable all or some of the settings within a GPO, consider the following:  The disabling of all settings within a GPO will reverse the corresponding settings applied to all target users and computers for the GPO. Hence, it is important to understand the function of the GPO, and all constituent configured policies, prior to disabling the entire GPO.  The intention for the use of this option is only to temporarily disable the GPO during configuration of the required policy settings prior to implementation. Modifications to GPO policy settings within a GPO created in a production environment are live, and each refresh of a GPO will apply the policy configuration as it is at the time of application. Disabling of all GPO policies will prevent the application of the GPO during configuration, prior to implementation. This design methodology recommends the disabling of just the computer or user configuration settings within a GPO where there are no configured computer or user policies within the GPO, respectively. Disabling just the computer or user configuration will enhance performance of the GPO by reducing the number of policies within the GPO the target user / computer must evaluate each time the GPO is applied. When determining the requirement for the configuration of “no override” or “enforcing” an implemented / linked GPO, consider the following:  It is not possible to enable or disable the “no override” configuration of a GPO for the GPO as an object. Instead, this option is available for configuration on a GPO only at each primary or secondary point of implementation of the GPO.  The following diagram illustrates and example of the enforcing of linked GPO:

Page 100 of 354

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

© 2004 Mustan Bharmal

LINKED GPO OU GPO OU GPO OU OU GPO
Enforced

GPO OU

OU

OU
© 2004 MUSTANSHI
R

BH

AR MAL

Figure 33.4: Example of the Enforcing of a Linked GPO This design methodology proposes the following approach for the determination of the design requirements to enforce GPOs:  Identify the requirement to enforce all of the policies within a GPO via the identification of each GPO and one or more of its primary or secondary points of implementation that comply with all of the following criteria:  The point of implementation where a GPO requires enforcement must be the recipient of one or more other GPOs, implemented at points of implementation ordinate or subordinate to this point. Where there are no other GPOs implemented or linked to the OU, then there is no requirement to enforce the GPO.  The scope of application of the GPO that requires enforcement matches or overlaps with the scope of application of one or more of the other GPOs. Without any overlap in-scope of application, there is no requirement to enforce the GPO.  It must be possible to identify the presence of one or more policies within one or more other GPOs that match the policies within the GPO to be enforced.  The matching policies have different configuration settings, and those settings within the GPO that requires configuration with “no override” must take precedence over all other instances of those policy configuration settings.  Where it is possible to identify compliance with all of the above criteria, then list each compliant GPO and its point(s) of implementation where the GPO is to be enforced.  Where it is not possible to attain compliance with all of the above criteria, then it is not possible to enforce a GPO at that point of implementation via the “no override” configuration. Using the above information, execute the following:  Determine and document the requirements to disable all or some of the configuration settings within the required GPOs. Where it is possible to identify this requirement, then list the GPOs and their required configuration.  Determine and document the requirements to enforce one or more GPOs at one or more of their primary or secondary point of implementation, via compliance with the criteria stated above. Where it is possible to identify compliance with the stated criteria for the enforcement of a GPO and its policies, list the compliant GPOs and their point(s) of implementation where the GPO is to be enforced.

Page 101 of 354

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

© 2004 Mustan Bharmal

4.9.5.

Design of a GPO Infrastructure Consider the following when generating the design for the GPO infrastructure to support the ORMI for this domain: • Factor D1: Generation of a design for a GPO infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand and generate the components of the design for a GPO infrastructure. ♦ 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 design for a GPO infrastructure is comprised of the following components:  A detailed design document, identifying the following:  The GPO policies required, their configuration requirements, and their scope of application  The type of GPO design model selected to generate the GPO infrastructure  The GPOs generated by the selected design model, and a brief statement as to the intended function of each required GPO  The security group and WMI filter design requirements to support the targeting of the GPOs  The primary and secondary points of implementation of each required GPO  The configuration requirements for each required GPO (disabling of all or some configuration settings within GPOs, and enforcing the application of selected GPOs at selected points of implementation)  The name to be assigned to each GPO, via the GPO naming model generated within the “Organisation-Wide Active Directory Plan”  A diagram illustrating the point(s) of implementation of each required GPO and, against each listed GPO, the following:  A brief summary of the GPO policies within each GPO  A brief description of the scope of application of the GPO  Details of the configuration settings on the GPO (where applicable) It is imperative that each element that generated and influenced the design for a GPO infrastructure is justifiable and auditable, to produce a consistent and functioning GPO infrastructure. Use the above to generate a design for the GPO infrastructure required to support the ORMI for this domain

Page 102 of 354

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

© 2004 Mustan Bharmal

5.

Design of a Delegation of Control (DOC) Infrastructure
Most organisations that design an Active Directory infrastructure require a delegation of control (DOC) strategy for an Active Directory domain, regardless of whether the organisation employs a centralised or decentralised IT administration model.

5.1.

Process Objectives The objective of this process is to assist an organisation in the generation of a design for the implementation of a DOC infrastructure. The design of a DOC infrastructure for an Active Directory domain permits the generation of a consistent object management infrastructure for the domain, via the assignment of DOC permissions to users tasked with object management within the organisation. The resulting DOC infrastructure will greatly enhance object management and troubleshooting. The fundamental objective for the design and implementation of DOC permissions is to permit the delegation of control over the administration of specific classes of objects within an Active Directory domain to “normal” user accounts. The term “normal” user accounts refers to all user accounts that are not members of any of the built-in security groups that, by membership, confer administrative rights and permissions, such as the “Administrators”, “Domain Admins”, “Enterprise Admins”, and so on. This requirement is hence fundamental for the majority of organisations where, for example, it is possible to identify one or more of the following scenarios and requirements: • The owner of the ORMI, this DOC infrastructure is to support, is an autonomous division represented partially or exclusively within this domain, and the domain owner wishes to restrict the membership of the “Domain Admins” security group. The exclusion of the IT administrators within the autonomous division from the “Domain Admins” group hence demands a delegation of control infrastructure, as all administrators will only have “normal” user accounts. • There is a requirement to limit and control the membership of these types of built-in security groups, as the rights and permissions conferred to the members are all powerful within a domain, and hence a security risk. A DOC infrastructure hence permits the generation of an administrative model where the execution of the majority of object administration tasks occur via DOC permissions assigned to “normal” user accounts and only a select few administrators are members of the built-in administration security groups. • There is a requirement to permit the execution of routine administration tasks to IT support personnel within the IT support function of an organisation, but restrict their activities to the scope of their delegated tasks. The granular delegation of control to security principals on specific properties of an object class provides support for this requirement. • There is a requirement to empower users, and concurrently reduce administrative workloads on IT support personnel, via the delegation of specific administrative tasks to end users. This hence permits a greater degree of granular control over the administration of Active Directory objects within a domain, whilst minimising the security risks posed by compromises to the membership of powerful built-in administration security groups. The design of a DOC infrastructure for an ORMI within this Active Directory domain must address and support several variables. The background information section below discusses the variables that the design for a DOC infrastructure is required to identify and support.

5.2.

Process Scope The following two components of a DOC infrastructure define its scope, and hence the scope of this process:

Page 103 of 354

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

© 2004 Mustan Bharmal • The type of objects to be managed by the DOC infrastructure (defined by the class of object within the default Windows Server 2003 Active Directory Schema) • The logical location of the objects to be managed within an Active Directory domain This design methodology supports the design of a DOC infrastructure to manage specific object classes, represented within the default schema for a Windows Server 2003 Active Directory infrastructure. The following table depicts the specific object classes supported by this design methodology for a DOC infrastructure:
Object Class Computer User InetOrgPerson Group Contact Printer Shared Folder Organizational Unit Group Policy Object Object Class Name in Windows Server 2003 Active Directory Schema computer user inetOrgPerson group contact printQueue volume organizationalUnit groupPolicyContainer

Table 34.1: Object Classes Supported by this Design Methodology for a DOC Infrastructure All other object classes, supported by a default or customised Windows Server 2003 Active Directory schema, and housed exclusively within a domain partition of an Active Directory infrastructure, are outside of the scope of this process and hence outside of the scope of management of a DOC infrastructure for this domain. Only those instances of in-scope object classes, logically located within the boundary of the ORMI, are within the scope of management of the DOC infrastructure. Within an Active Directory domain, it is possible to identify many other services and functions that may require delegation, such as the DNS, DHCP, WINS services (also known as “infrastructure services”), or the execution of domain administration tasks, such as generating external trust relationships, and so on. However, these services and functions are outside of the scope of the design of this DOC infrastructure, as its focus is on object administration. 5.3. Background Information A DOC infrastructure, in conjunction with a Group Policy Object (GPO), security group, and OU infrastructure, forms the foundation for the administration of Active Directory objects within an object and resource management infrastructure (ORMI) for this domain. The term “delegation of control” implies the assignment of specific permissions to one or more security principals, explicitly to manage specific in-scope object classes, or specific aspects of in-scope objects. The design and operation of a delegation of control infrastructure for an ORMI is required to identify and support all of the following six variables: 1. Identification of the objects / object classes within the scope of management of a DOC infrastructure

Page 104 of 354

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

© 2004 Mustan Bharmal

2. 3. 4. 5. 6.

Identification of the properties of the in-scope objects / object classes and their administrative tasks that require delegation Identification of the minimum permissions, rights, group memberships required to permit execution of the identified administrative tasks Identification of the security principals to be assigned the object administration tasks via the delegation of control permissions Identification of the vehicle(s) / method(s) for controlling the scope of implementation of the permissions to the objects / object classes Identification of the location(s) of the objects / object classes within an Active Directory infrastructure, to hence determine the most efficient location to implement the permissions based upon: a. The requirement to minimise the repetitive re-application of the required permissions, and b. The requirement to minimise or avoid the use of "deny" permissions or “block inheritance” of permissions to control and minimise the required scope of application of the DOC permissions

5.4.

Process Approach This design methodology proposes the following approach for the design of a delegation of control (DOC) infrastructure that will reflect and support the variables listed above: 1. 2. Determine the object classes and instances of object classes within and outside of the scope of management of the DOC infrastructure Identify the properties of the in-scope object classes, and their administrative tasks that require delegation of administration, and hence require inclusion within the scope of the DOC infrastructure Determine the permissions, rights, and membership to built-in security groups required by the delegates to permit execution of the administrative tasks that require delegation, and categories for the DOC permissions to permit abstraction from individual permissions Identify the security principals to be assigned the object administration tasks via the DOC permissions (the delegates) Pass the following determined information to the process to design an OU infrastructure for this ORMI, in this domain: a. The identification of the in and out-of-scope Active Directory object classes / instances of object classes that require management via DOC permissions b. The identification of the in-scope administrative tasks for the in-scope object classes / instances of object classes c. The identification of the delegates within the DOC infrastructure

3.

4. 5.

d. The identification of the categories of DOC permissions (to permit abstraction from individual permissions) 6. Delegate the in-scope object administration tasks to the identified security principals, and determine the required vehicle(s) / methods to control the scope of application of the DOC permissions to the delegates, and add delegates to appropriate security groups. Determine the point of implementation of the required DOC permissions

7.

Page 105 of 354

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

© 2004 Mustan Bharmal 5.5.

Process Components Based upon the above approach, the process to design a DOC infrastructure for the ORMI within this domain is composed of the following components: • Determination of the object class scope of the DOC infrastructure • Determination of the object administration requirements • Determination of the delegate scope for the DOC infrastructure • Determination of the DOC design requirements for in-scope object classes • Determination of the design requirements for the assignment of DOC permissions • Determination of the point of implementation of the required DOC permissions • Generate the design for the DOC infrastructure

5.6.

Deliverables of Process Components This process will have the following deliverables: • The determination of the in and out-of-scope object classes / instances of object classes for the DOC infrastructure • The identification of the properties of the in-scope object classes and the associated administrative tasks that require delegation • The determination of the DOC permissions, rights, and group memberships required by the delegates to execute their assigned object administration tasks • The determination of the in and out-of-scope delegates within the DOC infrastructure • The delegation of administrative tasks to the identified delegates within the DOC infrastructure, and determination of the required vehicle(s) / method(s) to control the scope of application of the assigned DOC permissions, and add delegates to appropriate security groups. • The determination of the points of implementation of the required DOC permissions • The generation of a design for the DOC infrastructure for an ORMI

5.7.

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

Page 106 of 354

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

© 2004 Mustan Bharmal

Domain Plan – Inter-Component Dependencies for Process to Design a DOC Infrastructure START
Determination of the object class scope for the DOC infrastructure Determination of the object administration requirements

Determination of the DOC design requirements for inscope object classes

Determination of the delegate scope for the DOC infrastructure

Determination of the design requirements for the assignment of DOC permissions

Determination of the point of implementation for the required DOC permissions

Generation of the design for a DOC infrastructure
© 2004 MUSTAN
SHI R

BHAR

MAL

5.8.

Process to Design a Delegation of Control Infrastructure
Domain Plan – Process to Design a DOC Infrastructure

START

Execute B1

Execute A1 – A3

Execute B2

Execute A4

Execute B3

Execute A5 – A11 Pass determined information to process to design OU infrastructure

Execute A12 – A13

Execute B4

Receive determined information from process to design OU infrastructure Execute B5

Execute process “design of an OU infrastructure”

Pass determined information to process to design security group infrastructure

Execute A14

Execute D1

END
© 2004 MUSTANSHI
R

BHAR

MAL

5.9.

Process Considerations Consider the following information when designing a DOC infrastructure for the ORMI within this domain. Presented within the following seven sections are the considerations for this process: 1. 2. 3. 4. 5. 6. 7. Considerations for the determination of the object class scope for the DOC infrastructure Considerations for the determination of the object administration requirements Considerations for the determination of the delegate scope for the DOC infrastructure Considerations for the determination of the delegation of control design requirements for in-scope object classes Considerations for the determination of the design requirements for the assignment of DOC permissions Considerations for the determination of the point of implementation of the required DOC permissions Considerations for the generation of the design for a DOC infrastructure

5.9.1.

Determination of the Object Class Scope for the DOC Infrastructure By default, not all classes of objects, or instances of an object class, will be within the scope of a DOC infrastructure for an ORMI within this domain. Hence, consider the following

Page 107 of 354

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

© 2004 Mustan Bharmal

information when determining the in and out-of-scope object classes / instances of object classes for the DOC infrastructure: • Factor B1: Understanding the components of a DOC infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the components of a DOC infrastructure. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The objective of a DOC infrastructure is to support the management of all in-scope objects by delegated administration security principals. Hence, the components of the scope of a GPO infrastructure are:  The object classes / instances of objects that require management  The security principals (delegates) that will mange the in-scope objects  The permissions assigned to the delegates to manage the object classes / instances of objects However, not all object classes / instances of an object class within this domain, or the boundary of an ORMI, are necessarily within the scope of a DOC infrastructure. The process to design a DOC infrastructure proposed by this design methodology only supports a specific set of object classes. The “Process Scope” section of this process lists the object classes supported by DOC infrastructure. Hence, the first step within this process is to determine which classes of objects, from the list of supported object classes, are present / proposed for creation within the boundary of the ORMI within this domain. • Factor A1: Determination of the in and out-of-scope object classes / instances of object classes ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the in and out-of-scope object classes / instances of object classes for this DOC infrastructure. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The scope for a DOC infrastructure must reflect only those Active Directory objects, within the list of object classes supported by this design methodology, that explicitly require management by one or more DOC permissions. When determining, from the list of identified / proposed object classes that reside within the boundary of the ORMI, those object classes that require exclusion from delegation of control, consider the following:  This design methodology proposes the following approach to determine the in and out-of-scope object classes / instances of object classes:  Identify those classes of objects that will definitely not require administration by one or more delegates within a DOC infrastructure, to hence identify the in and out-of-scope object classes.  For each in-scope object class, analyse the contents / proposed contents of the ORMI to identify all instances of that object class, and determine the requirement

Page 108 of 354

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

© 2004 Mustan Bharmal

to exclude any specific instances from delegation of control. List all instances of an object class that requires explicit exclusion from delegation of control, and mark as out-of-scope of the DOC infrastructure.  An entire object class may be marked as outside of the scope of a DOC infrastructure where it is possible to identify compliance with one or more of the following example criteria:  The nature or type of the object class places that object class outside of scope of a delegation of control infrastructure. For example: • An organisation may decide that the administration of Group Policy Objects (GPOs), due to their nature and powerful influence on the operation of an entire organisation, is restricted to members of the “Domain Administrators” group. • An organisation may decide to consolidate the administration of all instances of the “user” and “inetOrgPerson” object classes and hence remove the “inetOrgPerson” object class from independent / exclusive administration and delegation of administration. • An organisation may decide to generate instances of an object class, but not manage / delegate the management of the Active Directory avatars of the actual devices the objects represent. For example, although member Windows 2000 and Windows Server 2003 print servers automatically publish print queues within the Active Directory, as printer objects, there is a requirement to manage the print queues and devices independently of the Active Directory, and hence no requirement to delegate their administration within the Active Directory domain.  The number of instances of an object class that will / may reside within the boundary of an ORMI negates the requirement to design and assign supporting DOC permissions. For example, an organisation may wish to publish three or four instances of the “printer” object class within an Active Directory domain.  One or more instances of an object class may require exclusion from administration via a delegation of control infrastructure where it is possible to identify compliance with one or more of the following example criteria:  There is a requirement to assign an instance of an object class an owner, other than the default owner(s) for the object, and that owner is to be responsible for the execution of all administration tasks on that object instance. The owner of an object has the right to manage the assignment of permissions on that object, even when denied all access to that object.  The function of the instance of an object class removes it from the scope of administration via a DOC infrastructure. For example, a computer account object represents a laptop computer owned by a director within an organisation. The organisation may deem that the IT administration requirements for directors are outside of the scope of administration of other similar objects for non-directors, and hence this object instance is outside of the scope of the DOC infrastructure. Using the above information, execute the following:  Determine and document the object classes within and outside of the scope of a DOC infrastructure  Determine and document the instances of objects within the in-scope object classes within and outside of the scope of a DOC infrastructure

Page 109 of 354

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

© 2004 Mustan Bharmal

5.9.2.

Determination of the Object Administration Requirements Consider the following information when determining the object administration requirements for the in-scope object classes: • Factor A2: Determination of the object properties that require administration ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the object classes that require inclusion within the scope of the DOC infrastructure, and  Wishes to determine the properties of the in-scope object classes that require administration ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Following the identification of the in-scope object classes, and instances of object classes, it is necessary to determine the properties of the object classes that require administration. From this list of properties that require administration, it is then necessary to determine the administrative tasks on the identified properties that require delegation. It is necessary to execute this approach as not all properties of an object class require administration, and from the list of those that do, not all tasks require delegation of administration. When determining the properties of in-scope object classes that require administration, consider the following:  This design methodology defines the term object “property” as “all metadata for an object instance that may be created, modified, and deleted”. For example, it is possible to create a user account object, modify its group membership, and delete an existing value for its “home directory” attribute.  This design methodology defines the term “administration” as “the execution of a task to create, modify, or delete a property of an instance of an object class”. For example, an “administrative” task on a user account object may be the modification of the security group membership of the user account. An “administration” task is hence one that does not occur by default and requires manual initiation and execution.  For example, a task that occurs by “default”, and hence does not require “administration”, is where a user account created within a domain automatically becomes a member of the “Domain Users” Global security group. The addition of the domain user account to the “Domain Users” Global security group is a modification of a property of that user. The properties of an Active Directory object that requires administration typically revolve around one of three categories of administration tasks. These are the task to create, modify, or delete an object. Hence, it is possible to define the properties of an Active Directory object that require administration with respect to the execution of these three categories of administration tasks. The following table depicts examples of the administration tasks within each of these three categories (creation, modification, deletion) that may require execution on the inscope object classes for this process:

Page 110 of 354

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

© 2004 Mustan Bharmal

Object Administration Task

Components / Sub-Tasks on Properties of Object

User / inetOrgPerson Account Objects Creation of new user account objects; recreation of a previously deleted user account object (for a user or a service / application / resource) (This administration step is illustrated as it is a typical security requirement within most organisations to control the re-creation of user account objects intentionally or accidentally deleted previously); creation of a user account object for a service, application, or resource Modification of a user account object; modification of a user account object for a service, application, or resource Identification of the location for the creation of the user account object within the Active Directory

Population of the following mandatory attributes for user account object generation: given name, initials, and surname, user name, UPN suffix (if more than one available), password, account options (password must be changed at next logon; password can not be changed; password never expires; account disabled)

Modification of an any attribute of a user account (such as password, status (disabled / enabled), user name, group membership, and so on) Modification of the security access control list (ACL) for a user account object Relocation of the user account to another OU within the domain Identification of the user account object to be deleted Execution of an analysis to determine the impact of the deletion of the user account object Deletion of the user account object following successful impact analysis for this task

Deletion of user account objects; deletion of user account objects for services, application, and resources

Computer Account Objects Identification of the location for the creation of the computer account within the Active Directory Creation of computer account objects Population of the following mandatory attributes for computer account generation: computer account name, description of the computer account, GUID of the computer (if pre-staging computer accounts for desktop and laptop computers for operating system deployment via RIS), modification of the default user / group that can join this computer to the domain

Page 111 of 354

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

© 2004 Mustan Bharmal

Object Administration Task

Components / Sub-Tasks on Properties of Object Modification of the attributes for a computer account (description, group membership, status (enabled / disabled), and so on)

Modification of computer account objects

Modification of the security access control list (ACL) for a computer account object Relocation of a computer account to another OU within the domain Resetting a computer account Identification of the computer account object to be deleted

Deletion of a computer account object

Execution of an analysis to determine the impact of the deletion of the computer account object Deletion of the computer account object following successful impact analysis for this task

Group Objects Identification of the location for the new group to be created within the Active Directory, the scope of the group (Domain Local, Global or Universal), and the type of group to be created (security or distribution) Population of the group name, group membership, and description attributes during group creation Modification of the membership of a group (members of the group, and the groups the group is a member of), owner, rights, permissions, and so on Relocation of the group to another OU within the domain Identification of the group to be deleted Deletion of a group object Execution of an analysis to determine the impact of the deletion of the group object Deletion of the group following successful impact analysis for this task Organisational Unit (OU) Objects Identification of the location for the new OU Creation of an OU object Creation of the OU, populating the Name attribute for the OU

Creation of a group object

Modification of a group object

Page 112 of 354

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

© 2004 Mustan Bharmal

Object Administration Task

Components / Sub-Tasks on Properties of Object Population of the OU with existing objects (moving objects into an OU) Implementation / linking of GPOs at the OU Execution of the Delegation of Control wizard at the OU and / or manual modification of the ACL for the OU

Modification of an OU object

Relocation of the OU within the domain, which involves: • Identification of the OU to be moved • Identification of the target location for the OU to be moved • Execution of an analysis to determine the impact of the move on the contents of the OU, such as Resultant Set of Policy (planning), and so on • Relocation of the OU to the target location following successful impact analysis for this task Identification of the OU to be deleted Execution of an analysis to determine the impact of the deletion of the OU object

Deletion of an OU object

Relocation of all objects within the OU, which do not require co-deletion with the OU, to another OU within the domain Deletion of the OU object following successful impact analysis for this task

Contact Objects Creation of Contact Objects Identification of the OU to house the contact objects Creation of the contact objects and population of the attributes of the contact objects Modification / definition of the attributes for the contact objects Relocation of the contact object to another OU Identification of the contact object to be deleted

Modification of Contact Objects Deletion of Contact Objects Printer Objects Creation of Printer Objects

Identification of the OU to house the printer objects Creation of the Printer objects and population of the share path for the printer objects Modification / definition of the attributes for the Printer objects Relocation of the Printer object to another OU

Modification of Printer Objects

Page 113 of 354

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

© 2004 Mustan Bharmal

Object Administration Task Deletion of Printer Objects Shared Folder Objects

Components / Sub-Tasks on Properties of Object Identification of the Printer object to be deleted Deletion of the Printer object from the Active Directory

Identification of the OU to house the new shared folder object Creation of a Shared Folder Object Creation of the shared folder object, population of the name and path attributes for the object, and the keywords to describe the contents of the shared folder Modification of the attributes for the shared folder object (description, keywords, ACL and so on) Relocation of the shared folder object to another OU within the domain Identification of the shared folder object to be deleted Deletion of the shared folder object

Modification of a Shared Folder Object

Deletion of a Shared Folder Object

Group Policy Objects (GPOs) Identification of primary point of implementation of the GPO Creation of a GPO Creation of the GPO object at the identified primary point of implementation, provision of the name for the GPO, configuration of the policies within the GPO, configuration of the GPO permissions Modification of the GPO (configuration, scope) Modification of a GPO Modification of the primary / secondary point of implementation of the GPO Identification of the GPO to be deleted Deletion of a GPO Execution of an analysis to determine the impact of the deletion of the GPO on all objects within the scope of the GPO Deletion of the GPO following completion of a successful impact analysis

Table 34.2: Examples of Object Administration Tasks that may require Delegation When determining the administration tasks for properties of objects, it is important to identify all influences that dictate the required tasks. For example, the table above lists tasks such as “re-creation” of a user account object, as they have security implications. Using the above examples of administration tasks on properties for an object class, execute the following:  Determine and document the specific properties for each required object class that will require administration

Page 114 of 354

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

© 2004 Mustan Bharmal

 Determine and document all influences within an organisation, such as security, process, procedures, and so on that will dictate the number and types of administration tasks on the properties of the in-scope object classes. • Factor A3: Determination of the administration tasks that require delegation ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the properties for the in-scope object classes that will require administration  Wishes to determine, from the list of identified properties, those administration tasks that will require delegation to one or more security principals within the organisation ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The delegation of an administration task is typically performed either by:  Members of the built-in object administration security groups, such as the “Domain Admins”, or by  Security principals assigned Full Control permissions on all or some of the object classes within the scope of an ORMI, or by  Security principals assigned ownership on all or some of the object classes within the scope of an ORMI, or by  Security principals identified as having a managerial relationship with objects within the scope of an ORMI Following the identification of the properties of object classes that will require administration, it is necessary to identify those administration tasks that will require delegation. This will hence produce a single list of administration tasks that require one of the following combinations:  A list of administration tasks that require delegation, and none that do require delegation  A list of administration tasks that do and do not require delegation  A list of administration tasks that all require delegation to one or more security principals within an organisation Note that the administration tasks that do not require delegation will hence require execution by the security principal(s) that delegate the remaining administration tasks. When determining the administration tasks that require delegation, consider the following:  For all administration tasks that require delegation, it is necessary to define the following:  The object class and its administration task  The scope of the administration task that requires delegation, defined as: • All instances of objects within that object class

Page 115 of 354

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

© 2004 Mustan Bharmal • Specific instances of objects within that object class, differentiated via object metadata (for example, just computer account object for laptop and desktop computers)  The structure and organisation of the IT support function of an organisation may dictate the delegation of the administration tasks. For example:  A security function within the IT support department of an organisation may be responsible for the execution of all creation, deletion, and re-creation administration tasks for all user account objects  The help desk function responsible for the execution of some, but not all, modification tasks on user account objects  The PC support team responsible for the execution of the creation, modification, and deletion administration tasks for all computer account objects for laptop and desktop computers only  The server support team responsible for the execution of the creation, modification, and deletion administration tasks for all computer account objects or server computers only, and so on  Note that it is possible to delegate some administration tasks to end users not associated with any IT support functions within an organisation. For example, to reduce the workload on an IT support department, an organisation may decide to delegate the permission to reset passwords on user accounts to the assigned users of the user accounts (delegate the “reset password” permission to “SELF”), or permit users to join computers to the domain and so on. Using the above information, execute the following:  Determine and document the administration tasks that require delegation  Determine and document the potential scope of object instances for a delegated administration task 5.9.3. Determination of the Delegate Scope for the DOC Infrastructure Delegation of control implies the assignment of permissions for object administration to “normal” user accounts that do not receive the appropriate permissions via membership to built-in security groups. The term “delegates” refers to the user accounts assigned the DOC permissions within the DOC infrastructure for object administration. Consider the following information when determining the in and out-of-scope delegates within a DOC infrastructure: • Factor B2: Understanding delegates within a DOC infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the list of administration tasks, on properties of the in-scope object classes, that they wish to delegate, and  Wishes to understand the concept of delegates within a DOC infrastructure ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation:

Page 116 of 354

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

© 2004 Mustan Bharmal

Although the term “delegate” refers to a “normal” user account, that normal user account may represent any user within an organisation, and not just an IT administrator that is not a member of a built-in administration security group. For example, some organisations may wish to delegate simple (low risk) administrative tasks to users outside of the IT support function, such as the permission to create shared folder objects within an OU or OU hierarchy within the domain. The users assigned the permission to create shared folder objects would then become delegates within a DOC infrastructure. It was necessary to determine the administrative tasks that require delegation prior to the actual delegates themselves, as the selection of delegates depends upon the tasks. For example, an organisation may execute this process in the reverse manner, identify just members of the IT support function as potential delegates, and then identify the administrative tasks that require delegation. However, this reverse approach would negate the opportunity to delegate one or more “low level” administration tasks to users not aligned to any IT support functions within the organisation. • Factor A4: Determination of the delegates for the identified object administration tasks ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the list of administration tasks, on properties of the in-scope object classes, that they wish to delegate, and  Wishes to determine the delegates for the identified object administration tasks ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When determining the identity of the delegates for the identified object administration tasks, consider the following:  The presence / absence of the Active Directory objects that require administration within the boundary of the ORMI the DOC infrastructure supports defines the scope of the DOC infrastructure.  The presence / absence within the boundary of the ORMI of the security principals required to execute the identified object administration tasks does not define the scope of a DOC infrastructure.  Hence, security principals that require identification as delegates within the DOC infrastructure may reside within any trusted internal (in same forest as this domain) or external domain. A security principal may require delegation of object administration tasks in a trusting domain where, for example, the objects that require administration belong to a single autonomous division represented within two (or more) domains, and the autonomous division has a centralised IT support function. This design methodology proposes the following approach for the delegation of object administration tasks to security principals within an organisation:  Firstly, categorise all object administration tasks into one of the following three categories:  “High risk tasks” (object administration tasks that comply with the following (example) criteria:

Page 117 of 354

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

© 2004 Mustan Bharmal • The task can generate a significant impact on the security infrastructure for an organisation, such as Group Policy Object administration) • The task requires execution only by trusted administrators within an organisation / autonomous division, not members of the “Administrators” or “Domain Admins” security groups  “Normal risk tasks” (object administration tasks that comply with the following criteria: • Do not match the first criterion for “high risk tasks” • The task requires execution by trusted / trained administrators within an organisation / autonomous division, dedicated to that task / series of tasks  “Low risk tasks” (object administration tasks that do not comply with any of the criteria for high or normal risk tasks, such as population of the public property set attributes for a user account object)  Note that factors such as the requirement to reduce the administration overheads on trained and dedicated administrators within an organisation / autonomous division may influence the categorisation of identified object administration tasks into “low” risk task category.  Then, list all potential delegates (from IT support personnel to end users) within the scope of an ORMI and place them into one of the following three corresponding categories:  Trusted Administrators (these are potential delegates that may be trusted with the execution of high risk tasks)  Administrators (these are potential delegates trained and dedicated to the execution of routine object administration tasks)  End Users (these are potential delegates not trained or trusted in the execution of high or normal risk tasks, but may be trusted to execute low risk tasks)  Then match the delegates within each of these three categories with the corresponding categories for the identified object administration tasks. Using the above approach, execute the following:  Determine and document the list of high, normal, and low risk object administration tasks  Determine and document the list of potential delegates for each of the three categories (“trusted administrators”, “administrators”, and “end users”) 5.9.4. Determination of the DOC Design Requirements for In-Scope Object Classes Consider the following information when determining the DOC requirements for the identified administration tasks that require delegation: • Factor B3: Understanding DOC requirements ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the list of administration tasks that require delegation, and

Page 118 of 354

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

© 2004 Mustan Bharmal

 Wishes to understand the concepts of DOC requirements and Active Directory permissions ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Following the identification of the object administration tasks, it is necessary to determine their associated DOC requirements, which refer to the permissions, and (where necessary) the rights, and group memberships required by potential delegates to execute their assigned tasks. Although true for the majority, it is not possible to execute all object administration tasks that require delegation simply via the assignment of permissions on an object class to a delegate. Some DOC permissions require supplementation with membership to built-in security groups, and the assignment of rights within the domain. For example, delegation of control to permit execution of GPO administration (see below for details) may require a combination of DOC permissions and membership to a built-in security group. Some object administration tasks are linked together automatically by Active Directory permissions and are not separable by default. For example, delegation of the permission just to create user account objects within an OU container will result in the creator of the user account object to be the default owner of all user account objects they create. The delegates also automatically have Full Control permission on all user account objects they create, and those created by other security principals within that container and child containers, and this hence permits them to delete and modify these user account objects as well. This design methodology states the following recommendations associated with the assignment of permissions on Active Directory objects, for delegation of control over their administration:  Never alter or remove the default permissions generated on Active Directory objects, as this may generate unforeseen circumstances, and / or reduce the effectiveness of the default security model for the objects.  Where possible, attempt to minimise or consolidate the permissions assigned on objects to delegates. It is possible to achieve this via the use of security groups where multiple delegates are to receive the same set of permissions, and via the use of “property sets” for permissions (see below) instead of individual attributes. The larger the number of permissions implemented on an object, the greater the size of that object, as each ACE (access control entry) represents a finite amount of data for an object.  Be aware of the power of the “Full Control” permission on an object and a container for objects, such as an OU. The “Full Control” permission allows the delegate to control all aspects of that object, and all objects within a container, respectively. Note the following pertinent facts about Active Directory permissions and inheritance of permissions:  An access control entry (ACE) generated on a container object, such as an OU, will be received as by all objects within that container, even if the scope for the entry is restricted to a specific instances of an object class within the container. Instances of object classes that the ACE does not target will not use the ACE, but will store it within their access control list (ACL). Hence, where there are a large number of ACEs implemented on a container, this increases the size for each object, as the number of ACEs within the ACL for the object influences the size of the object, even if all of the ACEs do not apply. It is hence necessary to exercise caution when

Page 119 of 354

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

© 2004 Mustan Bharmal

implementing large numbers of permissions on container objects, and this is hence influential in the design of the OU infrastructure.  Where multiple objects have identical ACLs (for example, all permissions on Active Directory objects are generated via inheritance and there is no explicit implementation of permissions), Windows Server 2003 Active Directory will generate a “single instance” of that ACL for all of the objects. This support for “single instancing” of ACLs enhances performance and reduces the size of the objects.  The explicit assignment of permissions directly on an object take precedence over all permissions generated via inheritance. Note that this is true even where the inherited permission is “Deny” for the explicitly applied permission.  The “deny” permission is hence only effective when assigned explicitly on an Active Directory object. It is necessary to understand the concept of “property sets” on Active Directory objects, prior to the determination of the DOC requirements for object administration tasks. A “property set” is a collection of attributes for Active Directory objects. The assignment of permissions, such as Read and Write, to a property set applies to all attributes within the property set, and is hence a more efficient method for management of access control. It is possible to use property sets when defining DOC permission requirements where there is a requirement to delegate the administration of object attributes and their values. The following table describes a few examples of property sets and their constituent attributes, pre-defined for the user, computer, and contact object classes:
Property Set General Information (property set containing a set of user attributes that constitute general user information) Membership (property set containing user attributes that describe group membership information) Applicable Object Classes User Object Attributes within Property Set

Display Name adminDescription codePage CountryCode ObjectSid primaryGroupID sAMAccountName

sAMAccountType sDRightsEffective showInAdvancedViewOnly sIDHistory UID comment

User

memberOf

member

Page 120 of 354

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

© 2004 Mustan Bharmal

Property Set Personal Information (property set containing user attributes that describe personal user information)

Applicable Object Classes User, Contact, Computer

Object Attributes within Property Set

streetAddress homePostalAddress assistant info country/region name facsimileTelephoneNumber (fax number) International-ISDN-Number Locality-Name MSMQ-Digests mSMQSignCertificates Personal-Title Phone-Fax-Other Phone-Home-Other Phone-Home-Primary otherIpPhone ipPhonenumber primaryInternationalISDNNumbe r Phone-ISDN-Primary Phone-Mobile-Other (otherMobile) Phone-Mobile-Primary Additional-Information notes Allowed-Attributes allowedAttributesEffective allowedChildClasses allowedChildClassesEffective altSecurityIdentities Common-Name (cn) company department description displayNamePrintable division E-mail-Addresses givenName initials legacyExchangeDN manager msDS-Approx-ImmedSubordinates accountExpires pwdLastSet userAccountControl

Phone-Office-Other (otherTelephone) Phone-Pager-Other Phone-Pager-Primary physicalDeliveryOfficeName thumbnailPhoto (Picture) postalCode preferredDeliveryMethod registeredAddress State-Or-Province-Name Street-Address telephoneNumber teletexTerminalIdentifier telexNumber primaryTelexNumber userCert User-Shared-Folder User-Shared-Folder-Other userSMIMECertificate x121Address X509-Cert msDS-Auxiliary-Classes distinguishedName (Obj-DistName) Object-Category Object-Class Object-Guid Organization-Name Organizational-Unit-Name otherMailbox Proxy-Addresses RDN name Reports (directReports) servicePrincipalName showInAddressBook Surname System-Flags Text-Country/Region Title userPrincipalName userParameters tokenGroupsNoGCAcceptable

Public Information (property set containing user attributes that describe user public information)

User, Computer

User Account Restrictions (property set containing user attributes that describe account restrictions)

User, Computer

Page 121 of 354

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

© 2004 Mustan Bharmal

Property Set User Logon (property set containing user attributes that describe user logon information)

Applicable Object Classes User

Object Attributes within Property Set

badPwdCount homeDirectory homeDrive lastLogoff Last-Logon

lastLogonTimestamp logonCount logonHours logonWorkstation profilePath

Table 34.3: Examples of Property Sets and their Predefined Constituent Attributes for User, Computer, and Contact Object Classes • Factor A5: Determination of the requirements for the delegation of control of user account administration tasks ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the delegation of administration for user account objects, and  Wishes to determine the requirements to permit the execution of the delegated administration tasks for user account objects ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: As defined earlier, the delegation of control for user account administration may involve one or more of the following tasks and their sub-tasks:  The creation of a user account object, which involves:  The identification of the location for the creation of the user account object within the Active Directory  The population of the following mandatory attributes for user account generation: given name, initials, and surname, user name, UPN suffix (if more than one available), password, account options (password must be changed at next logon; password can not be changed; password never expires; account disabled)  The modification of a user account object, which involves:  The modification of an any attribute of a user account (such as password, status (disabled / enabled), user name, group membership, and so on)  The modification of the security access control list (ACL) for a user account object  The relocation of the user account to another OU within the domain  The deletion of a user account object, which involves:  The identification of the user account object to be deleted  The execution of an analysis to determine the impact of the deletion of the user account object

Page 122 of 354

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

© 2004 Mustan Bharmal

 The deletion of the user account object following successful impact analysis for this task Consider the following when determining the DOC requirements for the creation and deletion of user account objects:  It is possible to delegate the tasks associated with the creation of user account objects via assignment of the specific “Create User Objects” and “Full Control” permissions, to a potential delegate, on a container within a domain that supports the creation of user account objects.  Note that it is possible, although not recommended, to delegate the permission to create user account objects within all containers available within a domain (including the root of the domain), except the following default containers within a domain:  The “LostandFound” container  The “NTDS Quotas” container  Be aware that these permissions grant the delegate ownership on all user accounts objects they generate, and Full Control on all user account objects within the container that has this permission implemented.  Note that addition of a potential delegate to the built-in Domain Local security group “Account Operators”, grants full user account administration rights on all user account objects within the entire domain, except members of the “Administrators” or “Domain Admins” groups.  Note that it is necessary to exercise extreme caution when assigning membership to this group for user account delegation, as members of Account Operators group have the default right to:  Create user, inetOrgPerson, computer, and group objects  Log on locally to any computer  Shut down any computer Consider the following when determining the DOC requirements for the modification of user account objects:  Where the term “modification” implies administration of one or more of the attributes for the user account object, then assign explicit permissions on:  The individual attributes that require delegation of administration, or  The property set the attribute(s) are associated with  This design methodology recommends the use of property sets for the assignment of permissions, unless there is a requirement to restrict the attributes a delegate may modify.  Where the term “modification” implies the relocation (moving) of a user account object to another container, then relocation requires the following two sets of permissions:  The permission “Create User Objects” the target container  The permissions “Read and Write All Properties” and “Delete” to delete the user account object in the source container

Page 123 of 354

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

© 2004 Mustan Bharmal

 Note that it is possible to implement these permissions either at the container (such as an OU) or on the actual user account objects. Where these permissions require implementation on the container object, it is necessary to scope the permissions to apply to “user objects”.  Where the term “modification” implies the addition, modification, and deletion of ACEs on the ACLs for user account objects, then the delegate requires either:  Full Control permission on the user account objects  Ownership of the user account objects  The “Modify permission” permission on the user account objects Using the above information, execute the following:  Determine and document the minimum permissions / rights / group memberships required by delegates to execute the creation, modification, and deletion administration tasks on user account objects.  Determine and document the required scope of implementation of DOC permissions (for example, if there is a requirement to support the moving of objects between OUs, then the appropriate DOC permissions will require implementation on both source and target OUs).  Determine and document the required scope of application of the DOC permissions (which user accounts each delegate may create and administer, based upon, for example, categories for types of user account that reflect metadata for actual users, and so on).  Determine and document the delegates to receive the identified DOC permissions, rights, group memberships, and so on (identified as either specific individuals or categories of types users, based upon their metadata, such as job function and so on).  Determine and document the total scope of administration tasks for user account objects the required permissions will grant a delegate, beyond the minimum required permissions. For example, the assignment of “Read and Write All Properties” may grant a delegate a scope of administration beyond the minimum required scope. • Factor A6: Determination of the requirements for the delegation of control of computer account administration tasks ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the delegation of administration for computer account objects, and  Wishes to determine the requirements to permit the execution of the delegated administration tasks for computer account objects ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: As defined earlier, the delegation of control for computer account administration may involve one or more of the following tasks and their sub-tasks:  The creation of computer account objects, which involves:

Page 124 of 354

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

© 2004 Mustan Bharmal

 The identification of the location for the creation of the computer account within the Active Directory  The population of the mandatory attributes for computer account generation (computer account name, description of the computer account, GUID of the computer (if pre-staging computer accounts for desktop and laptop computers for operating system deployment via RIS)), and modification of the default user / group that can join this computer to the domain.  The modification of computer account objects, which involves:  The modification of the attributes for a computer account (description, group membership, status (enabled / disabled), and so on)  The modification of the security access control list (ACL) for a computer account object  The relocation of a computer account to another OU within the domain  The resetting of a computer account  The deletion of computer account objects, which involves:  The identification of the computer account object to be deleted  The execution of an analysis to determine the impact of the deletion of the computer account object  The deletion of the computer account object following successful impact analysis for this task Consider the following when determining the DOC requirements for the creation of computer account objects:  It is possible to delegate the tasks associated with the creation of computer account objects via assignment of the specific “Create Computer Objects” permission, to a potential delegate, on a container within a domain that supports the creation of computer account objects. Note that it is possible, although not recommended, to delegate the permission to create computer account objects within all containers available within a domain (including the root of the domain), except the following default containers within a domain:  The “LostandFound” container  The “NTDS Quotas” container  Note that this permission grants the delegate ownership on all computer accounts objects they generate, but only (by default) limited permissions (not Full Control). However, as the owner of the object, they can assign themselves Full Control permission. The delegate has limited permissions (not ownership or “modify permission”) on computer account objects generated by other delegates / security principals within that container / sub-containers.  Note that the addition of a potential delegate to the built-in Domain Local security group “Account Operators”, grants full computer account administration rights on all computer account objects within the entire domain, except domain controllers. As stated earlier, due to the powerful nature of this built-in security group, caution is necessary when assigning members to this group. Consider the following when determining the DOC requirements for the modification and deletion of computer account objects:

Page 125 of 354

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

© 2004 Mustan Bharmal

 The following table lists the Read and Write permissions required to modify the following examples of specific attributes for an existing computer account object:
Attribute The “Computer name (pre-Windows 2000)” The “DNS Name” Read / Write Permission “Computer name (pre-Windows 2000)” “dNSHostName” (Note: May also require permission “Validated Write to DNS host name”, which permits the definition of a DNS host name attribute value that is compliant with the computer and domain name) “Description” “memberOf” (Note: delegate must also have the permission to modify the membership of the group a computer account is to become a member of) “msDS-AllowedToDelegateTo” “Managed By”

The “Description” The group membership

The service delegation level for the computer The “Managed By” security principal

Table 34.4: Read and Write Permissions to Modify Specific Attributes for Computer Account Objects  To permit a delegate to manage the access control list (ACL) for computer account objects, assign the permission “Modify Permission”.  To reset a computer account (reset the password), assign the permission “Reset Password”.  As for other objects, the moving of a computer account object requires the permissions to:  Create a new computer account object in the destination container (such as an OU) (“Create Computer Objects” permission on the container)  Delete the computer account object to be moved in the source container (“Delete” permission) Using the above information, execute the following:  Determine and document the minimum permissions / rights / group memberships required by delegates to execute the creation, modification, and deletion administration tasks on computer account objects  Determine and document the required scope of implementation of DOC permissions  Determine and document the required scope of application of DOC permissions (which computer accounts each delegate may create and administer based upon, for example, categories for types of computer accounts that reflect metadata for actual computers)  Determine and document the delegates to receive the identified DOC permissions, rights, group memberships, and so on (identified as either specific individuals or categories of types users, based upon their metadata, such as job function and so on.)

Page 126 of 354

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

© 2004 Mustan Bharmal

 Determine and document the total scope of administration tasks for computer account objects the required permissions will grant the delegate, beyond the minimum required permissions. • Factor A7: Determination of the requirements for the delegation of control of group object administration tasks ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the delegation of administration for group objects, and  Wishes to determine the requirements to permit the execution of the delegated administration tasks for group objects ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: As defined earlier, the delegation of control for group object administration may involve one or more of the following tasks and their sub-tasks:  The creation of group objects, which involves:  The identification of the location for the new group to be created within the Active Directory, the selection of the required scope of the group (Domain Local, Global or Universal), and the type of group to be created (security or distribution)  The population of the mandatory attribute “group name” (and, where required, the “Group Name (pre-Windows 2000)” attribute) during group creation  The population of the group membership and description for the group  The modification of group objects, which involves:  The modification of the membership of a group (members of the group, and the groups the group is a member of), owner, rights, permissions, and so on  The relocation of the group to another OU within the domain  The deletion of group objects, which involves:  The identification of the group to be deleted  The execution of an analysis to determine the impact of the deletion of the group object  Deletion of the group following successful impact analysis for this task Consider the following when determining the DOC requirements for the creation of group objects:  It is possible to delegate the tasks associated with the creation of group objects via assignment of the specific “Create Group Objects” permission, to a potential delegate, on a container within a domain that supports the creation of group objects.  Note that this permission grants the delegate ownership on all group objects they generate, but only (by default) limited permissions. However, as owners of the group objects, the delegates can change the permissions to Full Control. The delegates have limited permissions (not Full Control, and not “modify permissions”) on other

Page 127 of 354

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

© 2004 Mustan Bharmal

group objects generated by other delegates / security principals with that container / sub-containers.  Note that the addition of a potential delegate to the built-in Domain Local security group “Account Operators”, grants full group object administration rights on all group objects within the entire domain, except the built-in administration security groups “Administrators”, “Domain Admins”, “Schema Admins”, “Account Operators”, and so on. As stated earlier, due to the powerful nature of this built-in security group, caution is necessary when assigning members to this group. Consider the following when determining the DOC requirements for the modification and deletion of group objects:  The most common administration tasks executed on group objects is the modification of the members of a group, and the membership of a group to other groups. The following permissions may be required to execute these tasks:  “Add/Remove self as member”  Read / Write “Members”  Read / Write “memberOf”  To permit a delegate to manage the access control list (ACL) for group objects, assign the permission “Modify Permission”.  As for other objects, the moving of a group object between containers within a domain requires the permissions to:  Create a new group object in the destination container (such as an OU) (“Create Group Objects” permission on the container)  Delete the group object to be moved in the source container (“Delete” permission) Using the above information, execute the following:  Determine and document the minimum permissions / rights / group memberships required by delegates to execute the creation, modification, and deletion administration tasks on group objects  Determine and document the required scope of implementation of DOC permissions  Determine and document the required scope of application of DOC permissions (which groups each delegate may create and administer based upon, for example, types of groups a delegate is permitted to generate, the potential members (users, computers, other groups) of the groups, and so on.)  Determine and document the delegates to receive the identified DOC permissions, rights, group memberships, and so on (identified as either specific individuals or categories of types users, based upon their metadata, such as job function and so on.)  Determine and document the total scope of group administration tasks the required permissions will grant the delegate, beyond the minimum required permissions. • Factor A8: Determination of the requirements for the delegation of control of OU object administration tasks ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:

Page 128 of 354

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

© 2004 Mustan Bharmal

 Has identified the requirement for the delegation of administration for OU objects, and  Wishes to determine the requirements to permit the execution of the delegated administration tasks for OU objects ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: As defined earlier, the delegation of control for OU object administration may involve one or more of the following tasks and their sub-tasks:  The creation of OU objects, which involves:  The identification of the location for the new OU  The creation of the OU, populating the Name attribute for the OU  The modification of OU objects, which involves:  The population of the OU with existing objects (moving objects into an OU)  The implementation / linking of GPOs at the OU  The execution of the Delegation of Control wizard at the OU and / or manual modification of the ACL for the OU  The relocation of the OU within the domain, which involves: • Identification of the OU to be moved • Identification of the target location for the OU to be moved • Execution of an analysis to determine the impact of the move on the contents of the OU, such as Resultant Set of Policy (planning), and so on • Relocation of the OU to the target location following successful impact analysis for this task  The deletion of OU objects, which involves:  The identification of the OU to be deleted  The execution of an analysis to determine the impact of the deletion of the OU object  The relocation of all objects within the OU, which do not require co-deletion with the OU, to another OU within the domain  The deletion of the OU object following successful impact analysis for this task Consider the following when determining the DOC requirements for the creation of OU objects:  It is possible to delegate the tasks associated with the creation of OU objects via assignment of the specific “Create Organizational Unit Objects” permission, to a potential delegate, at the root of a domain or on an OU within a domain.  Note that this permission grants the delegate ownership on all OU objects they generate, but only (by default) limited permissions. However, as owners of the OU objects, the delegates can change the permissions to Full Control. The delegates

Page 129 of 354

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

© 2004 Mustan Bharmal

have limited permissions (not Full Control, and not “modify permissions”) on other OU objects generated by other delegates / security principals with that container / sub-containers. Consider the following when determining the DOC requirements for the modification and deletion of OU objects:  The following table lists the Read and Write permissions required to modify the following examples of specific attributes for an existing OU object:
Attribute The “Description” The “Street” The “State / Province” The “Zip / Postal Code” The “Country / Region” The “Managed By” security principal Read / Write Permission “Description” “Street” “st” “postalCode” “countryCode” “Managed By”

Table 34.5: Read and Write Permissions to Modify Specific Attributes for OU Objects  To administer the other attributes for OU objects not listed above, such as City, it is necessary to assign Read and Write for All Properties.  To administer the implementation of GPOs at an OU, it is necessary to assign Read and Write for the “gpLink” permission on the “gpLink” property of the container. To enable the “Block Inheritance” configuration on a container (to block the inheritance of GPOs), it is necessary to assign Read and Write for the “gpOptions” permission on the “gpOptions” property of the container.  To permit a delegate to execute Resultant Set of Policy tasks, in planning and / or logging mode, it is necessary to assign the permissions “Generate Resultant Set of Policy (Planning)” and “Generate Resultant Set of Policy (Logging)”, respectively.  To permit a delegate to delete an OU object, it is necessary to assign the “Delete” permission.  As for other objects, the moving of an OU object between other OUs within a domain requires the permissions to:  Create a new OU object in the destination container (such as an OU) (“Create Organizational Unit Objects” permission on the container)  Delete the OU object to be moved in the source container (“Delete” permission) Using the above information, execute the following:  Determine and document the minimum permissions / rights / group memberships required by delegates to execute the creation, modification, and deletion administration tasks on OU objects  Determine and document the required scope of implementation of DOC permissions  Determine and document the required scope of application of DOC permissions (which types of OUs each delegate may create and administer based upon, for example, types of OUs (“admin” and “placeholder” OUs), and so on.)

Page 130 of 354

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

© 2004 Mustan Bharmal

 Determine and document the delegates to receive the identified DOC permissions, rights, group memberships, and so on (identified as either specific individuals or categories of types users, based upon their metadata, such as job function and so on.)  Determine and document the total scope of OU administration tasks the required permissions will grant the delegate, beyond the minimum required permissions. • Factor A9: Determination of the requirements for the delegation of control of printer object administration tasks ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the delegation of administration for printer objects, and  Wishes to determine the requirements to permit the execution of the delegated administration tasks for printer objects ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: As defined earlier, the delegation of control for printer object administration may involve one or more of the following tasks and their sub-tasks:  The creation of printer objects (that represent print queues not on Windows Server 2003 / Windows 2000 print servers), which involves:  The identification of the OU to house the printer objects  The creation of the printer objects and population of the share path for the printer objects  The modification of printer objects, which involves:  The modification / definition of the attributes for the Printer objects  The relocation of the printer object to another OU  The deletion of printer objects, which involves:  The identification of the printer object to be deleted  The deletion of the printer object from the Active Directory Consider the following when determining the DOC requirements for the creation of printer objects:  It is possible to delegate the tasks associated with the creation of printer objects via assignment of the specific “Create Printer Objects” permission, to a potential delegate, on a container within a domain that supports the creation of printer objects.  Note that this permission grants the delegate ownership and Full Control permissions, by default, on all printer objects they generate. The delegates have limited permissions on printer objects generated by other delegates / security principals, within the same container(s).  Note that the addition of a potential delegate to the built-in Domain Local security group “Print Operators”, grants full printer object administration rights on all domain

Page 131 of 354

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

© 2004 Mustan Bharmal

printers. Membership to this group assigns the additional user rights to members to logon locally, and shut down a computer. Caution is necessary when assigning membership to this group, as a member of this group, logged on to a domain controller, has the right to shut down the domain controller, and thus cause a denial of service. Consider the following when determining the DOC requirements for the modification and deletion of printer objects:  A printer object has multiple attributes that describe the functionality of the print device and print queue the printer object represents. It is possible to individually administer most attributes via assignment of the appropriate Read / Write permissions for the relevant property.  Administration of the ACL for a printer object, via assignment of the “modify permissions” permission, only permits modification of the permissions to administer the printer object, and does not assign permissions to use the print queue. Assign permissions to use the print queue on the print server.  As for other objects, the moving of a printer object between OUs within a domain requires the permissions to:  Create a new printer object in the destination container (such as an OU) (“Create Printer Objects” permission on the container)  Delete the printer object to be moved in the source container (“Delete” permission) Using the above information, execute the following:  Determine and document the minimum permissions / rights / group memberships required by delegates to execute the creation, modification, and deletion administration tasks on printer objects  Determine and document the required scope of implementation of DOC permissions  Determine and document the required scope of application of DOC permissions (which instances of print queues each delegate may create and administer based upon, for example, type, or location of print servers, and so on.)  Determine and document the delegates to receive the identified DOC permissions, rights, group memberships, and so on (identified as either specific individuals or categories of types users, based upon their metadata, such as job function and so on.)  Determine and document the total scope of administration tasks for printer objects the required permissions will grant the delegate, beyond the minimum required permissions. • Factor A10: Determination of the requirements for the delegation of control of shared folder object administration tasks ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the delegation of administration for shared folder objects, and  Wishes to determine the requirements to permit the execution of the delegated administration tasks for shared folder objects

Page 132 of 354

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

© 2004 Mustan Bharmal ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: As defined earlier, the delegation of control for shared folder object administration may involve one or more of the following tasks and their sub-tasks:  The creation of shared folder objects, which involves:  The identification of the OU to house the new shared folder object  The creation of the shared folder object, population of the name and path attributes for the object, and the keywords to describe the contents of the shared folder  The modification of shared folder objects, which involves:  The modification of the attributes for the shared folder object (description, keywords, ACL and so on)  The relocation of the shared folder object to another OU within the domain  The deletion of shared folder objects, which involves:  The identification of the shared folder object to be deleted  The deletion of the shared folder object Consider the following when determining the DOC requirements for the creation of shared folder objects:  It is possible to delegate the tasks associated with the creation of shared folder objects via assignment of the specific “Create Shared Folder Objects” permission, to a potential delegate, on a container within a domain that supports the creation of shared folder objects.  Note that this permission grants the delegate ownership on all shared folder objects they generate, but only (by default) limited permissions. However, as owners of the shared folder objects, the delegates can change the permissions to Full Control. The delegates have limited permissions on shared folder objects generated by other delegates / security principals, within the same container(s). Consider the following when determining the DOC requirements for the modification and deletion of shared folder objects:  The only attributes a shared folder possesses that may require administration are the “Managed By” and “keywords” attributes. To delegate the administration of these attributes, assign the Read and Write “Managed By” and “Keywords” permissions.  Administration of the ACL for a shared folder object, via assignment of the “modify permissions” permission, only permits modification of the permissions to administer the shared folder object, and does not assign permissions to use the contents of the shared folder. Assign permissions to use the contents of the shared folder using file system permissions on the file server.  As for other objects, the moving of a shared folder object between OUs within a domain requires the permissions to:  Create a new shared folder object in the destination container (such as an OU) (“Create Shared Folder Objects” permission on the container)

Page 133 of 354

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

© 2004 Mustan Bharmal

 Delete the shared folder object to be moved in the source container (“Delete” permission) Using the above information, execute the following:  Determine and document the minimum permissions / rights / group memberships required by delegates to execute the creation, modification, and deletion administration tasks on shared folder objects  Determine and document the required scope of implementation of DOC permissions  Determine and document the required scope of application of DOC permissions (which instances of shared folders each delegate may create and administer an Active Directory avatar for, based upon, for example, the file servers that host the shared folders, and so on.)  Determine and document the delegates to receive the identified DOC permissions, rights, group memberships, and so on (identified as either specific individuals or categories of types users, based upon their metadata, such as job function and so on.)  Determine and document the total scope of administration tasks for shared folder objects the required permissions will grant the delegate, beyond the minimum required permissions. • Factor A11: Determination of the requirements for the delegation of control of GPO administration tasks ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the delegation of administration for GPOs, and  Wishes to determine the requirements to permit the execution of the delegated administration tasks for GPOs ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: As defined earlier, the delegation of control for GPO administration may involve one or more of the following tasks and their sub-tasks:  The creation of GPOs, which involves:  The identification of primary point of implementation of the GPO  The creation of the GPO object at the identified primary point of implementation, provision of the name for the GPO, configuration of the policies within the GPO, and configuration of the GPO permissions  The modification of GPOs, which involves:  The modification of the GPO (configuration, scope, linked WMI filter, and so on)  The modification of the primary / secondary point of implementation of the GPO  The deletion of GPOs, which involves:  The identification of the GPO to be deleted

Page 134 of 354

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

© 2004 Mustan Bharmal

 The execution of an analysis to determine the impact of the deletion of the GPO on all objects within the scope of the GPO  The deletion of the GPO following completion of a successful impact analysis Consider the following when determining the DOC requirements for the creation of GPOs:  It is possible to delegate the tasks associated with the creation of GPOs via:  Assignment of the Read and Write “gpLink” permission to a potential delegate, on a potential point of creation and implementation of a GPO (root of domain or a custom OU), AND  Addition of the delegate to the built-in Global security group “Group Policy Creator Owners” (GPCO), OR  Assignment of GPO creation rights via the use of the Group Policy Management Console (GPMC), via the “Delegation” tabbed page for the “Group Policy Objects” container for a domain.  Note that the addition of a potential delegate to the GPCO group, or delegation of the right to generate GPOs via the “Delegation” tabbed paged for the Group Policy Objects container within the GPMC, does not permit, in isolation, the creation of GPOs. It is necessary to supplement either of these actions with the assignment of the Read and Write “gpLink” permission on a suitable container using:  The Delegation of Control Wizard within the “Users and Computers” MMC snapin to assign the “Manage Group Policy links” permissions, or  The GPMC, at the “Delegation” tabbed page for a Site, domain, or OU, via the selection of the “Link GPOs” permission. Note the use of the Delegation tabbed page for a Site, domain, or OU, also permits the assignment of the DOC permissions to “Perform Group Policy Modelling analyses” and “Read Group Policy Results data”.  The “gpLink” property for a container contains the list of GPOs implemented at that container, and their priority of application. The “gpOptions” property of a container contains the “Block Inheritance” settings for that container.  For example, membership to the built-in security group “Group Policy Creator Owners” (GPCO) permits the member security principal, using the Group Policy Management Console, to execute the GPO administration tasks listed in the following table:
GPO Administration Tasks Using GPMC Create, edit, and name a new Group Policy Object (GPO) Create, edit, and name a new WMI filter Link any WMI filters created by the security principal, or already existing WMI filters, to any GPO created by that security principal Implement / link a GPO to a primary or secondary point of implementation within the Active Directory forest Permitted with Just GPCO Membership? Yes Yes Yes No

Table 34.6: List of GPO Administration Tasks Supported by Membership to GPCO Group

Page 135 of 354

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

© 2004 Mustan Bharmal

 As can be seen from the above table, although membership to the built-in Global security group “Group Policy Creator Owners” (GPCO) permits a member to create GPOs and WMI filters, and link any existing / created WMI filters to GPOs they created, they cannot implement the GPOs they create, or link existing GPOs. An unimplemented GPO will hence not apply its policies to its intended target users / computers.  Note that with the use of the GPMC, it is also possible to grant users / groups the explicit permission to create GPOs within an Active Directory forest, without requiring membership to the GPCO Global security group. Note that delegation of GPO creation and administration tasks using this method is similar to the use of the built-in GPCO security group, and its associated rights. This option permits the delegation of GPO administration tasks to security principals outside of the domain, where previously security principals required membership to the Global GPCO security group, and hence had to reside within that domain. Hence, any security principals in trusted domains may manage GPOs within this domain.  This design methodology recommends the use of the GPCO where possible, to grant GPO administration rights to domain users. Where it is necessary to grant GPO administration rights to security principals outside of the domain, this design methodology recommends the generation of a Domain Local security group, addition of the external security principals to this security group, and assignment of GPO administration rights (via the GPMC) to this Domain Local group.  Note that the default delegates for GPO generation within an Active Directory domain are the:  “Group Policy Creator Owners” Global security group  “Domain Admins” Global security group  “SYSTEM” security principal Consider the following when determining the DOC requirements for the modification and deletion of GPOs:  It is possible to delegate the execution of administration tasks on existing GPOs, such as modification of the configuration, policy settings, security and WMI filters, and so on, via:  The assignment of permissions, on individual existing GPOs, using the GPMC, or  The addition of a delegate to the built-in GPCO Global security group, or  The delegation of GPO administration rights for all GPOs within a domain using the “Delegation” tabbed paged, within the GPMC, on the “Group Policy Objects” container  Assign permissions on individual GPOs via the GPMC, using the “Delegation” tabbed page for a GPO. It is possible to assign one of three categories of permissions to a potential delegate for an individual GPO. These categories are:  Read (allows the delegate just “Read” permission on the GPO)  Edit settings (allows the delegate “Read”, “Write”, “Create Child Objects”, and “Delete Child Objects”)  Edit settings, delete, modify security (allows the delegate “Read”, “Write”, “Create Child Objects”, “Delete Child Objects”, “Delete”, “Modify Permissions”, and “Modify Owner”, but not the “Apply Group Policy” permission.

Page 136 of 354

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

© 2004 Mustan Bharmal

 Note that the Delegation tabbed page for an individual GPO may also illustrate the following two other types of permissions:  “Read (from Security Filtering)” (this appears where the “Read” and “Apply Group Policy” permissions are assigned to a delegate  “Custom” (this appears where a custom set of permissions, including the use of a “Deny” permission, is assigned to a delegate)  It is possible to delegate the linking of a GPO to a potential point of implementation, and the re-arrangement of the priority for application of multiple GPOs at a container, via the assignment of the “Read” and “Write” “gpLink” permissions on the “gpLink” property of a suitable container object, such as a custom OU. Note that the assignment of this permission permits a delegate to link any existing GPO to the container with the assigned permission, regardless of ownership of the GPO. The assignment of this permission on the “gpLink” property of a container also permits the delegate to:  Enforce a GPO at the primary or secondary point of implementation  Enable or disable a link for a GPO Using the above information, execute the following:  Determine and document the minimum permissions / rights / group memberships required by delegates to execute the creation, modification, and deletion administration tasks on GPOs within the domain  Determine and document the required scope of implementation of DOC permissions  Determine and document the required scope of application of DOC permissions (which GPOs a delegate may generate and administer, based upon, for example, the function or categories of GPOs (using the GPO design model for the ORMI) and so on.)  Determine and document the delegates to receive the identified DOC permissions, rights, group memberships, and so on (identified as either specific individuals or categories of types users, based upon their metadata, such as job function and so on.)  Determine and document the total scope of GPO administration tasks the required permissions will grant the delegate, beyond the minimum required permissions. 5.9.5. Determination of the Design Requirements for the Assignment of DOC Permissions Execute this step after: • Supplying the process “design of an OU infrastructure” with the following information: ♦ The details of the object classes / instances of objects, and their properties that require administration ♦ The list of object administration tasks that require delegation ♦ The delegates for each identified object administration task ♦ The DOC requirements (permissions, rights, and group memberships) for each delegate to permit their execution of their delegated tasks ♦ The scope of implementation and application of the DOC requirements for each required object administration task

Page 137 of 354

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

© 2004 Mustan Bharmal • Receiving from the process “design of an OU infrastructure” the following information: ♦ The number, type (admin / placeholder), structure, and relationships of the OUs within the supporting OU infrastructure for the ORMI ♦ The contents of each required OU Consider the following when determining the vehicle(s) and methods for assignment of the identified DOC requirements to the delegates for each object administration task: • Factor B4: Understanding the assignment of DOC requirements ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the concept of assignment of DOC requirements to identified delegates within a DOC infrastructure. ♦ 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 is to determine the vehicles and methods to assign the identified DOC requirements to the delegates for each object administration task. The process “design of an OU infrastructure” has supplied an OU infrastructure that supports the implementation of the DOC permissions, based upon compliance with specific criteria. The DOC requirements, identified from previous steps in this process, will list the permissions and their scope of application, and the group memberships required by delegates. This information requires translation into vehicles and / or methods to assign these requirements to the identified delegates. • Factor A12: Determination of the vehicle requirements for assignment of DOC permissions ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the list of DOC permissions and the target security principals (delegates), and  Wishes to determine the vehicle requirements to assign DOC permissions to the target delegates ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with both of the above criteria within an organisation: It is possible to assign DOC permissions to delegates:  Individually, by generating access control entries for each required delegate to the appropriate access control lists  Collectively, by generating a access control entries for security groups, containing delegates with exactly similar delegation requirements, to the appropriate access control lists Where the number of delegates for a single object administration task exceeds a threshold criteria, it is recommended that a security group is used, where possible, to assign the DOC permissions.

Page 138 of 354

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

© 2004 Mustan Bharmal

The onus is with the organisation to determine the appropriate threshold criteria for the use of security groups to assign DOC permissions. This design methodology hence proposes the following approach to the determination of the vehicles for assignment of DOC permissions:  Firstly, analyse all of the DOC requirements and their corresponding recipient delegates. Identify within this list, similarities in delegation requirements and permissions. For example, it may be possible to identify a group of delegates that all collectively share two or more exactly similar object administration tasks and permission requirements.  Then, within each identified groups of delegates, identify those delegates that reside within a trusted internal or external domain. These delegates must hence be “brought” into this domain, to receive the permissions on the local Active Directory objects that require administration, via a Global or Universal security group. Where it is possible to identify the requirement to assign DOC permissions to “external” delegates (external to this domain), then create two categories (“external” and “internal”), and distribute all delegates amongst the respective categories.  The delegates within the “external” categories require collation into an appropriate security group in the trusting domain, and either nested into an appropriate security group in this domain, or directly assigned the required DOC permissions. The selected security group design model chosen to support the ORMI (see process “design of a security group infrastructure” influences these options.  The delegates within the “internal” category require collation into an appropriate security group, as dictated by the design model for security groups that supports this ORMI. Using the above information and approach, execute the following:  The threshold criteria for the use of custom security groups to assign DOC permissions  Lists detailing the groups of delegates with exactly similar DOC requirements  The list of delegates within the “internal” and “external” categories  The security group requirements (list of delegates for each required security group) for the “internal” and “external” categories Supply the process “design of a security group infrastructure” with these design requirements for a supporting security group infrastructure. • Factor A13: Determination of the methods for assignment of DOC requirements ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement to assign delegates membership to one or more builtin security groups, to permit execution of their delegated object administration tasks, and  Wishes to determine the appropriate method(s) for assignment of these DOC requirements ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation:

Page 139 of 354

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

© 2004 Mustan Bharmal

Where there is a requirement to add user account objects for delegates to one or more of the built-in security groups, such as “Account Operators”, it is necessary to determine the appropriate method to manage this operation. When determining the method(s) for assignment of these DOC requirements, consider the following:  It is possible to add security principals to one or more of the built-in security groups via the following methods:  Manual addition of each individual delegate / security group to a built-in security group  The use of the GPO policy setting “Restricted Groups” to manage the membership of the built-in and custom security groups  The number of delegates that require addition to one or more built-in security groups will dictate the method employed. Where the number of delegates that require addition to one or more built-in security groups exceeds a threshold value, then this design methodology recommends employment of the “Restricted Groups” policy setting within a GPO to assign and manage group membership. The onus is with the organisation to determine the appropriate threshold value, where required.  The majority of built-in security groups that facilitate the delegation of object administration tasks require careful control and supervision. The use of the “Restricted Groups” GPO policy setting will automatically manage the membership of the controlled security groups. Using the above information, execute the following:  Determine and document the threshold criteria for the use of the “Restricted Groups” GPO policy setting, based upon:  The number of delegates that require management  The number of built-in security groups that require management  The security risks associated with compromises to the membership of the built-in security groups  Determine and document the required method(s) for managing built-in security group membership, as a component of a DOC infrastructure for the ORMI  Where there is a requirement to employ the GPO “Restricted Groups” policy setting, determine the required policy configuration, and pass to the process “design of a GPO infrastructure”. 5.9.6. Determination of the Point(s) of Implementation of the DOC Permissions Consider the following information when determining the point(s) of implementation for the identified DOC permissions: • Factor B5: Understanding points of implementation of DOC permissions ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the concepts behind the determination of the points of implementation of DOC permissions ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation:

Page 140 of 354

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

© 2004 Mustan Bharmal

Permissions assigned to delegate one or more specific object administration tasks have the following components:  The target security principal(s) for the permission  The object class targeted by the permission (controlled via use of the “Apply onto:” field in the “permission entry for xyz” dialog box)  The target property / properties of the object class for the permission(s)  The type of permission (read, write, allow, deny (where appropriate), and so on.)  The point of implementation of the permission The previous steps within the process have determined all of the above information except the point of implementation of the permission. When implementing permissions within an Active Directory domain, consider the following:  It is possible to implement a DOC permission at one of two types of implementation points:  On a container (such as a custom OU) that contains the target objects for the DOC permission  On the actual target objects for the DOC permission  The implementation of permissions on a container will result in the receipt of the ACEs by all objects (regardless of the defined scope of application of the permission) within that container, and within all directly subordinate containers and their objects. However, only objects within the defined scope of application of the ACE will utilise the permission.  It is not possible to target DOC permissions to specific instances of an object class that requires administration by an assigned delegate, but only entire object classes. Hence, the implementation of DOC permissions is a primary influential factor in the design of the supporting OU infrastructure.  The manual and proactive implementation of DOC permission onto individual instances of an object and aspects of the object is inefficient where it is possible to identify a large number of objects to receive these permissions. It is important to note that an organisation may design a solution to perform “automatic” or spontaneous (unplanned and hence reactive) delegation of control, onto specific objects. This approach may hence negate the requirements to design an OU infrastructure to support the implementation of DOC permissions. For example, an organisation may design a web-based solution that provides the ability for managers within an organisation to reset the password for user accounts assigned only to direct reports of the manager. The use of the “managed by” and “direct reports” attributes of user account objects supports the dynamic retrieval of this information, via an LDAP enabled application, which can present a manager with a list of his / her direct reports in a suitable web page. Selection of a direct report to reset the password will prompt the modification of the access control list on the selected user account object, to assign the manager the appropriate permission to reset the password. However, although the design and implementation of these types of simple delegation of control solutions, to empower users, is beyond the scope of this process and design methodology, it is important to consider such alternatives.  The objectives for selection of a point for implementation of a DOC permission are:  To minimise the repetitive re-application of the same required permissions, and

Page 141 of 354

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

© 2004 Mustan Bharmal

 To minimise or avoid the use of "deny" permissions or “block inheritance” of permissions to control the required scope of application of the DOC permissions • Factor A14: Determination of the point of implementation for all required DOC permissions ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the point of implementation for all required DOC permissions. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: To support the objectives for this step outlined above, this design methodology proposes the following approach to determine the point of implementation for DOC permissions:  Identify the target object class for the permission  Identify the distribution of instances of the target object class that require the DOC permission amongst the OUs within the supporting OU infrastructure  Select a point of implementation and evaluate the following criteria to determine its status as a potential point of implementation for the DOC permission:  Would implementation of the DOC permission at the selected point of implementation apply the permission to all of the target instances of the object class? • If so, then proceed to the next criteria • If not, then determine the number of additional points of implementation for the DOC permission to target the remaining instances of the object class. If there is a requirement to use, for example, more than two additional points of implementation of the DOC permission, then (where possible) select another point of implementation that is capable of targeting all required object instances.  Does the supporting OU infrastructure support the requirements to control scope of application of the DOC permissions, or is there a requirement to employ the “deny” permission and / or “block inheritance” of permissions on OUs? • If so, then re-evaluate the design of the supporting OU infrastructure, or select another potential point of implementation • If not, then define the selected point of implementation as a “potential point of implementation” for the DOC permission  Once identified the potential points of implementation for all required DOC permissions, evaluate the following criterion to finalise the required point of implementation:  Does an analysis of each potential point of implementation within the boundary of the ORMI reveal any violations to the threshold criteria (defined within the process “design of an OU infrastructure”) for the maximum number of GPOs and DOC permissions implemented on an OU?  If there is a violation, then re-evaluate the point of implementation for the DOC permissions at that container.

Page 142 of 354

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

© 2004 Mustan Bharmal

 If it is not possible to identify a violation of the threshold criteria for each potential point of implementation, then finalise these points of implementation for the required DOC permissions. Use the above approach to execute an analysis to determine and document the point of implementation for all required DOC permissions within the DOC infrastructure. 5.9.7. Generation of the Design for a DOC Infrastructure Consider the following when generating the design for the DOC infrastructure to support the ORMI for this domain: • Factor D1: Generation of the design for a DOC infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand and generate the components of the design for a DOC infrastructure. ♦ 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 design for a DOC infrastructure is comprised of the following components:  A detailed design document, identifying the following:  The object classes within the scope of the DOC infrastructure for this ORMI  The requirements for the administration of aspects of the in-scope object classes  The delegates for the identified object administration tasks  The specific delegation of control requirements for each in-scope object class  The determination of the point of implementation of the required DOC permissions  A diagram illustrating the point(s) of implementation of all required DOC permissions and the following:  The target object classes  The aspects of the object classes that requires delegation of administration  The delegates / vehicle to target the delegate to receive the DOC permissions It is imperative that each element that generated and influenced the design for a DOC infrastructure is justifiable and auditable, to produce a consistent and functioning DOC infrastructure. Use the above to generate a design for the DOC infrastructure required to support the ORMI for this domain

Page 143 of 354

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

© 2004 Mustan Bharmal

6.

Design of a Security Group Infrastructure
All organisations executing the design and deployment of a Windows Server 2003 Active Directory domain must consider the design and use of custom security groups for object and resource management. This process requires execution a minimum of once for this domain, or once for each required object and resource management infrastructure for this domain.

6.1.

Process Objective The objective of this process is to assist an organisation in the generation of a design for the implementation of a security group infrastructure to support access control and object management requirements for “local” resources, services, and objects respectively. Note that it is not the objective of this process to design custom security groups for “remote” access control and object management. These requirements may be determined and designed following the implementation of the security group infrastructure into the production environment, using the Active Directory Management Plan (volume 2 of design methodology) process “design of an ORMI Management Plan”. The process to design the security group infrastructure for an ORMI will: • Identify the access control requirements for resources and services within the boundary of an ORMI • Select and design one or more types of security group design models • Use the selected types of design models to generate custom security groups to support: ♦ The identified object administration requirements via GPOs and DOC permissions, and ♦ The identified access control requirements for resources and services within the boundary of an ORMI The design of a security group infrastructure for an Active Directory domain must address several variables. This design methodology proposes the use of design models for security groups to address and support specific variables within the design, and hence permit the generation of a consistent and understandable design for a security group infrastructure. The remaining variables that require addressing must be determined during the execution of this process. The background information section below discusses the variables that this process addresses.

6.2.

Process Scope The following factors define the scope of this process: • The number and types of resources and services an object and resource management infrastructure within this domain is required to support and provide access control. • The scope of the requirements for object management within an ORMI using GPOs and DOC permissions • The logical distribution of security principals that require membership to custom security groups generated by this security group infrastructure

Page 144 of 354

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

© 2004 Mustan Bharmal 6.3.

Background Information Prior to execution of this process to design a security group infrastructure for an ORMI within this domain, it is important to understand the following: 1. 2. 3. The concepts and logic that form the foundation for the design approach, proposed by this design methodology, for the design of a security group infrastructure The variables that require addressing to generate a design for a security group infrastructure The variables addressed by security group design models

6.3.1.

Proposed Approach for Process to Design a Security Group Infrastructure The following statements provide the foundation and logic for the approach this design methodology proposes for the design of a security group infrastructure for an ORMI within this Active Directory domain: • The primary functions of a security group infrastructure are: ♦ To facilitate the management and control of access to resources ♦ To facilitate the management of Active Directory objects via GPOs and DOC permissions • Services and resources, which require access control, typically operate on servers and other computers within an organisation. This design methodology hence defines the scope of services and resources that may require access control as those that operate and reside only upon computers within the boundary of the ORMI. • Note that the security group infrastructure may support security principals inside and outside of the boundary of the ORMI. • Hence, to provide the foundations for the design of the custom security groups, the approach proposed for the execution of this process is required identify the following: ♦ The access control requirements for services and resources within the scope of influence of the ORMI ♦ The requirements for administration of objects within the boundary of the ORMI within this domain, using GPOs and DOC permissions ♦ The design model requirements for the controlled generation of custom security groups within the security group infrastructure for an ORMI

6.3.2.

Variables in the Design of a Security Group Infrastructure The design of a security group infrastructure is required to identify and address the following nine variables: 1. 2. 3. The requirements for custom security groups to support access control for resources and services within the boundary of an ORMI The requirements for custom security groups to support object management within an ORMI using GPOs and DOC permissions Based upon identified requirements for custom security groups, the actual / potential security principals (users and computers) that will be members of the custom security groups

Page 145 of 354

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

© 2004 Mustan Bharmal

4. 5. 6.

The logical location(s) of the actual / potential members, in relation to the point of creation of the custom security groups The function for each required custom security group (for permission access (“resource group”) or for security principal collation and transportation (“account group”)) The scope (Domain Local, Global, Universal) for each required custom security groups, to reflect its function and the logical location(s) of the actual / potential members of the group The total number of custom security groups required The requirements to nest custom security groups The name for each required custom security group

7. 8. 9. 6.3.3.

Design Variables Addressed by Design Models for Security Groups From the above nine variables, design models for security groups will identify and address the following three variables: 1. 2. The required functions for the custom security groups (for permission access (“resource group”) or for security principal collation and transportation (“account group”)) The scope (Domain Local, Global, Universal) for each required custom security groups, to reflect its function and the logical location(s) of the actual / potential members of the group The requirements to nest custom security groups

3. 6.4.

Process Approach When executing the process to design a security group infrastructure for an ORMI, the recommended approach is to “keep it simple”. This recommendation applies to the following aspects of the design for a security group infrastructure: • The number of types of design models for security groups designed and employed to generate the security group infrastructure • The number of custom security groups generated This approach considers the administrative, operational, and financial connotations associated with the design and maintenance of multiple (standard or hybrid) design models for groups, and hence implies the consideration for only one or a few group design models. (Note, for this process, “few” implies three or less, and “multiple” implies more than three group design models) Where an organisation has multiple group design models that span multiple domains and forests (internal and external to the Windows Server 2003 Active Directory infrastructure for an organisation), then it becomes very difficult to understand the function of the security groups generated by all of these design models. It is only possible to understand the function of a security group where the naming convention for the security groups reflects the design model that generated the groups (see later for details). To support these recommendations for the design of a security group infrastructure, this process states the following null hypothesis: “The selection and design of only a few types of standard or hybrid design models for security groups can adequately meet all the security group requirements for an ORMI without the need to design multiple standard or hybrid design models for security groups.”

Page 146 of 354

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

© 2004 Mustan Bharmal

After stating this null hypothesis, it is necessary to execute an analysis to disprove it and hence determine the number and type(s) of standard / hybrid design models for security groups required for the Active Directory domain. To reflect the requirements to disprove this null hypothesis, and to respect the presence of inter-process dependencies between the four components of an ORMI, this design methodology proposes the following approach to the design for a security group infrastructure: 1. 2. Determine the resource and service access control requirements the security group infrastructure is required to support Receive from the processes “design of a GPO infrastructure” and “design of a DOC infrastructure”, the custom security group requirements to support the GPO and DOC infrastructure for the ORMI, and the following information: a. The actual / potential security principals (users and computers) that will be members of the custom security groups b. The logical location(s) of the actual / potential members, in relation to the point of creation of the custom security groups 3. 4. 5. Understand the structure and components of the standard group design models, and the possible variances in these models to produce hybrid design models for security groups. Determine the requirements for multiple standard or hybrid design models for security groups within an ORMI. Where one or more standard / hybrid design models for security groups are required, determine the design requirements for these multiple group design models, to include: a. The boundary and scope for each group design model b. The relationships between the group design models within the ORMI c. The rules for the generation of security groups by a group design model

d. The naming convention requirements for multiple group design models 6. 7. Generate the design for each required group design model Use the selected design model(s) to determine the following design requirements for the security group infrastructure: a. The required functions for the custom security groups (account / resource groups) b. The scope (Domain Local, Global, Universal) for each required custom security groups, to reflect its function and the logical location(s) of the actual / potential members of the group c. The total number of security groups required to support the following: i. ii. The identified resource and service access control infrastructure for the ORMI The GPO infrastructure for the ORMI, and

iii. The DOC infrastructure for the ORMI d. The requirements to nest custom security groups e. The logical location(s) within the ORMI for the generation of the required custom security groups

Page 147 of 354

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

© 2004 Mustan Bharmal

8. 9.

Use the object naming model for security groups (from the Organisation-Wide Active Directory Plan) to assign a name to each required custom security group Generate the design for the security group infrastructure

10. Pass to the process “design of a GPO infrastructure” the names of the security groups required to support the GPO infrastructure for the ORMI 11. Pass to the process “design of a DOC infrastructure” the names of the security groups required to support the DOC infrastructure for the ORMI 6.5. Process Components Based upon the above approach, the process to design a security group infrastructure for an ORMI within this domain is composed of the following components: • Determination of the resource and service access control requirements the security group infrastructure is required to support • Understanding the structure and components of the standard and hybrid design models for custom security groups • Determination of the number of group design models required • Determination of the design requirements for each required group design model • Generation of the design of each required group design model • Determination of the design requirements for the security group infrastructure • Generation of the design for the security group infrastructure 6.6. Deliverables of Process Components This process will have the following deliverables: • Identification of the details of the resource and service access control requirements within an ORMI that require support via a security group infrastructure • The determination of the number and type(s) of group design models required to support the generation of the security group infrastructure • The design requirements for each required group design model • The design of each required group design model • The design requirements for the security group infrastructure • The design of the security group infrastructure for an ORMI 6.7. Inter-Component Dependencies Each component of this process will have the following inter-component dependencies:

Page 148 of 354

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

© 2004 Mustan Bharmal

Domain Plan – Inter-Component Dependencies for Process to Design a Security Group Infrastructure START
Understanding the structure and components of the standard and hybrid design models Determination of the resource and service access control requirements Determination of the number and types of group design models required

Determination of the design requirements for each required group design model

Generation of the design of each required group design model

Determination of the design requirements for the security group infrastructure

Generation of the design of the security group infrastructure
© 2004 MU STAN
SHI R

BHAR

MAL

6.8.

Process to Design a Security Group Infrastructure
Domain Plan – Process to Design a Security Group Infrastructure
Is there a requirement for a metadata-based access control infrastructure?

START

Execute B1

Execute A1 – A2

NO YES Execute

Execute A4

Execute B2

Execute A16 – A18

Execute B4

Execute A5 – A10

NO Are there any relationships between two or more group design models?

A3

Execute B5

Execute A15

YES

Execute A11 – A14

Execute B3

Execute A19

Execute D1 - D2

Execute B6

Execute A20

Execute D3

Pass names of appropriate security groups to processes to design a GPO and DOC infrastructure for the ORMI

END
© 2004 MU STANS HI
R

BH

ARMAL

6.9.

Process Considerations Consider the following information when designing a security group infrastructure to support all of the in-scope security group requirements for the ORMI within this domain. Presented within the following seven sections are the considerations for this process: 1. 2. 3. Considerations for the determination of the resource and service access control requirements Considerations for the structure and components of the standard group design models Considerations for the determination of the number of group design models required for an Active Directory domain

Page 149 of 354

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

© 2004 Mustan Bharmal

4. 5. 6. 7. 6.9.1.

Considerations for the determination of the design requirements for each required group design model Considerations for the design of each required group design model Considerations for the determination of the design requirements for the security group infrastructure Considerations for the design of a security group infrastructure

Determination of the Resource and Service Access Control Requirements When determining the access control requirements for resources and services within an ORMI that require support by the design of a security group infrastructure, the following approach is proposed: 1. 2. Determine the boundary and scope of the access control infrastructure for resources and services Determine the access control and corresponding security group requirements for the inscope resources and services

Based upon the above approach, the following two sections present the considerations for the execution of this step within this process: 1. 2. 6.9.1.1. Considerations for the determination of the boundary and scope of the access control infrastructure for resources and services Considerations for the determination of the access control requirements for the in-scope resources and services Determination of the Boundary and Scope of the Access Control Infrastructure Consider the following when determining the boundary and scope of the access control infrastructure: • Factor B1: Understanding access control requirements for resources and services ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the concept of access control for resources and services. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The resources and services that operate on computers, which reside within the scope of an ORMI, define the boundary and scope of an access control infrastructure for the ORMI. Hence, prior to the determination of the boundary and scope of an access control infrastructure for resources and services, it necessary to understand the following concepts:  The types of resources and services that may require access control  Proactive and reactive access control management  Resource and service categorisation  The forms of support for access control a security group infrastructure can provide for the in-scope resources and services

Page 150 of 354

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

© 2004 Mustan Bharmal

When determining the access control requirements for resources and services, it is necessary to first identify the resources and services that require access control, and then their specific requirements for access control. As the objective of this process is to design a security group infrastructure, only those requirements for access control that require support via security groups need identification. The following are examples of resources and services that may require access control:  Resources such as files, folders, applications and application data, databases, print queues, directory data, and so on.  Services such as intranet and Internet services, electronic messaging services, directory services, and so on It is possible to identify two forms of access control management, which are “proactive” and “reactive” access control. Proactive access control assigns security principals access to resources and services to support undetermined and predictable access requirements. Reactive access control assigns security principals “on demand” access to resources and services to support determined and unpredictable access requirements. The design for the implementation of a security group infrastructure is required to reflect the identification of proactive access control requirements, based upon predicted access requirements. Predictable access requirements permit the identification of the design requirements for custom security groups prior to deployment of the Active Directory infrastructure within the production environment. Reactive access control requirements form the majority of demands to design and generate custom security groups within an implemented Active Directory infrastructure. It is necessary to categorise access control requirements as proactive and reactive requirements, in order to identify the in-scope resources and services. Hence, this design methodology recommends that only access control requirements, identifiable as “proactive” based upon compliance with specific criteria, may influence the design for the implementation of a security group infrastructure. The next factor will define the criteria for the selection of resources and services, and their corresponding proactive access control requirements, which will influence the design of the security group infrastructure. The following are examples of the forms of support a security group infrastructure can provide for the access control requirements of resources and services:  The collation of security principals (users, computers, and other security groups) into a security group, and the inheritance of assigned access control permissions and rights to all members of a security group, presents a single point for administration of the access control requirements of multiple security principals. This hence greatly simplifies the administration process and reduces associated overheads.  Where an organisation will manage security group memberships manually, and not automatically or dynamically via scripts and applications, then the relatively stable security group membership validates their use in the generation of audit trails for access control. • Factor A1: Determination of the boundary and scope for the access control infrastructure of an ORMI

Page 151 of 354

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

© 2004 Mustan Bharmal ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the boundary and scope for the access control infrastructure of an ORMI. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology proposes the following approach to determine the boundary and scope for the access control infrastructure of an ORMI that requires support via a security group infrastructure:  Determine the criteria for the selection of in-scope resources and services  Identify all of the potential resources and services that:  Operate / will operate on computers within the scope of the ORMI, and  Comply with the defined criteria for the selection of in-scope resources and services When determining the criteria for the selection of in-scope resources and services, consider the following:  The objectives for the criteria are support the identification of only those access control requirements, for in-scope resources and services, which are classifiable as “proactive access control requirements”. Identification of resources and services that comply with the criteria will hence identify the in-scope resources and services for the access control infrastructure, and thus its boundary and scope.  The following are examples of criteria for the selection of in-scope resources and services:  A resource or service has long term (for example, more than 6 months) and predictable requirements for access control. For example, there is a requirement to control access to a SQL database designed for use by only a specific group of security principals, and hence the database has a long term and predictable access control requirement.  It is possible to support the predetermined access control requirements for a resource or service via a simple set of criteria, based for example on values for security principal metadata.  The access control requirements for a resource / service are fairly stable and do not require frequent modifications (for example, one or more times a week)  There is a medium to high risk potential for a compromise to the access control requirements for a resource / service  A compromise to the access control requirements for a resource / service may have serious financial / administrative consequences  Where it is possible to identify compliance will all or most of the above criteria for a resource or service, then use the proactive access control requirements for that resource or service to influence the design of the supporting security group infrastructure.  The onus is with the owner(s) of the ORMI to define their specific criteria and definitions for the selection of in-scope resources and services. When determining the in-scope resources and services, and hence the boundary and scope of the access control infrastructure, consider the following:

Page 152 of 354

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

© 2004 Mustan Bharmal

 A security group infrastructure has the following two primary facets to its function:  To support access control and object management for “local” resources, services, and objects.  To support access control and object management for “non-local” or “remote” resources, services, and objects. This facet of a security group infrastructure involves the collation of security principals into security groups for assignment of permissions to remote resources, services, and object.  As the objective of this process (defined within the “Process Objective” section) is to support access control and object management for “local” resources, services, and objects, the scope of the search for in scope resources and services is limited to those that operation only on computers represented within the boundary of the ORMI.  The identification of the boundary and scope of the access control infrastructure will also contribute the definition of the “actual” and “inbound virtual” boundaries of each group design model required to support access control for resources and services. See later for details of group design models and the definition of their logical boundaries. Using the above approach and information, execute the following:  Define and document the criteria to qualify the selection of in-scope resources and services  Determine and document the in-scope resources and services, which operate on “local” computers and comply will all or most of the defined criteria, and hence the boundary and scope for the access control infrastructure 6.9.1.2. Determination of the Access Control and Security Group Requirements Consider the following when determining the access control and corresponding security group requirements for in-scope resources and services: • Factor A2: Understanding, and determining the requirements for, a metadata-based access control infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the boundary and scope for the access control infrastructure, and  Wishes to understand the concept of metadata-based access control, and determine the requirements for the design of a metadata-based access control infrastructure for an ORMI. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology introduces the concept of “metadata-based access control”, and the design of a “metadata-based access control infrastructure”, as a means to determine and manage access control requirements within an ORMI. For each resource and service that requires access control, it may be possible to identify the need to support granular access control requirements, which reflect different levels or grades of access to that resource or service.

Page 153 of 354

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

© 2004 Mustan Bharmal

Each identifiable level or grade of access control may have criteria for access, with each criterion designed to reflect one or more metadata values of the security principals that require access. For example, there may be the requirement to grant only “Read” access to a SQL database only to those security principals within an office department or physical location within the organisation, but “Read” and “Write” access to administrators of the database. In this example, department and physical location are metadata values of the security principals. One of the most commonly used metadata values for access control is the role of a security principal within an organisation, expressed by, for example, a job title, alignment with a divisional structure within an organisation, and so on. However, within most organisations, the use of this single metadata value provides insufficient granularity for managing access control. Instead, there is typically the requirement to employ two or more metadata values for security principals to grant and control their access to resources and services. When determining the requirements for the design and use of a metadata-based access control infrastructure, consider the following:  A metadata-based access control infrastructure is a form of proactive access control management, where resource and service owners proactively identify and assign access to their resources / services to security principals, based upon compliance with access control rules.  It is not possible to use a metadata-based access control infrastructure for reactive access control. This is because reactive access control supports scenarios where there is an unpredicted requirement to assign security principals access to a resource or service, and the security principals may not conform or support the required metadata for access. For example, a metadata-based access control infrastructure defines a rule for access to a SQL database, which permits read access to the database only for security principals with a specific job title and membership to a specific department. This proactive form of access control permits the database owner to seek out all security principals that comply with these criteria and assign the appropriate access, via membership to a custom security group assigned the “Read” permission. It is hence not possible for this metadata-based access control infrastructure to support reactive access control requirements, unless the unpredicted access requirement exactly conforms to the predefined rules for access to the resource or service the rules support. Unless there is absolute conformity, it is not possible to grant access to the resource / service. The probability that a reactive access control requirement conforms exactly to predefined rules for access control is very low.  It is possible to use metadata values for security principals, such as job title, location, membership to divisional structures, and so on, to define rules for assignment of access to in-scope resources and services, based upon categories for metadata values.  The following are examples of advantages typically associated with the design and use of a metadata-based access control infrastructure within an ORMI:  The use of security principal metadata permits abstraction from the management of access control for individual security principals.  It is possible to port the rules defined by a metadata-based access control infrastructure to applications and scripts that dynamically generate custom security groups and populate the groups based upon the rules.  The security groups generated to support a metadata-based access control infrastructure are functional and hence simple to support and troubleshoot.

Page 154 of 354

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

© 2004 Mustan Bharmal

 The proactive approach to access control management permits the generation of a stable security group infrastructure to reflect and support predictable access control requirements within an ORMI.  The following are examples of disadvantages typically associated with the design and use of a metadata-based access control infrastructure:  Proactive access control typically represents only a percentage of the access control requirements for resources and services within an organisation, with the majority represented by reactive access control. A metadata-based access control infrastructure hence has only a limited scope of application within an ORMI, as it cannot support reactive access control requirements.  It is necessary to conduct an extensive analysis of all in-scope resources and services within an ORMI to identify all proactive access control requirements. Where an organisation does not wish to consider the design and use of a metadatabased access control infrastructure, then it is necessary to consider the use of alternatives. This design methodology provides the following examples of alternatives, to determine the design requirements for the implementation of a security group infrastructure to support resource and service access control:  The identification of only the top priority access control requirements for resources and services within an ORMI, followed by a purely reactive approach to access control management.  Port only those custom security group requirements currently supported by a legacy directory service to the new custom security group infrastructure for an ORMI within this Windows Server 2003 Active Directory domain. Using the above information, execute the following:  Determine and document the requirement for the design and use of a metadatabased access control infrastructure, or  Determine and document the requirements to use alternative access control methods to support and influence the design of the security group infrastructure. • Factor A3: Determination of the design requirements for a metadata-based access control infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the design and use of a metadata-based access control infrastructure for an ORMI, and  Wishes to determine the design requirements for this infrastructure ♦ 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 of a metadata-based access control infrastructure, consider the following:  A metadata-based access control infrastructure is comprised of a set of rules, which control the assignment of access permissions to security principals, for each inscope resource and service that supports proactive access control.

Page 155 of 354

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

© 2004 Mustan Bharmal

 The criteria defined earlier dictate compliance with proactive access control, and the rules reflect one or more metadata aspects and their values for the target security principals.  Hence, the components of a metadata-based access control infrastructure for an ORMI are:  The in-scope resources and services that require support via the metadatabased access control infrastructure  The grades of access control available for a resource or service that require assignment to one or more security principals  The metadata properties and their required values of the target security principals for each required grade of access to a resource or service  The rules for assignment of access to a resource or service, at each supported grade of access, based on the metadata properties and their values of the target security principals  The previous step in this process has identified the resources and services within the boundary and scope of an access control infrastructure.  For each in-scope resource and service, it is necessary to identify the potential grades of access the resource or service offers, and the grades of access that require access control via permissions.  For example, it may be possible to identify the requirements to define for a resource, such as a folder, the following grades of access:  Read access, which permits a security principal to only read folder items, but not create, edit, or delete any folder items.  Read and Write access, which permits a security principal to read, create, and edit folder items, but not delete any folder items.  Full Control access, which permits a security principal to perform all possible actions on the folder and its contents, including deleting, moving, renaming items, and so on  To define the scope of security principals for an identified grade of access to a resource or service, it is necessary to identify one or more metadata aspects of the potential security principals that require access, which can uniquely define the required scope. This design methodology proposes the following approach for the determination of the design requirements of a metadata-based access control infrastructure:  Select an in-scope resource or service that requires access control  Identify the scope of security principals that may / will require access to that resource or service  Based upon the identified scope of target security principals, determine the number of grades of access (note that there may only be one grade of access) the resource or service must support  For each required grade of access, determine the following:  The scope of security principals that will require access to each identified grade of access

Page 156 of 354

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

© 2004 Mustan Bharmal

 The metadata properties and values of the scope of security principals that will define that scope  The access control rule for the grade of access  Repeat the above process for each required resource and service within the boundary and scope of the access control infrastructure Using the above information and approach, execute the following:  Determine and document the potential scope of target security principals for access control permissions on each in-scope resource and service.  Determine and document the number of grades of access required to support variances in the scope of target security principals.  Where it is possible to identify the requirement to define multiple grades of access to resource or service, then determine and document the design requirements for each required grade of access. • Factor A4: Determination of the custom security group requirements ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the design requirements for either a metadata-based access control infrastructure or an alternative approach, and  Wishes to determine the requirements for the design of custom security groups to support the required metadata-based access control infrastructure / alternative approach ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The design requirements determined for the metadata-based access control infrastructure have identified the following for each in-scope resource and service:  The number of grades of access each resource and service provides, and the scope of access for each required grade  The potential scope of target security principals for assignment of the access control permissions to each identified grade of access It is possible to identify, using the information determined above, the requirements for the design of a custom security group infrastructure, to support the assignment of the identified proactive access control requirements. When determining the design requirements for custom security groups to support the metadata-based access control infrastructure, consider the following:  This design methodology proposes the following approach to identify the custom security group requirements for a metadata-based access control infrastructure:  Define the criteria for the use of a custom security group to manage the assignment of permissions to multiple security principals, as opposed to the assignment of permissions to individual security principals.  Analyse the access control rules for all of the in-scope resources and services, and identify patterns of metadata property and value requirements to support access to the resource / service. Where possible, generate categories for the

Page 157 of 354

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

© 2004 Mustan Bharmal

access control rules, based upon their component metadata properties and values.  Identify groups of security principals that exactly comply with each defined category.  Evaluate the groups of security principals against the criteria for the use of custom security groups and determine, where applicable, the design requirements for the custom security groups.  When determining the criteria for the use of custom security group to manage the assignment of access permissions to resources and services, consider the following:  The criteria for the use of custom security groups have a significant impact on the scope and operation of the security group infrastructure. This is because, within most organisations, support for resource and service access forms the majority of security group requirements within a security group infrastructure.  When determining the criteria for the use of custom security groups, it is important to understand the long-term consequences of the criteria, and the requirement to attain a balance in security group requirements. The definition of too “lenient” criteria, which thus supports the generation of a large number of custom security groups, will lead to an increase in administrative overheads for the security group infrastructure. The definition of too “severe” criteria, which only supports the generation of a very few custom security groups, will also lead to an increase in the administrative overheads, for the administrators of the resources and services that require access control.  The following are examples of criteria for the use of custom security groups, as opposed to assignment of access permissions to individual security principals, are: • The number of security principals that require assignment of access permissions to resources and services. Where there is a unique requirement to assign access permissions on a resource or service to only, for example, a few (one to five) security principals, then it may be superfluous to generate a custom security group just to support this small number of security principals. Note that this criterion requires consideration alongside all other criteria, and not exclusively of other criteria. • The requirement to support one or more group design models, and hence the requirement to create, for example, the following types of security groups: ♦ “Resource” groups (such as “Domain Local” security groups) to exclusively support the access control requirements of specific in-scope resources and services ♦ “Account” groups (such as “Global” and “Universal” security groups) to transport security principals across trust relationships and / or to nest the security groups into “resource” groups. • The requirement to identify a group of security principals for management based upon their access requirements to resources and services. A security group provides two primary functions, to collate security principals for collective identification and management, and (as a security principal) to receive permissions on behalf of the members of the group. The first function of any security group may be invaluable in the execution of administrative tasks for a large number of security principals, especially where the name for

Page 158 of 354

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

© 2004 Mustan Bharmal

a custom security group reflects its function, and thus may reflect the function of the members.  The onus is with the owner(s) of the ORMI to define the appropriate criteria for the design and use of custom security groups.  Knowledge of the rules for access control for the in-scope resources and services provides the opportunity to define categories for these rules, based upon their constituent metadata properties and values for properties. It is then possible to employ the categories to consolidate, where possible, the individual scopes of security groups for each in-scope resource and service, into groups of security principals, and subsequent collation into custom security groups. Using the above information and approach, execute the following:  Determine and document the evaluation criteria for the use of custom security groups  Determine and document the categories for metadata-based access control rules for the in-scope resources and services  Determine and document the requirements for the design and use of custom security groups  Determine and document the potential members / function of each required custom security group, to support requirements for resource and service access control 6.9.2. Understanding the Structure and Components of Standard Group Design Models Consider the following information where there is a requirement to understand the structure and components of the four standard group design models this design methodology proposes, and the factors that will influence their selection and use within an Active Directory domain: • Factor B2: Understanding the structure and components of standard group design models ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the structure and components of the four standard group design models this design methodology proposes. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Depending upon the scope of a security group, a security group requires creation to serve one or both of the following two primary functions within an Active Directory domain:  To collate security principals that share a common requirement for resource access, and act as a vehicle for transporting these security principals, within a domain or outside of the boundary of a domain (as appropriate to the scope of the security group), into other security groups (as appropriate).  To simply the management and assignment of permissions, to local and network resources, controlled by an Active Directory infrastructure. The assignment of permissions on a resource to a security group automatically applies to all members of the security group. This design methodology identifies the following objectives for a group design model:  To identify the scope of security groups that a group design model will generate

Page 159 of 354

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

© 2004 Mustan Bharmal

 To identify the rules for nesting of security groups within a group design model  To identify the roles for security groups, as account and / or resource groups, within a group design model  To identify the security principals that a group design model will manage via a security group infrastructure  To identify the resources that a group design model will manage for access control via a security group infrastructure  To identify the rules for the generation of account security groups by an appropriate group design model Execution of all of the following components of this process will permit compliance with all of these objectives. Based upon these objectives, a group design model has the following structural components:  The rules for the creation of security groups  The rules for the nesting of security groups into other security groups within and outside of an Active Directory domain Note that all group design models (standard or hybrid) must comply with all of the following fundamental rules for the use of group design models:  The security group to receive permissions to the resources (the resource group) must be generated by the group design model and not by another group design model  Based upon this first rule, it is hence only possible to port outbound security principals (that reside within the boundary of a group design model):  Via an account group generated by the group design model (and not via a resource group generated by the group design model)  To a destination scope of security group supported by the group design model The first fundamental rule applies where, for example, a group design model does not support the “account” and “resource” group design model (see later for details). The second fundamental rule reinforces the logic for a group design model, even outside of the boundary of the group design model. This is essential to maintain consistency in strategies for management of resource access. All other constraints on the operation and function of a group design model reflect the technical limitations for the different scopes for groups within an Active Directory infrastructure. This design methodology identified four standard group design models that vary based upon the scopes of security groups (Universal, Global, and Domain Local) supported by a design model and the rules for nesting of the security groups into other security groups. The different scopes for these security groups directly influence the rules for their creation and population. The names of the four standard group design models are acronyms, based upon the first letters for the following:  “A” for “Accounts”, refers to security principals represented by user and computer account objects  “P” for “Permissions”, refers to the assignment of permissions to a security group on a local or network resource

Page 160 of 354

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

© 2004 Mustan Bharmal

 “U” for “Universal”, refers to the “Universal” security group object  “G” for “Global”, refers to the “Global” security group object  “DL” for “Domain Local”, refers to the “Domain Local” security group object The four standard group design models are hence:  “ADLP”  “AGDLP”  “AUDLP”  “AGUDLP” The “ADLP” group design model places “Accounts” into “Domain Local” security groups, and applies Permissions to “Domain Local” security groups for local and network resources:
© 2004 MUSTANSHI
R

BHAR

MAL

Accounts

Domain Local

Permissions

Figure 35.1: Illustration of the Standard “ADLP” Security Group Design Model The “AGDLP” group design model places “Accounts” into “Global” security groups, nests “Global” security groups into “Domain Local” security groups, and applies Permissions to “Domain Local” security groups for local and network resources:
© 2004 MUSTANSHI
R

BHAR

MAL

Accounts

Global

Domain Local

Permissions

Figure 35.2: Illustration of the Standard “AGDLP” Security Group Design Model The “AUDLP” group design model places “Accounts” into “Universal” security groups, nests “Universal” security groups into “Domain Local” security groups, and applies Permissions to “Domain Local” security groups for local and network resources:
© 2004 MUSTANSHI
R

BHAR

MAL

Accounts

Universal

Domain Local

Permissions

Figure 35.3: Illustration of the Standard “AUDLP” Security Group Design Model The “AGUDLP” group design model places “Accounts” into “Global” security groups, nests “Global” security groups into “Universal” security groups, nests “Universal” security groups into “Domain Local” security groups, and applies Permissions to “Domain Local” security groups for local and network resources:
© 2004 MUSTANSHI
R

BHAR

MAL

Accounts

Global

Universal

Domain Local

Permissions

Page 161 of 354

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

© 2004 Mustan Bharmal

Figure 35.4: Illustration of the Standard “AGUDLP” Security Group Design Model Note the following facts common to all four standard group design models:  All four standard design model employ the use of the “Domain Local” (DL) security group as the “resource” group (with respect only to the assignment of permissions)  All permissions on a local or network resources are assigned only to “Domain Local” security groups (and thus its members), and not to Global or Universal groups.  Within all four of these group design models, Domain Local security groups are only serving the second function for a security group. This is to simply the management and assignment of permissions, to local and network resources, which an Active Directory infrastructure controls. It is also possible to refer to the security groups created to support this function as “resource groups” (see later for details).  None of these four standard group design models supports the duplicate nesting of group scopes, such as “Domain Local” into “Domain Local”, “Universal” into “Universal”, or “Global” into “Global”. Within three of these four group design models, the Global and Universal security groups are only serving the first function for a security group. This is to collate security principals (AG or AU) and act as vehicles for transporting these security principals, within a domain or outside of the boundary of a domain (as appropriate to the scope of the security group), into Domain Local security groups. It is also possible to refer to the security groups created to support this function as “account groups” (see later for details). All four standard group design models support the use of a common scope (Domain Local) for a resource group for assignment of permissions to resources. Consequently, the three “account” and “resource” group models (AGDLP, AUDLP, and AGUDLP) all support the fundamental rules for all group design models, especially for inter-design model transportation of security principals for access to non-local resources. This support for the fundamental rules permits the generation of only one or few standard group design models. For example, two group design models, AGDLP and AGUDLP have discrete “actual” boundaries (see later for details of boundaries) of Active Directory domains (Natsum.com and Acme.com respectively). There is a requirement to permit the outbound access from Natsum.com of security principals to access resources within Acme.com. The fundamental rules of all group design models state that the security group assigned permissions to the resources must be generated by that group design model that manages the access control for that resource, and that the destination security group for an account group (from an external group design model) must be supported by the external group design model. Hence, the external group design model in this example is the “AGDLP” model for Natsum.com, and the destination model is “AGUDLP” for Acme.com. As both models use Domain Local groups as the security group assigned permissions to the “local” resources, these models are compatible and hence comply with the fundamental rules for all group design models. Note that these two design models can only interoperate if Acme.com is in the same forest as Natsum.com for this example. This is because the AGDLP model for Natsum.com can only generate Global account groups, and the “AGUDLP” model for Acme.com can only receive Global groups into a Universal group, or a Universal group into the Domain Local group. Hence, if Acme.com was in a separate forest, the Global group from Natsum.com cannot become a member of the Universal group in Acme.com, and Natsum.com cannot generate a Universal group, as the AGDLP model does not permit this.

Page 162 of 354

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

© 2004 Mustan Bharmal

Each of these four standard models has advantages, disadvantages, dependencies, and limitations on their use within an Active Directory domain. The following factors discuss each of these considerations for each of the four standard group design models presented above. Use the following information to determine the requirements for one or more of these standard group design models within an Active Directory domain. • Factor A5: Determination of the requirements for the “ADLP” standard group design model ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the requirement for the design of the ADLP group design model. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: As this ADLP group design model only employs a single scope of security group, the model does not strictly emulate the dual “account group / resource group” model. An organisation considering the use of this ADLP group design model must hence determine whether the generation of the Domain Local groups is to support the creation criteria for account groups, or the creation criteria for resource groups, and thus generate Domain Local groups:  Exclusively to support account groups collation criteria, or  Exclusively to support the criteria for the generation of resource groups, or  To support both the collation criteria for security principals, and the criteria for the generation of resource groups (to create a mixture of Domain Local groups, and not “dual-function” groups) Note that the Domain Local groups created via this ADLP design model, to support collation criteria for security principals or criteria for the generation of resource groups, are not strict “account” or “resource” groups. Group models that strictly follow the generation of “account” and “resource” groups also comply with factors such as assignment of permissions, and membership criteria for the groups. The creation criteria for account groups define categories for the collation of security principals into an account group (see later for details of collation categories for security principals). For example, there may be collation categories that state:  “Collate all security principals from a specific department into an account group for that department”  “Collate all security principals with a specific job title into an account group for the job function”, and so on. The creation criteria for resource groups define categories for the generation of resource groups to support a resource instance / type or a set of permissions on a resource type or instance (see later for details of resource categories for the generation of resource groups). For example, there may be categories for the generation of resource groups that state:  “Generate a resource group for all printer objects within each building”  “Generate a resource group for all “manage printers” permissions on printers” The use of collation categories for security principals to generate Domain Local security groups via this ADLP group design model has the following advantages:

Page 163 of 354

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

© 2004 Mustan Bharmal

 It is possible to collate security principals into groups (based upon specific categories – see later for details) and re-apply each group to multiple resources. This hence negates the requirement to change group memberships continually to meet permission requirements.  There may be fewer categories for collation of security principals than categories of resource instance / type or permission sets (see later for details). This will hence result in fewer numbers of Domain Local groups generated within an Active Directory domain.  There is a simplified model for the assignment of permissions from a resource, as there is only the requirement to select the appropriate Domain Local group (generated to support collation criteria for security principals) and assign the required permissions. There is no requirement to change group memberships to attain the required permissions. The use of collation categories for security principals to generate Domain Local groups via this ADLP group design model has the following disadvantages:  Where it is possible to identify the requirements for a large number of categories, there may be a respective requirement to generate a large number of Domain Local groups.  Each resource may have a large number of entries on its access control list, corresponding to discrete Domain Local groups generated to support collation criteria for security principals. There may hence be potential permission conflict issues, and hence administrative overheads to troubleshoot these issues, where security principals are members of multiple Domain Local groups assigned permissions to resources.  Management of permissions can become a significant administrative overhead. For example, the use of a single Domain Local group across multiple resources may suit all of the members of that group. However, where there is an explicit requirement to deny access for one individual security principal to a specific resource instance, it is only possible to achieve this requirement (using this model for generation of Domain Local groups to support collation criteria for security principals), via performing one of the following actions:  Remove that security principal from the Domain Local group. This may be undesirable as that individual may consequently lose permissions to other resources to which the Domain Local group is assigned permissions  Manually enter an explicit “deny” permission for that individual security principal. This is undesirable as it is an administrative overhead, and results in assigning permissions directly to security principals. Note that the use of the “deny” permission requires careful consideration.  Generate an alternate Domain Local group and repopulate with the same members of the initial group except the undesired individual security principal. This is undesirable as it will generate more Domain Local groups, increase administrative overheads, and complicate troubleshooting exercises. The use of resource categories to generate Domain Local groups via this ADLP group design model has the following advantages:  The use of a single Domain Local group per resource type or instance, or set of permissions for a resources type or instance, facilitates the assignment of permissions to security principals, via the identification of the appropriate Domain Local group to which a security principal will require membership. However, an administrator must change the membership of a Domain Local group (add a specific security principal) in order to assign the permissions.

Page 164 of 354

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

© 2004 Mustan Bharmal

 The use of Domain Local groups, generated to support criteria for resource groups, permits the granular assignment of permissions to security principals, depending upon the defined criteria for the generation of the resource groups. Where there is an explicit requirement to deny permissions to a specific security principal, using this resource group model, it is possible to achieve this requirement via:  Not making the security principal a member of the appropriate Domain Local group that would grant access to the resource instance / type  Removal of the security principal from the appropriate Domain Local group where already a member  Making the security principal a member of a Domain Local group generated to support a specific set of “deny” permissions on a resource type or instance The use of resource categories to generate Domain Local groups via this ADLP group design model has the following disadvantages:  Where there is a requirement to define a large number of categories for the generation of Domain Local groups, there may hence be a respectively large number of Domain Local groups to generate and manage.  The management of permissions via altering memberships of Domain Local groups may become a significant administrative overhead in the long term, especially where there is a requirement to support large numbers of security principals and criteria for the generation of resource group types. The generation of Domain Local groups, using a mixture of generation criteria for account and resource groups, has the following advantages:  The ability to use the group generation criteria for both account and resource groups within an ADLP group design model permits the generation of Domain Local groups to support:  The collation of specific security principals, which comply with collation criteria  The use of specific categories of resource types or instances, or permissions / sets of permissions on resource instances / types  The ability to generate this wide spectrum of Domain Local groups permits the generation of a functional group infrastructure more capable of supporting all the required business and technical objectives for resource access management. The generation of Domain Local groups using a mixture of generation criteria for account and resource groups, has the following disadvantages:  Unless the naming model for security groups permits clear distinction of groups based upon function and collation criteria, the resulting mixture of Domain Local groups may be confusing to manage and troubleshoot.  The combined use of criteria for collation of security principals and categories for resource groups may generate a large number of Domain Local groups, thus increasing the administrative overheads for management and use of this group infrastructure. The ADLP group design model permits the owner of the model to:  Create only Domain Local security groups within each domain covered by the specified boundary of the group design model (see later for details on the determination of the boundary of a group design model)

Page 165 of 354

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

© 2004 Mustan Bharmal

 Populate these Domain Local security groups only with individual security principals (not groups of security principals), which can be from:  Within each domain covered by the boundary of the group design model  Within the same domain as the Domain Local group, or  From any internal or external trusted domain The scope of application of the Domain Local groups generated by this ADLP group design model is hence limited to resources within the boundary of the Active Directory domain that owns the Domain Local group, and hence the name “Domain Local” or “local to that domain”. The following diagram illustrates this, where the owner of an ADLP group design model is permitted to generate only Domain Local groups, but can add individual security principals (not groups of security principals) as members to the Domain Local groups from any trusted domain, internal or external to the forest (for example, “Acme.com”). Note in the illustration below, for this example, the boundary of the “Natsum.com” domain defines the boundary of the ADLP group design model:
One-Way External Trust Relationship, where “Natsum.com” trusts “Acme.com”

The “ADLP” Group Design Model
1 1 1
ACLs

Acme.com

2
ACLs Print Queue Volume

1 Domain Local

Natsum.com.
© 2004 MUSTANSHI
R

BH

AR MAL

A.Natsum. com

B.Natsum. com

LEGEND: Security Principals from same domain / same forest / 1 trusted external domain added to Domain Local group 2 Permissions on domain resources applied to Domain Local group

Figure 35.5: Example of the use of an “ADLP” Group Design Model Any Windows Server 2003 Active Directory domain, regardless of the functional level of the domain, can generate Domain Local security groups, and hence there are no dependencies upon the domain functional level for the creation of these groups. The use of this ADLP group design model has the following advantages:  The group design model is simple, and generates only Domain Local security groups, with no requirements to nest multiple types of security groups. Hence, the

Page 166 of 354

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

© 2004 Mustan Bharmal

security group infrastructure generated using this model is simple to manage (with respect to the types of groups generated) and troubleshoot.  This group design model permits the assignment of permissions to domain resources to security principals within the domain and from any external trusted domain.  This group design model simplifies the assignment of permissions to user and computer accounts, as an administrator only needs to locate the single appropriate Domain Local group and make the security principal a member of that group. There is no requirement to process a chain of nested groups to assign the required permissions to the security principals.  For example, there is a requirement to assign permissions to “User 1” to access a network printer. A Domain Local group exists with permissions assigned to that printer. Using this model, it is simple to add “User 1” to this group, and thus “User 1” inherits the permissions assigned to the Domain Local group. However, in multiple group type design models, such as “AGUDLP”, in order to assign permissions to the printer for “User 1” (using existing groups and not creating new groups), an administrator must find the Global group that is a member of the Universal group, which is a member of the appropriate Domain Local group. Processing this chain of groups may be time consuming and thus an administrative overhead.  There is no requirement to design categories for collation of security principals into groups. The generation of the Domain Local groups support the assignment of permissions to resources, and not the collation of accounts. The use of this ADLP group design model has the following disadvantages:  The use of this group design model may generate a significant administrative overhead, as the model does not support the abstracting of security principals from Domain Local groups via Global or Universal groups.  For example, an organisation has three departments (sales, marketing, and legal) with six users in each department. There is a requirement to grant access to all of these users to a network printer in close physical proximity to all three departments, and thus an administrator creates a Domain Local group, populates this group with all of the user accounts for these 18 users, and assigns permissions to this group on the network printer. However, when there is a subsequent requirement to assign permissions to only the sales and marketing department to a file share on a network file server, another Domain Local group is required with only user accounts for the user from the sales and marketing departments. Thus, each time there is a requirement to create a new Domain Local group, the administrator is required to manually select and add to the group each required security principal member. This may hence become a serious administrative overhead where there is a requirement to manage hundreds to thousands of user accounts.  This group design model does not support the nesting of Global or Universal groups into Domain Local groups. Hence, all members of this group, from outside of the domain that owns the group, must also be manually selected across automatic twoway transitive trusts between domains within a forest (or between forests with “cross-forest trusts”), or across non-transitive external trust relationships with external domains.  This group design model does not support the nesting of Domain Local groups into other Domain Local groups, which would assist in abstracting security principals from the “resource groups”. The nesting of Domain Local groups is only possible where the Windows Server 2003 Active Directory domain is at either the “Windows 2000 Native” or the “Windows Server 2003” domain functional level.

Page 167 of 354

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

© 2004 Mustan Bharmal

 This group design model does not support the assignment of permissions to security principals to resources outside of the scope of an Active Directory domain. This design methodology provides the following examples of scenarios where this ADLP group design model is suitable:  An OU infrastructure for an Active Directory domain entirely represents a small autonomous division within an organisation. The security principals within this autonomous division have no requirements to access Active Directory controlled resources outside of the host domain.  There is a requirement to generate an Active Directory domain to support service isolation from other domain owners within an Active Directory forest (for example, a parallel domain created as a test environment). The security principals within this domain have no requirements to access resources external to this domain. However, there is a requirement to grant permissions to access resources, controlled by this domain, to selective security principals from other trusted domains. This design methodology provides the following examples of scenarios where this ADLP group design model is unsuitable:  An autonomous division, represented within multiple domains of an Active Directory forest, requires the ability to assign permissions to resources within every appropriate domain to its users and computers. Although the use of the ADLP group design model permits the granting of permissions for both inbound and outbound security principals between the domains, there are significant administrative and performance overheads in administering individual accounts, and not groups of accounts, across trust relationships.  A domain owner is required to grant permissions to a large number of security principals from multiple domains within an Active Directory forest, and external trusted domains, to resources within a domain. The exclusive use of the ADLP model does not permit the efficient assignment of these permissions to the large numbers of security principals. Using the above information, execute the following:  Determine and document the requirements for the design of an ADLP group design model for an Active Directory domain  Where there is a requirement to design and use an ADLP model, then determine and document the requirements for the generation of Domain Local security groups to support security principals, resources, or a mixture of both. Note that it may be necessary to determine this requirement following the determination of the criteria for the generation of groups to support security principals and resource instances / types / permissions on resources (see late for details). • Factor A6: Determination of the requirements for the “AGDLP” standard group design model ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the requirement for the design of the AGDLP group design model. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This group design model employs the use of two scopes for security groups, Domain Local and Global. Hence, two boundaries require consideration for the scope of application and source of members of this group design model.

Page 168 of 354

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

© 2004 Mustan Bharmal

The AGDLP group design model permits the owner of the model to:  Create Domain Local security groups within each domain covered by the specified boundary of the group design model (see later for details on the determination of the boundary of a group design model)  Create Global security groups within each domain covered by the specified boundary of the group design model  Populate the Domain Local groups created via this model only with Global group objects, and not with individual security principal account objects. The Global groups may be:  Those generated by this group design model and within a domain in the same forest, or a trusted domain within the scope of this group design model  Those generated by other group design models within the same domain as the Domain Local group  Those generated by other group design models within the same forest (internal domains) or external trusted Windows Server 2003 domains  Populate the Global groups created via this model only with individual security principal objects (not groups of security principals) from the domain that hosts the Global group. Where the boundary of the group design model is smaller than the domain boundary (for example, represented by the boundary of an OU infrastructure within the domain) then the security principals may be selected from either:  Only within the same boundary of the group design model within the domain in which the Global group is created, or  Outside of the boundary of the group design model, but still within the boundary of the domain  Add the Global groups generated by this group design model only to Domain Local groups created:  By the same group design model in the same domain in which the Global group is created  By the same group design model in another domain in the same forest (where the boundary of a group design model extends to multiple domains in a forest)  By another group design model within the same domain in which the Global group is created  By another group design model in another domain in the same forest  By another group design model in an external trusted Windows Server 2003 domain The following diagram illustrates the process of “AGDLP”, where, in this example, the boundary of the “Natsum.com” domain defines the boundary of the AGDLP group design model:

Page 169 of 354

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

© 2004 Mustan Bharmal

One-Way External Trust Relationship, where “Natsum.com” trusts “Acme.com”

The “AGDLP” Group Design Model

1 2 2 Global Global

1

2
Print Queue Volume

ACLs

3

ACLs

Domain Local

Acme.com

2

Natsum.com.

1

Domain Local

Global
© 2004 MUSTANSH
I R

BH

ARMAL

A.Natsum.com
LEGEND: 1 2 3

B.Natsum.com

Security Principals added to Global group in same domain Global group from same domain / same forest / trusted domain added to Domain Local group Permissions on domain resources applied to Domain Local group

Figure 35.6: Example of use of the “AGDLP” Group Design Model The AGDLP group design model employs the strict use of “account groups” and “resource groups”, and hence requires compliance with all of the following factors associated with the generation and use of these groups:  There is a requirement to design the criteria for collation of security principals into the Global account groups  There is a requirement to design the criteria for the generation of the Domain Local resource groups, based upon collation of:  Specific resource instances or types of resources  Specific permissions or sets of permissions for specific resource instances or types of resources  There is a requirement to comply with the rules for group membership and assignment of permissions to these groups. There are no dependencies upon the domain functional level for the creation and nesting of the security groups for the AGDLP group design model. Any Windows Server 2003 Active Directory domain, regardless of the functional level of the domain, can:  Generate Domain Local and Global security groups

Page 170 of 354

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

© 2004 Mustan Bharmal

 Nest Global groups (from the local domain or an external trusted domain) into Domain Local groups The use of this AGDLP group design model has the following advantages:  The AGDLP group design model is a very flexible and caters for the majority of access control requirements within and between trusted Active Directory domains.  This model abstracts security principals from Domain Local groups, and hence:  Follows the “account group / resource group” approach to access control  Reduces the administrative overheads associated with the assignment of permissions to security principals by negating the requirement to add individual security principals to Domain Local groups  Permits the reuse of Global groups of security principals amongst a number of Domain Local groups within the local domain and within external trusted domains  Permits the generation of a more granular authorisation infrastructure for resource access  The AGDLP group design model support the nesting of Global security groups generated via this model into local resource groups on servers or workstations. The use of this approach negates the requirement to create or use a Domain Local security group to control access to local resources on a server or workstation, without compromising the integrity of this design model. The use of this AGDLP group design model has the following disadvantages:  The AGDLP group design model generates a larger number of security group objects than the ADLP design model. However, this does reflects the broader scope of application of this design model within an Active Directory infrastructure.  For strict compliance with this group design model, there is a requirement to process a chain of nested groups to assign the appropriate permissions to a security principal. However, as there are only two links within this chain, this is not a significant overhead.  There is a requirement to design the criteria for collation of security principals into Global groups, and the rules for generation of Domain Local groups to support categories of resource instances / types, or permissions / sets of permissions on resources.  The ability of this design model to permit the use of local resource groups, and not Domain Local resource groups, to manage access to local resources on servers and workstations requires management. Inappropriate use of this method may generate inconsistent results for resource access. For example, an administrator of a server generates a local resource group, and assigns permissions to this group to an application and its associated data on the server. The administrator then adds a Global security group to this local resource group as a member, thus providing the members of that group appropriate access. If, however, the server experiences a hardware or operating system failure, and requires a rebuild and restore of just the data, the local resource group infrastructure is lost, and requires manual regeneration. Where local resource group infrastructures are extensive and contain multiple Global group members, this may be difficult to re-establish. The exclusive use of Domain Local groups as resource groups abstracts this group infrastructure from local computer account databases. This design methodology provides the following examples of scenarios where the AGDLP group design model is suitable:

Page 171 of 354

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

© 2004 Mustan Bharmal

 There is a requirement permit access to resources within a domain, to groups of security principals from any other domain within the same forest.  There is a requirement within an organisation to grant permissions on local domain resources to groups of security principals from one or more trusted domains within other forests, across, for example, an external trust relationship or an intra-forest trust relationship. This requirement is to support, for example, an intranet or extranet federated forest infrastructure. To meet this requirement, using this AGDLP group design model, an administrator in the local domain assigns permissions to a Domain Local group within the domain, and a Global group, containing the security principals from the trusted domain in the other forest, becomes a member of this Domain Local group, across the trust relationship. This design methodology provides the following examples of scenarios where the AGDLP group design model is unsuitable:  There is a requirement to restrict access to resources within a domain to Global groups of security principals generated within domains in the same forest, and not from domains in other forests.  There is a requirement to restrict access to resources within a domain to specific individual security principal accounts, within the same domain or any other domain in the same forest or external trusted domain. The use of Domain Local groups within this design model strictly as “resource groups” does not permit the population of these “resource groups” with individual accounts for security principals. Use the above information to execute an analysis to determine and document the requirements for the design of an AGDLP group design model for an Active Directory domain. • Factor A7: Determination of the requirements for the “AUDLP” standard group design model ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the requirement for the design of the AUDLP group design model. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This group design model employs the use of two scopes for security groups, Domain Local and Universal. Hence, two boundaries require consideration for the scope of application and source of members of this group design model. The AUDLP group design model permits the owner of the model to:  Create Domain Local security groups within each domain covered by the specified boundary of the group design model (see later for details on the determination of the boundary of a group design model)  Create Universal security groups within any domain that reside inside the specified boundary of the AUDLP group design model  Populate the Domain Local groups created via this model only with Universal group objects, and not with individual security principal account objects. The Universal groups may be:  Those generated by this group design model, and either in the same forest as the Domain Local group, or from a different forest

Page 172 of 354

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

© 2004 Mustan Bharmal

 Those generated by other group design models within the same domain as the Domain Local Group  Those generated by other group design models within other domains in the same forest or different forests  Populate the Universal security groups created via this model only with individual security principal objects (not groups of security principals). The security principals can be from any domain in the same forest as the domain that created the Universal security group, but not from any external trusted domains or forests. This design methodology strongly recommends that security principals from domains in the same forest, but at a “Windows 2000 Mixed” domain functional level, are not made members of the Universal security groups. The execution of such attempts presents the following dialog box because Universal security groups are not available in mixed mode domains, and hence it is not possible for the security principals in the mixed mode domain to add the SID for the Universal groups they are members of, to their access tokens. Adding such security principals to a Universal security group may lead to permission issues, as these security principals will not inherit permissions assigned to a Universal group.

Figure 35.7: Information Dialog Box When Add Members to Universal Groups from a Mixed-Mode Domain  Add the Universal security groups generated by this group design model only to Domain Local groups created:  By the same group design model in the same domain in which the Universal group is created  By the same group design model in another domain in the same forest (where the boundary of a group design model extends to multiple domains in a forest)  By another group design model within the same domain in which the Universal group is created, or another domain in the same forest  By another group design model within another trusted forest The following diagram illustrates the process of “AUDLP”, where, in this example, the boundary of the “Natsum.com” domain defines the boundary of the AUDLP group design model:

Page 173 of 354

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

© 2004 Mustan Bharmal

One-Way External Trust Relationship, where “Acme.com” trusts “Natsum.com”

2

1

The “AUDLP” Group Design Model

Domain Local Universal 2
ACLs Print Queue Volume

2

2 Domain Local

Acme.com

3

ACLs

Natsum.com.
Domain Local 1
© 2 0 0 4 MU ST AN SH I
R

Universal

1

BHAR

MAL

A.Natsum.com
LEGEND: 1 2 3

B.Natsum.com

Security Principals added to Universal group from same domain / forest Universal group from same domain / forest or different forests added to Domain Local group Permissions on domain resources applied to Domain Local group

Figure 35.8: Example of use of the “AUDLP” Group Design Model The AUDLP design model strictly employs the “account group” (the Universal security groups) and “resource group” (the Domain Local groups) model for the management of resource access. The following technical dependencies and constraints are present on the use of this AUDLP group design model:  The scope of membership of the Universal groups generated via this AUDLP design model is restricted to individual accounts for security principals. It is only possible to select these security principals from domains in the same forest that hosts the domain that generates the Universal group. It is not possible to add security principals to a Universal security group from external trusted domains or forests.  It is only possible to generate security Universal groups in a Windows Server 2003 Active Directory domain where the functional level of that domain is either “Windows 2000 Native” or “Windows Server 2003”. Windows Server 2003 Active Directory domains with the default functional level of “Windows 2000 Mixed” do not support the generation of Universal security groups.  There are no technical dependencies or constraints on the functional level of a domain for the generation of Domain Local groups.

Page 174 of 354

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

© 2004 Mustan Bharmal

 The scope of membership of the Domain Local groups generated via this AUDLP design model is restricted to Universal groups from the same forest or any trusted Windows Server 2003 Active Directory forest. The use of this AUDLP group design model has the following advantages:  The AUDLP group design model permits the abstraction of domain boundaries within a forest for the collation of security principals. The use of Universal groups permits the collation of security principals from any domain within a forest, unlike the AGDLP design model, where a Global group can only collate security principals from the same domain that generates the Global group. Hence, the use of Universal groups, when compared to Global groups in the AGDLP design model, permits the generation of fewer group objects, and simpler administration of resource access across domains within a forest.  The use of the AUDLP design model permits the use of only two steps for granting access to security principals, within any domain in a forest, to any appropriate resource within the forest. An administrator of a domain must only add security principals to a Universal group, and then add that Universal group to the appropriate Domain Local group. This advantage is in comparison to the AGUDLP group design model that involves the use of three steps for granting security principals access to resources. The use of this AUDLP group design model has the following disadvantages:  The direct population of a Universal group with security principal account objects may generate network issues, due to the publication of the members of a Universal group to the Global Catalog for a forest. Hence, any changes to this membership will require reflection on all Global Catalog servers for the forest.  The publication of Universal group membership to Global Catalog servers within a forest may place a constraint on the maximum numbers of security principal objects that can become members. Note that the larger the number of member objects within a Universal group, the:  Larger the number of objects represented by a membership change percentage  Larger the size of the Global Catalog partition, and hence the greater the network bandwidth requirements for replication  The use of the AUDLP design model within a domain will have a limited scope of application by administrators within the domain. Most parent organisations will be reluctant to permit autonomous divisions, represented exclusively within an OU or even a domain in a forest, to generate Universal groups due to the publication of their membership to the Global Catalog servers, and hence the extended scope of such actions within a forest. It is very simple to disrupt Global Catalog replication via the accidental population of a Universal group with many hundreds or thousands of security principal objects. Hence, in such scenarios, permissions are typical only granted for domain owners within a parent organisation to generate Universal groups within a forest. This design methodology provides the following examples of scenarios where the use of the AUDLP group design model is suitable:  There is a requirement to provide access to resources within a domain to selected security principals from multiple domains within a forest.  There is a requirement to provide access to resources within a domain to selected security principals from multiple domains within an external trusted forest.

Page 175 of 354

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

© 2004 Mustan Bharmal

This design methodology provides the following examples of scenarios where the use of the AUDLP group design model is unsuitable:  There is a requirement to populate a large number of security principals into Universal groups, and the required membership for the Universal groups is likely to change on a frequent basis (daily, weekly, or monthly), thus generating a significant volume of network traffic.  Where an autonomous division, entirely represented within an OU for a domain and not within any other domain of the forest, wishes access to resources within other domains of the forest. The use of the AGDLP design model would be more suitable to permit the autonomous division to generate a Global group, and then join that Global group to an appropriate resource group in another domain of the forest. Use the above information to execute an analysis to determine and document the requirements for the design of an AUDLP group design model for an Active Directory domain. • Factor A8: Determination of the requirements for the “AGUDLP” standard group design model ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the requirement for the design of the AGUDLP group design model. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This group design model employs the use of three scopes of security groups, Domain Local, Global, and Universal. Hence, three boundaries require consideration for the scope of application and source of members of this group design model. The AGUDLP group design model permits the owner of the model to:  Create Domain Local security groups within each domain covered by the specified boundary of the group design model (see later for details on the determination of the boundary of a group design model)  Create Universal security groups within any domain that resides inside the specified boundary of the AGUDLP group design model  Create Global security groups within each domain covered by the specified boundary of the group design model  Populate the Domain Local groups created via this model only with Universal group objects, and not with individual security principal account objects. The Universal groups may be:  Those generated by this group design model, but in the same forest as the Domain Local group  Those generated by other group design models within the same domain or same forest as the Domain Local group  Those generated by other group design models within external trusted forests  Populate the Universal security groups created via this model only with Global group objects, and not with individual security principal account objects. The Global groups may be:

Page 176 of 354

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

© 2004 Mustan Bharmal

 Those generated by this group design model and within the same domain or the same forest as the Universal security group  Those generated by other group design models within the same domain or forest as the Universal security group  Populate the Global groups created via this model only with individual security principal objects (not groups of security principals) from the domain that hosts the Global group. Where the boundary of the group design model is smaller than the domain boundary (for example, represented by the boundary of an OU infrastructure within the domain) then the security principals may be selected from either:  Only within the same boundary of the group design model within the domain in which the Global group is created, or  Outside of the boundary of the group design model, but still within the boundary of the domain in which the Global group is created The following diagram illustrates the process of “AGUDLP”, where, in this example, the boundary of the “Natsum.com” domain defines the boundary of the AGUDLP group design model:
One-Way External Trust Relationship, where “Acme.com” trusts “Natsum.com”

3 2 Domain Local Global 3

1

The “AGUDLP” Group Design Model

Acme.com
3

Universal ACLs 4
Print Queue ACLs Volume

Domain Local

3

Natsum.com.
Domain Local 1 Global
© 2004 MUSTANSHI
R

2

Universal 1

2

Global
BHAR
MAL

A.Natsum.com

B.Natsum.com

LEGEND: 1 Security Principals added to a Global security group in the same domain 2 3 Global security group added to a Universal security group in same domain / forest Universal group added to Domain Local group in the same domain / forest or external forest

4 Permissions assigned to Domain Local group on local resources

Figure 35.9: Example of use of the “AGUDLP” Group Design Model

Page 177 of 354

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

© 2004 Mustan Bharmal

The AGUDLP group design model strictly employs the “account group” (Global groups) and “resource group” (Domain Local groups) model, with the Universal groups acting as the “vehicle groups” to transport the account groups to the resource groups within the same forest, or to external trusted forests. The same technical dependencies and constraints, with respect to the generation of the different scopes for groups, are in effect for the AGUDLP group design model as for the AGDLP and AUDLP group design models. The use of the AGUDLP group design model has the following advantages:  The AGUDLP group design model permits the abstraction of the account groups from the resource groups by another group layer. This permits a more granular approach towards the management of resource access within and between forests.  The use of the Universal group as the middle layer between the Global account and Domain Local resource groups, permits the following:  A reduction in the frequency of changes to the membership of a Universal group, since the only permitted members, via the AGUDLP group design model, are Global groups from the same forest. Hence, if the membership of the Global groups change, this will not affect the membership of the Universal groups. This reduction in frequency of changes means fewer replication requirements for Universal group membership changes.  The use of Global groups as members reduces the number of members of a Universal group (when compared to the use of the AUDLP group design model).  The consolidation of multiple Global groups into one Universal group creates a more manageable group infrastructure. The consolidation of multiple account groups into a single Universal group permits a reduction in size of the membership list of the appropriate Domain Local groups (when compared to the ADLP, AGDLP, or AUDLP group design models).  The transport of multiple security principals, within Global groups from one or multiple domains within a forest, to other trusted forests, via a Universal security group, into an appropriate Domain Local group in the target domain. The use of the AGUDLP group design model has the following disadvantages:  There is a significantly larger number of security groups generated using this group design model that require management, thus increasing the administrative overheads for this group design model  This design model requires the processing of two links within a chain of security groups prior to addition of the Universal group to the appropriate Domain Local group. This group design model is consequently more complex to use and administer. This design methodology provides the following examples of scenarios where the use of the AGUDLP group design model is suitable:  There is a requirement to support the consolidation of multiple Global groups from different domains within a forest into one or more Universal groups, for application within the same forest, or within another trusted forest. For example, an organisation will not permit autonomous divisions, represented within a domain or an OU infrastructure for a domain in a forest, to generate Universal groups. However, permission is available for autonomous divisions to use the AGDLP group design model. Using the AGDLP group design model, the organisation can take the Global account groups generated by these autonomous divisions, and add them to a Universal security group. It is then possible, using the AGUDLP group design model,

Page 178 of 354

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

© 2004 Mustan Bharmal

to add this Universal security group to the appropriate Domain Local group in a domain in the same forest, or an external trusted forest.  There is a requirement to grant permissions to a very large number of security principals, within multiple domains in a forest, for access to a forest resource or a resource in another trusted forest. Using the AUDLP group design model to support this requirement may result in an increase in replication requirements to support frequent changes in membership of the Universal groups. However, using the AGUDLP group design model, and hence abstracting the Universal groups from the security principal accounts via Global groups, permits the generation of Universal groups with stable memberships. This design methodology provides the following examples of scenarios where the use of the AGUDLP group design model is unsuitable:  There is a requirement to grant permissions to only a very few security principals (for example, less than twenty to thirty accounts), in one or a few domains within a forest, for access to a forest resource or a resource in another trusted forest. Using the AGUDLP group design model for this requirement generates unnecessary Global groups as account groups. The AGDLP group design model is more suitable to support this requirement.  There is a requirement to grant permissions to a few or a large number of security principals within one forest, for access to a forest resource or a resource in another trusted forest. The number of security principals is to remain static (for example, <10 changes per month), and hence the use of Universal groups as the account groups is permissible. Hence, the abstraction of Universal account groups by Global groups is unnecessary, and instead, the AUDLP group design model is more suitable to support this requirement. Use the above information to execute an analysis to determine and document the requirements for the design of an AGUDLP group design model for an Active Directory domain. • Factor A9: Determination of the requirements for hybrid design models for security groups ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the requirement for the design of one or more hybrid design models for security groups. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: It is possible to define a multitude of technically permissible combinations for the use and nesting of different scopes of security groups for use within a domain, forest, trust domain, trusted forest. However, as with the four standard group design models, each of these “hybrid” combinations have associated advantages and disadvantages. This section will discuss three of the technically permissible hybrid design models for security groups, and discuss the considerations for the design and use of these models. This design methodology proposes the following three hybrid design models for security groups:  “AGP”  “AUP”  “AGUP”

Page 179 of 354

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

© 2004 Mustan Bharmal

The “AGP” group design model places “Accounts” into “Global” security groups and applies Permissions to the “Global” security groups for local and network resources:
© 2004 MUSTANSHI
R

BHARMAL

Accounts

Global

Permissions

Figure 35.10: Illustration of the Hybrid “AGP” Security Group Design Model The “AUP” group design model places “Accounts” into “Universal” security group and applies Permissions to the “Universal” security groups for local and network resources:
© 2 0 0 4 MU ST AN SH I
R

BHAR

MAL

Accounts

Universal

Permissions

Figure 35.11: Illustration of the Hybrid “AUP” Security Group Design Model The “AGUP” group design model places “Accounts” into “Global” security groups, nests “Global” security groups into “Universal” security groups, and applies Permissions to the “Universal” security groups for local and network resources:
© 2004 MUSTANSHI BHARMAL
R

Accounts

Global

Universal

Permissions

Figure 35.12: Illustration of the Hybrid “AGUP” Security Group Design Model Note the following facts common to all three of the above hybrid design models for security groups:  None of the hybrid design models presented above employ the use of Domain Local security groups  None of these hybrid group design model support the duplicate nesting of group scopes, such as “Global” into “Global” or “Universal” into “Universal” Note that only the “AGUP” hybrid group design model strictly employs the “account group” and resource group” approach to resource management via a security group infrastructure, with “Global” groups as the account groups that abstract security principals from the Universal groups, as the resource groups. The other two hybrid design models rely upon an organisation determining the criteria for the generation of groups to support either:  The collation of security principals into a Global or Universal group (to create these groups as “account” groups), or  The generation of a Global or Universal group to support specific resources, types of resources, or permissions / sets of permissions on resource instances / types (to create these groups as “resource” groups) The same design model rules for the standard group design models apply to the hybrid design models, respective to group creation, population, and application, for the appropriate group scopes. It is possible to extrapolate the information supplied for the standard group design models to determine the following for each of these three hybrid design models:

Page 180 of 354

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

© 2004 Mustan Bharmal

 The advantages and disadvantages for the use of each hybrid design model  The possible scenarios where each hybrid group design model would be suitable and unsuitable Use table 35.1 within the next section (determination of the number of group design models required) to understand the limitations of these three selected hybrid design models for security groups. Note, with hybrid design models for security groups, an organisation may design the model to permit the duplicate nesting of security group scopes, as, for example, an AGGDLP or AGUUDLP model. However, there are many factors to consider when determining the requirements for the duplicate nesting of security group scope. Factors such as the extra complexity and administrative overheads for management of such a security group infrastructure require consideration. Using the above and extrapolated information, execute the following:  Determine and document the requirements for the design of one or more hybrid design models for security groups  Determine and document the specific hybrid design model(s) required 6.9.3. Determination of the Number of Group Design Models Required When determining the requirements for multiple hybrid or standard design models for security groups, the following approach is proposed: 1. 2. Understand the factors that will influence the requirements for two or more hybrid or standard design models for security groups Determine the requirements for the design of two or more hybrid or standard design models for security groups

Following this approach, consider the following information when determining the number of hybrid or standard design models required for security groups within an Active Directory domain: • Factor A10: Determination of the requirements for multiple types of group design models ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the requirements for two or more group design models for an Active Directory domain based upon the type of standard or hybrid design model. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The requirements for multiple types of group design models (hybrid or standard) are a reflection of the requirements to manage access to resources within an Active Directory domain, by the owner(s) of a group design model, for the following modes of access:  Inbound and outbound access by security principal objects within the boundary of a group design model  Inbound access by security principal objects outside of the boundary of a group design model These two fundamental requirements will dictate the types of group design model required within a domain.

Page 181 of 354

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

© 2004 Mustan Bharmal

The following table details the different support capabilities of each of the four standard and three selected hybrid design models for security groups, against these two fundamental requirements for controlling access to resources. Prior to consultation of the table below, understand the following definitions for terms employed within this table:  “Actual” boundary of the group design model refers to the directory service containers or logical boundaries for the “local” security principals and resources (see later for details of boundaries of a group design model). For example, the “actual” boundary of a group design model may be an entire Active Directory domain, and hence all security principals within the domain are within the “actual” boundary of the group design model. If the “actual” boundary of a group design model was an OU infrastructure, then only security principals within the defined OU infrastructure are within the “actual” boundary of the group design model.  “Inbound” refers to the assignment of permissions on resources to security principals that reside either within or outside of the “actual” boundary of a group design model. Note that the group assigned the permissions to the resources MUST be generated by the group design model. This is a fundamental rule for all group design models.  “Outbound” refers to the support for the assignment of permissions to resources that reside outside of the “actual” boundary of a group design model, for security principals within the “actual” boundary of a group design model, using only the groups permissible by the group design model. For example, a user in Domain A wishes to access a file share on a server in Domain B, but the “actual” boundary of an AGDLP group design model is Domain A. Hence, this group design model must cater for the “outbound” transport of the user to Domain B where can be assigned the appropriate permissions (directly or indirectly via a resource group), via the transport of the user in a Global group. It is not possible to support this requirement using a Universal group for the AGDLP group design model, as this model does not support the generation and use of Universal groups. Outbound can hence be the same domain (and hence the assumption that the boundary for the group design model is smaller than that of the Active Directory domain), another domain in the same forest, or a trusted domain. The “trusted domain” in this table refers to an external trusted domain that is outside of the forest that hosts the group design model.  For security principals within the “actual” boundary of a group design model, the following terms are defined:  Inbound “same domain” refers to a boundary for a group design model that matches or exceeds the domain boundary. For example, a group design model has an “actual” boundary of one entire domain within a forest, and hence must support the “inbound” management of resource access for all security principals within the boundary of this domain.  Inbound “same forest” refers to a boundary for a group design model that matches or exceeds the boundaries of two or more domains within a forest, or the entire forest boundary. For example, a group design model has a boundary of one entire forest, and hence must support the “inbound” management of resource access for all security principals within the boundaries of each domain within the entire forest.  Inbound “trusted domain” refers to a boundary for a group design model that matches or exceeds two or more domains with a trust relationship between them. For example, a group design model has a boundary of three domains, in three separate forests, with two-way external trust relationships between each of these three domains only. Hence, the group design model must support the “inbound”

Page 182 of 354

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

© 2004 Mustan Bharmal

management of resource access for all security principals within the boundaries of each of these three trusted domains.  For security principals that reside outside of the boundary of a group design model, the group design model may have to support resource access management for these inbound security principals. These inbound security principals may be from the same domain as the group design model, from the same forest as the group design model, or an external “trusted domain” to a domain / forest that hosts the group design model. Specific notes accompany the ticks () and crosses () in the table below, and require consideration (see below table for notes). A tick denotes support for the requirement by the group design model, and a cross denotes a lack of support for this requirement by the group design model.
Standard And Hybrid Group Design Models ADLP AGDLP AUDLP AGUDLP AGP AUP AGUP Security Principals within the “actual” boundary of a group design model Inbound Same Domain        Same Forest  3  3 3  3 Trusted Domain  3 6 9 3  3 Outbound Same Domain 1 4 7 10    Same Forest 1a 4 7 10 11 13 16 Trusted Domain 1b 4 7 10 11 14 16 Inbound security principals from outside of the “actual” boundary of a group design model Same Domain 2 5 8 10    Same Forest 2 5 8 10 12   Trusted Domain 2 5 8 10 12 15 17

Table 35.1: Comparison of Standard and Hybrid Group Design Models against Requirements to Support Inbound and Outbound Access to Resources The following notes accompany the above table. The list below matches the numbers and letters in the above table: 1. The following applies to ALL four standard design models that employ the Domain Local security groups. The standard group design models do not permit making a Domain Local group a member of any other security groups in the same domain, same forest, or trusted domain. This rule is to enforce the generation of consistent Domain Local groups and management of the groups. Note the following as well: a. It is not technically possible to add a Domain Local group from a domain in a forest into another Domain Local group or a Universal security group. Hence, it is not possible for a standard group design model to port security principals (via a Domain Local group) outside of the domain into another Domain Local or Universal group in another domain. b. It is not technically possible to add a Domain Local group into a Domain Local group in a trusted domain. Hence, the standard group design model does not support the porting of security principals, via Domain Local groups, outside of the domain that hosts the Domain Local group. 2. A Domain Local group can accept security principals as individual members from the local domain, any domain in the same forest, any trusted external domain.

Page 183 of 354

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

© 2004 Mustan Bharmal

3.

It is only possible to add the inbound security principals to a Global group in the same domain as the security principals. It is not possible to add the security principals to a Global group where they reside in another domain to the Global group, even if in the same forest. As the AGDLP group design model supports the “account” and “resource” group model, this model hence supports the porting of security principals, via the Global account group, into a Domain Local group in the same domain, another domain in the same forest, or a trusted external domain. The AGDLP group design model dictates that the destination group for a Global group generated via this model must be a Domain Local group. The destination Domain Local group does not require generation by this group design model and can hence reside in any domain where it is technically possible to port the Global group. The AGDLP group design model only supports the inbound addition of Global account groups from the same domain, another domain in the same forest, or any other trusted external domain, into a Domain Local group. For the AUDLP group design model, inbound security principals from a trusted domain must come via a Universal group generated in that trusted domain / forest. It is not possible to add these security principals, from a trusted domain, into a Universal group in the trusting forest. As the AUDLP group design model supports the “account” and “resource” group model, this model hence supports the porting of security principals, via the Universal account group, into a Domain Local group in the same domain, another domain in the same forest, or a trusted external domain. The AUDLP group design model dictates that the destination group for a Universal group generated via this model must be a Domain Local group. The destination Domain Local group does not require generation by this group design model and can hence reside in any domain where it is technically possible to port the Universal group. For the AUDLP group design model, inbound security principals from outside of the boundary of a group design model must come via a Universal group generated by another group design model in the same domain, same forest, or trusted domain / forest. For the AGUDLP group design model, inbound security principals from a trusted domain can only be accepted into the Domain Local group in a trusting domain via a Universal group created in the trusted domain, that holds a Global group (for the same forest as the trusted domain) with the appropriate security principals.

4.

5.

6.

7.

8.

9.

10. For the AGUDLP group design model, outbound of local security principals or inbound of external security principals can only either be via security principals within a Global group, or via the Global group within a Universal group from the same forest. 11. For the AGP group design model, it is technically possible to send security principals within a Global group out to any other domain within a forest, or a trusted domain. However, the first fundamental rule for the AGP group design model (and for all group design models) states that the group assigned permissions to the resource(s) (in this model, the Global group), requires creation only by the group design model. Hence, unless the boundary of the AGP group design model extends to the entire forest, or one or more trusted domains, it is not possible to port these security principals to another domain via this model. 12. For the AGP group design model, it is not possible to permit external security principals access to resources where they reside outside of the domain that owns a Global group. This is because it is not possible to add these external security principals to the Global group in another domain (technical limitation), and the permissions must be applied to the Global group. The fundamental rule, that applies to all group design models, states that the group to receive permissions to the resources requires generation by the group design model. Hence, in this scenario, it is not possible to assign permissions to a Global

Page 184 of 354

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

© 2004 Mustan Bharmal

group from an external domain, unless the external domain (and hence the Global group) is within the boundary of a group design model. 13. For the AUP group design model, it is technically possible to send security principals within a Universal group out to any other domain within a forest. However, the first fundamental rule for the AUP group design model (and for all group design models) states that the group assigned permissions to the resource(s) (in this model, the Global group), requires creation only by the group design model. Hence, unless the boundary of the AUP group design model extends to the destination domain within the forest, it is not possible to port these security principals to another domain within the forest via this model. 14. For the AUP group design model, as it is only technically possible for a Universal group to have members from the same forest, it is not possible to use this group design model to port users outside of the forest to an external trusted domain. 15. It is not possible to accept inbound security principals from a trusted external domain into a Universal group, as this is a technical limitation of Universal groups. The first fundamental rule for all group design models also applies here, that the group to receive permissions to the resources (a Universal security group in the AUP design model) requires generation by the group design model. 16. For the AGUP group design model, it is only possible to use the Global account groups to port the internal security principals to Universal groups in the destination domain in the same forest, or trusted domain. 17. For the AGUP group design model, it is only possible to accept external inbound security principals from a trusted domain via a Global group generated in the trusted domain, into the Universal group generated in the trusting domain. Using the above table and notes, execute the following:  Determine and document the types of group design models required to support all inbound and outbound resource access requirements, for internal and external security principals (with respect to the boundary of the group design model), within an ORMI.  Determine and document the total number of group design models required for an ORMI, based upon the types of the design models. 6.9.4. Determination of the Design Requirements for Each Required Group Design Model Consider the following information where an organisation has identified the requirements for the design of one or more standard or hybrid design models for security groups within an ORMI. Presented within the following four sections are the considerations for execution of this step within this process: 1. 2. 3. 4. Considerations for the determination of the boundary for each required group design model within an ORMI Considerations for the determination of the relationship(s) between multiple group design models Considerations for the determination of the rules for generation of security groups by a group design model Considerations for the determination of the naming convention requirements for multiple group design models

Page 185 of 354

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

© 2004 Mustan Bharmal

6.9.4.1.

Determination of the Boundary for Each Required Group Design Model Consider the following information when determining the boundary for each required group design model within an Active Directory and / or legacy (Windows NT 4.0) directory service infrastructure: • Factor B3: Understanding boundaries for group design models ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for the design of one or more standard or hybrid design models for security groups within a security group infrastructure for an ORMI, and  Wishes to understand the concept and types of boundaries that require analysis and design for the group design models ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with all of the above criteria within an organisation: Where an ORMI is required to support two or more group design models, it is important to determine and define the boundaries of each of these group design models. There are two factors, associated with all group design models, which define the boundary of a group design model. These two factors are:  The logical locations (within and outside of the boundary of an ORMI) of the resources to which a security group will receive permissions  The logical locations (within and outside of the boundary of an ORMI) of the security principals that will require membership to a security group To support these two factors, this design methodology defines the following three types of boundaries for any standard or hybrid design model for security groups (see later for details of each type of boundary):  An “actual” boundary  An “outbound virtual” boundary  An “inbound virtual” boundary An “actual” boundary defines the following three parameters for a group design model:  The logical locations of the “local” (with respect to the group design model) resources and services (within and outside of the boundary of an ORMI) that require management, with respect to access control using a security group infrastructure supported by a group design model.  The logical boundary for “local” security principals (within and outside of the boundary of an ORMI), which require membership to security groups supported by a group design model.  The logical boundary for the generation of security groups, by the group design model, to receive permissions to the “local” resources within the “actual” boundary of the group design model. Note that this parameter reflects the first fundamental rule of all group design models. An “outbound virtual” boundary defines the logical boundary for all “non-local” resources and services to which the “local” security principals require access, via

Page 186 of 354

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

© 2004 Mustan Bharmal

membership to security groups not supported by the group design model, and are hence outside of the “actual” boundary for the group design model. Sending security principals out of the “actual” boundary for the group design model and into security groups within the “actual” boundaries of other group design models thus extends the virtual outbound boundary of a group design model. An “inbound virtual” boundary defines the logical boundary for all “non-local” security principals (security principals not within the actual boundary of a group design model), which require membership to security groups supported by the group design model. Receiving security principals into a security group generated by a group design model, for application within the “actual” boundary of the model, thus extends the virtual inbound boundary of a group design model. The following diagram illustrates these concepts of security group boundaries, for an example of a group design model (using the standard AGUDLP group design model), where:  The “actual” boundary for the AGUDLP group design model is defined as the entire “Natsum.com” domain (abstracted to the domain level (and not ORMI boundary) for clarity)  The “outbound virtual” boundary for the AGUDLP group design model is defined by all domains in the same forest as the Natsum.com domain, and  The “inbound virtual” boundary for the AGUDLP group design model is defined by the logical boundary for the “Acme.com” trusted domain, and all domains in the same forest as the Natsum.com domain  “Local” and “non-local” resources and security principals are identified within the “actual”, “outbound virtual”, and “inbound virtual” boundaries of the group design model.

Page 187 of 354

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

© 2004 Mustan Bharmal

Example of boundaries for an “AGUDLP” Group Design Model

“ACTUAL” BOUNDARY

One-Way External Trust Relationship, where “Acme.com” trusts “Natsum.com” “local” security principals

1 2 Global 3 Universal ACLs 4
Print Queue ACLs Volume

Domain Local 3 3 “local” resources

3

Natsum.com.

“non-local” resources
ACLs

2 Domain Local
Print Queue

Universal 1

2

Universal 1

2

1 Global Global Global

A.Natsum.com

B.Natsum.com

Acme.com
“non-local” security principals
© 2 0 0 4 MU S TAN SH I
R

“OUTBOUND VIRTUAL” BOUNDARY “INBOUND VIRTUAL” BOUNDARY
LEGEND: Security Principals added to a Global security group in a domain within 1 the “actual” or “inbound virtual boundary” for the group design model 2

BHARMAL

Global security group added to a Universal security group in same domain / forest as the Global group, and within the “actual” or “inbound virtual boundary” for the group design model 3 3 3 “Local” Universal group (created within “actual” boundary) added to Domain Local group within the “actual” boundary for the group design model Outbound Universal group (created within “actual” boundary) added to Domain Local group in a domain within the “outbound virtual” boundary for the group design model Inbound Universal group added to Domain Local group (within “actual” boundary) from a domain within the “inbound virtual” boundary for the group design model

4

Permissions assigned to Domain Local group, within the “actual” boundary of a group design model, on local resources

Figure 35.13: Example of Security Group Boundaries using an “AGUDLP Security Group Design Model Although every group design model requires the definition of an “actual” boundary, not all group design models require an inbound and / or an outbound virtual boundary.

Page 188 of 354

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

© 2004 Mustan Bharmal

Presented below are the considerations for the determination and design of the “actual”, “inbound virtual” and “outbound virtual” boundaries for group design models. • Factor A11: Determination of the “actual” boundary of a group design model ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the “actual” boundary for a group design model. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with all of the above criteria within an organisation: The definition of the “actual” boundary of a group design model is actually a by-product of the process to determine the requirement for a group design model. A group design model is required to generate a security group infrastructure that is required, in turn, to support the management of access control for either resources or security principals, or both. Hence, defining the requirement to manage the access control for resources and / or security principals defines the objective of the group design model, and in turn, the “actual” boundary for the group design model via the mapping of the logical distribution of these objects within the boundary of an ORMI. The definition of the “actual” boundary defines the “local” resources and security principals since they reside within the “actual” boundary of the group design model. Hence, this boundary also defines all resources and security principals that do not reside within the “actual” boundary as “non-local”. This is fundamental to the determination of the “outbound virtual” boundary (for non-local resources) and the “inbound virtual” boundary for non-local security principals. Thus, when determining the “actual” boundary for a group design model, this design methodology proposes execution of the following approach:  Determine the parameter(s) (resources and / or security principals) to be used to define the “actual” boundary for a group design model  Determine the distribution of the resources and / or security principals within an internal and external Active Directory infrastructure  Determine the smallest components of an ORMI that will exclusively, or nonexclusively, reflect the distribution of the resources and / or security principals and permit collation of the selected parameter(s) into one or more logical containers / boundaries  Where multiple components of an ORMI are required to represent the distribution of the selected parameter(s), collate all such components together to define the “actual” boundary for a group design model. As stated earlier, although the “actual” boundary for a group design model defines three parameters (the logical locations of the “local” resources and services, the logical boundary for “local” security principals, and the logical boundary for the generation of security groups), it is possible to select either or both of the first two parameters to conversely define the “actual” boundary. For example:  An organisation may require a group design model to control access to specific resources or types of resources, such as printers, file shares, non-security principal Active Directory objects, and so on. For example, an organisation requires a group design model for the exclusive management of access control on all printer objects within an organisation. Hence, the logical locations for these printer objects within

Page 189 of 354

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

© 2004 Mustan Bharmal

an Active Directory infrastructure will contribute to the definition of the “actual” boundary for this group design model. The definition of the in-scope resources and services, to determine the scope and boundary for an access control infrastructure, hence contributes the definition of the “actual” boundary for this group design model.  An organisation may require a group design model for the management of access control requirements to resources for all or specific groups of security principals within an internal or external Active Directory infrastructure. For example, an organisation required a group design model for the exclusive management of the access control requirements for all users and computers within an autonomous division within the organisation. Hence, the logical distribution of all of these users or computers for this autonomous division within an ORMI will hence contribute to the definition of the “actual” boundary for this group design model. When identifying the resources that require consideration for inclusion within the scope of the “actual” boundary of a group design model, and hence “local”, consider the following:  The “local” resources may only be those resources where their control of access and use is via a security infrastructure that involves the assignment of permissions to security principals within an Active Directory or legacy (Windows NT 4.0) directory service infrastructure. Where there is the absence of an Active Directory or legacy (Windows NT 4.0) directory service infrastructure to support the candidate “local” resource, consider that resource outside of the scope of the “actual” boundary of a group design model.  Where possible, avoid the inclusion of resources within the “actual” boundary for a group design model where they currently reside within the “actual” boundary of one or more other group design models, unless there is one owner for all group design models, or the owner of the resource also owns both or all group design models. Differences in ownership of the resource and the group design models can generate issues over management of access control for the resource. For example, the owner of a resource may wish to restrict access to the resource to specific groups of security principals, and enforces this via a group design model, which includes the resource within its “actual” boundary. However, if another group design model, not owned by the resource owner, includes the resource within its “actual” boundary, then that group design model is able to control access and use of the resource via its security group infrastructure. This may be undesirable for the owner of the resource.  The “local” resource must reside within a component of an in-scope directory service infrastructure where the owner(s) of the group design model have the appropriate rights and permissions to generate security groups and manage the access control requirements for the resource.  The “local” resource must be accessible using only existing or planned Active Directory, trust relationship, and DNS infrastructure. Where the supporting infrastructure does not permit management of the access control requirements for the “local” resource, consider that resource outside of the scope of the “actual” boundary of the group design model and hence not “local”. When identifying the security principals that require consideration for inclusion within the scope of the “actual” boundary of a group design models, and hence “local”, consider the following:  The “local” security principals may only be those security principals represented within, and supported by, an Active Directory or legacy (Windows NT 4.0) directory service infrastructure. Where there is the absence of an Active Directory or legacy (Windows NT 4.0) directory service infrastructure to support the candidate “local” security principals, consider these security principals outside of the scope of the “actual” boundary of a group design model.

Page 190 of 354

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

© 2004 Mustan Bharmal

 The “local” security principals must reside within a component of an in-scope directory service infrastructure where the owner(s) of the group design model have the appropriate rights and permissions to manage the access requirements for these security principals for “local” and “non-local” resources. Where the owner(s) of the group design model do not have the appropriate rights or permissions to manage the resource access requirements for the candidate “local” security principals, consider these security principals outside of the scope of the “actual” boundary for a group design model.  Where possible, avoid the inclusion of security principals within the “actual” boundary for a group design model where they currently reside within the “actual” boundary of another group design model, unless there are no “local” or “non-local” resources in common to the two group design models to which the “local” security principals may require access. The presence of security principals with the “actual” boundaries of two or more group design models may generate issues over management of access control for “local” and “non-local” resources common to each design model and managed by each group design model. For example, the owner of a resource may wish to grant and deny access to the resource to specific groups of security principals, and enforces this via a group design model, which includes the resource within its “actual” boundary. However, if another group design model, not owned by the resource owner, includes the same security principals within its “actual” boundary, then that group design model is able to control access and use of the resource via its security group infrastructure. This may be undesirable for the owner of the resource. For example, group design model 1 (GDM1) owns and controls access to a resource “resource1”, and permits access to “local” security principal “User1”, but denies access to “local” security principal “User2”. However, “User2” also resides within the “actual” boundary of group design model 2 (GDM2), as does “resource1”. The owners of GDM1 and GDM2 are not the same, and hence it is possible for “User2” to gain inadvertent access to “resource1” via GDM2 even though not granted access (although not explicitly denied access) by GDM1. Hence, where possible avoid overlaps in “actual” boundaries for group design models via the selection of the appropriate security principals as “local” security principals.  The management of the resource access control requirements for the candidate “local” security principals must be supported by an existing or planned Active Directory, trust relationship, and DNS infrastructure, as appropriate to the logical location within the supporting directory service infrastructure for these security principals. The supporting infrastructure must permit the sustained management of the access control requirements for resources, for these security principals, by the group design model. Absence of such a supporting infrastructure will preclude these security principals from the “actual” boundary of the group design model. Upon identification of the required parameter(s) to define the “actual” boundary of the group design model, and the logical distribution of these resources and / or security principals, the next step is to determine the smallest components of an ORMI that will accurately reflect the logical distribution of the resources and / or security principals. The components of an ORMI that may be used are individual Organizational Units (OUs), and OU hierarchies. This design methodology has provided below two examples for the process to identify the smallest component of an Active Directory infrastructure, which will reflect the logical distribution of resources and / or security principals within an Active Directory infrastructure:  An organisation has identified the requirement for a group design model to manage access control for all printers within the organisation. The organisation has determined that there is an even distribution of the printer objects, which represent the print queues on a print server, across all of the domains within an Active Directory infrastructure. Hence, the next step is to identify the smallest component of an ORMI that will permit the collation of all respective printer objects. The

Page 191 of 354

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

© 2004 Mustan Bharmal

organisation has decided to collate all printer objects into an OU commonly named “Printers” within each ORMI. There are no other objects within these OUs except printer objects. Hence, it is possible to state that the smallest components of an ORMI that may collate all printer objects is an OU named “Printers” within each ORMI. It is thus possible to define the “actual” boundary for this group design model as “All printer objects within the “Printers” OU present in each required ORMI within the Windows Server 2003 Active Directory infrastructure for an organisation”.  An organisation has identified the requirement for a group design model to manage access control for all security principals within an autonomous division (“Natsum Gardens”) within the organisation. The organisation has determined that there is an exclusive distribution of all of these security principals across two trusted domains, where one domain is within an Active Directory forest for an organisation, and the other domain is an external trusted Windows Server 2003 Active Directory domain. Hence, the next step is to identify the smallest component of an Active Directory infrastructure that will permit the collation of all respective security principals for this autonomous division. As these two domains support multiple autonomous divisions, it is hence not possible to define the domain boundaries as components of the “actual” boundaries. However, the organisation has decided to collate all of the security principals for this autonomous division into a single discrete OU infrastructure within each domain, and each OU infrastructure in each domain has a single ML1 OU named “Natsum Gardens”. Hence, it is possible to state that the smallest components of an Active Directory infrastructure that may collate all security principals for this autonomous division is an OU infrastructure beneath a top level OU named “Natsum Gardens” within each of these two domains. It is thus possible to define the “actual” boundary for this group design model as “All security principal objects, within an OU infrastructure beneath a ML1 OU named “Natsum Gardens”, within each of the two trusted domains”. There may be instances where it is not possible to identify an entire Active Directory component that exclusively collates all of the required resources and / or security principals, such as an OU or domain. In these scenarios, it is necessary to select the smallest component that collates all of the required resources and / or security principals and state exclusions to the “actual” boundary. For example, although specific security principals belonging to the Sales department are the required parameter, they represent an uneven distribution across a single domain (for example in several OUs shared with other non-required security principals). It is hence necessary to select the entire domain as the smallest Active Directory component for the “actual” boundary, and state exclusions, such as “all security principals within “<name_of_domain>” except those not belonging to the Sales department”. Using the above information, execute the following:  Determine and document the required parameter(s) (resources and / or security principals) that are to be used to define the “actual” boundary for a group design model  Determine and document the logical distribution of the selected resources and / or security principals within an organisation  Determine and document either the:  Smallest Active Directory components that can exclusively collate all of the required resources and / or security principals, or  The smallest Active Directory components that can closely collate all or groups of the required resources and / or security principals, and the exclusion statements to define the scope for the group design model

Page 192 of 354

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

© 2004 Mustan Bharmal

 Determine and document the definition of the “actual” boundary for each required group design model within an organisation • Factor A12: Determination of the “outbound virtual” boundary of a group design model ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the “outbound virtual” boundary for a group design model. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with all of the above criteria within an organisation: The “outbound virtual” boundary for a group design model identifies the non-local (nonlocal with respect to the group design model) resources to which the “local” security principals (within the “actual” boundary of a group design model) will require access. Note that this design methodology defines this boundary with respect to the following two factors:  The logical locations for the required non-local resources within the supporting directory service infrastructures  The “actual” boundary of the group design model Note that the “outbound virtual” boundary is not defined with respect to the logical location of the target “resource” security group, to which the “account” group from the group design model will be added, within the supporting directory service infrastructure. This is because the target “resource” group may reside in another component of the supporting directory service infrastructure. It is important to define an “outbound virtual” boundary for a group design model as it permits an organisation to determine the numbers and members of security groups that are required to support outbound access requirements for “local” security principals. It is possible to identify resources as being “non-local” to the group design model because either:  They were outside of the scope of the resources that defined the “actual” boundary for a group design model, or  They were outside of the boundary of the factor that collated the security principals within the “actual” boundary for a group design model. For example, there is a requirement to collate “local” security principals (“local” to a group design model) based upon membership to a department such as “Sales”. The non-local resources that these “local” security principals require access to are those resources that (for example) belong to another department, such as “Marketing”. Hence, they are not “local” to the group design model. However, because the “Sales” users require access to the “Marketing” resources, these resources are hence within the “outbound virtual” boundary of this group design model. Where it is not possible to identify the requirements for “local” security principals to access non-local resources, then there is no requirement to define the “outbound virtual” boundary for the group design model. In this instance, the security groups generated by the group design model will not cross the “actual” boundary for the design model. Note that it is not possible for all group design models to define an “outbound virtual” boundary, due to either:  Technical limitations based upon the scope(s) of groups supported by the group design model (see table above for details), or

Page 193 of 354

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

© 2004 Mustan Bharmal

 The first fundamental rule for all group design models that states that the group design model must generate the group that requires assignment of permissions to resources. This rule hence excludes all group design models that do not employ the “account” and “resource” group method from defining an “outbound virtual” boundary.  Thus, the only standard and hybrid group design models that can send “out” (of the “actual” boundary) account groups generated by the group design model, and thus can define an “outbound virtual” boundary, are:  AGDLP (can send out Global account groups only to a destination Domain Local group assigned permissions to the non-local resource)  AUDLP (can send out Universal account groups only to a destination Domain Local group assigned permissions to the non-local resource)  AGUDLP (can send out: • Global account groups only to a destination Universal group (which will be a member of a Domain Local group assigned permissions to the non-local resource), or • Universal groups with Global account groups only as members only to a destination Domain Local group assigned permissions to the non-local resource)  AGUP (can send out Global account groups only to a destination Universal group assigned permissions to the non-local resource) It is necessary to adopt a similar approach to determine the “outbound virtual” boundary for a group design model as for the process to determine the “actual” boundary for a group design model. The approach to determine the “outbound virtual” boundary identifies the requirement to determine the following:  Identify the non-local resources to which “local” security principals will require access.  Identify the logical distribution of these non-local resources within the supporting directory service infrastructure. The supporting directory service infrastructure may be an internal Active Directory infrastructure or external (legacy) directory service infrastructure.  Identify the smallest components of the supporting directory service infrastructure, which can exclusively, or non-exclusively, reflect the distribution of the non-local resources and permit collation of the selected resources into one or more logical containers / boundaries.  Where multiple components of an Active Directory infrastructure are required to represent the distribution of the selected resources, collate all such components together to define the “outbound virtual” boundary for a group design model. When identifying the non-local resources to which “local” security principals will require access, consider the following:  It may not be possible at this stage in the design of an Active Directory infrastructure to determine the specific non-local resources to which “local” security principals may require access. In these scenarios, it is sufficient to establish initially whether there will be any future requirements for “local” security principals to access non-local resources. Upon identification of such requirements in the future, it is necessary to complete this process to determine the “outbound virtual” boundary for a group design model.

Page 194 of 354

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

© 2004 Mustan Bharmal

 The non-local resources may only be those resources where their control of access and use is via a security infrastructure that involves the assignment of permissions to security principals within an Active Directory or legacy (for example, Windows NT 4.0) directory service infrastructure. If the non-local resources are not supported by an Active Directory or legacy directory service infrastructure, then it is to be considered outside of the scope of the “outbound virtual” boundary of a group design model.  It is necessary to determine the requirement for singular, occasional, or regular access the non-local resource(s). Where there is a requirement for a group design model to support only singular or very infrequent access to the non-local resources, then consider these resources as being outside of the scope of the “outbound virtual” boundary for a group design model.  Where possible, avoid the inclusion of a non-local resource within an “outbound virtual” boundary where it already resides within the “actual” or “outbound virtual” boundary for one or more other group design models, unless:  Security principals are not common to any of the group design models (within the “actual” or “inbound virtual” boundaries), or  There are security principals common to both or all group design models, but all group design models have the same owner  It is necessary to identify only those non-local resources that are accessible using only the existing or planned Active Directory, trust relationship, and DNS infrastructure, and that infrastructure can maintain sustained access to the resources. For example, where there is a requirement to access a non-local resource, but that resource resides in an external domain. Where there is no current or planned trust relationship to that external domain, then that non-local resource is to be considered outside of the scope of the “outbound virtual” boundary for a group design model. Note, that a DNS infrastructure must be able to support name resolution to an external domain with a planned or current trust relationship with a domain in the Active Directory infrastructure.  The non-local resources must be within the scope of a security group infrastructure, in the target domain, that supports the “resource” group scope of the group design model. This is requirement reflects the fundamental rule (2b) for all group design models. For example, an organisation using the “AGDLP” group design model, wishes to send out a Global group containing security principals to access a nonlocal resource in another domain. The non-local resource must reside within the management scope of a Domain Local group (as the “resource” or “account” group) to which the outbound Global group can become a member. The source design model for security groups dictates the target group scope for an account group. Compliance with fundamental rule 2b for all group design models permits the generation of a consistent strategy for management of resource access via security group infrastructures. Where there is no existing or planned target group that is required by the source group design model, then this non-local resource is to be considered outside of the scope of the “outbound virtual” boundary for the source group design model.  The owner(s) of the non-local resources must identify which security principals, “local” to a group design model, they will grant access to, and use of, the non-local resources. If none of the “local” security principals are to be granted access, then the non-local resource is to be considered outside of the scope of the “outbound virtual” boundary for the source group design model. However, where specific individual or groups of security principals are to receive exclusive access and use of the non-local resource, then it is necessary to ensure that the appropriate account group is available to collate, exclusively, only those privileged security principals.

Page 195 of 354

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

© 2004 Mustan Bharmal

The logical distribution of non-local resources will contribute to the definition of the “outbound virtual” boundary for a group design model. When determining the logical distribution of the non-local resources, consider the following:  The directory service infrastructure that supports access and use of the non-local resource must be either an Active Directory infrastructure or a legacy (for example) Windows NT 4.0 domain infrastructure.  The non-local resource may be logically located within the same domain as a group design model, which has a smaller “actual” boundary than the boundary of the domain.  The logical distribution of the resource must relate directly to logical components of the directory service infrastructure where possible. For example, if the required nonlocal resources are files shares on three file servers in a trusted external domain, then the logical distribution of the resource is not the location of the file shares on the file system of the servers. Instead, to support the definition of the “outbound virtual” boundary of a group design mode, the logical distribution of these resources is represented by the logical distribution of the computer accounts for the file servers within the supporting directory service infrastructure of the trusted external domain. This is necessary just to determine the “outbound virtual” boundary for the group design model, respective to the “actual” boundary of the group design model, and the logical location of the non-local resource. Note that the actual “resource” security group in the destination directory service that will host the “account” group from the design model may reside in another component of the directory service.  Where it is possible to identify the requirement to access multiple non-local resources by “local” security principals, it is important to establish all of the logical locations (within the supporting directory service infrastructure) for each of these resources. When determining the smallest Active Directory infrastructure component or component of a legacy directory service that collates the required non-local resources into a logical container or boundary, consider the following:  The provision of an access control infrastructure for a non-local resource by an Active Directory infrastructure permits the identification of several components that can form the logical boundary or container, such as OUs, domains, trees of domains, forests, or entire Windows Server 2003 Active Directory infrastructures. However, where the access control infrastructure for a non-local resource is a legacy (Windows NT 4.0) directory service infrastructure, the only possible components of the directory service that can provide the smallest logical container or boundary for the non-local resources are general domains or resource domains.  The smallest selected container or logical boundary must ideally, and exclusively, collate just the required non-local resources. For example, an OU that holds just shared folder objects that are all required non-local resources. Where it is not possible to identify a container or logical boundary that permits the exclusive collation of the required non-local resources (as represented within the directory service infrastructure), then select the next largest container and define exclusion statements. The following is an example of the definition of the “outbound virtual” boundary for a group design model where “local” security principals only require access to shared folder objects access controlled by a child domain in the same forest. The shared folder objects are all exclusively located within an OU named “Files Shares”. Hence, the “outbound virtual” boundary is defined as “all objects within the OU named “File shares”, that resides within the child domain <name_of_domain>”. Using the above information, execute the following:

Page 196 of 354

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

© 2004 Mustan Bharmal

 Determine and document the requirements for “local” security principals to access non-local resources, and hence the requirement to define an “outbound virtual” boundary for the group design model  Where there is a requirement to define the “outbound virtual” boundary, then execute the following:  Identify and document the specific non-local resources to which “local” security principals will require access. Where it is not possible to identify all or any specific non-local resources, then skip the next steps and re-execute them following the determination of this information.  Where it is possible to identify all or some of the specific non-local resources, then determine and document the following: • Identify the logical distribution of the representative objects of the required non-local resources within their supporting directory service infrastructure. • Identify the smallest container or logical boundary that can exclusively collate all of the required non-local resources. Where this is not possible to identify, then identify the next largest container or logical boundary and define exclusion statements.  Determine and document the “outbound virtual” boundary for each required group design model • Factor A13: Determination of the “inbound virtual” boundary of a group design model ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the “inbound virtual” boundary for a group design model. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with all of the above criteria within an organisation: The “inbound virtual” boundary for a group design model identifies the non-local (with respect to the group design model) security principals that require access to the “local” resources within the “actual” boundary of a group design model. Note that this design methodology defines the boundary with respect to the following two factors:  The logical locations for the non-local security principals within the supporting directory service infrastructures  The “actual” boundary of the group design model Note that the definition of the “inbound virtual” boundary does not respect the logical location of the source “account” security group which will require membership to the “resource” group from the group design model. This is because the source “account” security group may reside in another component of the supporting directory service infrastructure. It is important to identify the “inbound virtual” boundary for a group design model as it permits an organisation to implement a more granular access control infrastructure for “local” resources. It is possible to identify security principals as being “non-local” to the group design model because either:  They were outside of the scope of the security principals that defined the “actual” boundary for a group design model, or

Page 197 of 354

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

© 2004 Mustan Bharmal

 They were outside of the boundary of the factor that collated the resources within the “actual” boundary for a group design model. For example, there is a requirement to collate “local” resources (“local” to a group design model) based upon the logical location of the representative objects for the resources within three domains of an Active Directory infrastructure. Hence, the “non-local” security principals are those that are outside of the boundaries of these three domains. This is because (by simple logic) if the boundaries for these three domains defines the “actual” (and hence local) boundary for “local” resources, all the security principals within these domains are hence also within the “actual” boundary and are hence “local”. Where it is not possible to identify the requirements to support access to “local” resources (access controlled by security groups generated by a group design model) by “non-local” security principals, then there is no requirement to define the “inbound virtual” boundary for the group design model. Note that it is not possible for all group design models to define an “inbound virtual” boundary, due to either:  Technical limitations based upon the scope(s) of groups supported by the group design model (see table above for details), or  The fundamental rules for all group design models that state that the group design model must generate the group that requires assignment of permissions to resources. This rule hence excludes all group design models that do not employ the “account” and “resource” group method from defining an “inbound virtual” boundary.  Thus, the only standard and hybrid group design models that can receive “in” (to the “actual” boundary) account groups generated by another external group design model, and thus can define an “inbound virtual” boundary, are:  AGDLP (the source group design model can send out Global account groups (with non-local security principals as members) only to a destination Domain Local group assigned permissions to the non-local resource)  AUDLP (can send out Universal account groups (with non-local security principals as members) only to a destination Domain Local group assigned permissions to the non-local resource)  AGUDLP (can send out: • Global account groups (with non-local security principals as members) only to a destination Universal group (which will be a member of a Domain Local group assigned permissions to the non-local resource), or • Universal groups with Global account groups (with non-local security principals as members) only as members, only to a destination Domain Local group assigned permissions to the non-local resource)  AGUP (can send out Global account groups (with non-local security principals as members) only to a destination Universal group assigned permissions to the nonlocal resource) It is necessary to adopt the same approach to determine the “inbound virtual” boundary for a group design model as for the process to determine the “outbound virtual” boundary for a group design model. The approach to determine the “inbound virtual” boundary for a group design model identifies the requirement to determine the following:  Identify the non-local security principals that will require access to the “local” resources access controlled by the group design model.

Page 198 of 354

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

© 2004 Mustan Bharmal

 Identify the logical distribution of these non-local security principals within the supporting directory service infrastructure. The supporting directory service infrastructure may be an internal Active Directory infrastructure or external (legacy) directory service infrastructure.  Identify the smallest components of the supporting directory service infrastructure, which can exclusively, or non-exclusively, reflect the distribution of the non-local security principals and permit collation of the selected security principals into one or more logical containers / boundaries.  Where multiple components of an Active Directory infrastructure are required to represent the distribution of the selected security principals, collate all such components together to define the “inbound virtual” boundary for a group design model. When identifying the non-local security principals that will require access to the “local” resources, consider the following:  It may not be possible at this stage in the design of an Active Directory infrastructure to determine the specific non-local security principals that will require access to the “local” resources. In these scenarios, it is sufficient to establish initially whether there will be any future requirements to permit access to “local” resources by non-local security principals. Upon identification of such requirements in the future, it is necessary to complete this process to determine the “inbound virtual” boundary for a group design model.  The non-local security principals may only be those security principals supported by an Active Directory or legacy (Windows NT 4.0) directory service infrastructure. Where the supporting directory service infrastructures is not an Active Directory or legacy infrastructure, then consider these non-local security principals outside of the scope of the “inbound virtual” boundary for a group design model.  It is necessary to determine the requirement for singular, occasional, or regular access by non-local security principals to “local” resources. Where there is a requirement for a group design model to support only singular or very infrequent access by non-local security principals, then consider these non-local security principals as being outside of the scope of the “inbound virtual” boundary for a group design model.  It is necessary to identify only those non-local security principals that may access the “local” resources using only the existing or planned Active Directory, trust relationship, and DNS infrastructure, and that infrastructure can maintain sustained access by these non-local security principals to the “local” resources. Absence of a supporting infrastructure to permit access by these non-local security principals to “local” resources will preclude these security principals from the “inbound virtual” boundary for a group design model.  The owner(s) of the “local” resources must identify which non-local security principals they will grant access to the “local” resources. If none of the candidate “non-local” security principals will receive access to the “local” resources, then preclude these security principals from the “inbound virtual” boundary for a group design model. However, where specific non-local security principals are to receive exclusive access and use of the “local” resources, then it is necessary to ensure that the appropriate account group (relative to the appropriate target account or resource group for the (destination) group design model) is available to collate, exclusively, only those privileged non-local security principals.  Note that there may be a security concern regarding the access to “local” resources by non-local security principals that logically reside within a trusted domain. Creating a trust relationship with an external domain may allow undesirable security principals into the trusting domain. Hence, consider the requirement to configure

Page 199 of 354

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

© 2004 Mustan Bharmal

“selective authentication” on the trust relationships. For details on the configuration of selective authentication, see the:  Organisation-Wide Active Directory Plan process to “design federated forest infrastructures” for inter-forest trust relationships, and the  Domain Plan process to “design external trust relationships” for external trust relationships The logical distribution of the candidate non-local security principals will contribute to the definition of the “inbound virtual” boundary for a group design model. When determining the logical distribution of the non-local security principals, consider the following:  The supporting directory service infrastructure for the non-local security principals must be either an Active Directory or legacy (Windows NT 4.0) directory service infrastructure.  The non-local security principals may be logically located within the same domain as the group design model, which has a smaller “actual” boundary than the boundary of the domain.  The logical distribution of the non-local security principals may be within one or more OU, domain, tree, or forest infrastructures of a supporting Active Directory infrastructure. When determining the smallest Active Directory infrastructure component or component of a legacy directory service that collates the permitted non-local security principals into a container or logical boundary, consider the following:  The smallest selected container or logical boundary must ideally exclusively collate just the permitted non-local security principals within their supported directory service infrastructure. Where it is not possible to identify such a container or logical boundary, then it is necessary to identify the next largest container or logical boundary, and define exclusion statements, to exclude the un-required non-local security principals.  The use of selective filtering on a trust relationship, for the exclusive support of the management of access to local resources by non-local security principals in a trusted domain, can provide a logical container. With selective authentication, only those non-local security principals assigned (indirectly or directly) permissions to access local resources are permitted to cross the trust-relationship. This hence provides a “logical container” for the permitted non-local security principals. Using the above information, execute the following:  Determine and document the requirements for “non-local” security principals to access “local” resources, and hence the requirement to define an “inbound virtual” boundary for the group design model  Where there is a requirement to define the “inbound virtual” boundary, then determine and document the following:  Identify the specific non-local security principals that will require access to the “local” resources. Where it is not possible to identify all or any specific non-local security principals, then skip the next steps and re-execute them following the determination of this information.  Where it is possible to identify all or some of the specific non-local security principals, then determine and document the following:

Page 200 of 354

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

© 2004 Mustan Bharmal • Identify the logical distribution of the representative objects of the permitted non-local security principals within their supporting directory service infrastructure. • Identify the smallest container or logical boundary that can exclusively collate all of the required non-local security principals. Where this is not possible to identify, then identify the next largest container or logical boundary and define exclusion statements.  Determine and document the “inbound virtual” boundary for each required group design model. 6.9.4.2. Determination of the Relationship(s) Between Multiple Group Design Models Where it is determined (from the previous process) that the boundaries (actual, inbound virtual, and outbound virtual) of two or more group design models overlap or have a hierarchical relationship within the boundary of an ORMI, then consider the following information when determining the relationship(s) between multiple group design models: • Factor A14: Understanding and determining the types of relationships between group design models ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand and determine the types of relationships that are possible between two or more group design models. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with all of the above criteria within an organisation: A relationship between two or more group design models depends on the overlap of one or more of the defined boundaries (“actual”, “outbound virtual” and “inbound virtual”) for a group design model. This design methodology defines an overlap as the presence of a “local” or “non-local” resource or security principal within one of the defined boundaries of two or more group design models. For example, a security principal, “user1” is “local” to one group design model (GDM1) and “non-local” (within the “inbound virtual” boundary) to another group design model (GDM2). Hence, there is overlap between these two group design models. Where it is possible to identify such overlaps between two or more group design models, then it is important to identify the type of relationship the group design models have between them. This design methodology identifies two types of relationships possible, defined simply as either an “OK” or a “bad” relationship, and specific criteria available for their determination (see below for details). (Note that an “OK” relationship does not imply “good” but instead just not “bad”). It is very important to define and categorise the relationships between multiple group design models as overlaps in their boundaries may lead to conflicts and issues around management of access control for resources. A “bad” relationship between two or more group design models is one where it is possible to identify between the models, all of the following criteria:  The presence of one or more resources as being “local” or “non-local” to two or more group design models (and hence within the “actual” or “outbound virtual” boundaries of the group design models)

Page 201 of 354

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

© 2004 Mustan Bharmal

 The presence of one or more security principals as being “local” or “non-local” to two or more group design models (and hence within the “actual” or “inbound virtual” boundaries of the group design models)  The requirement to support access to one or more of these “local” or “non-local” resources, common to two or more models, by one or more “local” or “non-local” security principals (common to two or more models) via two or more of these models. The following diagram illustrates this, where two group design models (GDM1 and GDM2), have one security principal and resource in common:
TWO x ONE-WAY EXTERNAL TRUST RELATIONSHIPS

4 2 1 8
Print Queue Volume Volume Print Queue

5

6

7

3
© 2004 MUSTANSHI
R

BHAR

MAL

Acme.com.
LEGEND: 1 2 3 4 5 6 7 8

Natsum.com.

“Actual” boundary for Acme.com’s group design model (GDM1) “Local” security principals within the “actual” boundary for GDM1 “Local” resources within the “actual” boundary for GDM1 “Non-Local” security principal ( ) within the “inbound virtual” boundary for GDM1

“Actual” boundary for Natsum.com’s group design model (GDM2) “Local” security principals within the “actual” boundary for GDM2 “Local” resources within the “actual” boundary for GDM2 “Non-Local” resource ( ) within the “outbound virtual” boundary for GDM2

Figure 35.14: Example of Relationships between Two Group Design Models In the above example, it is possible to identify the first two criteria for an inter-group design model relationship, as the security principal in Natsum.com is local to GDM2 and non-local to GDM1, and the resource in Acme.com is local to GDM1 and non-local to GDM2. This scenario is perfectly acceptable (and is an “OK” relationship) until it is possible to identify the third criteria. For example (using the above illustration), GDM2 generates an outbound security group containing the local security principal to provide this user with read only access to the non-local resource in Acme.com. However, GMD1 also takes the same security principal (as an inbound non-local security principal) into a local resource group, but which has being assigned full access permission to the (local to GDM1) resource. Hence, the security principal gains a greater level of access to the resource via GDM1 than via its local group object design model, GMD2. This is hence a “bad” relationship between the two group design models, as there is interaction for access to a common resource and hence confusion in management of access control.

Page 202 of 354

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

© 2004 Mustan Bharmal

Note that some group design models cannot have an “OK” or a “bad” relationship at all, as they are restricted by design from defining “inbound virtual” and “outbound virtual” boundaries for resources and security principals. Using the above information, execute an analysis to determine and document, within each required group design model, whether it is possible to determine the following:  Compliance with criteria one and two above, (and hence an “OK” relationship)  Compliance with all of the criteria above (and hence a “bad” relationship) • Factor A15: What to do if identify “OK” or “bad” relationships between two or more group design models ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation has:  Identified the presence of an “OK” or “bad” relationship between two or more of the required group design models  Wishes to determine the next steps upon identification of such relationships ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with all of the above criteria within an organisation: Where it is possible to identify an “OK” relationship between two or more group design models, consider the following:  The identification of an “OK” relationship between two or more group design models will not generate any issues surrounding the management of access to common resources. Hence, this relationship can exist without due concern. However, it is highly possible for this scenario to change within a dynamic production environment.  As this scenario is likely to change, the next step, upon identification of such a scenario, is to highlight it as a variable. This variable requires monitoring during the processing of change requests for the expansion or compression of the boundaries of the respective group design models. Where it is possible to identify a “bad” relationship between two or more group design models, consider the following:  The identification of a “bad” relationship can, as discussed, generate issues surrounding the management of access to common resources. The next steps that require execution upon identification of a “bad” relationship depend upon several factors.  For example, if the two group design models share the same owner, then it is simpler to ensure no resource access conflicts, and hence the next step for this identified scenario is to monitor the situation and evaluate all change requests for resource access to common resources.  If two or more owners collectively own the resource shared between two or more group design models, and / or the group design models, then there must be regular interaction between the owners for the joint evaluation of all resource access requests. This interaction can help to ensure no conflicts arise in resource access by security principals.  An alternative to these two approaches is to alter the content of the respective boundaries of the group design models to ensure no overlap in resources and security principals, where common access is inevitable.

Page 203 of 354

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

© 2004 Mustan Bharmal

Using the above information, identify and document the required steps to take upon identification of an “OK” or “bad” relationship between two or more group design models. 6.9.4.3. Determination of the Rules for Generation of Security Groups Consider the following information when determining the rules for the generation of security groups by a group design model: • Factor B4: Understanding the components and approach for the determination of the rules for generation of security groups ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the components and the approach for the determination of the rules for generation of security groups. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with all of the above criteria within an organisation: Execution of the above components of this process has permitted the determination of the following information:  The type(s) (and numbers) of standard and / or hybrid group design models required  The scope of security groups each required group design model is permitted to generate  Where there is a requirement for a group design model that employs two or more security group scopes, then the:  Role of each security group scope (account group, resource group, and vehicle group (such as the Universal group in the AGUDLP group design model)), and the  Nesting order of multiple scopes of security groups  The identification of the “local” and “non-local” resources and security principals via the determination of the “actual”, “inbound virtual” and “outbound virtual” boundaries for each required group design model. The final step in the design of a group design model is to define, for each required group design model, the rules for the generation of security groups. Without clear rules to control the generation of security groups, it is very easy to generate a confusing and superfluous security group infrastructure with groups that duplicate the functions of existing groups, and so on. The rules for the generation of security groups are hence the crux for all group design models. When determining the rules for the generation of security groups, the following approach is proposed:  For group design models that support only a single group scope, determine the parameter and the subsequent criteria for the generation of security groups (for example, the ADLP, AGP, or AUP group design models). The four possible parameters for the generation of security groups for these models are:  To support metadata aspects of security principals  To support metadata aspects of resources  To support specific permissions / sets of permissions, for security principals, on metadata aspects of resources

Page 204 of 354

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

© 2004 Mustan Bharmal

 For group design models that support two or more scopes for security groups, determine the criteria for the generation of security groups, respective to the appropriate functions of the security groups. For example, the AGDLP group design model supports two functions for security groups (“account” (Global) groups and “resource” groups (Domain Local) groups). Hence, for the “account” groups, it is necessary to determine the rules for the collation of security principals into an account groups to support specific metadata aspects of security principals.  For the “resource” groups, it is necessary to determine the rules for the generation of security groups to support:  To support metadata aspects of resources  To support specific permissions / sets of permissions, for security principals, on metadata aspects of resources Hence, the components of the rules for the generation of security groups are:  For group design models that support only a single group scope, identification of the criteria for the collation of:  Security principals into security groups  Resources to support the generation of security groups  Permissions or sets of permissions on resources to support the generation of security groups  For group design models that support the “account” and “resource” group types, identification of the criteria for the collation of:  Security principals into security groups (for the “account” types groups)  Resources to support the generation of security groups (for the “resource” groups)  Permissions on resources to support the generation of security groups (for the “resource” groups) The following section of this sub component, to determine the rules for the generation of security groups, presents the considerations for the options mentioned above. • Factor A16: Generation of security groups to support metadata aspects of security principals ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the criteria for the generation of security groups to support metadata aspects of security principals. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with all of the above criteria within an organisation: The criteria for the collation of security principals into security groups must define whether a security group requires generation, by a group design model, to support one or more of the following metadata aspects of security principals:  The specific type(s) of “local” or “non-local” security principals, such as, for example, the requirement to generate a security group to collate:  Just user accounts

Page 205 of 354

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

© 2004 Mustan Bharmal

 Just user accounts for services or applications  Just computer accounts  Just computer accounts for servers, desktops, laptops and so on  Specific memberships of “local” or “non-local” security principals to departments / divisions within an organisation, such as, for example, the requirement to generate a security group to collate:  Just security principals that belong to the Sales department  Just security principals that belong to the IT support department, and so on  Specific physical and / or logical locations for “local” or “non-local” security principals within an organisation and / or directory service infrastructure, such as, for example, the requirement to generate a security group to collate:  All security principals within the New York office location  All security principals within the entire organisation  All security principals within an OU in a domain  All security principals within the 3rd floor of building 3, and so on  Specific instances of “local” or “non-local” security principals that require collation into a security group to support two or more common metadata aspects. For example, the requirement to generate a security group to collate just “user1”, “user2”, and “user5”, and “workstation2”, as these security principals are:  In the same physical location, and  Have the same membership to a department or division within an organisation (for example, they all represent users and computers within the IT support department) When determining the criteria for the generation of security groups to support metadata aspects of security principals, consider the following:  The collation of security principals into security groups, to support metadata aspects of the security principals, is one of the most common criteria for security group generation.  In order to maintain consistency in security group generation, and facilitate the management and troubleshooting of a security group infrastructure, it is important to restrict the number of criteria used, based upon the metadata aspects of security principals, to generate the security groups.  The criteria selected must be simple and have a broad scope of application across all or most of the “local” and “non-local” security principals supported by a group design model.  The criteria selected must reflect existing and stable metadata aspects of security principals, such as directory service containers or logical boundaries, departments and divisions, types of security principals and so on. It is important not to select metadata aspects of security principals that are transient in nature, as this will naturally affect the lifespan and application of the criteria for generation of the security groups.

Page 206 of 354

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

© 2004 Mustan Bharmal

Use the above information to execute an analysis to determine and document the required criteria, for each group design model, to qualify the collation of security principals into security groups. • Factor A17: Generation of security groups to support the metadata aspects of resources ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the criteria for the generation of security groups to support metadata aspects of resources. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with all of the above criteria within an organisation: The criteria for the collation of resources must define whether a security group requires generation, by a group design model, to support one or more of the following metadata aspects of resources:  The specific type(s) of “local” or “non-local” resources, such as , for example, the requirement to generate a security group to support:  Just security principals (as resources that require management by other security principals)  Just shared folder objects  Just printer objects, and so on.  The specific physical or logical location of resources within an organisation / directory service infrastructure, such as, for example, the requirement to generate a security group to support:  All objects within an OU / OU infrastructure in a domain  All objects representing users and computers within the third floor of building one, and so on.  The ownership / membership of resources to departments / divisions within an organisation, such as, for example, the requirement to generate a security group to support:  All resources, represented as Active Directory objects or controlled by an Active Directory infrastructure, that are owned by the Sales department  All computer account objects for servers controlled by the server team in the IT support department, and so on.  Specific instances of “local” or “non-local” resources to support the generation of a security group to support two or more common metadata aspects of the resources. For example, the requirement to generate a security group to support just “user1”, “user2”, and “user5”, and “workstation2”, as these security principals are:  Logically located within one OU, and  Belong to a specific department within an organisation When determining the criteria for the generation of security groups to support metadata aspects of resources, consider the following:  Using the “type” of a resource as the metadata aspect to support the generation of security groups is acceptable as it generates a fewer number of groups. The use of this metadata aspect of a resource is to support the generation of security groups

Page 207 of 354

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

© 2004 Mustan Bharmal

that are required to manage resources based exclusively upon the type of the resource. For example, the generation of resource groups (assigned permissions to resources) for management of just user accounts, or just computer accounts, and so on. This is a common criterion for the generation of security groups as:  The management of resources focuses, predominantly, around the type of the resource, rather than specific instances of resources and so on.  The use of this criterion has a wider scope of application across “local” and “nonlocal” resources supported by a group design model  The use of both the logical location of resources within a directory service infrastructure, and the ownership / membership of a resource to a division or department supports the criteria for the generation of security groups by an autonomous division within an organisation. Use the above information to execute an analysis to determine and document the required criteria, for each group design model, to qualify the generation of security groups to support metadata aspects of resources. • Factor A18: Generation of security groups to support permissions on resources ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the rules for the generation of security groups to support permissions / sets of permissions on resources. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with all of the above criteria within an organisation: The criteria for the collation of permissions on resources must define whether a security group requires generation, by a group design model, to support one or more of the following metadata aspects of permissions on resources:  Specific categories / sets of permissions for specific metadata aspects of “local” or “non-local” resources, such as the requirement to generate a security group for the collation of security principals to be assigned the following examples of permissions (via, for example, a delegation of control exercise):  The permission to create and delete one or more specific types of resources, such as user accounts, computer accounts, OUs, groups, shared volume objects, printer objects, and so on.  The permission to read and write specific attributes on specific resources collated into an OU, and so on.  Specific permissions for specific metadata aspects of “local” or “non-local” resources, such as the requirement to generate a security group for the collation of security principals to be assigned the following examples of specific permissions (directly, or via, for example, a delegation of control exercise):  The deny permission to view, access, read, write (etc) all resources within a specific directory service container such s an OU  The full control permission for a specific type or instance of resource, and so on When determining the criteria for the generation of security groups to support the permissions / sets of permissions (for assignment to security groups) on resources, consider the following:  It is possible to assign permissions to directory service containers as well as to security groups, for the management of resources. Hence, where appropriate,

Page 208 of 354

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

© 2004 Mustan Bharmal

consider the use of the existing or planned directory service containers, such as OUs, to manage the appropriate resources, rather than the generation of security groups for this function. This approach will help to reduce the number of security groups generated, and facilitate the management of resources without additional overheads.  The use of permissions / sets of permissions as the criteria for the generation of security groups support the use of groups that apply common sets of permissions for resources logically distributed across a directory service infrastructure. For example, there is a requirement to generate a security group to support the permission to reset passwords on all user accounts. This security group may be applied to multiple locations within the boundaries of a group design model where user accounts reside, such as in separate domains, or OUs within domains. Use the above information to execute an analysis to determine and document the required criteria, for each group design model, to qualify the generation of security groups to permissions / sets of permissions for “local” or “non-local” resources. 6.9.4.4. Determination of the Naming Convention Requirements for Multiple Group Design Models Consider the following information when determining the naming convention requirements for multiple group design models: • Factor B5: Understanding naming model components ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirements for the design of two or more group design models, and  Wishes to understand and determine the required components of a naming convention for group design models ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with all of the above criteria within an organisation: Where an organisation has identified the requirements for the design of two or more group design models, it is important to assign a name to these models to permit identification of, and distinction between, the models. Group design models are not represented within an Active Directory infrastructure as objects and hence do not require compliance with any standard naming conventions or models. However, as the IT administration of an organisation will reference these models on a frequent basis, the names assigned to them should be informative and permit intuitive deduction of general information about the model. Examples of typical components of a naming convention that can constitute a name for a group design models are:  An acronym or abbreviation which identifies that the assigned name references a group design model, such as “GDM”  The name of the owner(s) of the group design model, such as a department, or division  The type of group design model (such as “ADLP”, AGDLP”, “AGUP”, and so on)  The directory service container or logical boundary that represents the “actual” boundary of the group design model

Page 209 of 354

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

© 2004 Mustan Bharmal

Use the above information to execute an analysis to determine the required components (from the above examples, or other components not mentioned here) for the naming convention for group design models. • Factor A19: Determination of the design requirements for a group design model naming convention ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation  Has identified the required components for a group design model naming convention  Wishes to determine the design requirements and required formula for a group design model naming convention ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with all of the above criteria within an organisation: Following the identification of the required naming components, it is possible to determine a formula for a naming convention for group design models. An example of a naming convention formula for a group design models within an organisation is <acronym prefix to denote this name references a group design model>_<abbreviation of type of group design model>_<abbreviation of directory service container / logical boundary that defines the “actual” boundary for a group design model>. This hence produces, for example “GDM_AGDLP_Natsum” as the name of a standard group design model (AGDLP) with an actual boundary of the domain “Natsum.com”. Use the above information to execute an analysis to determine and document the design requirements for a naming convention for group design models. 6.9.5. Design of Each Required Group Design Model The final stage in this process is to collate all of the identified design requirements for each group design model, and the group naming convention, into a process that reflects all identified rules. Consider the following information when creating a design for each required group design model and the group naming convention: • Factor D1: Understanding the required content of group design models, and generation of the design for each required group design model ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the required content for each required group design model, and generate the design for the required group design model(s). ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology requires the content of each required group design model to reflect all of the identified requirements gathered during the analysis phase of this process. This design methodology proposes that each required group design model comprise the following content:  A brief summary of the type, boundaries (actual, inbound and outbound virtual), and owner(s) of the group design model, and so on

Page 210 of 354

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

© 2004 Mustan Bharmal

 A list of the specific administrators permitted to use each group design model to generate security groups, and the permissions and group memberships required by these administrators.  A detailed set of instructions for the use of each group design model, including:  Checklist for pre-execution tasks, such as: • Ensuring compliance with change control procedures to generate a change request for the generation of a new group, or the modification of an existing group • Gathering all the required information prior to the use of the group design model • Running GPO modelling and planning exercises to determine the impact of changing a security group infrastructure on GPO application and inheritance  Checklists for execution tasks to follow the process flow chart in the group design model Use the above information to generate the design for the required content for each required group design model. • Factor D2: Understanding the required format of group design model, and generation of the design for the format of each required group design model ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the required format for each required group design model. ♦ 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 format of the actual group design model is a flow chart that reflects all of the rules for group generation to support each required standard or hybrid design model for security groups. Where progress through the flow chart determines the requirement for the generation of a new group, then the final step in the flow chart for each required group design model will be the execution of the group naming convention flow chart. This will hence determine the required name for each generated group. Use the above information to generate the design for the required format of each required group design model. 6.9.6. Determination of the Design Requirements for the Security Group Infrastructure Consider the following information when determining the design requirements for the security group infrastructure of an ORMI within this domain: • Factor B6: Understanding the requirements for the design of the security group infrastructure that require determination ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the requirements that require determination to design the security group infrastructure. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation:

Page 211 of 354

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

© 2004 Mustan Bharmal

The analysis and design activities so far have determined the following information:  The following security group requirements to support an access control infrastructure for in-scope resources and services:  The security principals that require collation into custom security groups for assignment of access permissions  The scope and functions of the security groups required to support an access control infrastructure  The custom security group requirements to support the GPO and DOC infrastructures for an ORMI  The number and types of group design models required to support the generation of custom security group  The design requirements for each required group design model Using the information above, it is necessary to determine the following requirements to generate a design for the implementation of the security group infrastructure:  Determination of the total number of security groups required for the implementation of the security group infrastructure  Assignment of a group design model to security group generation tasks within the security group infrastructure  Determination of the scope and function for each required security group  Determination of the member security principals for each required security group  Determination of the name for each required security group  Determination of the logical location (OU) for the generation of each required custom security group within an ORMI • Factor A20: Determination of the design requirements for the implementation of the security group infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to collate all custom security group requirements to determine the design requirements for the implementation of the security group infrastructure. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: In order to implement the design for a security group infrastructure, it is necessary to know all relevant details for the design of each required custom security group. This design methodology proposes the following approach to determine all of the relevant requirements for the design of the security group infrastructure:  Analyse all of the following identified requirements for the generation of custom security groups:  The requirements to support proactive access control, using a metadata-based access control infrastructure, for in-scope resources and services

Page 212 of 354

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

© 2004 Mustan Bharmal

 The requirements to support the targeting of GPOs to security principals within the ORMI  The requirements to support the assignment of DOC permissions to security principals within the ORMI  Collate all identified support requirements for the security group infrastructure and execute an analysis to identify any patterns in security group requirements, and hence opportunities to consolidate custom security group requirements.  Use the following example criteria to determine the opportunity to consolidate custom security group requirements:  It is possible to identify one or more custom security group requirements that have one or more of the following criteria in common: • The specific member security principals of the security groups (for example, potential custom security groups “group A” and “group H” have the same member security principals) • The membership criteria for the security groups is exactly the same (for example, the membership criteria for “group A” and “group B” match as they both state that membership to these groups is only for security principals that have a job title of “analyst” and belong to the “Help Desk” department of an organisation. The actual member security principals may not remain constant, but the membership criteria is constant.) • The scope of the custom security groups match, and hence consolidation of two or more potential security groups will not affect the function or operation of the groups.  The consolidation of the groups will not affect the function and / or the variable membership criteria for the group (for example, a custom security group requirement is unique to a resource and is not portable to support another requirement without influencing the function and membership criteria.)  The onus is with the owner(s) of the ORMI to define the specific criteria required to identify opportunities for the consolidation of custom security group requirements. Note that this step, to consolidate security group requirements, is one of the foundations for the involvement of this process within the design of an ORMI. Most organisations determine custom security requirements for GPO, DOC, and resource / service access control infrastructures independently of each other, and hence typically generate multiple instances of security groups that have the potential for consolidation. This hence unnecessarily increases the administrative overheads for a security group infrastructure.  Where it is possible to identify two or more custom security group requirements that comply with the above criteria, then:  Consolidate the custom group requirements, and  Note the change in the scope of the function of the consolidated group  Following the identification of all custom security group requirements and opportunities for group consolidation, determine the final number of custom security groups that require generation within the security group infrastructure.  Delegate custom security group generation tasks to the group design models selected for the security group infrastructure, based upon the supported scopes of groups, logical locations of security principals, and the logical boundaries of each group design model.

Page 213 of 354

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

© 2004 Mustan Bharmal

 Use the delegated group design models to determine the following for all identified custom security group requirements:  The scope and function of the custom security group  The member security principals / membership criteria  Determine the OU(s) to house the generated security groups  Use the naming model for security groups (from the “Organisation-Wide Active Directory Plan” process “design of object naming models”) to assign a name to each required security group Use the above information and approach to determine and document the design requirements for the implementation of the security group infrastructure for an ORMI within this domain. Pass to the processes “design of a GPO infrastructure” and “design of a DOC infrastructure” the names of the appropriate security groups that will support the identified GPO and DOC requirements, respectively. 6.9.7. Design of the Security Group Infrastructure Consider the following when generating the design for the security group infrastructure to support the ORMI for this domain: • Factor D3: Understanding and generation of the components of a design for a security group infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand and generate the components of the design for a security group infrastructure. ♦ 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 a security group infrastructure comprise the following components:  A detailed design document for the security group infrastructure, containing the following design information:  The details of the types of group design model selected to generate the security group infrastructure  A series of tables providing the following details for each custom security group that requires generation for the implementation of the security group infrastructure: • The name, function, and scope of the security group • The member security principals / membership criteria for the group • The logical location within the boundary of the ORMI for the generation of the security group • The group design model that generated the security group • The name for each required group design mode, using the identified naming convention

Page 214 of 354

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

© 2004 Mustan Bharmal

Where there is a requirement to create the groups within multiple OUs in the supporting OU infrastructure, include a diagram illustrating the distribution of the groups amongst the OUs. This will facilitate their administration post-implementation of the security group infrastructure in the production environment. Use the above to generate a design for the security group infrastructure required to support the ORMI for this domain.

Page 215 of 354

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

© 2004 Mustan Bharmal

7.

Design of an Organizational Unit Infrastructure
All organisations considering the design and deployment of a Windows Server 2003 Active Directory domain must consider the design and use of Organizational Units (OUs) for object management. This process requires execution a minimum of once for this domain, or once for each required object and resource management infrastructure for this domain.

7.1.

Process Objectives The objective of this process is to assist an organisation in the generation of a design for the implementation of an OU infrastructure, for each required object and resource management infrastructure (ORMI) this Windows Server 2003 Active Directory domain is to support. The design for the implemented OU infrastructure will reflect the object management requirements identified during the design for implementation of the Active Directory infrastructure for an organisation. Note that the design for the management of an ORMI, and hence the component OU infrastructure, is a component of the Active Directory Management Plan. The design of an OU infrastructure for an Active Directory domain must address several variables. This design methodology proposes the use of an OU design model that eliminates specific variables from the design, and hence permits the generation of a consistent and understandable design for OUs within the OU infrastructure. The remaining variables that require addressing must be determined during the execution of this process. The background information section below discusses the variables that this process addresses.

7.2.

Process Scope The following factors define the scope of this process: • The boundary of an object management infrastructure within this domain will dictate the scope for the supporting OU infrastructure, and hence impose a restriction on the potential locations within this domain where it is possible to generate the OUs. • The GPO policy and DOC permission requirements for the ORMI will dictate the Active Directory objects that require collation into OUs, and hence define the scope for this process. Note that this process does not provide considerations for the design of OU infrastructures to support: • Custom application directory partitions of a Windows Server 2003 Active Directory forest • Association with COM+ partitions of COM+ sets

7.3.

Background Information Before executing this process to design an OU infrastructure for an ORMI within this domain, it is important to understand the following: 1. 2. 3. The concepts and logic that form the foundation for the design approach, proposed by this design methodology, for the design of an OU infrastructure The variables that require addressing to generate a design for an OU infrastructure The variables addressed by OU design models

Page 216 of 354

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

© 2004 Mustan Bharmal

7.3.1.

Proposed Approach for Process to Design an OU Infrastructure The following statements provide the foundation and logic for the approach this design methodology proposes for the design of an OU infrastructure for an ORMI within this Active Directory domain: • The function of an OU is to collate and segregate Active Directory objects together within a domain for simplified management. • It is possible to collate or segregate Active Directory objects into OUs. The collation of objects into OUs may support the requirement to either: ♦ Reflect similar administration profiles (that reflect GPO / DOC requirements) shared by the collated objects, or ♦ Reflect the requirement to segregate the Active Directory objects from administration profiles for other similar objects via their collation into other OUs • Additionally, the potential requirements for the collation / segregation of the objects may be either: ♦ To support the execution of administrative functions (via GPO policies and / or DOC permissions) on or for the collated objects, or ♦ To support the execution of non-administrative functions on or for the collated / segregated objects • The potential objectives for the generation of multiple OUs are to support, for example: ♦ The repetitive differentiation between the collated / segregated objects, based upon their differing management requirements ♦ The segregation of objects to provide an efficient management infrastructure via the use of GPOs and DOC permissions • The potential objectives for the hierarchical arrangement of multiple OUs within an OU infrastructure are, for example: ♦ To support the efficient:  Implementation of GPO policies and / or DOC permissions via the use of policy / permission inheritance down an OU hierarchy  Administration of multiple GPOs and / or DOC permissions via the segregation of the GPOs / DOC permissions amongst multiple OUs, and hence the segregation of the target objects ♦ To support non-administrative requirements, such as the reflection of a visual relationships between the contents of multiple OUs within an OU infrastructure • Note however that this design methodology proposes to generate OUs, to collate objects, primarily to support the execution of administrative functions on or for the collated objects. The approach by this design methodology provides only limited support for the generation of OUs to support any non-administrative functions. For example, the collation of objects to reflect visually the presence of political or geopolitical patterns or differences between objects that has no bearing at all on the administrative requirements for these objects. Hence, this design methodology proposes that an OU requires consideration primarily as a tool for the administration of Active Directory objects within a domain partition. Limited support for non-administrative requirements is via the design and use of special types of OUs (“placeholder OUs”) discussed later.

Page 217 of 354

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

© 2004 Mustan Bharmal • From an OU perspective, Group Policy Objects (GPOs) and permissions (delegation of control) form the foundation for the administration of objects within an Active Directory domain. It is possible to implement a GPO at a Site, Domain, or OU level. However, within a domain, GPOs rely upon an OU infrastructure for implementation. It is possible to implement delegation of control (DOC) permissions at one of a multitude of logical containers and boundaries within an Active Directory infrastructure. However, within a domain, the majority of DOC requirements rely upon the presence of a suitable supporting OU infrastructure. • An OU provides support for a GPO and DOC infrastructure via the two fundamental concepts supported by all Active Directory OUs of inheritance and logical boundaries. The use of these two concepts for an OU in the support of a GPO infrastructure and a DOC infrastructure for a domain are explained below: ♦ All objects within an OU, including all child OUs and their contents, will inherit DOC permissions applied to an OU, as a component of, for example, a DOC infrastructure. Note that it is only possible to target DOC permissions to classes of objects and not to security groups that contain Active Directory objects, unlike GPO policies. This, however, does not impede, by default, the inheritance of the permissions by all object classes, including OUs down an OU hierarchy. This hence eliminates the requirement to re-apply the same DOC permissions lower down the OU hierarchy. An OU infrastructure, represented as a hierarchical arrangement of multiple OUs, may hence facilitate the implementation of a DOC infrastructure, designed to assign permissions to security principals for the explicit management of the Active Directory objects within that OU infrastructure. ♦ GPO policy settings within a GPO implemented at an OU will target only those objects represented directly or indirectly as access control entries (ACEs) within the access control list (ACL) of a GPO object. Target objects for a GPO may reside either within the immediate OU that represents the point of implementation of a GPO, or within any other OU inside the OU hierarchy beneath that OU. The inheritance of GPO policies down an OU hierarchy hence eliminates the requirement to link an existing GPO to one or more child OUs, or even re-create the required policy settings within another GPO for implementation on one or more child OUs. An OU infrastructure may hence facilitate the implementation of a GPO infrastructure to manage user and computer objects within that OU infrastructure. ♦ An OU forms a logical boundary for permissions and GPOs implemented onto the OU. Only direct child OUs of a parent OU inherit permissions and GPO policies implemented on the parent OU. The “child” OUs may be first, second, third and so on, generation OUs from a single parent OU. Permissions and GPO policies are not “inherited” between sibling OUs. This logical boundary hence permits the granular control of permission and GPO application within an Active Directory domain. Hence, the design of an OU hierarchy within an OU infrastructure may facilitate the requirements to control the inheritance of permissions and GPO policies and the structure of multiple OUs within an OU hierarchy can influence and control the scope of application of policies and permissions. ♦ Hence, although OU infrastructure does not rely upon a GPO infrastructure or a DOC infrastructure for implementation, this design methodology proposes the approach that the design for an OU infrastructure for a domain is only required to support the GPO and DOC infrastructure(s) within ORMIs for that domain. Based upon this proposed approach, and extending it to the execution of the analysis phase for the design of an OU infrastructure, the objectives for OU generation must only support variances in the administration of objects only where it is possible to identify: • A requirement for the administration of objects using GPO policies within one or more GPOs of a GPO infrastructure, and / or

Page 218 of 354

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

© 2004 Mustan Bharmal • A requirement for the administration of objects using permissions assigned as part of a DOC infrastructure for an Active Directory domain Note that the “process considerations” section of this process discuss, in detail, the mapping of the requirement to design an OU infrastructure (to exclusively support GPO and DOC infrastructures) to the objectives for OU generation. The following explains the relationships between OU design models and “OU infrastructures”: • Regard an “OU infrastructure” as a collection of OUs generated by an OU design model. A domain can support multiple OU design models, and hence it is possible to generate multiple OU infrastructures within a domain. • One type of OU design model may generate multiple instances of OU infrastructures. However, regard each OU infrastructure as a reflection of the type of an OU design model used to generate the OU infrastructure, and not an instance of use of an OU design model. Hence, the use of two instances of only one type of an OU design model will generate only one OU infrastructure, but with two instances. This alliance between instances of an OU infrastructure and type of OU design model is to support the approach to this process (see below) to minimise the number of types of OU design models used within this domain without compromising the number of OU infrastructures a domain may support. The greater the number of types of OU design models employed, the more complex and confusing all of the collective OU infrastructures become. 7.3.2. Variables in the Design of an OU Infrastructure The design for any OU infrastructure, when facilitated by OU design models, and as a component of an ORMI for an Active Directory domain, is required to identify and support the following eleven variables: 1. 2. 3. 4. 5. 6. 7. Identification of the specific Active Directory domain in which the OU infrastructure is to be generated Determination of the upper boundary for an OU infrastructure (defines the highest point of creation of the first level of OUs) within the selected Active Directory domain Analysis and determination of the object administration requirements (GPO and DOC requirements) within this domain that will support the collation of the objects into OUs Determination of the maximum depth for an OU infrastructure (defined by the maximum number of levels, and thus the inner perimeter for an OU infrastructure) Determination of the maximum breadth for an OU infrastructure at each permitted OU design model level (see later for details of model levels for OUs) Determination of the objectives for the generation of an OU at each model level (see later for details about the objectives for OU generation and model levels) Determination of the specific number of OUs required at each permitted OU design model level, to support the required objectives and the identified administrative functions for the collated objects Determination of the structure and relationships for multiple “admin OUs” within an OU infrastructure (see later for details of types of OUs, such as “admin OUs”) Determination of the specific content for of each OU generated by an OU design model

8. 9.

10. Determination of the specific permissions to be implemented on each OU generated by an OU design model, where required

Page 219 of 354

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

© 2004 Mustan Bharmal

11. Determination of the name to be assigned to each required OU within the OU infrastructure (the name for an OU is generated by the naming model for OUs, designed as a component of the “Organisation-Wide Active Directory Plan”) Note that the above list of variables excludes the selection of a type of OU design model. This is because the selection of a type of OU design model is not a direct variable in the design of an OU infrastructure, and hence not listed above, even though this process requires the execution of this step. Instead, the “objectives for the generation of an OU at each model level” is a variable addressed and supported by OU design models, with different objectives supported by different types of OU design models. 7.3.3. Variables Addressed by OU Design Models From the above list of eleven design variables for an OU infrastructure, OU design models identify and address the following three design variables: 1. 2. 3. Determination of the objectives for the generation of an OU at each model level Determination of the maximum depth for an OU infrastructure Determination of the maximum breadth for an OU infrastructure at each permitted OU design model level

This process to design an OU infrastructure for an ORMI will hence identify and address the following eight remaining variables: 1. 2. 3. 4. 5. 6. 7. 8. The specific Active Directory domain in which the OU infrastructure is to be generated (this variable is addressed via the execution of this process for “this” domain) The identity of the administrative function(s) for objects within this domain that will support the collation of the objects into OUs The upper boundary for an OU infrastructure The specific number of OUs required at each permitted OU design model level The structure and relationships for multiple “admin OUs” within an OU infrastructure The specific content for of each OU generated by an OU design model The specific permissions to be implemented on each OU generated by an OU design model, where required Determination of the name to be assigned to each required OU within the OU infrastructure (via the object naming model for OUs generated in the “Organisation-Wide Active Directory Plan” process “design of object naming models”)

7.4.

Process Approach When executing the process to design an OU infrastructure for an ORMI, the recommended approach is to “keep it simple”, with respect to the number and structure of OUs within the OU infrastructure. Note that the primary objective supported by this design methodology for the generation of OUs is to support the administration of Active Directory objects using GPO policies and / or DOC permissions. Hence, the combination of this approach, to “keep it simple”, with primary objective for the generation of OUs hence implies the design of an OU infrastructure consisting of only a minimal number of OUs dedicated to the efficient administration of the Active Directory objects they collate.

Page 220 of 354

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

© 2004 Mustan Bharmal

To support these recommendations for the design of an OU infrastructure, this design methodology states the following null hypotheses for this process: 1. “The use of a single custom (non-default) Organizational Unit (OU) will support all of the administration requirements for the in-scope Active Directory objects, based upon the identified GPO policy and DOC permission requirements for the ORMI within this domain” Where it is possible to disprove the first null hypothesis (and hence there is a requirement for the design of multiple OUs), then the second null hypothesis is active. The second null hypothesis states, “There is no requirement to nest any of the multiple OUs required for the OU infrastructure, as a parallel arrangement of all (multiple) OUs will support all of the administration requirements for the in-scope Active Directory objects, based upon the implementation requirements for the identified GPO policy and DOC permissions”.

2.

Note that the second null hypothesis is only applicable to “admin OUs” and not “placeholder OUs”. The section “OU Design Models” (see later) discusses these two types of OUs in detail. It is hence necessary to conduct an investigation to disprove the first null hypothesis, and where this is possible, the second null hypothesis as well. This will hence permit the determination of the actual number of OUs required, and the structure and relationships of the multiple OUs (where required) within the OU infrastructure. To reflect the requirements to disprove these null hypotheses, and to respect the presence of inter-process dependencies between the four components of an ORMI, this design methodology proposes the following approach to the design for an OU infrastructure: 1. Analyse the results from the process “design of an object and resource management infrastructure” for this domain to determine the following: a. The scope for this OU infrastructure to identify: i. ii. The in-scope Active Directory objects that require collation into OUs The upper boundary within this domain for the OU infrastructure, where an organisation has identified the requirements for the design of two or more ORMIs

b. The generic categories for the types of in-scope Active Directory objects within this ORMI, based upon pertinent and non-variable object metadata 2. Receive the following object management requirements from the process to design a GPO infrastructure for the ORMI: a. The identification of the in-scope GPO policies that are to target users and computers within the scope of the ORMI b. The identification of the categories of types of GPO policies (to permit abstraction from individual policies) c. The identification of the required configuration(s) and the categories of user and computer objects explicitly within and outside of the scope of application for each required GPO policy category

3.

Receive the following object management requirements from the process to design a DOC infrastructure for the ORMI: a. The identification of the in and out-of-scope Active Directory object classes / instances of object classes that require management via DOC permissions b. The identification of the in-scope administrative tasks for the in-scope object classes / instances of object classes c. The identification of the delegates within the DOC infrastructure

Page 221 of 354

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

© 2004 Mustan Bharmal

d. The identification of the categories of DOC permissions (to permit abstraction from individual permissions) 4. Analyse the results of the Active Directory object management requirements using GPO policies and DOC permissions to determine the following: a. The number of object administration profiles (see later for details of object administration profiles) it is possible to identify, based upon the identified scope of application of GPO policies / policy configurations & DOC permissions b. The components (Active Directory objects) of each identified object administration profile c. 5. 6. The high level categories for types of Active Directory objects within each administration profile

Select the required type of OU design model Using the selected type of OU design model, determine the following design requirements for the OU infrastructure: a. The maximum breadth and depth of OUs permitted for the OU infrastructure b. The actual number of OUs required to support all identified object management requirements using GPO policies and DOC permissions, and each OU model level c. The structure and relationships of multiple OUs within the OU infrastructure to reflect object management requirements

d. The specific content for each required OU in the OU infrastructure e. The specific permissions to be applied to each OU in the OU infrastructure, where required f. 7. 7.5. The name to be assigned to the OU via the use of the OU naming model for the organisation

Design the OU infrastructure for the ORMI

Process Components Based upon the above approach, the process to design an OU infrastructure for the ORMI within this domain is composed of the following components: • Analysis of the results from the process to “design and object and resource management infrastructure” for this domain to determine the following: ♦ The scope of the OU infrastructure for the ORMI within this domain ♦ The generic categories for types of in-scope Active Directory objects based upon pertinent and non-variable metadata for the objects • Analysis of the requirements for the management of the in-scope Active Directory objects via GPO policies and DOC permissions • Identification of the required type of OU design model to control the design and generation of the OU infrastructure for the ORMI within this domain • Determination of the design requirements for the OU infrastructure • Design of the OU infrastructure for the ORMI within this domain

Page 222 of 354

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

© 2004 Mustan Bharmal 7.6.

Deliverables of Process Components This process will have the following deliverables: • The determination of the scope of the OU infrastructure within the domain • The determination of the requirements to collate Active Directory objects into one or more object administration profiles • The determination of the specific type of OU design model required to control the generation of an OU infrastructure • The determination of the design requirements for the OU infrastructure for the ORMI within this domain • The design of the OU infrastructure for the ORMI within this domain

7.7.

Inter-Component Dependencies Each component of this process will have the following inter-component dependencies:
Domain Plan – Inter-Component Dependencies for Process to Design an OU Infrastructure
Determination of scope and upper boundary within domain for OU infrastructure Analysis of GPO policy and DOC permission requirements Selection of a type of OU design model Determination of the design requirements for the OU infrastructure Generation of the design of an OU infrastructure
© 2004 MUST
ANSHI R

START

BHAR

MAL

7.8.

Process to Design an OU Infrastructure
Domain Plan – Process to Design an OU Infrastructure
Is there a requirement for two or more ORMIs? Receive determined information from processes to design GPO and DOC infrastructures Execute A4 – A5

START

NO

Execute B1 – B6

Execute A2

Execute A3

YES

Execute A1

Execute B12

Execute B7 – B11

Execute A6 – A11

Execute D1

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

BHAR

MAL

7.9.

Process Considerations Consider the following information when executing this process to design an OU infrastructure to support all of the in-scope OU requirements for the ORMI within this domain. Presented within the following five sections are the considerations for this process: 1. 2. Considerations for the determination of the scope and upper boundary for the OU infrastructure for the ORMI within this domain Considerations for the analysis of the results of the GPO policy and DOC permission requirements for object management

Page 223 of 354

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

© 2004 Mustan Bharmal

3. 4. 5. 7.9.1.

Considerations for the selection and design of a type of OU design model Considerations for the determination of the design requirements for the OU infrastructure Considerations for the design of an OU infrastructure

Determination of the Scope and Upper Boundary of the OU Infrastructure Consider the following information when determining the scope and upper boundary of the OU infrastructure: • Factor A1: Determination of the scope and upper boundary of the OU infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirements for the design of two or more object and resource management infrastructures (ORMIs) within this domain, and  Wishes to determine the scope and upper boundary of the OU infrastructure for this ORMI within this domain ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The highest point within a domain where it is possible to create an OU, via a selected type of OU design model, defines the upper boundary of an OU infrastructure. The upper boundary for an OU infrastructure may be either the root of a domain, or an existing / planned OU within a domain. Note that the upper boundary for an OU infrastructure translates to the root of a domain where the domain is to support only one ORMI. It is important to determine the upper boundary for an OU infrastructure as this will influence the determination of the maximum depth for the OU infrastructure within this domain. The upper boundary of an OU design model defines ML1 (model level 1) for OUs created via the selected type of OU design model (see later for details of “model levels” for OU design models). The maximum depth of OUs generated within an ORMI defines the scope of the OU infrastructure. The maximum permitted depth for an OU infrastructure is in turn defined and influence by the following parameters:  The perimeter or outer boundary of the ORMI, the OU infrastructure is to support, within this domain  The hierarchical relationship between one or more ORMIs within this domain See later for the considerations in the determination of the specific maximum depth and breadth of the OU infrastructure, as this is a parameter for the determination of the design requirements for the OU infrastructure. The following diagram illustrates the concepts of the scope and upper boundary for an OU infrastructure within an ORMI, where a domain is required to support three ORMIs:

Page 224 of 354

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

© 2004 Mustan Bharmal

Upper Boundaries of OU Infrastructures Natsum.com.

OU Level 1 (Domain Root) OU Level 2 OU Level 3
OU
ORMI 1

OU

OU

OU

ORMI 2

OU

OU
ORMI 3

OU

OU

OU

OU

OU
© 2004 MUSTANSHI
R

BHAR

MAL

Scope of OU Infrastructures

Figure 36.1: Example of the Upper Boundaries for OU Infrastructures Note, within the above illustration, the following points:  The upper boundary for “ORMI 1” and “ORMI 2” are set at the root of the domain.  “ORMI 3” is hierarchically subordinate to “ORMI 2” and has an upper boundary of OU level 2 (OUL2) from the root of the domain. Note that at this stage it is important to determine only the upper boundary of an OU infrastructure and not the inner perimeters of the infrastructure. The process to determine the design requirements for the OU infrastructure will determine the inner perimeter. Use the above information to execute an analysis to determine and document the upper boundary for the OU infrastructure. 7.9.2. Analysis of Identified GPO Policy and DOC Permission Requirements Consider the following information when determining the object administration requirements for the ORMI within this domain, based upon the identified GPO policy and DOC permission requirements. Presented within the following two sections are the considerations for the execution of this step within this process: 1. 2. 7.9.2.1. Considerations for concepts to be understood prior to analysis of identified GPO policy and DOC permission requirements Considerations for the analysis of the identified GPO policy and DOC permission requirements to determine object administration profiles Pre-Analysis Concepts and Considerations Consider the following concepts and considerations prior to analysis of the identified GPO policy and DOC permission requirements: • Factor B1: Understanding the requirements for the design and use of OUs ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:

Page 225 of 354

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

© 2004 Mustan Bharmal

 Has completed the execution of the first set of analysis tasks for the processes to design a GPO and DOC infrastructure, and has hence determined the GPO policy and DOC permission requirements for the ORMI, and  Wishes to understand the requirements for the design and use of OUs ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Prior to the determination of the number of OUs required, it is important to understand the requirements for OUs, and the alternatives to OUs that require consideration. Consideration of these factors, prior to execution of the next analysis steps, will influence the results of those analysis tasks to determine the number and structure of OUs required, and the structure of a required OU infrastructure. In order to understand the requirements for OUs, it is necessary to understand first the high-level functions OUs provide within an Active Directory domain, listed below by this design methodology:  An OU represent a point for implementation of GPOs and DOC permissions  An OU may be used to provide a security boundary for GPO policies and DOC and “normal” (not DOC) permissions. The characteristic of OUs that supports this requirement is the support for the inheritance of GPO policies and DOC permissions down an OU hierarchy, and not between OU hierarchies.  An OU may be used to collate Active Directory objects (such as user, InetOrgPerson, computer account objects, printers and shared volume objects, other OUs, and so on) into logical containers, like folders in a file system, to group objects together to:  Receive GPO policies and / or DOC permissions for object administration  Hide from view of users that have visual access to the Active Directory tree  Reflect other administrative and non-administrative requirements  Reflect legacy administration requirements by emulating, for example, a Windows NT 4.0 “resource domain”, to thus permit the generation and support of a distributed administration model within one Active Directory domain. Based upon these high-level functions for OUs, consider the following information to understand the requirements for the design and use of OUs:  Although it is possible to implement (create and link) GPOs at the domain level or at an OU level, and only link (but not create) a GPO at a Site level, OUs represent the most logical point of implementation of GPOs. Implementation of GPOs at OUs within a domain facilitates the targeting of GPO policies and administration of the GPOs themselves.  The use of security groups alone to control the scope of application of a GPO does not provide an effective method to permit and control the inheritance of the policy. Hence, the use of security groups must compliment the use of OUs to facilitate the implementation of GPO policies.  It is possible to implement DOC permissions at multiple non-custom OU points within an Active Directory domain. However, as for GPOs, the use of custom OUs for the implementation of DOC permissions facilitates their implementation by:  Providing a logical boundary for application of the permissions

Page 226 of 354

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

© 2004 Mustan Bharmal

 Controlling the scope of application of permissions across multiple OUs within an OU hierarchy • Factor B2: Understanding the criteria for a “good” design for an OU infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the criteria and composition of a “good” design for an OU infrastructure ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology proposes the following aspects as being instrumental in the generation of a “good” design for an OU infrastructure:  The design of the OU infrastructure is simple, intuitive to use, and administer the objects within the OU infrastructure  The design of the OU infrastructure supports the implementation of a minimal number of GPOs and DOC permissions at the OUs  The design of the OU infrastructure supports the minimal use of linking of GPOs between OUs and OU hierarchies within an OU infrastructure  The design of the OU infrastructure supports the minimal duplicate implementation of DOC permissions at the OUs  The design of the OU infrastructure supports the minimal use of the block inheritance feature on an OU to block the inheritance of GPO policies and DOC permissions  The design of the OU infrastructure can withstand “minor” changes in administration requirements for the Active Directory objects within the OUs, due to, for example, organisational changes, restructures and so on. Note that the onus is with the organisation to interpret the definition of a “minor” change.  The design of the OU infrastructure supports the good use of a combination of security groups, WMI filters, and OUs to target the application of GPOs to the users and computers held within the OU infrastructure When executing the analysis for the design of an OU infrastructure, attempt, where possible, to attain compliance with all of these criteria for the design of a “good” OU infrastructure. • Factor B3: Understanding the pre-analysis concepts associated with the design objectives for an OU infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has completed the execution of the first set of analysis tasks for the processes to design a GPO and DOC infrastructure, and has hence determined the GPO policy and DOC permission requirements for the ORMI, and  Wishes to understand the concepts associated with the design objectives for an OU infrastructure prior to analysing the identified object administration requirements ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation:

Page 227 of 354

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

© 2004 Mustan Bharmal

Prior to analysing the identified GPO policy and DOC permission requirements, for object administration, it is important to understand the following concepts that will influence the approach taken towards the analysis, and the resulting design of an OU infrastructure for the ORMI:  The objectives for the analysis of the identified GPO policy and DOC permission requirements  The concept of object administration profiles (based on GPO policy and DOC permission requirements)  The concept of partitioning object administration profiles  The requirement to define the threshold criteria for controlling the maximum number of GPOs and DOC permissions for implementation at an OU The following factors discuss these four concepts critical to the design of an OU infrastructure. • Factor B4: Understanding the objectives for analysis of identified GPO policy and DOC permission requirements ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the objectives of this step to analyse the identified GPO policy and DOC permission requirements ♦ 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 OUs require generation and use primarily to support administration of the Active Directory objects that require collation into OUs within a domain. Based upon this approach, this step will analyse the results of the processes to design a GPO and DOC infrastructure for an ORMI, and hence determine the administration requirements for the Active Directory objects. The objective of this step is to execute an analysis of the identified GPO and DOC permission requirements to attempt to disprove the first null hypothesis stated in the process approach. Where it is not possible to disprove the first null hypothesis, then only a single custom OU is required for the ORMI. However, where it is possible to disprove the first null hypothesis, and hence prove the requirement for multiple OUs, then this step in this process will attempt to disprove the second null hypothesis, and hence determine the design requirements for the structure and relationships for multiple OUs within the OU infrastructure. This approach to disprove the stated null hypotheses will hence permit determination of answers to the following two fundamental questions:  Why collate Active Directory objects into multiple OUs and not all into one OU?  Where multiple OUs are required, why nest the OUs within each other instead of keeping them parallel and discrete to each other? There are numerous potential justifications for the segregation of Active Directory objects into multiple OUs within a domain. However, this design methodology only recognises and supports the following:

Page 228 of 354

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

© 2004 Mustan Bharmal

 The requirement to control the scope of application of GPO policies and DOC permissions to Active Directory objects. For example, there may be a requirement to remove one or more Active Directory objects from an OU (and place in another parallel and not nested OU) to remove the objects from the scope of application of:  One or more DOC permissions targeted to the object class of the object to be moved, and implemented at the OU  One or more GPOs targeted using a built-in (and not custom) security group (such as “Authenticated Users”) or WMI filter (for targeting computer account objects) implemented at the OU  The requirement to reduce the administrative overheads for management of the GPO and DOC infrastructures by reducing the number of GPOs and DOC permissions implemented at an OU. By segregating the objects into multiple OUs, based upon the scope of application of GPOs and DOC permissions, this:  Negates the requirement to implement all required GPOs and DOC permissions at a single OU  Reduces the corresponding numbers of GPOs and DOC permissions implemented at the OU  The requirement to segregate and collate Active Directory objects into multiple OUs to reflect logical and non-GPO / DOC administrative requirements. For example, the requirement to collate Active Directory objects into multiple OUs to facilitate the searching and administration of the objects without the use of GPOs and DOC permissions. There are numerous potential justifications for the nesting of OUs within parent OUs. However, this design methodology only recognises and supports the following:  The requirement to control the scope of application of GPO policies and DOC permissions to Active Directory objects. For example, to permit compliance with the design guideline (see later) to minimise the use of linking of GPO objects to multiple OUs or duplication of DOC permissions, and hence generate an efficient implementation plan for the GPOs and DOC permissions by taking advantage of inheritance down an OU hierarchy.  The use of the “placeholder” and “functional” OU design models, where OUs for object administration are nested within “placeholder OUs” (see later for details of types of OU design models)  The (restricted) requirement to reflect logical and administrative / non-administrative relationships between the contents of multiple OUs (see considerations for the supported types of OUs discussed later, and the partitioning of object administration profiles). As can be noted from above, object administration using GPO policies and DOC permissions represent the primary factors in influencing the determination of the number of OUs required, and the structure and relationships between the OUs. Hence, the objective of the analysis of identified GPO policy and DOC permission requirements is to determine the following:  The number of object administration profiles that reflect the identified GPO policy and DOC permission requirements for object administration  The contents (Active Directory objects) of the object administration profiles

Page 229 of 354

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

© 2004 Mustan Bharmal

 The categories for types of Active Directory objects within each identified object administration profile • Factor B5: Understanding object administration profiles ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the concept of “object administration profiles” that reflect the identified GPO policy and DOC permission requirements for object administration. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology has stated that the primary function (and thus the driver for the design, generation, and use) of an OU is to support the administration of the Active Directory objects that may represent the contents of an OU. The collation or segregation of Active Directory objects into OUs, based upon their requirements for administration using GPO policies and / DOC permissions, is hence essential to the design of the OU infrastructure, as it will influence the number and structure of required OUs. As stated earlier, one of the recognised and supported justifications for the design and use of multiple OUs is to permit control over the scope of application of GPO policies and DOC permissions. Using this supported justification, there is a requirement to identify opportunities to segregate and collate Active Directory objects into OUs to control the scope of application of the required GPO policies and DOC permissions. The identification of these opportunities, to collate or segregate objects into OUs, relies upon the identification of administration profiles for the objects, and, thus “patterns of variances” between the administration profiles for groups of Active Directory objects. Consider the following information to understand the concept of object administration profiles:  This design methodology identifies and supports only two scenarios where identified GPO policy / policy configurations may influence the number of admin OUs required. These are where:  It is possible to identify one or more groups of Active Directory objects (users and computers) that require specific exclusion from the reception of one or more GPO policies / policy configurations. There is also a requirement to target the policies to their in-scope Active Directory object using either a built-in security group (or not a custom security group) or a WMI filter. Hence, it is necessary to move the out-of-scope Active Directory objects to another OU to support their specific exclusion from the reception of one or more GPO policies / policy configurations.  There is a requirement to improve the efficiency of GPO management via a reduction in the number of GPOs implemented at an OU (see next factor on “threshold criteria on maximum numbers of GPOs and DOC permissions” for details). This requirement is only attainable by distributing the implementation of the required GPOs across different OUs, and accordingly, segregating the respective target Active Directory objects between the multiple OUs.  Note that it is possible to attain very granular targeting of required GPO policies / policy configurations via the use of custom security groups and carefully designed WMI filters. Hence, as it is very difficult to identify compliance with the first scenario identified above, in the majority of production environments, only a requirement to manage the numbers of GPOs implemented at an OU will influence the number of OUs required.

Page 230 of 354

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

© 2004 Mustan Bharmal

 Note that at this stage in the design of an OU infrastructure, it may not be possible to determine the specific required vehicle for targeting the GPO policies (a built-in / custom security group and / or a WMI filter). Hence, it is necessary to assume that custom security groups are required as the vehicles for targeting of all identified GPO policies.  Note also that it is possible to control the scope of application of GPOs linked at Site containers, or implemented at domain or ordinate OU containers via the use of “block inheritance” on a domain or OU. The use of block inheritance requires careful consideration as it is indiscriminate and will block the inheritance of all GPOs, unless configured with “no override”. The use of “block inheritance” on a domain or OU does not restrict the ability to implement GPOs at the domain root or OU.  GPOs are discrete objects that represent collections of individual policies, and the use of management tools such as the Group Policy Management Console (GPMC) can facilitate their management. However, the requirement to control the number of GPOs implemented at an OU is imperative as it influences the following:  The execution of the logon and startup processes for the users and computers within the OU, respectively. The larger the number of GPOs within the “GPO chain” in a domain (Site, domain, OU), the slower the logon and startup processes as all in-line GPOs require evaluation to identify compliance with the scope of application of the GPOs.  The sequencing of GPOs implemented at an OU influences the resultant configurations for the target users and computers, and hence there is a potential for policy conflicts.  The ability to manage and troubleshoot conflicting GPOs and their policies / policy configurations, as the larger the number of GPOs implemented at an OU, the longer it takes to: • Find a GPO to manage it, or • Evaluate multiple GPOs to troubleshoot a policy conflict  This design methodology identifies and supports only two scenarios where identified DOC permissions may influence the number of OUs required. These are:  It is possible to identify one or more groups of Active Directory objects that require explicit exclusion from the reception of one or more sets of DOC permissions targeted to their object class or classes. Hence, to prevent the reception of DOC permissions implemented at an OU to an out-of-scope object, it is necessary to move that object to another parallel OU. Note that due to the default inheritance of DOC permissions down an OU hierarchy, the new OU to house the out-of-scope objects must not reside within the same OU hierarchy, but in a parallel hierarchy that will not receive the un-required DOC permissions. Note that it is possible to identify “out-of-scope” objects for one or more DOC permissions based upon the nature and function of the DOC permission or a combination of the ownership of the objects and the assignee(s) for the DOC permissions.  There is a requirement to improve the efficiency of DOC permission management via a reduction on the number of DOC permissions implemented at an OU (see next factor on “threshold criteria on maximum numbers of GPOs and DOC permissions” for details). This requirement is only attainable by distributing the implementation of the required DOC permissions across different OUs, and accordingly, segregating the respective target Active Directory objects between the multiple OUs.

Page 231 of 354

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

© 2004 Mustan Bharmal

 Note that it is very difficult to control the targeting of DOC permissions, as it is only possible to target object classes and not (security) groups of Active Directory objects of a particular object class. In addition, within most IT departments for organisations, there is a distribution of object management tasks to respect owners and duty hierarchies that also influences the distribution of target objects for DOC permissions across multiple OUs, and hence the requirement to control the scope of application of DOC permissions. Hence, the requirement to control the scope of application of DOC permissions is the most influential factor in the determination of the number of OUs required.  The requirement to control the number of DOC permissions is imperative as it influences the following:  The potential for permission conflicts  The ability to manage and troubleshoot multiple sets of DOC permissions implemented at an OU. Because DOC permissions are individual ACEs (access control entries) on the ACL for an OU, and with a specific target scope based upon an object class, the presence of multiple DOC permissions can influence the ability to: • Search for a DOC permission to manage it (delete or modify) • Evaluate multiple DOC permissions to troubleshoot a permission conflict  The following diagram illustrates, very simplistically, the potential for the four supported scenarios to influence the number of OUs required, as a reflection of the administration requirements for the Active Directory objects within the scope of the ORMI:
Control scope of application of DOC permissions

Control number of GPOs implemented at an OU Potential to Influence Number of OUs Required

Control number of DOC permissions implemented at an OU

Control scope of application of GPO policies / policy configurations
© 2 0 0 4 MU S TA NS HI
R

BHAR

MAL

Influence on Number of OUs Required

Figure 36.2: Graph Illustrating Influence of Four Factors in Number of OUs Required  In addition to the above four administrative scenarios, this design methodology supports a fifth, non-administrative, scenario that will influence the number of OUs required. This is the scenario where there is a requirement to segregate and collate Active Directory objects into OUs to reflect logical and visual relationships between the objects, based upon their object metadata.  This design methodology identifies and supports only two scenarios that support the opportunity to disprove the second null hypothesis for this process, and hence permit the nesting of multiple OUs within an OU hierarchy. These are:

Page 232 of 354

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

© 2004 Mustan Bharmal

 Where it is possible to identify the requirement to control the number of GPOs implemented at OUs and nest the subsequent OUs as: • GPO policy inheritance to the nested OU(s) will not generate conflicts or conflict with scoping requirements for policies, and / or • There is a requirement to reflect one or more logical relationships between the objects within the OUs, based upon object metadata, without generating any conflicts via policy inheritance  Where it is possible to identify the requirement to control the number of DOC permissions implemented at OUs and nest the subsequent OUs as: • Permission inheritance to the nested OU(s) will not generate conflicts or apply to out-of-scope Active Directory objects, and / or • There is a requirement to reflect one or more logical relationships between the objects within the OUs, based upon object metadata, without generating any conflicts via permission inheritance Analysis of identified GPO policies and DOC permissions permits the determination of the requirements to control the scope of application of GPOs and DOC permissions and the numbers of GPOs and DOC permissions implemented at OUs. “Object administration profiles” represent the collated results of this analysis. The components of an object administration profile are:  GPO policies / policy configurations  DOC permissions  The target Active Directory objects for all or some of the GPO policies and / or DOC permissions Object administration profiles provide the basis for the collation / segregation of Active Directory objects into OUs within a domain. This is because they represent one or more groups of Active Directory objects that require one or more of the following:  Collation to permit collective exclusion from the reception of GPO policies / policy configurations scoped using a non-custom security group (such as “Authenticated Users”)  Collation to permit collective exclusion from the reception of DOC permissions for their object class  Collation to receive GPO policies / policy configurations, targeted using a noncustom security group  Collation to receive DOC permissions that are scope for their object class  Collation into OUs to support the requirements to distribute the implementation of GPOs across multiple OUs  Collation into OUs to support the requirements to distribute the implementation of DOC permissions across multiple OUs  Collation into OUs to support the non-administrative requirements to reflect logical or visual relationships between the collated objects, based upon their object metadata

Page 233 of 354

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

© 2004 Mustan Bharmal

Note that although, ideally, an Active Directory object is strictly aligned to one object administration profile, it is possible and permissible for an Active Directory object may be associated with more than one object administration profile. For example, there may be a set of GPO policies / policy configurations and / or DOC permissions targeted to a large group of user accounts. A subset of those user accounts may be the recipients of another set of GPO policies / policy configurations and / or DOC permissions, and hence a user account object may belong to two object administration profiles. The process to identify object administration profiles (see later for details of the steps) supports the attempt to disprove both the first and second stated null hypotheses for this process. • Factor B6: Understanding the partitioning of object administration profiles ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has understood the concept of object administration profiles, and  Wishes to understand the concept of partitioning of object administration profiles ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology supports the partitioning of an object administration profile, for administrative or non-administrative purposes, such as the requirement to reflect visual or logical relationships between the objects within the profile based upon their object metadata. The identification of the requirement to partition a single object administration profile will disprove the first null hypothesis for this process, and hence identify the requirement for multiple OUs within the OU infrastructure. An object administration profile may contain a multitude of seemingly disparate Active Directory objects, linked together only by common GPO / DOC requirements. As long as the partitions between the groups of objects defined by the GPO / DOC requirements are respected and not broken, the groups of Active Directory object may be partitioned along these boundaries into smaller object administration profiles where required. Each object administration profile will ultimately represent an Organizational Unit (OU) that reflects the object administration boundaries represented by the profiles. It is possible to partition an object administration profile to reflect one or more of the following three supported requirements:  The requirement to control the scope of application of GPO policies and DOC permissions  The requirement to reduce the number of GPOs and DOC permissions implemented at an OU  The requirement to segregate and collate Active Directory objects to reflect logical and visual relationships between the objects, based upon their object metadata Note the following considerations for the use of the above three scenarios to partition object administration profiles:  As discussed earlier, the requirement to control the scope of application of GPOs by moving out-of-scope Active Directory objects has a minimal effect on the number of

Page 234 of 354

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

© 2004 Mustan Bharmal

OUs required, as GPOs may be accurately targeted using security groups and WMI filters. Hence, the requirement to control the scope of application of DOC permissions is the influential factor, unless the GPOs policies require targeting using non-custom security groups.  At this stage in the design of an ORMI, it is not possible to identify the requirement to reduce the number of GPOs implemented at an OU, as the policies still require collation into GPOs. Hence, it is important to direct the requirements to partition object administration profiles based upon compliance with the threshold criteria for the maximum number of DOC permissions implemented. This step hence requires re-execution, within the process to design a GPO infrastructure, following the collation of the policies into GPOs by a selected type of GPO design model.  The requirement to reflect logical and visual relationships between Active Directory objects via the partitioning of object administration profiles functions at the objectlevel. The use of “placeholder” OUs supports this requirement at the OU level (and not for individual Active Directory objects), via the collation of “admin OUs” into OU hierarchies beneath a parent placeholder OU. The basis for the use of logic and visual relationships between Active Directory objects, to support the partitioning of object administration profiles, may be one or more of the following:  The pre-defined generic categories for types of Active Directory objects  Any other metadata for the actual objects or their Active Directory avatars, such as:  The logical or physical distribution of the objects within an organisation  The membership of the objects to divisional structures within an organisation The order in which the above three requirements are listed is significant, as the requirement to control the scope of application of GPOs and DOC permissions (more so for DOC permissions) must be considered first. The requirement to reflect logical and visual relationships between Active Directory objects, as a non-administrative requirement, takes the lowest precedence. The actual process of partitioning of an object administration profile, to support one or more of the three scenarios, will imply a different action, depending upon the requirement. The different actions for partitioning of an object administration profile that require execution, depending upon the requirement, are as follows:  For requirement to control the scope of application of GPO policies and DOC permissions, the action of partitioning the object administration profile can be to execute one or a combination of the following actions, depending upon the number of objects affected:  Move the Active Directory objects outside of the scope of application of a DOC permission to another (stage 1) object administration profile  Move the DOC permissions / GPO policies and all of their corresponding inscope Active Directory objects to another (stage 1) object administration profile. Note that it is possible to retain some of the in-scope Active Directory objects within the original profile, and thus generate a parent-child relationship between the two stage 1 object administration profiles.  For the requirement to reduce the number of GPOs / DOC permissions implemented at an OU, the action of partitioning an object administration profile can be to move the excessive GPOs / DOC permissions (and either all or some of their corresponding in-scope Active Directory objects) to another (stage 2) object administration profile. There is a requirement to move sufficient GPOs / DOC

Page 235 of 354

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

© 2004 Mustan Bharmal

permissions to permit compliance with the threshold criteria for the maximum numbers of GPOs and DOC permissions defined below.  For the requirement to reflect a logical and / or visual relationship between Active Directory objects, based upon their object metadata, it is necessary to move the Active Directory objects to another (stage 3) object administration profile. The partitioning of object administration profiles has a significant impact on the number of resultant OUs and the design for the structure and relationships of multiple OUs. Hence, to permit differentiation between the resultant partitions, undertaken to support one of the above three requirements, each partition of an object administration profile will receive a stage number, from one to three. The next section, which discusses the considerations and approach for the execution of the analysis tasks, illustrates the process to partition the object administration profiles, and the assignment of stage numbers to each resultant partition. • Factor A2: Understanding and determining the threshold criteria for maximum numbers of GPOs and DOC permissions implemented at OUs ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has completed the execution of the first set of analysis tasks for the processes to design a GPO and DOC infrastructure, and has hence determined the GPO policy and DOC permission requirements for the ORMI, and  Wishes to understand and define the threshold criteria to support the determination of the maximum number of GPOs and DOC permissions that may be implemented at OUs, which this OU infrastructure will support ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: As stated earlier, an important factor that will influence the number and structure of OUs required within an OU infrastructure is the requirement to control the maximum number of GPOs and DOC permissions implemented at OUs. Due to the fluid nature of an ORMI within a domain, and in order to provide consistent control over this requirement, it is necessary to define threshold criteria for the distribution of GPOs and DOC permissions across multiple OUs. Without such criteria, or compliance with defined criteria, the resulting OU infrastructure will become confusing and inconsistent in design and function. The objectives for the threshold criteria are hence to control the distribution of multiple GPOs and / or DOC permissions from one or a few OUs to multiple OUs, via defined criteria. When determining the threshold criteria for the maximum number of GPOs and DOC permissions supported for implementation at OUs within the OU infrastructure, consider the following:  When permissions (access control entries (ACEs) within an access control list (ACL) are implemented on a container object (such as an OU), the ACEs are copied by all objects within the container, regardless of the “Apply to” configuration of the ACE. For example, if a DOC permission is implemented on an OU, and scoped to apply only to instances of the “computer” object class, instances of all object classes in the OU would copy the ACE, although only instances of the computer object class would apply the ACE. This may not seem significant until there is a requirement to implement a large number of permissions on OUs, and the OUs contain mixtures of

Page 236 of 354

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

© 2004 Mustan Bharmal

object classes. The number of ACEs within the ACL for an object influences the size of the object, where each new ACE represents approximately 60 bytes of data. Hence, a large number of ACEs, copied to a large number of objects will increase their size significantly. Windows Server 2003 Active Directory supports “single instancing”, but only for entire ACLs and not ACEs.  The threshold criteria must support the identification of the requirement to distribute multiple GPOs and DOC permissions to multiple OUs where:  Their numbers implemented at an OU exceed a defined number  It is possible to identify the potential for conflicts in policy / permission application within that OU  It is possible to identify the potential for delaying the logon and startup processes for users and computers based upon the numbers of GPOs implemented at an OU  It is possible to identify the potential for delaying the execution of routing administration tasks, such as searching for GPOs and DOC permissions for modification or deletion  It is possible to identify the potential for delaying the execution of troubleshooting tasks to locate and evaluate multiple GPOs / DOC permissions  Define the threshold criteria as a specific number that represents the maximum number of GPOs / DOC permissions permitted for implementation at any OU within the OU infrastructure. Ensure that the maximum number is not too low, as this will result in an excessive number of OUs, or too high, as this would result in a minimal gain in performance and management of the ORMI. Use the above information to execute an analysis to determine the threshold criteria for the maximum number of GPOs / DOC permissions permitted for implementation at any OU within the OU infrastructure. This value is required to support the partitioning of object administration profiles into multiple stage 2 profiles during the next step in this process. 7.9.2.2. Analysis of GPO / DOC Requirements Consider the following information when executing the step to analyse the identified GPO policy and DOC permission requirements to identify the object administration profiles for this OU infrastructure: • Factor A3: Execution of an analysis of GPO and DOC requirements ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand and execute the process, this design methodology proposes, to analyse the identified GPO and DOC requirements. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The following approach for the execution of the analysis tasks reflects the requirement to disprove the first stated null hypothesis, and hence, where this is possible, determine the requirements for the design of a multiple OU infrastructure. This process starts with an analysis of the identified GPO policy and DOC permission requirements, followed by the collation of all in-scope Active Directory objects into a single object administration profile, which resembles a “virtual OU”.

Page 237 of 354

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

© 2004 Mustan Bharmal

It is then necessary to execute investigations to partition the object administration profiles to support one or more of the three supported requirements discussed earlier. After completion of this analysis, it is possible to translate the resultant groups of Active Directory objects, as object administration profiles, into “admin OUs”. The next step in this process, following the selection of a type of OU design model, will utilise the data on the number and content of the identified object administration profiles to determine the final number of OUs required, and the structure and relationships for all of the required OUs within the OU infrastructure. The following represents the steps in the execution of the analysis of identified GPO policy and DOC permission requirements, and are supplemented with a series of diagrams (using a very simple fictitious example) to illustrate the process.  Understand the pre-defined generic categories for types of Active Directory objects used to facilitate the targeting of GPO policies / policy configurations and / or DOC permissions. Figure 36.3 illustrates an example of predefined categories for users and computers within an organisation.
Identified Generic Categories (“CAT<n>”) for Types of User and Computer Accounts U7 U4 “CAT1" = User Accounts for Administrators “CAT2" = User Accounts for Sales Team U3 CAT1 U5 U6 U8 CAT3 “CAT3" = User Accounts for Legal Team “CAT4" = Computer Accounts for Desktops for Administrators “CAT5" = Computer Accounts for Desktops for Sales Team D1 D2 D7 CAT4 D8 D3 D4 CAT5 D5 D6 CAT6 “CAT6" = Computer Accounts for Desktops for Legal Team “CAT7" = Computer Accounts for Laptops for Account Managers in Sales Team L1 L3 L6 L7 CAT7 L8 L2 L5 L4 CAT8 “CAT8" = Computer Accounts for Laptops for Administrators
© 2004 MUSTANSHI
R

U1

U2 CAT2

BHARMAL

Figure 36.3: Examples of Predefined Categories for Users and Computers  Analyse the identified GPO policy and DOC permission requirements to identify the in-scope Active Directory objects. Figure 36.4 illustrates an example of the mapping of predetermined GPO policies for users and computers, and DOC permissions to the predefined categories.

Page 238 of 354

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

© 2004 Mustan Bharmal

Mapping of Identified GPO Policy Requirements Against Target Users and Computers 1 9 7 10 U1 2 5 3 6 4 8 U3 3 8 4 9 7 10 D1 1 5 2 6 D3 D4 D5 D6 L1 L3 L6 L7
R

1 1 U2

User GPO Policies Computer GPO Policies

U4

U5

U6

U7

U8

D2

D7

D8

L2

L4

L5

L8
BHAR
MAL

© 2004 MUSTANSHI

Mapping of Identified DOC Permission Requirements Against Target Users and Computers 1 4 2 5 3 6 U3 7 9 8 10 D3 D4 D5 D6 L1 L3 L6 L7
R

1 U4 U5 U6 U7 U8

DOC Permission

L8
BHAR
MAL

© 2004 MUSTANSHI

Figure 36.4: Mapping of GPO Policy and DOC Permission Requirements to Categories of Target Users and Computers  Collate all in-scope Active Directory objects into a single object administration profile (as a “virtual OU”) and initiate the steps to identify requirements to partition the single object administration profile. Figure 36.5 illustrates an example of the collation of all in-scope Active Directory objects into a single object administration profile.
The First Object Administration Profile

D1

D2

D3

D4

D5

D6

D7

D8

U1

U2

U3

U4

U5

U6

U7

U8

L1

L2

L3

L4

L5

L6

L7
SHI R

L8
BHAR
MAL

© 2004 MUSTAN

Figure 36.5: Example of the Collation of all In-Scope Active Directory Objects into the First Object Administration Profile The following flow diagram provides an example illustration of the process to partition the first object administration profile to reflect one or more of the three supported scenarios:

Page 239 of 354

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

© 2004 Mustan Bharmal

Examples of Steps in Process to Partition Object Administration Profiles
Is there a requirement to isolate Active Directory objects from scope of application of GPO policies and / or DOC permissions? NO Stage 1 “object administration profile”

START

Analysis of identified GPO policy and DOC permission requreiments

Start with one “object administration profile” Stage 1 “Object administration profile 1”

Is there a requirement to reduce the number of GPOs / DOC permissions implemented?

YES Stage 1 “Object administration profile 2”

YES

Is there a requirement to reduce the number of GPOs / DOC permissions implemented?

NO

YES Stage 1 “Object Administration Profile 1” Stage 2 “Object administration profile 1” Stage 1 “Object administration profile 2” (unpartitioned) Is there a requirement to partition the object admin profiles to reflect logical / visual non-admin NO requirements?

NO Stage 1 “Object administration profile 1” Stage 1 “Object administration profile 2”

Stage 1 “Object Administration Profile” Stage 2 “Object administration profile 1” Stage 2 “Object administration profile 2”

Stage 1 “object administration profile” Is there a requirement to partition the object admin profiles to reflect logical / visual non-admin requirements?

NO

YES

Is there a requirement to partition the object admin profiles to reflect logical / visual non-admin requirements?

NO

Is there a requirement to partition the object admin profiles to reflect logical / visual non-admin requirements?

YES

Stage 1 “object administration profile”

Admin OU

Stage 1 “Object Administration Profile” Stage 3 “Object administration profile 1”

Admin OU

Stage 1 “Object Administration Profile 1” Stage 2 “Object administration profile 1” Stage 1 “Object administration profile 2” (unpartitioned)

Admin OU

Stage 1 “Object Administration Profile” Stage 2 “Object administration profile 1” Stage 2 “Object administration profile 2” NO

Admin OU

Admin OU

Admin OU

Admin OU

END
YES The single “Object Administration Profile” Stage 2 “object Administration Profile 1” Stage 3 “Object administration profile 2” Stage 3 “Object administration profile 3” Stage 3 “Object administration profile 1” Stage 2 “Object administration profile 2”
Admin OU Admin OU

Admin OU

Admin OU

END
Stage 1 “Object Administration Profile 1” Stage 2 “Object administration profile 1” Stage 3 “Object administration profile 1” Stage 1 “Object administration profile 2” (unpartitioned)
Admin OU

YES

Stage 1 “Object Stage 1 “Object administration administration profile 2” profile 1”

Admin OU

Admin OU

Admin OU

Admin OU

Admin OU

Admin OU

Stage 1 “Object Administration Profile 1” Stage 3 “Object administration profile 1” Stage 1 “Object administration profile 2” (unpartitioned)

Admin OU

Admin OU

END
Admin OU Admin OU

Admin OU

Admin OU

© 2 0 0 4 MU S T A NS H I R BH AR M AL

Figure 36.6: Example Flow Diagram to Guide in the Partitioning of Object Administration Profiles

Page 240 of 354

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

© 2004 Mustan Bharmal

Using the above process, analyse all identified GPO policy and DOC permission requirement and execute the following:  Determine and document the requirements to partition object administration profiles into multiple profiles  Determine and document the following information for each final required object administration profile:  The Active Directory objects within each object administration profile  Where possible, identify high-level categories for the types of Active Directory object that represent the contents of the object administration profiles. For example, if all the objects within an object administration profile are computer accounts for servers, then use the category “servers”, and so on.  The GPO policies / policy configurations and / or DOC permissions targeted for the in-scope Active Directory objects  The specific GPO policies / policy configurations and / or DOC permissions that the Active Directory objects within the object administration profile require explicit exclusion from 7.9.3. Selection and Design of OU Design Models Consider the following information when selecting a type of OU design model to support the design and generation of an OU infrastructure for the ORMI within this domain. Presented within the following three sections are the considerations for the execution of this step within this process: 1. 2. 3. 7.9.3.1. Understanding OU design model concepts Understanding the structure and objectives of each type of OU design model supported by this design methodology Considerations to support the selection of a type of OU design model Understanding OU Design Model Concepts Consider the following information when attempting to understand the following specific OU design models concepts: 1. 2. 3. 4. The concept of OU and Model Levels and the maximum depth of OUs within an OU infrastructure The concept of the maximum breadth of OUs within an OU infrastructure Model Level The concept of OU hierarchies The concept of types of OUs supported by this design methodology

• Factor B7: Understanding “OU Levels”, “Model Levels”, and maximum OU depth ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the concept of “OU levels” within a domain, “model levels” for OUs within an OU infrastructure, and the maximum permitted depth for OUs within a domain. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation:

Page 241 of 354

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

© 2004 Mustan Bharmal

An Active Directory domain may support a multitude of OU infrastructures and hence OUs within each infrastructure. All OU design models must control the maximum permitted depth of an OU infrastructure they support. This design methodology recommends a maximum OU depth of between three and five OUs from the root of the domain (OU Level 3 to OU Level 5). As it is only possible to create an OU within the root of a domain, or within another OU in a domain, for ease of reference, all “OU Levels” (abbreviated to “OUL”) are relative references from the root of the domain. Note however, it is possible to have complete autonomous OU infrastructures nested within a “first level OU” (created at the root of the domain), or even a second or third level OU. Hence, to prevent confusion when referring to levels of OUs within an OU infrastructure, which has a highest point of creation within another OU and not the root of the domain, all OU levels within an OU infrastructure are termed “model levels” (abbreviated to “ML”), as an OU design model supports and controls their generation. This concept is illustrated in the following diagram, where the Model Level 1 (ML1) OUs for the OU infrastructures within “ORMI 1” and “ORMI 2” are at the domain root, and hence OU Level 1 (OUL1). However, because “ORMI 3” resides within the ML1 OU for “ORMI 2”, the ML1 OU for “ORMI 3” is at OUL2 from the root of the domain.

Model Level 1
Natsum.com.

OU Level 1 (Domain Root) OU Level 2 OU Level 3
OU
ORMI 1

OU

OU

OU

ORMI 2

OU

OU
ORMI 3

OU

OU

OU

OU

OU
© 2 0 0 4 MU ST AN SHI
R

BHAR

MAL

Figure 36.7: Example of Model Levels for an OU Infrastructure The nesting of OU infrastructures within an OUL1 or OUL2 OU of another OU infrastructure has a significant impact on the maximum supported depth for OUs. For example, where ML1 for a nested OU infrastructure starts at OUL2 from the root of the domain, then the maximum supported depth for OUs within that OU infrastructure is four OUs (i.e. from ML1 (=OUL2) to ML4 (=OUL5)). “Model Levels” for OUs hence permit distinction between OU levels within an OU infrastructure. The ML1 OU(s) for an OU infrastructure represent the upper boundaries for that OU infrastructure. • Factor B8: Understanding the maximum breadth of OUs supported by OU design models ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the maximum breadth of OUs supported by OU design models in the design of an OU infrastructure for an ORMI. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation:

Page 242 of 354

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

© 2004 Mustan Bharmal

In addition to the determination and support for the maximum depth for an OU infrastructure within an ORMI, and OU design model must address and support the maximum breadth for OUs within a Model Level for an OU infrastructure. Illustrated in the following diagram is an example of where the maximum breadth for the OU infrastructure is set to four within each Model Level:

Natsum.com.

MAX BREADTH ML1
OU1 OU2 OU3

MAX DEPTH

ML2

OU4

OU5

OU6

OU7

ML3

OU8

OU9

OU10

OU11
© 2004 MUSTANSHI
R

BHAR

MAL

Figure 36.8: Example of the Maximum Breadth for an OU Infrastructure The value for the maximum breadth of an OU infrastructure exerts control over the maximum number of child OUs a parent OU can support, relative to the child OUs of peer parent OUs. In the illustrated example above, where the maximum breadth for a Model Level is set to four, OU1 and OU3 can only support, between them, four child OUs. The example above shows this value evenly distributed amongst both OU1 and OU3. The maximum breadth for a Model Level within an OU infrastructure is dependent upon the function of the model level, as dictated by the type of OU design model. See later for details on the types of OU design models. Note that the maximum breadth for an OU infrastructure does not influence the execution of logon and startup processes for users and computers, nor influence, for example, the performance of directory-enabled application to execute LDAP queries against an Active Directory domain. There are no technical requirements to control the maximum breadth for OUs within a Model Level for an OU infrastructure. Hence, the requirement to control the maximum breadth for an OU infrastructure is to support the recommended approach for this process, to “keep it simple”. Generating a large number of child OUs within a parent OU complicates the OU infrastructure and makes it visually harder to manage and troubleshoot. Hence, enforcing control over the maximum breadth for the OU infrastructure permits the generation of a consistent and understandable OU infrastructure. • Factor B9: Understanding OU hierarchies ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the concept of OU hierarchies. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation:

Page 243 of 354

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

© 2004 Mustan Bharmal

Within an OU infrastructure, it may be possible to identify one or more OU hierarchies. An OU hierarchy is a collection of OUs within an OU infrastructure with direct parent / child relationships, as illustrated in the following diagram:
OU Hierarchy

OU Level 1 (Domain Root) OU Level 2 OU Level 3
OU
ORMI 1

OU

OU

OU

ORMI 2

OU

OU
ORMI 3

OU

OU

OU

OU

OU
© 2004 MUSTANSHI
R

BHAR

MAL

Figure 36.9: Example of OU Hierarchy An OU hierarchy can cross the boundaries between OU infrastructures, as can be seen in the illustration above, between the OU infrastructure within “ORMI 2” and “ORMI 3”. OU hierarchies represent an important control element in the efficient administration of the contents of multiple OUs via the use of inheritance down an OU hierarchy. The following diagram illustrates this, where there is a requirement to implement multiple GPOs at different points along an OU hierarchy:
GPO OU GPO OU GPO OU OU Policy Inheritance down an OU hierarchy
© 2004 MUSTANSHI
R

GPO OU

OU

OU

BHAR

MAL

Figure 36.10: Example of GPO Policy Inheritance Influenced by an OU Hierarchy Note that OUs that do not participate within an OU hierarchy, and hence do not have any parent or child OUs, can only exist at OU Level 1 (the root of a domain). • Factor B10: Understanding types of OUs supported by this design methodology ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the types of OUs supported by this design methodology. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Although the primary objectives for the design, generation, and use of OUs supported by this design methodology is to support the administration of Active Directory objects, it is recognised that there are a number of non-administrative requirements that also require support. For example, there may be a requirement to reflect visual or logical relationships between Active Directory objects, based on their object metadata, which do not align to

Page 244 of 354

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

© 2004 Mustan Bharmal

administration requirements for the objects using GPO policies and / or DOC permissions. When designing an OU infrastructure for an ORMI within a domain, many organisations will veer towards using OUs to reflect visually one or more metadata aspects of the Active Directory objects that require collation into OUs. For example, the metadata aspects of objects (users, computers, printer objects, shared volume objects, and so on) such as their membership to divisional structures within the organisation, such as departments, divisions, teams, and so on. The sole use of this objective for OU design would hence generate an OU infrastructure that does not directly or ideally support the actual administration of the objects via GPOs and DOC permissions. Hence, to achieve a compromise between this tendency towards a visual or logical reflection of metadata aspects of objects, and the actual administrative requirements for the objects in the design of a supporting OU infrastructure, this design methodology proposes the use of two types of OUs, introduced as “placeholder OUs” and “admin OUs”. This design methodology supports the following functions and objectives for the generation of “placeholder OUs”:  The primary function is to support the segregation and collation of “admin OUs” into OU hierarchies, to reflect the non-administrative based logical and visual requirements to group the admin OUs, such as the requirement to reflect one or more metadata aspects for the Active Directory objects. The placeholder OU is hence the “placeholder” for an OU hierarchy within an OU infrastructure. For example, it may be possible to identify the requirement to generate three OUs (based upon administration requirements) for servers, desktops, and laptops, each as “admin OUs”. It is hence feasible to generate a placeholder OU named “Computers” to collate these “admin OUs” to permit their visual and logical grouping into a discrete OU hierarchy.  To serve as an implementation point for GPO policies / DOC permissions that target all objects represented by the placeholder OU, via the use of policy / permission inheritance.  To support non-GPO / DOC administration requirements, such as the requirement to facilitate the searching for objects, GPOs, and DOC permissions. Based upon these stated functions and objectives, placeholder OUs have the following characteristics and usage profiles:  They will rarely contain Active Directory objects, such as user and computer accounts, security groups, printers, and so on, as their primary function is to provide a method to segregate and collate “admin OUs” into OU hierarchies.  The objective for their generation must reflect object metadata common to all objects within the child “admin OUs”.  Combining the primary objective for placeholder OUs, to collate “admin OUs” into discrete OU hierarchies, with the maximum recommended depth for an OU infrastructure, means that the generation of placeholder OUs is not supported at “OU Level 4” or “OU Level 5” from the root of a domain. This is because the collated “admin OUs” may already exist within an OU hierarchy to reflect a requirement to generate an efficient GPO / DOC permission implementation infrastructure via the use of inheritance.  This design methodology does not support the nesting of placeholder OUs (unless the parent placeholder OU belongs to another OU infrastructure) as this contradicts

Page 245 of 354

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

© 2004 Mustan Bharmal

the primary objective for the design, generation, and use of OUs, to support administration of the segregated and collated Active Directory objects. Hence, this design methodology only supports the generation of placeholder OUs at “model level 1” for an OU infrastructure. This design methodology supports the following functions and objectives for the generation of “admin OUs”:  The primary function is to support the segregation and collation of Active Directory objects into OUs, based upon the pre-defined “object administration profiles”, to permit their administration via GPO policies / policy configurations and / or DOC permissions.  To serve as an implementation point for GPO policies / DOC permissions that target all objects collated by the “admin OUs”. Based upon these stated functions and objectives, the characteristics and usage profiles for admin OUs reflect their design to hold the following:  Active Directory objects for administration via GPO policies and / or DOC permissions, and where required,  Other admin OUs for generation of an efficient implementation infrastructure for GPOs and DOC permissions 7.9.3.2. Understanding Types of OU Design Models Consider the following information when attempting to understand the different types of OU design models supported by this design methodology: • Factor B11: Understanding the types of Standard OU Design Models ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the types of standard OU design models supported by this design methodology. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology supports the following two types of standard OU design models:  “Functional” OU design model  “Placeholder” OU design model The “functional” OU design model has the following characteristics:  The “functional” OU design model only employs the use of “admin OUs” and not “placeholder OUs”. The resultant OU infrastructure is hence purely functional and does not reflect any requirements to logically or visually segregate and collate entire OUs into OU hierarchies based upon non-administrative requirements, but only Active Directory objects into OUs (via the partitioning of object administration profiles).  The depth and breadth of an OU infrastructure generated using a “functional” OU design model is smaller than one generated using a “placeholder” OU design model. The smaller depth and breadth of the resulting OU infrastructure from a “functional” OU design model permits the use of this design model where the ML1 OU for the OU infrastructure represents an “OUL 3” or “OUL 4” OU within the domain.

Page 246 of 354

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

© 2004 Mustan Bharmal

 The lack of support for the design and use of placeholder OUs by a “functional” OU design model generates a strictly functional OU infrastructure.  A “functional” OU design model is hence only suitable for the generation of an OU infrastructure required to support only a small number of Active Directory objects, and not many hundreds to thousands of objects. In ORMIs with a large number of in-scope Active Directory objects, there is a requirement for the OU infrastructure to be visually intuitive as to its function and objective to support the execution of routine administration tasks on the objects. In these scenarios, the use of placeholder OUs (only supported by a “placeholder” and not a “functional” OU design model) permit the design of an intuitive OU infrastructure by reflecting logical and visual relationships between the contents of admin OUs to generate OU hierarchies. The “placeholder” OU design model has the following characteristics:  The “placeholder” OU design model employs the use of both “admin OUs” and “placeholder OUs”, with “admin OUs” nested inside “placeholder OUs”. An example of an OU infrastructure generated using a placeholder OU design model is illustrated in the following diagram: ML1 ML2 ML3

OU

OU

Placeholder OUs

OU

OU

OU Admin OUs

OU

OU

OU
© 2 0 0 4 MU S TAN SH I

OU
R

BHAR

MAL

Figure 36.11: Example of a Placeholder OU Design Model  Due to the use of two types of OUs by this design model, the resulting depth and breadth of the OU infrastructure is larger than one generated using a “functional” OU design model. This hence places a restriction on the use of this design model where the ML1 OU for an OU infrastructure represents an “OUL 3” or “OUL 4” OU within the domain.  The placeholder OU design model supports the use of different metadata aspects of the objects within the admin OUs to support the generation of the different placeholder OUs. For example, and organisation may wish to segregate the Active Directory objects to reflect the IT support departments that manage the objects, such as:  Dedicated teams that look after user accounts for normal users and computer accounts for desktop and laptop computers  Dedicated teams that look after servers and user accounts for services, applications and resources, and so on  In this example, it is possible to segregate the Active Directory objects into those that represent “front-end” and “back-end” elements of the IT infrastructure, to thus generate, for example, “front end” and “back end” placeholder OUs. The “front end” placeholder OU may collate those admin OUs that support the front-end user accounts, computer account, printer objects, shared volume objects, and so on, and their corresponding GPOs and DOC permissions. The “back end” placeholder OU may collate those admin OUs that support the back end user accounts (for services, applications, and resources), and computer accounts for servers, and so on)

Page 247 of 354

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

© 2004 Mustan Bharmal

 The placeholder OU design model does not permit the following:  The generation of a placeholder OU without any nested “admin OUs”, as this contradicts the primary function of a placeholder OU.  The generation of a placeholder OU, with only one nested “admin OU”, as the placeholder OU is superfluous in this instance and serves no function. Hence, for example, where six “admin OUs” are identified, only a maximum of three placeholder OUs may be generated, with a minimum of two “admin OUs” within each placeholder OU.  The nesting of a placeholder OU within an “admin OU”, which may or may not be nested within another placeholder OU  The placeholder OU design model does not require all admin OUs to be child OUs of a placeholder OU, and hence supports the generation of ML1 admin OUs. 7.9.3.3. Selection of a Type of OU Design Model Consider the following information when determining the type of OU design model that will support the design and generation of the OU infrastructure for the ORMI within this domain: • Factor A4: Determination of the requirement for the use of a “functional” OU design model ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the requirement for the design and use of a “functional” OU design model. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When determining the requirement for the design and use of a “functional” OU design model, consider the following information presented as advantages and disadvantages. The following are examples of advantages associated with the use of a “functional” OU design model:  The OU infrastructures generated by “functional” OU design model are shallow and narrow due to the lack of support for placeholder OUs. Hence, the use of “functional” OU design models is suitable for ORMIs that have an upper boundary represented by an OUL3 or deeper OU.  The support for non-administrative partitioning of object administration profiles permits the collation of Active Directory objects into admin OUs to reflect visual and logical relationships between them, based upon their object metadata. However, the lack of support for placeholder OUs does not permit the collation of OUs (as opposed to individual Active Directory objects) to reflect visual and logical relationships between the Active Directory objects.  The OU infrastructures generated by a “functional” OU design model are simple, purely functional, and hence suitable for small organisations with a centralised IT infrastructure. In these scenarios, as only a small number of administrators will be required to interact with the OU infrastructure, to execute routine maintenance tasks, the functional OU infrastructure is simple to use. The following are examples of disadvantages associated with the use of a “functional” OU design model:  The lack of support for placeholder OUs results in an OU infrastructure that, although functional, may not be visually intuitive where it is required to support a

Page 248 of 354

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

© 2004 Mustan Bharmal

large number of Active Directory objects, collated in multiple object administration profiles, and hence OUs.  A visually intuitive OU infrastructure may not be suitable where it is required to support a large and distributed IT support infrastructure for an organisation. Use the above information to execute an analysis to determine and document the requirements for the design and use of a “functional” OU design model. • Factor A5: Determination of the requirement for the use of a “placeholder” OU design model ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the requirement for the design and use of a “placeholder” OU design model. ♦ 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 use of a “placeholder” OU design model, consider the following information presented as advantages and disadvantages. The following are examples of advantages associated with the use of a “placeholder” OU design model:  The support for the design and use of placeholder OUs by a “placeholder” OU design model results in combination of a functional and intuitive OU infrastructure that supports both administrative and non-administrative requirements. This hence means that although the resultant OUs are functional, with respect to the support for the administration of the collated Active Directory objects, they are intuitive because they reflect logical and visual relationships between the contents of admin OUs to generate OU hierarchies. The OU infrastructure thus generated by a “placeholder” OU design model is suitable for a distributed IT support infrastructure within an organisation.  A “placeholder” OU design model is suitable where there is a requirement to support a large number (many hundreds to thousands) of Active Directory objects, collated into multiple object administration profiles and hence OUs.  The use of placeholder OUs permits the implementation of GPOs and DOC permissions that require targeting to a wide scope of Active Directory objects. The target Active Directory objects may reside within any of the “admin OUs” collated within the OU hierarchy generated by the placeholder OU. The following are examples of disadvantages associated with the use of a “placeholder” OU design model:  Depending upon the number of object administration profiles that require collation / partitioning into OUs, the resulting OU infrastructure from a “placeholder” OU design model may be both deep and broad. The greater depth of the resulting OU infrastructure may limit the use of a “placeholder” OU design model where the ML1 OUs require generation as OUL3 or deeper OUs within the domain.  The design of an OU infrastructure using a “placeholder” OU design model requires more time and analysis than when using a “functional” OU design model. Use the above information to execute an analysis to determine and document the requirements for the design and use of a “placeholder” OU design model.

Page 249 of 354

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

© 2004 Mustan Bharmal

7.9.4.

Determination of the Design Requirements for the OU Infrastructure Consider the following when determining the design requirements for the OU infrastructure: • Factor B12: Understanding the remaining design requirements that require determination ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the design requirements for an OU infrastructure that still require determination. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: From the list of eleven variables in the design of an OU infrastructure, as stated earlier in the “Background Information” section of this process, the previous steps in this process have addresses the following four variables so far:  The identity of the specific Active Directory domain where the OU infrastructure requires generation is “this domain” that this Domain Plan supports.  The upper boundary for an OU infrastructure (that defines the highest point of creation of the first level of OUs) within the selected Active Directory domain was determined during the execution of the step “determination of the scope and upper boundary of the OU infrastructure” within this process.  The object administration requirements (GPO and DOC requirements) within this domain that will support the collation of the objects into OUs were determined via the execution of the step “analysis of identified GPO policy and DOC permission requirements” within this process.  The objectives for the generation of an OU at each model level were determined via the selection of a type of OU design model (“functional” or “placeholder”) Hence, the execution of this step, to determine the design requirements for the OU infrastructure, will address the following remaining seven variables:  The determination of the maximum depth for an OU infrastructure (defined by the maximum number of levels, and thus the inner perimeter for an OU infrastructure)  The determination of the maximum breadth for an OU infrastructure at each permitted OU design model level  The determination of the specific number of OUs required at each permitted OU design model level, to support the required objectives and the identified administrative functions for the collated objects.  The determination of the specific content for of each OU generated by an OU design model  The determination of the structure and relationships for multiple “admin OUs” within an OU infrastructure  The determination of the specific permissions to be implemented on each OU generated by an OU design model, where required  The determination of the name for each required OU within the OU infrastructure. The object-naming model for OUs, generated in the “Organisation-Wide Active Directory Plan” process “design of object naming models”, will provide the formula to generate the name for each required OU. • Factor A6: Determination of the maximum permitted depth for the OU infrastructure

Page 250 of 354

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

© 2004 Mustan Bharmal ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has determined the upper boundary (and hence highest point of creation of OUs) for the OU infrastructure, and  Has selected the type of OU design model that will support and control the generation of the OU infrastructure, and  Wishes to determine the maximum permitted depth, and hence the inner perimeter, for the OU infrastructure ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The requirement to determine and state the maximum permitted depth for an OU infrastructure is imperative to the operation and management of the both the OU infrastructure and the Active Directory objects collated within. Where an OU infrastructure is ordinate to a subordinate OU infrastructure, then the determination of the maximum permitted depth for the ordinate OU infrastructure will assist in identifying the inner perimeter. The determined maximum permitted depth, and hence inner perimeter, contributes to the definition of the scope of the OU infrastructure. The following diagram illustrates the concept of an inner perimeter for an ordinate OU infrastructure:
Ordinate OU infrastructure

OU

OU

OU

Subordinate OU infrastructure

OU

OU

OU

OU

Inner perimeter of OU infrastructure

OU

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

BHARMAL

Figure 36.12: Example of the Inner Perimeter for an OU Infrastructure The following examples illustrate the scope of influence of the maximum permitted depth for an OU infrastructure:  The time required to execute the logon process for users, and the startup process for computers. The relationship between depth of OU infrastructure and the time required to execute these process is based upon the:  The position of the OU within the OU infrastructure where the user / computer object resides, and  The number of GPOs implemented at the OU in which the user / computer object resides, and at various supported points of implementation hierarchically above the OU.  When users logon and computers startup, they must evaluate all applicable GPOs implemented at their OU and hierarchically above their OU. If the OU in which the

Page 251 of 354

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

© 2004 Mustan Bharmal

user / computer account objects reside within is deep within the OU infrastructure, there are hence a larger number of points for implementation of GPOs hierarchically above that OU. Where it is possible to identify a large number of implemented GPOs that may require evaluation, the users and computers will take longer to evaluate all applicable GPOs, and hence take longer to execute their logon and startup processes respectively.  A deep OU infrastructure may impair the operation and performance of Active Directory-enabled applications, which perform LDAP-based queries on the Active Directory. The deeper an OU infrastructure becomes within an Active Directory domain, the longer it will take for a search of the directory tree to complete, thus reducing the performance of such operations by directory-enabled applications.  A deep OU infrastructure may impair the execution of troubleshooting and routing maintenance procedures on the Active Directory domain. OUs are Active Directory objects that contribute to the distinguished name (DN) for an object within the directory tree. Hence, the deeper the OU infrastructure, the longer the DN will be for tree objects such as users and computers. Hence, for example, where there is a requirement to perform an authoritative restore for an OU and its contents, a long DN for the OU and its contents may lead to errors during the authoritative restore, as the DN requires manual entry at a command prompt. The following factors influence the maximum permitted depth for an OU infrastructure:  The highest point of creation (upper boundary) of ML1 OUs within an OU infrastructure for the Active Directory domain directly influences the maximum permitted depth for an OU infrastructure. Although it is technically possible to generate an extremely deep OU hierarchy within an Active Directory domain, this design methodology recommends a maximum permitted depth of between three and five OUs from the root of the domain (and hence OUL3 to OUL5). Note that most OU hierarchies within a domain will not exceed two or three OU levels deep.  The presence of ordinate and subordinate OU infrastructures will influence the highest point of creation (for a subordinate OU infrastructure) and the maximum permitted depth (for both an ordinate and subordinate OU infrastructure). For example, a discrete OU infrastructure may begin from within another custom OU. In this scenario, the parent OU in the parent OU infrastructure represents “ML1 -1” for the child OU infrastructure. Thus, “OUL<n> + 1” for the parent OU represents the highest point of creation for the child OU infrastructure.  The following diagram illustrates this, where an OU (in ORMI 1 of this example) represents the parent OU for a child OU infrastructure (in ORMI 2 of this example). As the parent OU in ORMI 2 is generated at OUL1 (the root of the domain), OUL2 hence represents the highest point of creation for the child OU infrastructure in ORMI 2 of this example:

Highest Point of Creation for OUs in ORMI 2 ORMI 1 Natsum.com.

OUL1 (Domain Root) OUL2 ML1 for ORMI 2
OU OU
ORMI 2

OU

ML1 for ORMI 1
OU

ML2 for ORMI 1 ML2 for ORMI 2
© 2004 MUSTANSHI
R

OUL3

OU

BHAR

MAL

Page 252 of 354

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

© 2004 Mustan Bharmal

Figure 36.13: Example of Highest Point of Creation for an OU Infrastructure  The type of OU design model selected will influence the determination of the maximum permitted depth for the OU infrastructure, where:  The use of a “functional” OU design model results in a flatter OU infrastructure, as this design model only supports the use of “admin OUs”. The nesting of “admin OUs” can only occur where it is possible to disprove the second null hypothesis for this process via compliance with the criteria for nesting of OUs stated earlier.  The use of a “placeholder” OU design model may result in a slightly deeper OU infrastructure as one extra level of OUs (the placeholder OUs) may reside (where required), above specific “admin OUs”. Based the above information, when determining the maximum permitted depth for the OU infrastructure, consider the following:  This design methodology recommends a maximum OU depth of between three and five OUs from the root of the domain (OUL3 to OUL5).  The value for the maximum permitted depth must hence reflect the highest point of creation of the OU infrastructure within the domain, and the requirement to support any subordinate ORMIs and hence their OU infrastructures.  If the ORMI is to support a subordinate ORMI for an autonomous division represented within the domain, then consider the following information prior to the determination of the maximum depth for the OU infrastructure in the parent ORMI:  The number of Active Directory objects that each subordinate ORMI is required to support  Where possible, and where known, the required type of OU design model to be used within each subordinate ORMI and the potential depth of OUs required  The OU and Model Level in the OU infrastructure for the parent ORMI that represents the highest point of creation (upper boundary) for the OU infrastructure in each subordinate ORMI Use the above information to execute an analysis to determine and document the maximum permitted depth for the OU infrastructure. • Factor A7: Determination of the maximum permitted breadth for OUs at each required Model Level in the OU infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has determined the maximum permitted depth for the OU infrastructure (and hence identified the number of permitted model levels), and  Wishes to determine the requirement to stipulate a value for the maximum permitted breadth for OUs at each required Model Level in the OU infrastructure ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The stipulation of a value for the maximum permitted breadth for OUs at each required Model Level is optional and not mandatory, unlike the maximum permitted depth for an OU infrastructure. The definition of the maximum permitted breadth is optional as there are no administrative or technical requirements to support its definition.

Page 253 of 354

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

© 2004 Mustan Bharmal

The definition of the maximum permitted breadth for OUs at each required Model Level in the OU infrastructure implies the following:  A limitation on the total breadth of OUs at each required Model Level. The value for the maximum breadth may be set independently for each required Model Level or uniformly for all Model Levels in the OU infrastructure.  A limitation on the maximum number of child OUs a parent OU may support, in relation to other peer / parallel OUs at the same Model Level. The maximum breadth for a Model Level within an OU infrastructure must reflect the identification of the requirement to support or disprove the second null hypothesis for this process. The second null hypothesis for this process states that where multiple “admin OUs” are required, they should exist in parallel with other “admin OUs” and not nested within other “admin OUs” to generate an OU hierarchy. The basis for this null hypothesis is to generate an OU infrastructure that does not create conflicts in application of GPO policies and DOC permissions due to inheritance down an OU hierarchy. This design methodology requires that to disprove the second null hypothesis, it is necessary to attain compliance with the following criteria:  The nesting of an “admin OU” beneath (within) another “admin OU” must not conflict with the scope of application of the GPOs and DOC permissions implemented at the parent “admin OU”, or inherited by the parent “admin OU” from its ordinate OUs. For example, where an “admin OU” is to receive a set of DOC permissions with an inscope target of a set of desktop computers, and an out-of-scope target of all laptop computers, then the nesting of an OU containing computer account objects for laptops beneath this OU will generate a DOC permission conflict via inheritance.  The nesting of OUs indicates a non-administrative and administrative relationship between the OUs. Hence, it is possible to disprove the second null hypothesis where there is a requirement to reflect a visual and / or a logical relationship between the contents of one “admin OU” and another “admin OU” based upon object metadata. If it is possible to identify a requirement to determine the maximum permitted breadth for OUs, then when determining the value for this parameter, consider the following:  The value for the maximum permitted breadth may be set individually for each required Model Level in the OU infrastructure, or collectively for all required levels.  Setting the value to the ML1 OUs for an OU infrastructure where a “placeholder” OU design model is to be used, will restrict the number of placeholder OUs that may be generated, and ML1 “admin OUs”, where required.  Use the above information to execute an analysis to determine the maximum permitted breadth for OUs at each required Model Level, either individually or collectively for all levels. • Factor A8: Determination of the specific number of OUs required ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has completed the analysis of identified GPO policy and DOC permission requirements, and  Has selected a type of OU design model (functional or placeholder), and

Page 254 of 354

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

© 2004 Mustan Bharmal

 Wishes to determine the exact number of OUs required for the OU infrastructure to support the ORMI for this domain ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: So far, the following information has being determined:  The number and content of object administration profiles (and sub-profiles where required)  The type of OU design model selected to control the generation of the OU infrastructure The next step is to determine, using the selected type of OU design model, the final number of OUs required for the OU infrastructure. Where there is a requirement for the use of a “functional” OU design model, then it is only necessary to determine the number of “admin OUs” required for the OU infrastructure. The object administration profiles and sub-profiles map directly to the “admin OUs”. However, where there is a requirement for the use of a “placeholder” OU design model, it is necessary to determine the number of “admin OUs” and “placeholder” OUs for the OU infrastructure. In order to determine the number of placeholder OUs required, it is necessary to analyse the high-level categories identified for the types of Active Directory objects collated into the object administration profiles / sub-profiles. The placeholder OUs must ideally reflect a single high-level category that represents the all of the objects within two or more object administration profiles / “admin OUs”, but which also permits differentiation from other placeholder OUs within the OU infrastructure. Use the above information to execute an analysis to determine and document the final number of “admin OUs” and, where required, “placeholder OUs” for the OU infrastructure. • Factor A9: Determination of the specific content for each required OU within the OU infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has determined the number of object administration profiles required and their content, and  Determined the number and types of OUs required for generation within the OU infrastructure, and  Wishes to determine the specific content for each OU identified for generation within the OU infrastructure ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The step to identify the object administration profiles necessary to reflect the identified GPO policy and DOC permission requirements, also permitted identification of the contents (as Active Directory objects) of the profiles. The subsequent translation of these profiles to “admin OUs” supplies the contents of these OUs.

Page 255 of 354

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

© 2004 Mustan Bharmal

As stated earlier, although not encouraged it is possible for placeholder OUs to hold Active Directory objects other than OUs. Where this is true, then it is also necessary to identify the proposed contents for these placeholder OUs. The listing of the specific contents of the OUs must detail all of the in-scope Active Directory objects, including “admin OUs”. This information will support specific steps within the other three processes associated with the design of an ORMI for this domain. • Factor A10: Determination the structure and relationships for multiple “admin OUs” within the OU infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the total number and content of “admin” and “placeholder” OUs (where required) for the OU infrastructure, and  Wishes to determine the structure and relationships for multiple “admin OUs” within the OU infrastructure ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology only permits the nesting of “admin OUs” where it is possible to identify compliance with the stated criteria used to disprove the second null hypothesis for this process. The following rules for nesting of “admin OUs” refer back to the process to partition the object administration profiles, and the stage numbers assigned to partitions generated at each of the three stages:  It is not possible to nest an “admin OU” within another “admin OU” where both are generated as “stage 1 object administration profiles”. This is because the partitioning of the single original object administration profile into two or more “stage 1” profiles was to support the requirement to control the scope of application of GPOs and / or DOC permissions. Hence, nesting two “admin OUs”, with both generated from “stage 1 object administration profiles”, contradicts the existence of the stage 1 partitions due to the inheritance of GPOs and DOC permissions from the corresponding parent admin OU to the child admin OU.  Admin OUs generated from stage 2 or stage 3 object administration profiles may participate within a parent-child OU relationship with admin OUs generated from any stage 1, 2, or 3 object administration profiles.  Where it is possible to identify the presence of Active Directory objects that reside within two or more object administration profiles, the corresponding admin OUs may be nested (permitting compliance with the above rules) to reflect any requirements to inherit GPO policies and / or DOC permissions. Using the above information, execute an analysis to determine and document the requirements to nest “admin OUs”, and where identified, the required structure and relationships for the admin OUs. • Factor A11: Determination of the specific permissions / configurations to be implemented on each OU ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the specific number, structure, and relationships for OUs within the OU infrastructure, and

Page 256 of 354

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

© 2004 Mustan Bharmal

 Wishes to determine the specific (non-DOC) permissions and configurations that require implementation at each required OU ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The majority of permissions that may require implementation on an OU may be associated with one or more aspects of delegation of control, and hence covered in the process “design of a DOC infrastructure”. However, there are some OU permissions not directly associated with DOC. For example, the use of the “list contents” permission, with which it is possible to collate Active Directory objects within an OU to hide the objects from view via the use of “Deny list contents” permission on the OU. However, as it is quite rare to identify this requirement within most organisations, this design methodology does not consider this factor to support the collation of Active Directory objects into OUs. Where there is a requirement for the use of this permission, then design the implementation of this permission where it is possible to identify one or more “admin OUs”, or a hierarchy of OUs that have obscurity requirements for their contents. Note that the use of the “deny” permission overrides all grant permissions, and thus it is necessary to evaluate carefully the potential for permission conflicts at a target OU or within an OU hierarchy. It is possible to configure an OU with “Block Inheritance” to prevent the inheritance of GPOs implemented at directly ordinate OUs or at the root of a domain, or linked to a Site that represents the domain. When determining the requirement for the configuration of “block inheritance” for GPOs, consider the following:  The use of “block inheritance” is indiscriminate and it is hence not possible to target it to specific GPOs. Instead, it will block the inheritance of all GPOs except the GPOs configured with “no override”.  The use of “block inheritance” on an OU does not restrict the direct linking or implementation of GPOs at that OU. It is possible to configure an OU to prevent the inheritance of all permissions implemented at ordinate OUs or the root of the domain. The prevention of inheritance of permissions at an OU is an effective method to isolate an OU and its contents within an OU infrastructure and domain. When configuring an OU to prevent inheritance of permissions, the following three options are presented:  Copy – this option will copy all existing inherited permissions but not accept any new permissions implemented at ordinate OUs or the root of the domain  Remove – this option will only remove all inherited permissions, but retain the permissions implemented directly at that OU, either manually or automatically upon OU generation.  Cancel – this option will cancel the task to preventing inheritance and return the OU to the default state of accepting the inheritance of all permissions implemented at ordinate OUs or the root of the domain. Note that the use of this configuration option on an OU will hence negate all delegation of control permissions on that OU, unless the implementation of this configuration occurs after all the implementation of all required DOC permissions, and the organisation selects the option to copy the inherited permissions. Using the above information, execute the following:

Page 257 of 354

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

© 2004 Mustan Bharmal

 Determine and document the requirement for the use of the “deny list contents” permission on an OU to hide the contents of the OU from view  Where there is a requirement for the use of this permission, identify the OU(s) that require the implementation of this permission  Determine and document the requirement for the use of the “block inheritance” of GPOs at an OU within this OU infrastructure  Where there is a requirement to control the scope of application of GPOs within an OU infrastructure via the use of “block inheritance”, identify the specific OU(s) that require this configuration.  Determine and document the requirement for the configuration of an OU to prevent the inheritance of permissions implemented at ordinate OUs or the root of the domain.  Where there is a requirement to prevent the inheritance of permissions at an OU, identify the OU(s) that require this configuration. 7.9.5. Design of Each Required OU Infrastructure Consider the following information when generating the design for the OU infrastructure to support the ORMI for this domain: • Factor D1: Components of a design for an OU infrastructure ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand and generate the components of the design for an OU infrastructure. ♦ 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 an OU infrastructure is comprised of the following components:  A detailed design document for the design of the OU infrastructure, including the following:  The object administration requirements (GPO and DOC requirements) within this domain that will support the collation of the objects into OUs  The objectives for the generation of an OU at each model level  The maximum required depth for the OU infrastructure (defined by the maximum number of levels, and thus the inner perimeter for an OU infrastructure)  The maximum required breadth for the OU infrastructure at each permitted OU design model level  The specific number of OUs required at each permitted OU design model level, to support the required objectives and the identified administrative functions for the collated objects.  The specific content for of each OU generated by an OU design model  The structure and relationships for multiple “admin OUs” within an OU infrastructure

Page 258 of 354

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

© 2004 Mustan Bharmal

 The specific permissions to be implemented on each OU generated by an OU design model, where required  The name for each required OU within the OU infrastructure. The object-naming model for OUs, generated in the “Organisation-Wide Active Directory Plan” process “design of object naming models”, will provide the formula to generate the name for each required OU.  The upper boundary for an OU infrastructure (that defines the highest point of creation of the first level of OUs) within the selected Active Directory domain  A diagram illustrating the following:  The placeholder and admin OUs (as appropriate to the selected type of OU design model) and their assigned names  The structure and relationships of multiple OUs (where required) It is imperative that each element that influenced the generation of the design for an OU infrastructure is justifiable and auditable, to produce a consistent and functioning OU infrastructure. Use the above to generate a design for the OU infrastructure required to support the ORMI for this domain.

Page 259 of 354

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

© 2004 Mustan Bharmal

8.

Design for Domain Controllers for this Domain
This process requires execution by the owner(s) of this domain, to generate a design for all domain controllers required to support this domain.

8.1.

Process Objectives The objectives of this process are to assist the domain owner(s) in the generation of a design for the following: • The placement of domain-level FSMO roles across two or more domain controllers within this domain • The sizing of domain controller server hardware • The design of a standard server build for Windows Server 2003 domain controllers • The design of the required mode(s) for implementation of domain controllers within the production environment The design for the placement of domain-level FSMO roles has a direct influence on the sizing of domain controller hardware, as each FMSO role has varying hardware resource requirements. It is imperative that the domain owner(s) employ the appropriate server hardware and components for the domain controller servers for this domain. The domain controllers represent the domain, and hence their hardware specifications directly influence the performance and operation of the domain. The design of a standard server build for Windows Server 2003 domain controllers is essential where this domain requires support by two or more domain controllers. The design and use of a standard server build reduces configuration errors within domain controllers, and ensures a consistent build that is simpler to manage and troubleshoot. There are multiple methods and modes available for the implementation of domain controllers for this domain within the production environment. This process will assist the domain owner(s) in selection and design of the most appropriate mode(s) for implementation of domain controllers.

8.2.

Process Scope The number of domain controllers required to support this domain, and their function(s) within the domain, directly influences the design for the hardware specifications of the domain controllers and their implementation within the production environment, and hence the scope of this process. The Site Plan process “design for domain controllers and GC servers” has determined the number of domain controllers and GC servers required for this domain. This process will determine the function(s) for each required domain controller within this domain, as the input for the determination of the server hardware specifications, and the design for implementation of the domain controllers.

8.3.

Background Information The design for domain controllers within this domain is required to identify and address the following four variables: 1. 2. The function of each required domain controller within this domain The hardware specifications, performance, and fault tolerance / high availability requirements of each required domain controller within this domain

Page 260 of 354

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

© 2004 Mustan Bharmal

3. 4.

The components of the design of a standard server build for Windows Server 2003 domain controllers The mode of implementation of each required domain controller within the production environment

The following factors directly influence the function(s) of a domain controller within a production environment for an organisation: • The domain-level Flexible Single Master Operations (FSMO) role(s) a domain controller is required to operate • The directory-enabled applications, services, and processes a domain controller is required to support The following factors directly influence the performance and operation of a domain controller within a production environment for an organisation: • The function(s) of each required domain controller within the domain • The number and size of Active Directory objects within the domain, and the rate of change to the Active Directory objects the domain is predicted to experience • The total number of domain controllers within each required Site that represents this domain, which influences the impact of intra-Site replication between domain controllers on their performance and operation. • The hardware components, and their specifications, for the domain controller servers The following factors directly influence the design of a standard server build for Windows Server 2003 domain controllers within this domain: • The number of domain controller roles that require discrete standard builds • The additional functions each domain controller is required to support in addition to their primary role The following factors directly influence the mode of implementation of the domain controllers for this domain within the production environment: • The server hardware components, specifications, and features • The number of domain controllers that require deployment • The physical locations for the domain controllers within the organisation • The levels of available bandwidth within network links between the administrators of the domain and remote domain controllers • The requirements to reduce or manage any financial and administrative overheads associated with the deployment and initial configuration of domain controllers for this domain This process will consider all of the above factors, and more, to assist the domain owner(s) in the generation of a design for domain controllers for this domain. 8.4. Process Approach This design methodology proposes the following approach for the generation of a design for the domain controllers required to support and represent this domain:

Page 261 of 354

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

© 2004 Mustan Bharmal

1. 2. 3.

Determine the expected function(s), operations, and resource loads for each domain controller within this domain. Determine the design requirements for the placement and configuration of the domainlevel FSMO roles on the domain controllers for this domain. Determine the minimum recommended specifications for the hardware components of each required domain controller, to reflect the identified functions, operations, and resource loads. Determine the design requirements for one or more standard server builds for the Windows Server 2003 domain controllers within this domain Determine the design requirements for the required mode(s) for implementation of each required domain controller within the production environment. Generate the design for the placement of the domain-level FSMO roles, the standard server build(s), and each required mode of implementation of the domain controllers within the production environment.

4. 5. 6.

8.5.

Process Components Based upon the above approach, the process to generate a design for the domain controllers within this domain is composed of the following components: • Determination of the expected function(s), operations, and resource loads for each required domain controller • Determination of the design requirements for the placement and configuration of the domain-level FSMO roles on the domain controllers for this domain • Determination of the minimum recommended specifications for the hardware components of each required domain controller • Determination of the design requirements for one or more standard server builds for the Windows Server 2003 domain controllers within this domain • Determination of the design requirements for the required mode(s) of implementation of the domain controllers • Design of FSMO role placement, standard domain controller server builds, and domain controller implementation

8.6.

Deliverables of Process Components This process will have the following deliverables: • The determination of the expected function(s), operations, and resource loads for each required domain controller • The determination of the design requirements for the placement and configuration of the domain-level FSMO roles • The determination of the minimum recommended hardware specifications for all relevant hardware components for the domain controllers • The determination of the design requirements for one or more standard server builds for Windows Server 2003 domain controllers • The determination of the design requirements for the required mode(s) of implementation of the domain controllers within the production environment

Page 262 of 354

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

© 2004 Mustan Bharmal • The design of FSMO role placement, one or more standard server builds, and domain controller implementation 8.7. Inter-Component Dependencies Each component of this process will have the following inter-component dependencies:
Domain Plan – Inter-Component Dependencies for Process to Design Domain Controllers for this Domain
Determination of the expected function(s), operations, and resource loads Determination of the design requirements for domain-level FSMO roles Determination of the hardware sizing requirements for the domain controllers Generation of the design for domain controllers

START

Determination of the design requirements for standard server build(s) for the domain controllers

Determination of the design requirements for the mode of implementation of the domain controllers
© 2004 MUSTANSH I R BHARMAL

8.8.

Process to Design Domain Controllers for this Domain
Domain Plan – Process to Design Domain Controllers for this Domain START
Execute B1 Execute D1 – D3 Execute A1 Execute A12 – A14 Execute B2 Execute B5 – B6 Execute A2 Execute B3 Execute A8 – A11 Execute A3 – A7 Execute B4
© 2 0 0 4 MU ST AN SH I
R

END

BHAR

MAL

8.9.

Process Considerations Consider the following information to generate a design for the domain controllers for this domain. Presented within the following six sections are the considerations for this process: 1. 2. 3. 4. 5. 6. Considerations for the determination of the expected function(s), operations, and resource loads on the domain controllers for this domain Considerations for the determination of the design requirements for the domain-level FSMO roles Considerations for the determination of the hardware sizing requirements for the domain controllers Considerations for the determination of the design requirements for standard server build(s) for the Windows Server 2003 domain controllers within this domain. Considerations for the determination of the design requirements for the mode(s) of implementation of the domain controllers Considerations for the generation of the design for the domain controllers for this domain

8.9.1.

Determination of the Expected Function(s), Operations, and Resource Loads Consider the following information when determining the expected function(s), operations, and resource loads on the domain controllers for this domain: • Factor B1: Understanding domain controller functions, operations, and resource loads

Page 263 of 354

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

© 2004 Mustan Bharmal ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the functions, operations, and resource loads of domain controllers that require determination. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: All domain controllers within a domain share multiple functions and operations in common, such as:  Provision of Kerberos authentication services and the Key Distribution Centre (KDC)  Provision of storage and access to the directory data held within the Domain partition  Provision of an access control infrastructure for Active Directory objects and services, and so on However, some domain controllers are required to support one or more functions and operations beyond those shared with their peers within the domain, such as the hosting of a domain-level FSMO role or the provision of directory support to a directory-enabled application, such as Exchange Server 2003. In some cases, it is possible to either distribute the “additional” functions and operations evenly across all domain controllers within a domain, or direct them to specific domain controllers. For example, it may be possible to configure a directory-enabled application to send read and write queries only to one or two specific domain controllers, or to any domain controller within the domain, via the supporting DNS infrastructure. The following factors represent and influence the potential “resource load” on domain controllers within a domain:  The number of Active Directory objects within the domain partition  The size of the Active Directory objects  The expected frequency of change in object numbers and one or more aspects / attributes of the objects The function(s) and operations domain controllers are expected to perform directly influence their performance, and hence the performance of a domain. As the objective of the design for the sizing of server hardware for domain controllers is to enhance and optimise the performance of the domain controllers (where possible), the determination of the expected function(s), operations, and resource loads on the domain controllers is pertinent to that design. • Factor A1: Determination of the expected function(s), operations, and resource loads for the domain controllers ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the expected function(s), operations, and resource loads for each required domain controller within this domain. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When determining the expected function(s), operations, and resource loads for the domain controllers within this domain, consider the following:

Page 264 of 354

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

© 2004 Mustan Bharmal

 This design methodology proposes the following approach to the determination of this information:  Review the results of the Site Plan process “design for domain controllers and GC servers” and determine the: • Number of domain controllers required for this domain • Which domain controllers within this domain require configuration as Global Catalog (GC) servers  Determine or predict the number of Active Directory objects this domain is required to support.  Determine the requirements for the domain to support directory-enabled applications, processes, and scripts  Determine the requirements for the domain to support any other functions and operations not installed and configured on a default installation of a Windows Server 2003 Active Directory domain controller. When attempting to determine or predict the number of Active Directory objects this domain is required to support, consider the following:  It is only necessary to count the instances of objects for the object classes with the highest representation in numbers within the domain, such as user and computer account objects, and group objects. Do not count system objects, as a default installation of a domain will have a standard number of objects and hence size of Active Directory database.  Where the Active Directory objects require creation via a migration tool that ports the objects from, for example, a legacy Windows NT 4.0 directory service, then it is simple to determine the number of objects required.  Determine or predict the number and nature of changes to Active Directory objects the domain controllers for this domain may be required to support. Changes include the creation, modification, and deletion of Active Directory objects, and aspects / attributes of the objects. A typical rate of change in a medium to large organisation of about three or more thousand users and computers is roughly between five and ten percent of the total number of objects in the domain per typical working day. In very small organisations, with only a couple of hundred Active Directory objects, the rate of change may be correspondingly quite low, such as one percent of the total number of object in the domain per typical working week.  Include estimates for the predicted growth of the Active Directory database for this domain, to reflect the growth of the organisation and / or autonomous divisions represented within the domain. When determining the requirements for the domain to support directory-enabled applications, processes, and scripts, consider the following:  Include all applications that rely on the Active Directory for normal operation and those that will only occasionally query the Active Directory for information.  Include applications and processes such as metadirectory solutions that may have a significant impact on the workload of a domain controller. A directory integration solution may generate a large number of sustained read queries, and infrequent write updates to the Active Directory.  The LDAP and ADSI interfaces of an Active Directory infrastructure support the operation of many scripted commands. Where possible, attempt to identify all

Page 265 of 354

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

© 2004 Mustan Bharmal

current, proposed, and potential scripts and processes that will execute such commands against the domain controllers for the domain. Using the above information and approach, execute the following:  Determine and document the actual / predicted resource load on the domain controllers for the domain, based upon the number of Active Directory objects the domain will support  Determine and document the functions, operations, and directory-enabled applications, processes, and scripts the domain controllers for this domain will be required to support.  Collate all determined information to generate a profile of the typical / predicted workload for each domain controller within this domain. 8.9.2. Determination of the Design Requirements for the Domain-Level FSMO Roles Consider the following information when determining the design requirements for the domainlevel FSMO roles: • Factor B2: Understanding the design requirements for domain-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 domainlevel 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 domain is required to support the following three domain-level FSMO roles:  The “PDC Emulator” role  The “RID Pool Master” role  The “Infrastructure Master” role The design for these three FSMO roles involves the following:  The determination of the requirements for the logical placement for these roles on domain controllers within the domain  The determination of the requirements to support the temporary failover of these roles to other domain controllers within this domain • Factor A2: Determination of the design requirements for the domain-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 domainlevel FSMO roles for this domain. ♦ 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 three domain-level FSMO roles, consider the following: The following factors influence the design for the placement of some or all of the domain-level FSMO roles:

Page 266 of 354

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

© 2004 Mustan Bharmal

 The number of domains in the forest  The configuration of the domain controllers as GC servers  The replication topology for this domain partition  The hardware specifications and capabilities of the domain controllers  The current / predicted function(s), operations, and resource loads on the domain controllers  The fault-tolerance and availability requirements for the domain-level FSMO roles Domain controller failures due to hardware issues, such as a faulty hard disk drive or other component, are readily addressable in most new servers with minimal or even no downtime. However, if a domain controller hosting FSMO role experiences hardware or software failure, or is subject to a planned maintenance outage that may exceed the time parameters for a directory service outage SLA, then it may be necessary to move the FSMO role to another domain controller within the domain. To support this requirement, it is necessary to identify alternative domain controllers within the domain for each of the three FSMO roles. This design methodology proposes the following approach to determine the design requirements for the placement of the three domain-level FSMO roles:  Define the criteria for the placement and failover of the Infrastructure Master FSMO role, and use the defined criteria to identify:  A suitable domain controller to permanently host this role, and  A failover domain controller to temporarily host this role in the event of a failure or planned outage of the permanent host domain controller for this role  Define the criteria for the placement and failover of the PDC Emulator and RID Pool FSMO roles, and use the defined criteria to identify:  Either one or two suitable domain controllers to permanently host these roles, and  Either one or two suitable failover domain controllers to temporarily host these roles in the event of a failure or planned outage of the permanent host domain controller(s) for these roles Consider the following when determining the criteria for the identification of the permanent and temporary host domain controllers for the Infrastructure Master FSMO role:  If this domain is the only domain within its forest, then this will influence the placement of the Infrastructure Master FSMO role. This is because the Infrastructure Master is responsible for the management of references to objects in its domain to objects in other domains. Where no other domains exist within the forest, then this role is, in effect, redundant.  It is essential for the operation of the Infrastructure Master FSMO role that the host domain controller is not a GC server, unless all of the domain controllers within a domain are GC servers. If all domain controllers are GC servers, then it is possible to host the Infrastructure Master FSMO role on any suitable domain controller within the domain.

Page 267 of 354

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

© 2004 Mustan Bharmal

 Due to the nature of the Infrastructure Master FSMO role, the resource demands placed on a domain controller by this role are minimal, unless there are frequent requirements to update inter-domain object references. Where it is not possible to identify or predict frequent requirements to update inter-domain object references, then it is feasible to consider the use of a medium to heavily utilised domain controller as the permanent host for this role.  The function of the Infrastructure Master FSMO role requires it to replicate the updates it makes to inter-domain object references to all other domain controllers within the domain. Hence, the permanent domain controller host for this domain should be, ideally, one placed at the hub of the replication topology for the domain. The temporary host domain controller for this role, required during a failure or planned outage of the permanent host, should also be located within the same Site as the permanent host domain controller. Consider the following when determining the criteria for the identification of the permanent and temporary domain controller host(s) for the PDC Emulator and RID Pool FSMO roles:  Note that the PDC Emulator role is typically a large consumer of RIDs, and hence will require frequent contact with the domain controller hosting the RID Pool FSMO role. This design methodology hence recommends hosting these two roles on a single domain controller. If, however, this is not desirable, to comply with (for example) availability requirements for the FSMO roles, or workload on the domain controller from the PDC Emulator role, then select two domain controllers, logically residing within the same Site, and configured as direct (and not transitive) replication partners. In this scenario, the design of the replication topology for a domain will hence have a strong influence on the design for the placement of the PDC Emulator and RID Pool FSMO roles.  Of the three domain-level FSMO roles, the PDC Emulator role typically places the highest demands on hardware resources of the host domain controller. The design for the sizing of the server hardware for the domain controllers will consider the resource utilisation profiles for each FSMO role, alongside other resource demands on the domain controller.  When identifying the suitable domain controllers to become the permanent host of the PDC Emulator FSMO role, consider the following hardware resource requirements for this role:  Ideally, the domain controller should not be: • The target for numerous queries generated by directory-enabled applications, processes, and scripts • Configured with another resource-intensive role, such as the bridgehead domain controller for a Site, and so on  The domain controller should have low processor utilisation (for example, less than forty percent), sufficient available RAM, and a good hard disk infrastructure to support the frequent read and write operations executed by this FSMO role.  The function of the PDC Emulator FSMO role means that all other domain controllers within the domain must contact it on a frequent basis. Hence, the permanent and temporary host domain controllers should have good network connectivity to all other domain controllers within the domain, and hence logically placed, for example, at a hub in the replication topology for this domain.  The function of the RID Pool FSMO role means that all other domain controllers within the domain must contact it, but on an infrequent basis, unless one or more domain controllers are the focus for multiple object creation demands. Good

Page 268 of 354

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

© 2004 Mustan Bharmal

network connectivity to all the other domain controllers within the domain is hence also essential for this role.  The hardware resource demands of the RID Pool FSMO role are minimal, as typically a domain controller does not consume allocated RIDs on a frequent basis. Hence, where there is a requirement to separate this role from the PDC Emulator role, it is feasible to consider the use of a medium to heavily utilised domain controller as the permanent / temporary host for this role. Using the above information and approach, execute the following:  Determine and document the criteria for the selection of the permanent and temporary domain controller hosts for the Infrastructure Master FSMO role within this domain  Identify and document the permanent and temporary domain controller host for the Infrastructure Master FSMO role within this domain  Determine and document the criteria for the selection of the permanent and temporary domain controller hosts for the PDC Emulator and RID Pool FSMO roles within this domain  Determine and document the requirement to host the PDC Emulator and RID Pool FSMO roles on the same domain controller (recommended), or on separate permanent domain controllers  Where there is a requirement to separate these two FSMO roles, determine and document the permanent and temporary host for each role. 8.9.3. Determination of the Domain Controller Hardware Sizing Requirements Consider the following information when determining the design requirements for the domainlevel FSMO roles: • Factor B3: Understanding the scope and components of a design for sizing domain controller hardware ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the scope and components of a design for sizing of domain controller hardware. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology presents the following objectives of the design for sizing of domain controller hardware:  To determine the hardware specifications and design (where necessary) of the inscope components of this design for each required domain controller  To ensure that the design for sizing of the domain controllers supports all actual and predicted resource demands on the domain controllers for this domain, predictable at this stage in the design and deployment of the domain, inline with criteria within defined service or operating level agreements (SLAs or OLAs) for the Active Directory infrastructure. It is important to note that pre-deployment server sizing is not a definite science but an educated assessment of the potential factors that influence the performance of hardware components to derive a potentially suitable hardware component specification and configuration.

Page 269 of 354

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

© 2004 Mustan Bharmal

Only once a domain controller is operating within its destined production environment is it possible to determine the actual performance of the in-scope hardware components of the server. Where an organisation can afford to invest in server hardware and infrastructure to generate a near-duplicate production environment, as a test laboratory, then it is possible to determine near realistic sizing requirements. However, most organisations do not have this luxury due to financial, logistical, and time constraints, and must hence rely on processes such as this to determine the most appropriate hardware specifications and configurations. The hardware components most influential in the performance of a domain controller are the processor, RAM, hard disks, and network interface cards (NICs). This design methodology hence proposes that aspects of the following hardware components of servers define the scope for the design of the sizing of domain controller hardware:  The model, version, and operating speed of the processor (often still referred to by the older term “CPU”), and numbers of Intel processors for an x86-based or an Itanium-based computer  The size, type, and configuration of random access memory (RAM)  The type, capacity, and data transfer speeds of hard disk drives, and numbers and configuration of multiple hard disk drives  The type and bandwidth capacity of network interface cards (NICs), and numbers and configuration of multiple NICs There is a plethora of excellent information available on sizing of Windows 2000 and, more specifically, Windows Server 2003 domain controllers. Hence, the objective of this step in this process is not to duplicate this readily available information, but simply instead to provide a summary of the factors and their considerations that will influence the selection and design (where required) of the above four hardware components. The onus is with the owner(s) of the domain to determine, following consideration of the information provided below, the most appropriate hardware configurations for the domain controllers within this domain. When determining the appropriate hardware specifications and configuration for the inscope components, consider the following:  The selection of hardware component specifications and configurations must reflect, and ideally exceed, their predicted or actual usage profiles. It is hence necessary to generate a usage profile for each hardware component most influential in the overall performance of a domain controller. It is possible to generate component usage profiles via the analysis of the volume, frequency, and nature of the appropriate input and output demands on the components over time. Typically, and where possible, baseline data is collected over a medium to long-term duration, such as a week to a month, as this provides a better statistical representation of the usage profiles for the in-scope components. However, as the objective of this design is to determine the hardware specifications and configuration of the in-scope components prior to the implementation of the domain controllers, it may not be possible to collect baseline data for component usage profiles until postdeployment.  The design for the hardware specifications and configurations of hardware components for domain controllers must hence only consider those determinable factors that may influence the operation and performance of a domain controller following implementation within the production environment. Performance management for domain controllers is an ongoing process that requires execution against all implemented domain controllers. The Active Directory Management Plan

Page 270 of 354

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

© 2004 Mustan Bharmal

process “design of a management plan for domain controllers and FSMO roles” discusses performance management in detail.  It is not sufficient to define a specification and / or configuration for a hardware component without the execution of an analysis to determine the potential usage profile for that component. Without the appropriate analysis, or an understanding of the factors that will influence the performance of a domain controller, the resulting domain controller specifications may:  Make it impossible for the domain owner(s) to comply with SLAs for the Active Directory infrastructure, where the specifications are insufficient to support the operational demands on the domain controllers, or  Prove a costly overspend on server hardware where the component specifications / configurations prove superfluous for the support of the actual operational demands on the domain controllers.  As discussed earlier, when determining the expected function(s), operations, and resource loads of the domain controllers, the following factors are influential in the performance of a domain controller:  The number of Active Directory objects the domain partition is to support, and the predicted rate of change on these objects.  The number of concurrent logons (interactive and network) and the authentication protocols employed (NTLM and Kerberos). The type of organisation will influence the impact of user logons. For example, a corporate organisation may generate a larger number of concurrent user logons than an ISP with the same number of users.  The volume, frequency, content, and function of queries directed at the domain controllers for this Active Directory domain via applications, processes, scripts that rely upon the Active Directory for routine operation.  The function(s) of a domain controller, such as a bridgehead server for inter-Site replication, a DNS server, a Global Catalog server, a FSMO role host, and so on.  Note the following non-usage profile factors, which will influence the selection of the specifications of the in-scope hardware components, and hence require consideration:  The availability of a hardware specification for a standard model or version of a proprietary server  The requirement to reduce financial overheads via the standardisation on only a few models of proprietary servers, and the opportunities to store standard replacement parts for all servers.  The financial overheads associated with different versions of hardware components, generally increasing with higher and more capable hardware specifications for components.  The financial overhead and availability of the supporting hardware, software, and cabling infrastructures required to support specific hardware specifications and configurations within servers. For example, the selection of a fibre-channel network interface card requires support with fibre-channel switches, cabling, and so on. This design methodology proposes the following approach towards the determination of the most appropriate hardware specifications and configuration for each of these four components:

Page 271 of 354

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

© 2004 Mustan Bharmal

 Execute following analysis for each of the four in-scope hardware components for this step (processor, RAM, hard disk, and NIC):  Understand the criteria for what constitutes “poor”, “normal”, and “good” operational performance for the component, and: • The impact of the performance of this component on the performance of the domain controller • The presence of any other hardware dependencies or bottlenecks on the operation of the component  Determine all specifications / configuration options available for that hardware component on the desired server platform / model.  Determine the routine operational factors for each required domain controller that will have an impact on the performance of that component  Define criteria for the use of each available specification / configuration option for a hardware component, to reflect financial constraints and requirements to enhance the operational performance that component and hence the domain controller. Note that these criteria are invaluable in post-implementation performance management, as they will support the requirements for upgrades, where necessary, in component specification / configuration to support compliance with higher criteria.  Evaluate the determined routine operational factors for each required domain controller against the defined criteria for the selection of hardware specifications / configurations.  Select the most appropriate specification / configuration for the component, based upon compliance with defined criteria, for each required domain controller within this domain. • Factor A3: Determination of the processor requirements for the domain controllers ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the appropriate processor specifications and configurations for each required domain controller within this domain. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Prior to the determination of the processor requirements for the domain controllers, consider the following:  The Windows Server 2003 operating system is designed to support the Intel Architecture, and consequently will install and operate only on x86-based or Itanium-based computers. Note that the 64-bit versions of Windows Server 2003, Enterprise Edition and Windows Server 2003, Datacenter Edition are only compatible with 64-bit Intel Itanium-based systems. It is not possible to execute the successful installation of these operating system versions on 32-bit systems.  Manufacturers of processors measure and define the performance of a processor in terms of “clock speed”, also called “clock rate”, which is the speed at which a microprocessor executes instructions. Every computer contains an internal clock that regulates the execution rate for instructions and synchronises all the various computer components. The processor requires a fixed number of clock ticks (or “clock cycles”) to execute each instruction. The faster the clock, the more instructions the processor can execute per second. Manufacturers express clock speeds in megahertz (MHz) or gigahertz (GHz). However, in order to measure and

Page 272 of 354

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

© 2004 Mustan Bharmal

define the performance of a processor on a server, it is necessary to employ very different parameters to the “clock speed” of the processor. For example, it is possible to use the parameters such as the queue length of a processor, or its percentage utilisation to measure the operational performance of a processor.  Note that it is only technically feasible to employ these parameters to assess the performance of the processor(s) on a domain controller deployed within a production environment. However, this process will use these parameters to define guidelines for processor performance targets, and provide factors that can influence the attainment of these targets.  The suitability of processor specifications and configurations on domain controllers requires assessment against:  The operational performance of the domain controllers  The operational performance of the applications, services, processes that generate the demands on the processors for domain controllers Consider the following to understand the target performance criteria for processors within domain controllers for this domain:  “% Processor Time” is the percentage of elapsed time that the processor spends to execute a non-idle thread. The system calculates “% Processor Time” by measuring the duration when the idle thread is active in the sample interval, and subtracting that time from interval duration. Each processor has an idle thread that consumes cycles when no other threads are ready to run. The use of the “% Processor Time” counter is the primary indicator of processor activity, and displays the average percentage of busy time observed during the sample interval. A sustained value of less than 40% during the routine operation of a “typical” domain controller within a production environment is acceptable.  “Processor Queue Length” is the number of threads in the processor queue. Unlike disk counters, this counter only shows ready threads and not running threads. Note that there is a single queue for processor time even on computers with multiple processors, and hence if a computer has multiple processors, it is necessary to divide this value by the number of processors servicing the workload. A sustained processor queue of less than 10 threads per processor is normally acceptable, dependent of the workload.  Note that like processors, expansion buses also have clock speeds. Ideally, the processor clock speed and the bus clock speed should be the same so that neither component slows down the other. However, in practice, the bus clock speed is often slower than the processor clock speed, which creates a bottleneck. The selection of the processor specifications and configuration for a proprietary server is dependent upon the model / version of the servers. It is hence necessary to determine, for the server model / version required to support the domain controllers, all of the potential processor selection options and upgrade options available, and the costs / feasibility of post-implementation upgrades. The options available for the selection of processors for servers are:  The model / type of processor, such as an Intel Pentium III, Intel Pentium III Xeon, Intel Xeon DP (Dual Processor), Intel Xeon MP (Multiple Processor), Intel Itanium, or an Intel Itanium 2 processor. Note that only the Enterprise and Datacenter Editions of Windows Server 2003 support the 64-bit Itanium processor. (Note that Intel designed the Xeon processor family specifically for mid-tier and back-end servers performing key business functions such as application serving, transaction processing, database management, and supply chain management. The Intel Xeon

Page 273 of 354

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

© 2004 Mustan Bharmal

processor features Hyper-Threading technology, Integrated Three-Level cache architecture, and Intel NetBurstTM microarchitecture.)  The number of processors required. Most models of proprietary servers for medium to high-end businesses support multiple processors in symmetric multiprocessor (SMP) configurations. Operating system support for numbers of processors varies with the version. For example:  Windows Server 2003, Standard Edition, supports a maximum of four processors in SMP configuration  Windows Server 2003, Enterprise Edition, supports a maximum of eight processors in SMP configuration  Windows Server 2003, Datacenter Edition, supports only eight, thirty-two, or sixty-four processors in SMP configuration  The clock speed of each required processor, ranging from, for example, 2.80 GHz to 3.2 GHz and greater, depending upon processor type  The amount and type of processor cache level, ranging from, for example, 512Kb L2 cache to 6Mb L3 cache, and greater, depending on processor type When determining the operations a domain controller may be required to execute that influence, and rely upon, the performance of the processor, consider the following:  The Active Directory operations a domain controller is required to support and execute that have the greatest influence and reliance on the performance statistics of the processor are interactive logons and LDAP queries and searches.  The performance of interactive logons, measured by the time required for a domain controller to execute an interactive logon request, is dependent upon the number and specifications of the processors within a domain controller. For example:  Increasing the number of processors from, for example, one to two can quarter the time required for an interactive logon, and from one to four can more than halve the time for an interactive logon (data from tests executed and published by Microsoft). It is important to consider the number of concurrent interactive logons each domain controller is required to support, as these specific results reflect large numbers of concurrent interactive logons (such as 10,000). Where a domain controller is required to support only a small range of concurrent interactive logons, such as from 500 to a thousand, then an increase in numbers of processors may not have a significant influence on the performance of interactive logons and the domain controllers. It is hence necessary to define the following criteria and execute tests, where possible, for evaluation against the defined criteria to determine the number of processors required: • The criteria for optimal performance of interactive logons, such as acceptable duration of time from initiation to completion of an interactive logon • The criteria for optimal domain controller processor utilisation levels during the processing of multiple concurrent interactive logons  The size of the L2 cache (processor cache memory that is typically external to the processor) has a significant impact on the performance of interactive logons. For example, a four-fold increase in the size of L2 cache from 512Kb to 2Mb, can quarter the time required for an interactive logon (data from tests executed and published by Microsoft). As above, it is necessary to define criteria and execute appropriate tests, where possible, to determine the optimal type and size of layered cache for the selected processor(s), bearing in mind the layered cache options available for the selected processor(s).

Page 274 of 354

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

© 2004 Mustan Bharmal

 The numbers of processors on a domain controller influences the performance of the domain controller and execution of LDAP queries and read / write operations targeted to the Active Directory database. It is possible to note the following about the influence of domain controller processors on the performance of LDAP operations:  The performance impact on a domain controller is primarily from the LDAP read and not LDAP write operations, and hence increasing the number of processors on a target domain controller will enhance read operations. The execution of read and write queries by a domain controller also increases the utilisation of the processors.  The type and size of layered cache will have a similar impact on the performance of LDAP read operations. It is important to note that most organisations employ mission critical directory-enabled applications, and hence their performance is vital to the operation of business processes. In these scenarios, it is important to ensure that the domain controllers for this domain are not the bottlenecks in the operation of these applications and processes. The criteria for the SLAs / OLAs for these applications may provide guidance on the targets for optimal processor performance of the target domain controllers for the applications. Based upon the above information, this design methodology proposes the following approach to the determination of the processor requirements for the domain controllers within this domain:  Determine the number of concurrent interactive logons each domain controller is required to support  Determine the presence, configuration, and function of applications, processes, and scripts that generate LDAP read and write queries targeted against the Active Directory database for this domain. Where it is possible to identify any sources of LDAP read and write operations against the Active Directory database, determine the following:  The nature and function of the LDAP operations  The expected frequency and volume of queries generated  The expected volume and type of data to be queried within each LDAP event (for example, is an LDAP query to ask for information about one object or one hundred thousand objects, and the number and types of object attributes queried, and so on.)  Determine the criteria for the optimal performance of the domain controllers based upon the processor utilisation and queue length parameters  Determine the criteria for the optimal performance for concurrent interactive logons  Determine or identify the criteria for the optimal performance of LDAP operations against one or more domain controllers for this domain using, where applicable, the criteria defined within any SLAs / OLAs for the applications.  Categorise, where possible, the domain controllers for this domain based upon their expected workload to support interactive logons and LDAP operations.  This design methodology recommends, respecting available time, resources, and the presence of other business and technical requirements, the design and execution of proof-of-concept tests to determine the optimal number and configuration of processors and layered cache size for each category of domain controller.

Page 275 of 354

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

© 2004 Mustan Bharmal

 Where it is not possible to execute proof-of-concept tests to determine hardware requirements more precisely, use just the information determined above to decide the appropriate processor requirements for each identified category of domain controller. Note that it is possible to generate the following conclusions using the information provided above:  Consider increasing the number and specifications of processors and size of layered processor cache on domain controllers required to service frequent and large numbers of concurrent interactive logon requests.  Consider increasing the number and specifications of processors for domain controllers required to support intensive LDAP operations. The support of infrequent and “light” LDAP operations has a negligible impact on the performance of the processor(s) of a domain controller. Use the above information and approach to execute an analysis to determine and document the processor requirements for each defined category of domain controller within this domain. • Factor A4: Determination of the RAM requirements for the domain controllers ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the appropriate random access memory (RAM) specifications and configurations for each required domain controller within this domain. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Prior to the determination of the random access memory (RAM) requirements for the domain controllers, consider the following:  Windows Server 2003 Active Directory is limited to utilisation of a main cache of with a virtual address space of 512Mb by default, or 1024Mb when enabled via the use of the “/3GB” switch within the Boot.ini file. However, an improvement over Windows 2000 Active Directory is the ability for the cache to grow more freely.  RAM, processors, and hard disk drives all influence their respective performance. For example, the performance and configuration of the hard disk infrastructure for a server that supports the page file, and the number, type, and specifications of the processor(s) have a significant influence on the performance of installed random access memory (RAM). Insufficient and, conversely, superfluous amount of installed RAM generate dependencies upon the hard disk and processor infrastructure, to support access to the page file, and processor utilisation to manage larger page files and swapping of data between installed RAM and page file.  Active Directory uses RAM as a temporary store for information read about Active Directory objects, or that requires writing to the Active Directory database. Hence, the amount, type, speed, and other capabilities of RAM, can influence the execution performance for read and write operations to the Active Directory database. The suitability of installed RAM specifications and configurations on domain controllers thus requires assessment against:  The operational performance of the domain controllers, to execute read and write operations to the Active Directory database, and  The operational performance of the applications, services, processes that generate the demands on the domain controllers to execute the read and write operations

Page 276 of 354

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

© 2004 Mustan Bharmal

 Manufacturers of RAM measure and define the performance of RAM based upon the following examples of parameters:  The speed of the memory, sometimes measured in Megahertz (MHz) or in terms of access time, which the actual time required to deliver data, measured in nanoseconds (ns). Whether measured in Megahertz or nanoseconds, memory speed indicates how quickly the memory module itself can deliver on a request following the reception of the request. When the processor needs information from memory, it sends out a request, which the memory controller manages. The memory controller sends the request to memory and reports to the processor when the information will be available for it to read. This entire cycle, from processor to memory controller to memory and back to the processor, can vary in length according to memory speed as well as other factors, such as bus speed.  The memory bandwidth (by analogy with the term “bandwidth” from communication theory), which is a measure of how quickly information (expressed in terms of bits) can be transferred between two places in a computer system. The memory bandwidth for RAM, typically expressed in bits per second, bytes per second, or cycles per second (Hertz), is a function of the rated speed of RAM (for example in MHz or ns) and the size of its data path. The determination of the RAM requirements for domain controllers within this domain for a proprietary server is often dependent upon the model / version of the server and the support RAM options. It is hence necessary to determine, for the server model / version required to support the domain controllers, all of the potential RAM selection options and upgrade options available, and the costs / feasibility of post-implementation upgrades. The options available for the selection of RAM for servers are:  The type of RAM installed. It is possible to identify the following common types of RAM:  Dynamic RAM (DRAM), is the most common form of RAM for computers, and can hold data for only a short period. To retain the data, it requires periodic refreshes, and if the cell does not receive a refresh, then the data is lost.  Synchronous DRAM (SDRAM) is a DRAM technology that uses a clock to synchronise signal input and output on a memory chip. The clock is coordinated with the processor clock so the timing of the memory chips and the timing of the processor are "in synch". Synchronous DRAM saves time in executing commands and transmitting data, thereby increasing the overall performance of the computer. SDRAM allows the processor to access memory approximately 25 percent faster than EDO memory.  EDO Memory is a type of DRAM technology that shortens the read cycle between memory and processor. On computer systems designed to support it, EDO memory allows a processor to access memory 10 to 20 percent faster than comparable fast page mode memory.  Fast Page Memory (FPM), is an early form of DRAM, and had an advantage over previous memory technologies because it allowed for faster access to data located in the same row.  Rambus DRAM (RDRAM), developed by Rambus, Inc, provides significant performance improvements of up to 800 MHz where standard PC133 SDRAM operates at 133 MHz.  Double Data Rate-Synchronous DRAM (DDR Memory), is the next generation of the current SDRAM technology. DDR SDRAM reads data on both the rising and

Page 277 of 354

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

© 2004 Mustan Bharmal

the falling edge of the system clock, delivering twice the bandwidth of standard SDRAM, hence doubling memory speed without increasing the clock frequency. DDR SDRAM memory hence offers superior performance over current SDRAM technology. Note that although DDR memory is on the same size circuit board as SDRAM, DDR memory is not backward compatible with existing SDRAM memory. DDR memory has 184 pins and a single notched motherboard key. SDRAM memory has 168 pins and a double-notched motherboard key.  The amount of RAM installed, will limit the storage capability of the RAM, and thus the operational performance of the domain controller. Note the following limitations on amount of RAM supported by the different versions of the Windows Server 2003 operating system:  Windows Server 2003, Standard Edition, will support a maximum of 4GB of RAM  Windows Server 2003, Enterprise Edition, will support: • 32-bit for x86 computers will support 32GB of RAM • 64-bit for Itanium-based computers will support 64GB of RAM  Windows Server 2003, Datacenter Edition, will support: • 32-bit for x86 computers will support 64GB of RAM • 64-bit for Itanium-based computers will support 512GB of RAM When determining the operations a domain controller is required to execute that influence, and rely upon, the operational performance of installed RAM, consider the following:  The Active Directory operations a domain controller is required to execute and support that have the greatest influence and reliance on installed RAM are interactive logons and read / write operations.  Note however, that the impact of installed RAM on the performance of interactive logons is dependent upon the number of users logging on. For example, Microsoft have published the following memory guidelines:  512Mb of RAM is capable of supporting interactive logons for up to five hundred users  1Gb of RAM is capable of supporting interactive logons for up to a thousand users  2Gb of RAM is capable of supporting interactive logons for up to ten thousand users  Although read and write operations to the Active Directory database are memory intensive, they rarely occur on a very frequent basis to be detrimental to the performance of a domain controller, or unless the amount of installed RAM is less than 512Gb in size. Based upon the above information, this design methodology proposes the following approach to the determination of the RAM requirements for the domain controllers within this domain:  See the results of the earlier analysis, to determine the processor requirements for the domain controllers, to determine the following information:

Page 278 of 354

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

© 2004 Mustan Bharmal

 The number of concurrent interactive logons each domain controller is required to support  The presence, configuration, and function of applications, processes, and scripts that generate LDAP read and write queries targeted against the Active Directory database for this domain.  Where identified, the categories for the domain controllers for this domain based upon their expected workload to support interactive logons and LDAP operations. Using the above information and approach, execute the following:  Determine and document the RAM requirements for each defined category of domain controller within this domain, to support their predicted workloads.  Determine and document the requirements for fault-tolerance of RAM, via the use of technologies such as online spare memory, and hot plug RAID memory, and so on. • Factor A5: Determination of the hard disk requirements for the domain controllers ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the appropriate hard disk specifications and configurations for each required domain controller within this domain. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The following two factors associated with domain controllers predominately generate the hard disk dependencies:  The hard disk support requirements for the pagefile(s) for the operating system  The hard disk support requirements for the Active Directory database (ntds.dit) and associated files, such as the transaction logs and checkpoint files. The results of the Forest Plan process “determination of the size of the Active Directory database for the forest” will provide an indication of the hard disk space and storage requirements to support the Active Directory database. The following aspects of hard disk drives (HDDs) influence the performance of the hard disk infrastructure for a domain controller:  The type of HDD (typically IDE or SCSI interface)  The performance profile / statistics for the HDDs  The fault-tolerance configurations for the HDDs, and the resulting number of HDDs (referred to by “spindles”)  The number of SCSI disk controllers and the number of SCSI HDDs each controller is to manage, and so on. Manufacturers rate the performance of hard disk drives (HDDs) using the following parameters:  The type of hard disk drive, where SCSI interfaced HDDs have a significantly improved performance profile in comparison to IDE interfaced HDDs. A SCSI interfaced HDD provides a greater bandwidth throughput for data.  The specifications of the HDD, such as the:

Page 279 of 354

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

© 2004 Mustan Bharmal

 Disk access times, which are measured in milliseconds (thousandths of a second), often abbreviated as ms. Fast hard disk drives for computers boast access times of about 9 to 15 milliseconds. Note that this is about 200 times slower than average DRAM. The access time for disk drives includes the time it actually takes for the read/write head to locate a sector on the disk (called the seek time). This is an average time since it depends on how far away the head is from the desired data.  The speed of the HDD, measured in revolutions per minute, such as 3,600 to 15,000 RPM. The configuration requirements for the Active Directory database and support files will influence the design for the supporting HDD infrastructure. For example, an organisation may identify the requirement to host the Active Directory database and transaction log files on separate HDDs to the operating system and pagefile(s), and the discrete Active Directory HDDs may require fault tolerance using a RAID technique. This will hence increase the number of HDDs required, and their configuration. Note that HDD requirements must be constrained around the support capabilities of the intended proprietary server model / version, as some models / versions of servers can only support a limited number of HDDs. It is possible to install external arrays of HDDs for some server models / versions, but at an expense. When determining the hard disk requirements for the domain controllers within this domain, consider the following:  The following variables require support from the design for a hard disk infrastructure for the domain controllers:  The requirement to support the expected size of the Active Directory database for this domain (on non-GC servers), and the forest (on GC servers)  The requirement to support the frequency and performance of read and write operations executed and supported by the domain controllers  The requirement to support the fault tolerance and performance requirements for the Active Directory database and supporting files  Disk space is relatively inexpensive in comparison with other primary hardware components of domain controllers. This should hence not represent a significant influence on the determination of the number and size of HDDs required.  The majority of proprietary models and versions of servers support a variety of high performance, inexpensive, and fault tolerant HDD solutions. This design methodology proposes the following approach to determine the hard disk drive requirements for the domain controllers within this domain:  Using the determined values for the predicted workloads of domain controllers, identify the hard disk size requirements for the Active Directory database for normal domain controllers, and domain controllers operating as GC servers as well.  Determine the requirements for increased performance of read / write operations to the Active Directory database via, for example, the hosting of these files on dedicated HDDs. Isolation of the Active Directory database and transaction log files from other data that may require concurrent read / write access increases the speed of such operations. Hosting these dedicated HDDs via a dedicated HDD controller will enhance the performance as well.  Determine the requirements for the fault tolerance / high availability of the HDDs that will host the Active Directory database and transaction log files. Note that the

Page 280 of 354

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

© 2004 Mustan Bharmal

use of RAID technologies, depending on the RAID level employed, may slightly compromise the performance of the HDD infrastructure, as there may be a requirement for the co-write of parity information, and so on. Use the above information and approach to execute an analysis to determine and document the HDD requirements for each defined category of domain controller within this domain. • Factor A6: Determination of the NIC requirements for the domain controllers ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the appropriate network interface card (NIC) specifications and configurations for each required domain controller within this domain. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Network interface cards (NICs) are a very significant hardware component within a domain controller for a domain, especially where two or more domain controllers support the domain. Without an available and performing NIC on domain controllers within a domain, the Active Directory domain is not accessible by clients of the domain. The selection of a network interface card for a domain controller must address the following variables:  The types of network interface cards (NIC) required to support:  The network communication requirements for the domain controllers, and  Operate within the supporting TCP/IP architecture for the forest  The bandwidth throughput for the NICs When determining the NIC requirements for the domain controllers, consider the following:  The following are a few examples of the different types of NICs, based upon network topology and data throughput capabilities, which are available for use by domain controllers:  Ethernet (10 Mbps)  Fast Ethernet (100 Mbps)  Gigabit Ethernet (1000 Mbps)  Manufacturers of NICs measure the data throughput of a NIC in Megabits per second (Mbps).  Note that the data throughput of a NIC on a LAN is rarely a limiting factor in the performance of Active Directory-related operations by domain controllers within this domain. Only where the network is saturated and levels of available bandwidth on a LAN are consistently low would a NIC represent a throughput bottleneck. Increasing the data throughput of a NIC, for example, from a 100 to a 1000 Mbps, will only shift the cause of a data throughput bottleneck from the NIC to another factor. A requirement for a significant improvement in the performance of a network is only attainable where, for example in this scenario, the supporting network infrastructure

Page 281 of 354

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

© 2004 Mustan Bharmal

is upgraded to support fibre optic data transmission, and all servers and domain controllers are also upgraded with Gigabit Ethernet NICs, and so on.  Most proprietary servers ship with built-in NICs, and / or capabilities to install additional NICs. Some servers support the teaming of NICs to attain either:  An increase in data throughput via the teaming of multiple NICs to act as a single virtual NIC, or  To attain fault tolerance and high availability of a NIC by supporting automatic failover to a standby NIC in case of failure of a primary NIC Use the above information to execute an analysis to determine and document the NIC requirements for each defined category of domain controller within this domain. 8.9.4. Determination of the Design Requirements for Standard Server Build(s) Consider the following information when determining the design requirements for standard server build(s) for the Windows Server 2003 domain controller within this domain: • Factor A7: Determination of the requirements for the design of standard server builds for domain controllers ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand and determine the requirements for the design of one or more standard server builds for Windows Server 2003 domain controllers within this domain. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: It is possible to install Active Directory on any Windows Server 2003 standalone or member server. However, to support any security and operational requirements for the domain controller, it is also necessary to implement a variety of configurations on the supporting operating system. Note that it is also necessary to ensure the hardware components of the server will also support any performance requirements for the domain controller. Most organisation hence prefer to design and build standard builds for their domain controllers and member servers, with each build customised to support all known and predicted requirements of the role it will support. Where organisations invest in server hardware dedicated to hosting a particular server role, then the design of the hardware components may also require customisation to support the requirements of the server roles. Note that this information is available following execution of the above steps to determine the hardware component requirements for the domain controllers. When determining the requirements for the design of one or more standard server builds for the Windows Server 2003 domain controllers within this domain, consider the following:  The design of a standard server build for domain controllers has the following associated advantages:  All details of the configuration requirements for all hardware, operating system, and applications on the domain controllers are documented and available for future reference.

Page 282 of 354

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

© 2004 Mustan Bharmal

 The documentation of all configuration requirements will ensure that all domain controllers deployed using a standard server build will have an identical configuration. This will hence reduce configuration errors, administrative overheads, and time required to manage and troubleshoot the domain controllers.  A standard server build for domain controllers facilitates any requirements to rebuild one or more domain controllers in an emergency, via the presence of documented and detailed build requirements for the domain controllers.  A standard server build facilitates any requirements to roll out a configuration change across all domain controllers. This is because all domain controllers generated using a standard build for a domain controller will have an exactly similar baseline configuration.  The design of a standard server build for domain controllers has the following associated disadvantages:  There are administrative and financial overheads associated with the: • Development and testing of the design for each required standard server build for domain controllers. • Maintenance of each required standard server build, to update the builds with configuration and operating system service packs, hot fixes and so on. • Maintenance of the design documentation for each required standard server build to reflect modifications to the build.  It may be necessary to train local and remote administrators in the use of the standard server builds for the domain controllers, and enforce their compliance to execute all configuration requirements detailed within the standard builds.  The number of domain controllers that will represent this domain will influence the requirements for the design of one or more standard server builds. For example, where a domain will only require the minimum of two domain controllers, then the overheads associated with the design, development, and testing of a standard server build may be unjustified. However, where this domain will require ten or more domain controllers, then there is a strong case for the design of one or more standard server builds.  The roles of the domain controllers within this domain may influence the number of types of standard server builds required. For example, a particular domain controller role may require a specific hardware configuration to support intensive performance requirements, such as a PDC Emulator or Bridgehead server. In this scenario, it may be necessary to design a dedicated standard server build to support the hardware configuration requirements for these server roles.  Note that a design for a standard server build for domain controllers manifests initially as a design document that details all the necessary configuration requirements. It is subsequently possible to translate the design of the standard server build into one or more of the following examples:  An automated / scripted deployment CD-ROM / DVD-ROM or an image that accurately reflects all of the design requirements for a standard build.  An image of a hard disk drive from a reference domain controller configured as per the design specifications of the standard server build.

Page 283 of 354

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

© 2004 Mustan Bharmal

 A series of systematic instructions for the installation and configuration of a domain controller, to reflect a standard server build, by a local or remote administrator / engineer / consultant.  The next step in this process, to determine the required mode(s) of implementation of the domain controllers, will determine the translation requirements for the standard server build(s) into one or more of the above options. This design methodology proposes the following approach to determine the requirements for the design of one or more standard server builds for domain controllers within this domain:  Determine the threshold criteria for the design of a standard server build based upon the number of domain controllers within this domain. It is necessary to define this criterion, as the number of domain controllers within a domain may not remain constant. Hence, with a defined threshold criterion, subsequent compliance in the future may support the requirements to design standard server builds.  Determine the criteria for the categorisation of the domain controllers for this domain to support different types of standard server builds. The following example criteria are offered:  A domain controller role may require a dedicated / customised standard server build where it is possible to identify significant differences in the hardware, operating system, or software configuration requirements of that role against other domain controller roles. For example: • A domain controller hosting the PDC Emulator FSMO role or the Bridgehead server role for a Site may have specific hardware configuration requirements to support the performance demands of their roles. • There is a requirement to deploy domain controllers for this domain within multiple countries, and hence a requirement to reflect language differences and possibly security configuration differences. • It is possible to identify a group of domain controllers that will share a different server platform (identified by a model or version of a proprietary server), and hence the requirement for a discrete standard server build.  Determine the threshold criteria to support the requirement for the design of more that one type of standard server build. For example, generate a dedicated / customised standard server build only where it is possible to identify three or more domain controllers, with identical and custom configuration requirements significantly different to that of the majority of domain controllers.  Using the defined criteria, determine the number of standard server builds required, and the domain controllers each server build will support. Using the above information, execute the following:  Determine and document the requirement for the design of one or more standard server builds for domain controllers.  Where it is possible to identify the requirement for the design and use of one or more standard server builds, then execute the following:  Determine and document the threshold criteria, based upon numbers of domain controllers for this domain, which support the requirement to design one or more standard server builds for the domain controllers.

Page 284 of 354

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

© 2004 Mustan Bharmal

 Determine and document the categories of domain controller roles that support significantly differing configuration requirements and hence may require a dedicated standard server build  Determine and document the threshold criteria, based upon the number of domain controllers within each identified category, which will support the requirement to design a dedicated / customised standard server build for the domain controllers aligned to that category.  Determine and document the number of standard server builds required, and the domain controllers each standard server build will support. • Factor B4: Understanding the components of a standard server build for a Windows Server 2003 domain controller ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has understood and identified the requirement for the design of one or more standard server builds for Windows Server 2003 domain controllers, and  Wishes to understand the components of a standard server build prior to the determination of the design requirements. ♦ 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 a standard server build design for a domain controller is comprised of the following three primary components:  The design of the configuration for server hardware and components  The design of the configuration for the Windows Server 2003 operating system  The design for the installation and configuration of standard software The design of the configuration of the server hardware and components is comprised of the following sub-components:  Design of the disk and RAID configuration  Design of the disk partitioning, file system, and drive letter configuration  Design of the CMOS and BIOS configuration and security settings  Determination of the minimum BIOS and firmware versions for the server and hardware components  Design of the configuration of peripheral devices, cards and so on The design of the configuration for the Windows Server 2003 the operating system is comprised of the following sub-components (note that most operating system configuration settings are definable via GPO policies, such as the settings for Event Logs, file system and registry security, and system services):  Determination of the operating system version, service pack and post-service pack hot fixes that require application to the build  Determination of the Windows component that require installation as part of the standard build

Page 285 of 354

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

© 2004 Mustan Bharmal

 Configuration of the regional, language, and data / time settings  Configuration of computer performance options  Configuration of user and system environmental variables  Configuration of startup and recovery options  Configuration of error reporting  Configuration of local backup and recovery (where not defined elsewhere)  Configuration of networking options  Configuration of settings for default and custom services The design for the installation and configuration of standard software is comprised of the following sub-components:  Determination of the proprietary and custom applications and utilities to be installed within the standard build  Determination of the applications that are to be installed as part of the standard build that:  Are compatible with Windows Server 2003  Are incompatible with Windows Server 2003 in their current version / service pack but can be upgraded to become compatible  Are incompatible with Windows Server 2003 and can not be upgraded to a compatible version  Determination of the OEM drivers and software to be installed within the standard build  Design for the installation and configuration of the standard applications and utilities  Design for the installation and configuration of the OEM drivers and software The design requirements for the installation and initial configuration of Active Directory on the domain controller, and the requirements to customise a standard server build for a particular domain controller role. For example:  To configure a domain controller as a Global Catalog (GC) server  To configure a domain controller as a preferred bridgehead server  To configure a domain controller to host a FSMO role  The assignment of a Site location to a domain controller  The assignment of a functional level for a new forest  And so on. • Factor A8: Determination of the design requirements for the hardware configuration within each required standard server build for Windows Server 2003 domain controllers ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:

Page 286 of 354

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

© 2004 Mustan Bharmal

 Has understood and identified the requirement for the design of one or more standard server builds for Windows Server 2003 domain controllers, and  Wishes to determine the design requirements for the hardware configuration within each required standard server build for the Windows Server 2003 domain controllers within this domain. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: When determining the hard disk drive (HDD) configuration requirements for each required standard server build, consider the following: The following HDD configuration options require determination:  The number and size of HDDs required for each standard server build, based upon the disk requirements for the domain controllers supported by a standard build.  The fault tolerance and high availability configuration requirements for the HDDs  The disk partition requirements for the HDDs  The file system requirements  The drive letter configurations for the HDD partitions The first two options above (the number and size of HDDs, and the fault tolerance / high availability requirements for the HDDs) for each standard build is determined from the above steps to identify the hardware sizing requirements for the domain controllers. When determining the disk partition requirements for the HDDs, consider the following:  This design methodology recommends HDDs do not have two or more partitions, and instead just a single primary partition for each entire HDD, where possible. This will facilitate disk management and growth requirements for the data on the partition.  A HDD with multiple partitions will leave a significant amount of redundant disk space within each partition, and hence prove inefficient. When determining the file system requirements for the HDDs, the design methodology recommends formatting of all HDDs with NTFS. When determining the drive letter configurations for the HDD partitions, this design methodology recommends the following:  All required partitions be assigned a drive letter and must not be mounted to folders and so on.  The assignment of drive letters must be consistent across all standard builds for the domain controllers. For example, where a domain controller is to have four partitions to support the operating system, pagefile, Active Directory database and transaction log files, assign following drive letters:  Assign “C” to the system and boot partition (where operating system files reside)  Assign “D” to the partition that holds the pagefile and any other infrequently accessed data, such as source files for applications and the operating system.  Assign “E” to the partition to host the Active Directory database  Assign “F” to the partition to host the Active Directory transaction log files

Page 287 of 354

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

© 2004 Mustan Bharmal

 Note that drive letters also require assignment to CD/DVD-ROM drives, and network drive mappings, and so on. Note that Active Directory automatically disables disk write caching and advanced performance for HDDs. When determining the design requirements for the CMOS and BIOS configuration settings for each required standard server build, consider the following: It is possible to control a variety of aspects of servers via the BIOS for a server. For example, it is possible to define security settings, boot order, device settings and status (such as enabled or disabled), and so on. Most new motherboards for proprietary servers have a “dual BIOS” for fault tolerance, so that a fault in the primary BIOS triggers an automatic replacement of the primary BIOS by the backup BIOS. When determining the BIOS configuration requirements for domain controllers, consider the following:  Disable unnecessary and security hazardous devices and ports, such as serial ports  Assign an “Administrator” password that controls access to the BIOS and configuration of the BIOS  Configure / select any fast boot options for the domain controllers  Disable any key input prompts for boot up, since this may hinder / prevent restarts of a domain controller unless physically at the server Determine, from the server manufacturer’s website, the latest BIOS version(s) for each required server model / version, and stipulate a BIOS version as the standard for a standard server build. Note that the BIOS version will change on a regular basis, as manufacturers release updates, so the version stipulated for the design of the standard server build is just to provide a start point for BIOS versions. Note also that most large manufacturers do not manufacture servers on demand, but in advance and hence are stored in warehouses until shipped to the customers. Hence, the BIOS version that ships with a server may be a few months out of data and thus require updating. Stipulate and provide, within the design for the standard server builds, a central shared location for all BIOS and firmware updates, and detail the versions, target server models, and so on, and instructions for execution of BIOS and firmware updates. Using the above information, execute the following:  Determine and document the design requirements for the configuration of all aspects of the HDDs for each required standard server build  Determine and document the design requirements for the configuration of all aspects of the CMOS and BIOS for each required standard server build • Factor A9: Determination of the design requirements for the operating system configuration within each required standard server build for Windows Server 2003 domain controllers ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:

Page 288 of 354

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

© 2004 Mustan Bharmal

 Has understood and identified the requirement for the design of one or more standard server builds for Windows Server 2003 domain controllers, and  Wishes to determine the design requirements for the operating system configuration within each required standard server build for Windows Server 2003 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 operating system version, service pack version, and inter-service pack hot fixes requirements for each required standard server build, consider the following:  This design methodology recommends the use of Windows Server 2003, Standard Edition, for all domain controllers. However, consider the use of the Enterprise or Datacenter Editions of Windows Server 2003 only where it is possible to identify requirements for hardware support profiles or clustering.  Identify and set the initial standard on pre- or post-service pack hot fixes, and update the design as appropriate with each new release of service pack / hot fix. When determining the operating system registration setting requirements for each required standard server build, consider the following:  The registration settings for an operating system refer to the details for the “Name” and “Organisation” fields that denote the owner(s) of the server.  Ensure a consistent value for all standard server builds, which may already exist within an organisation-wide policy. When determining the Windows components requirements for each required standard server build, consider the following:  A combination of the new features within Windows Server 2003 and the Microsoft secure computing initiative has changed the Windows components installed by default with the operating system.  This design methodology strongly recommends consultation of the “Microsoft Windows Preinstallation Reference” to identify those Windows components installed by default. This reference is within the file “ref.chm”, found within the “deploy.cab” cabinet file, in the “Support” folder on the operating system CD-ROM.  Domain controllers should, ideally, be dedicated to the operation of this service and directly related services (such as DNS) only, and not perform any other services or functions. Hence, when determining the design requirements for the Windows components, ensure that the design for the standard server build only installs those components essential to the operation of a domain controller. When determining the regional, language, and date / time setting requirements for each required standard server build, consider the following:  Include regional, language, and date / time settings within the design of a standard server build only where all target domain controllers for the build will share the same settings.  Where it is possible to identify differing requirements for regional, language, and date / time settings, then there may be a requirement to define these as postdeployment configuration tasks for the target domain controllers.

Page 289 of 354

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

© 2004 Mustan Bharmal

When determining the computer performance options for each required standard server build, consider the following:  The “performance” options for a Windows Server 2003 domain controller are accessible via the “advanced” tabbed page of the “System Properties” dialog box. The following options are available for configuration:  Visual Effects  Processor Scheduling  Memory Usage  Virtual Memory (see the previous step for virtual memory configuration requirements)  This design methodology proposes the following recommendations for these “performance” options:  Select, in the “Visual Effects” section, the option “Adjust for best performance”  Select, in the “Processor Scheduling” section, the option “Background services” to specify that all programs receive equal amounts of processor resources. Note that the selection of the alternate option “Programs” specifies that the operating system provide more processor resources to the foreground program than to the background program.  Select, in the “Memory Usage” section, the option “System cache” as this option provides the computer and applications with a large system cache. Note that the selection of the alternate option “Programs” specifies that the server operate as a workstation, rather than as a server. The applications operating on the server may work faster but the system cache size will be the default size that came with Windows. When determining the user and system environmental variables for each required standard server build, consider the following:  The “Environmental Variables” options for a Windows Server 2003 domain controller are accessible via the “advanced” tabbed page of the “System Properties” dialog box. The following options are available for configuration:  The “user variables” for the currently logged on user  The “system variables” for the operating system  When determining the requirements to define any custom user and / or system environmental variables, consider the following:  Applications, processes, and scripts that require execution on the domain controllers may require a custom variable, such as a file path or folder. Most proprietary applications generate the appropriate system variables during installation. However, custom applications or scripts may not define the variables, and these may hence require manual definition.  It is important to modify the default variables for the operating system only with a full understanding of the potential consequences of such modifications. When determining the computer startup and recovery options for each required standard server build, consider the following:

Page 290 of 354

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

© 2004 Mustan Bharmal

 The “startup and recovery” options are accessible via the “advanced” tabbed page of the “System Properties” dialog box. The following options are available for configuration:  The “system startup” options  The “system failure” options  This design methodology recommends that a domain controller for a production environment must operate on a single-boot server, and not a multi-boot server. Hence, disregard the “system startup” options.  This design methodology proposes the following recommendations for the “system failure” options:  Enable the check box for “Send an administrative alert”  Selection of the “automatically restart” checkbox is controversial. Some organisations prefer a domain controller not to restart automatically if it experienced, for example, a “blue-screen event”. However, some organisations prefer to select this checkbox where, for example, a domain controller is the only domain controller for a physical location, and it must hence automatically restart, if possible.  Within the “write debugging information” section, this design methodology recommends the selection of the option to perform a “complete memory dump”. Note that it is important to consider the total amount of RAM installed prior to selection of this option. For example, a Windows Server 2003 domain controller with more than 2 GB of RAM installed may time quite some time to generate a complete dump file, and this may hence exceed any SLA / OLA criteria. Note the following when selecting the “complete memory dump” option: • It is possible to enable or disable the checkbox to “overwrite an existing file” • Where the pagefile does not reside on the system partition, or has an initial size of zero Mb, then the system may not be able to create a debugging file of a STOP error occurs. A dialog box will appear requesting confirmation of this option.  This design methodology recommends no alternation to the default location for the dump file, unless disk capacity of the default location may not support the predicted size of the dump file. Do not select a network location for the dump file. When determining the error reporting options for each required standard server build, consider the following:  The “error reporting” options, new to Windows Server 2003, are accessible via the “advanced” tabbed page of the “System Properties” dialog box. The following options are available for configuration:  “Disable error reporting”, with a sub option of “but notify me when critical errors occur”  “Enable error reporting”, with the following sub options: • (For) Windows operating system • (For) Unplanned machine shutdowns • (For) Programs (can select the Programs), and the sub option:

Page 291 of 354

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

© 2004 Mustan Bharmal ♦ Force queue mode for program errors  This design methodology recommends that the standard server builds for all domain controllers should “Enable error reporting”, with, at a minimum, selection of the (for) “Windows operating system” sub option. When determining the local backup and recovery options for each required standard server build, consider the following:  This design methodology recommends the following local backup and recovery options for the standard server build of each required domain controller:  Install the recovery console via execution of the switch “winnt32.exe /cmdcons” on the “winnt32.exe” executable in the “i386” folder on the operating system CDROM. This installs a command line operating system, accessible via the boot menu, which permits the emergency recovery of the operating system. The installation of the recovery console has a very small footprint (approximately 8Mb) on the system partition.  The generation of local scheduled backups of the “System State” can facilitate faster recovery of a domain controller. In addition to backing up a domain controller to tape or other media, the generation of a local copy of the System State supports the faster recovery of a domain controller, as a restore is run directly from a HDD and not, for example, from a tape.  The automated backup of the registry, independently of the “System State”, via a batch file executed during the shutdown of a domain controller, using the “regback.exe” resource kit utility. For example, it is possible to create a “shutdown script”, assigned to a domain controller using a GPO policy, which runs a batch file named, for example, “regback.bat” that executes the “regback.exe” utility. The “regback.exe” utility can generate backup copies of the five registry files (default, SAM, SECURITY, software, and system) to a local folder. The presence of these files can assist a disaster recovery process for the domain controller if the operating system does not startup because of a corrupted registry file. When determining the networking options for each required standard server build, consider the following:  The “networking” options refer to the configuration of the network interface card(s) (NICs) and TCP/IP protocol stacks for each NIC.  This design methodology recommends the following networking options:  Install and configure only the TCP/IP protocol stack on the domain controllers unless there is an explicit requirement for the use of other protocols  Configure a static IP address for each NIC and do not share the NIC  Do not configure TCP/IP filtering unless there is an explicit requirement to support this feature  Where a domain controller has multiple NICs, rename them as appropriate to permit differentiation between the NICs. When determining the configuration options for default and custom services within each required standard server build, consider the following:  The following configuration options are available for each default or custom service:  The display name for the service

Page 292 of 354

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

© 2004 Mustan Bharmal

 The startup type for the service (disabled, manual, or automatic)  The start parameters for the service, where required  The log on requirements for the service (use of the Local System account, or a custom account granted the “log on as a service” right)  The association of the service with a hardware profile  The recovery options for the service  This design methodology proposes the following recommendations for the configuration of default or custom services as part of a standard server build:  Do not change the display name or change the startup parameters for default services unless explicitly required. Be aware that the “dependencies” tabbed page only lists the dependencies for a service to operate, or the dependencies a service generates. It is possible to note inter-service dependencies not clearly intuitive, or not listed in this tabbed page or even documented in help files or whitepapers, and hence it is important to test all custom configuration requirements for default services carefully.  Consider the configuration of recovery options for services critical to the operation of the domain controller, such as the DNS server service, the Server service, and so on. Note some services, such as the Security Accounts Manager (lsass.exe), and the Netlogon service, do not permit the definition of recovery options. If the Netlogon or SAM services fail, this will restart the computer. Use the above information and approaches to execute an analysis to determine and document the Windows Server 2003 operating system design requirements. • Factor A10: Determination of the design requirements for standard software on one or more standard server builds for Windows Server 2003 domain controllers ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has understood and identified the requirement for the design of one or more standard server builds for Windows Server 2003 domain controllers, and  Wishes to determine the design requirements for standard software on each required standard server build for the Windows Server 2003 domain controllers within this domain. ♦ 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 standard programs, tools, and utilities for incorporation into each required standard server build, consider the following:  It is necessary to identify all applications, utilities, and tools that a standard server build for domain controllers is to include.  For each identified program, determine the following:  The compatibility of the application with the Windows Server 2003 operating system  The version and service pack / hot fix requirements for the program, where applicable.

Page 293 of 354

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

© 2004 Mustan Bharmal

 The installation directory for the software on the domain controller, and any requirements for: • Custom system environmental variables • File type re-association (association of a file suffix with an application), and so on  The required function(s) of the program on the domain controller  The resource utilisation profile (processor, RAM, disk, and so on) of the program on the domain controller  The required mode and instructions for installation of the program onto the domain controller (for example, via a Windows Installer (*.msi) package, installation from a CD-ROM or from a network file share, and so on)  Any requirements for post-installation configuration of the program on the domain controllers When determining the design requirements for OEM drivers and utilities for incorporation into each required standard server build, consider the following:  The version and release date for the OEM driver / utility. Note that as these will change on a regular basis, it is important to stipulate, for the initial design, a cut off date for the versions and release dates for all OEM drivers and utilities. For example, only define the latest versions of OEM drivers available from a specific date.  Determine the installation directory for the OEM drivers and utilities, where applicable.  The recommended process for the installation and post installation configuration for all required OEM drivers and utilities Use the above information to execute an analysis to determine and document the design requirements for standard software on the standard server build(s). • Factor A11: Determination of the design requirements for the installation and initial configuration of Active Directory on a domain controller ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has understood and identified the requirement for the design of one or more standard server builds for Windows Server 2003 domain controllers, and  Wishes to determine the design requirements for the installation and initial configuration of Active Directory on a domain controller on a deployed standard server build for the Windows Server 2003 domain controllers within this domain. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Regardless of the mode of implementation selected, for an automated implementation solution, it is necessary to script the installation and initial configuration of Active Directory on a standard server build to generate a domain controller. It is possible to automate the installation and configuration of Active Directory on a deployed standard server build by providing an answer file to the “dcpromo.exe” application (the Active Directory Installation Wizard).

Page 294 of 354

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

© 2004 Mustan Bharmal

Note that a new feature to Windows Server 2003 Active Directory is the option to define the source of an Active Directory database for replication between domain controllers during the installation of a new domain controller for an existing domain. In Windows 2000 Active Directory, upon creation and addition of a new domain controller to an existing domain, it was necessary for that new domain controller to contact an existing domain controller for that domain to receive a copy of the Active Directory database for the forest. This replication requirement is not an issue on a highspeed local area network. However, where the domain controller is in a remote location, and the Active Directory database is very large, this requirement to replicate the entire Active Directory database across a low available bandwidth network link becomes a significant issue. For Windows 2000 Active Directory, organisations tackled these scenarios is different manners. The following are examples of such approaches:  Some organisations used a laptop as an additional domain controller for a domain and transported it to the remote location. This hence permitted the new domain controller, for that domain in that location, to receive a copy of the Active Directory database across a LAN connection and not a WAN connection.  Some organisations built the additional domain controllers at a hub site / headquarters and then shipped either the entire server or the HDDs (assuming the reference and target servers were identical in all aspects) to the remote location. However, in Windows Server 2003 Active Directory, it is possible to configure the Active Directory Installation Wizard to replicate from media and not directly from another domain controller for a domain. This is enabled via the use of the “/adv” switch for the “dcpromo.exe” executable. Note the following points when considering the use of this option:  This option to replicate from media is naturally only available where the domain controller is required to become an additional domain controller for an existing domain.  It is only possible to support the bulk of the replication requirements for an additional domain controller using this install replica from media option for the Active Directory Installation Wizard. The Active Directory Installation Wizard is still required to connect to an existing domain controller for that domain to update the Active Directory database.  It is necessary to consider the following salient points about the backup of the system state used to provide a copy of the Active Directory database for the forest:  It is necessary to generate the backup of the system state of a Windows Server 2003 domain controller using either the native backup tool on a Windows Server 2003 server, or any other Active Directory-aware backup software. The backup must be of only the system state on the domain controller.  It is necessary to restore the backup of the system state on and at the potential domain controller using either third party backup software of the native Windows Server 2003 backup program. It is not possible to provide just the previously restored files from a system state backup, as this will generate an error within the Active Directory Installation Wizard, stating that the Wizard is unable to find the files specified. See the process later for details.  The backup of the system state must be generated from a Windows Server 2003 domain controller for that domain, and that domain controller may be configured as a normal domain controller or a GC server (see process details later for the use of a backup from a GC server).

Page 295 of 354

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

© 2004 Mustan Bharmal

 It is not possible to use a backup of the system state from a Windows 2000 domain controller within that domain, where the domain is in Windows 2000 mixed, or native mode.  Where the source domain controller for the backup of the system state is host to a replica of an application directory partition (ADP), then the additional domain controller does not replicate the ADP(s) via the backup media (see process details later for the re-creation of ADPs, where required, on an additional domain controller for a domain).  The backup of the system state must be less than 60 days old to prevent the additional domain controller from re-introducing previously deleted objects that remain within an old backup. This has a serious implication on the integration of backups within implementation media such as CD-ROMs / DVD-ROMs and so on (see later for details).  It is possible to transport the system state backup to the target additional domain controller via any media, such as a CD-ROM, DVD-ROM, tape, or even (where feasible) copy it across a network from a shared resource such as a network drive.  The process to execute the Active Directory Installation Wizard and configure it to install Active Directory for an addition domain controller from media is as follows:  Execute the following tasks prior to execution of the Active Directory Installation Wizard: • At the potential domain controller, retrieve a copy of a system state backup, from an existing Windows Server 2003 domain controller for the target domain, and copy it to a local HDD • Use a third party or the built-in Windows Server 2003 backup utility to perform a restore of this system state backup to an “alternate location”. Note that it is important not to select the options “original location” or “single folder”. The target for the alternate location should be a folder on a local partition. The default location the Active Directory Installation Wizard searches for a restored system state backup is a folder with the folder path of “C:\NTDSRestore”. The use of the “alternate location” option preserves the folder structure within the system state backup, which the use of the option “single folder” does not. Note that the target partition for the restore must have sufficient free disk space to accommodate the entire restore.  Following the restore of the system state backup, execute the DCPROMO.exe program using the “/adv” switch, which enables the advanced options.  Select the option “Domain Controller for an existing domain” and click “Next”. When prompted for the source of the replication, select the radio button “From these restored backup files:” and ensure the field displays the correct file path to the restored files. Click “Next”. If the source domain controller for the system state backup was a GC server, the Active Directory Installation Wizard will prompt to make this additional domain controller a GC server as well, or a normal domain controller. Select the desired option, and click “Next”. Then complete the Active Directory Installation Wizard as normal (see below for process)  If the additional domain controller is required to host a replica of an ADP, then configure this following completion of the Active Directory Installation Wizard. See the Forest Plan process “design of application directory partitions within a forest” for details on addition of domain controller to the replication list for an ADP. Note that it is possible to automate the execution of the Active Directory Installation Wizard where it is required to install the replica of the Active Directory database from a

Page 296 of 354

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

© 2004 Mustan Bharmal

restored system state backup. See below for the appropriate entries within the [DCInstall] section of the answer file supplied to the “dcpromo.exe” executable. Prior to determination of the requirements to script the installation and initial configuration of Active Directory on Windows Server 2003 server, it is necessary to understand the installation process and options. The following flow diagram illustrates the options presented by the Active Directory Installation Wizard during installation and initial configuration of Active Directory on a Windows Server 2003 server:

Page 297 of 354

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

© 2004 Mustan Bharmal

Windows Server 2003 Active Directory Installation Wizard Process START

Domain controller for an existing domain?

Domain controller for a new domain?

Was dcpromo executed with the “/ adv” switch to replicate from media?

YES

Domain in a new forest?

Child domain in an existing domain tree?

Domain tree in an existing forest?

Provide the file path to the restored system state backup

Supply the full DNS name for the domain

Provide user name, password, and user domain of an account with sufficient privileges to install Active Directory on this computer

Provide user name, password, and user domain of an account with sufficient privileges to install Active Directory on this computer

NO NO

Was source domain controller for backup a GC server?

Supply the NETBIOS domain name for the domain

Supply the full DNS name for the parent and child domains

Supply the full DNS name for the domain

YES

Supply the NETBIOS domain name for the child domain

Supply the NETBIOS domain name for the domain

Select option to make additional domain controller also a GC server or not Provide user name, password, and user domain of an account with sufficient privileges to install Active Directory on this computer Supply the full DNS name for the domain

Indicate required file paths for database folder and log folder

Indicate required file path for SYSVOL folder

DNS diagnostic tests; install & / or configure DNS

Indicate required file paths for database folder and log folder

Permissions compatible with pre-Windows 2000 server operating systems?

Permissions compatible only with Windows 2000 or Windows Server 2003 operating systems

Indicate required file path for SYSVOL folder

Provide Directory Service Restore Mode Administrator Password

Summary Page & Start installation

END
© 2004 MUSTANS HI
R

BH

ARMAL

Figure 37.1: Windows Server 2003 Active Directory Installation Wizard Flow Diagram

Page 298 of 354

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

© 2004 Mustan Bharmal

Note that although it is very simple to script all Active Directory installation tasks via an unattended installation script file, it is not so easy to script all of the post-installation configuration tasks on the Active Directory. It is possible to script the following installation options and initial configuration tasks for Active Directory using the [DCInstall] section of an unattended installation script file (such as a “unattend.txt” or “sysprep.ini” file) for dcpromo.exe:  From the above illustration of the process and options within the Active Directory Installation Wizard, several options and requests for answers are common to multiple paths. Hence, the following “common” configuration options are available, regardless of the selected options for the domain controller:  Indicate the requirement to reboot the domain controller automatically upon successful completion of the Active Directory Installation Wizard using the “RebootOnSuccess” entry.  Indicate the required file path for the Active Directory database using the “DatabasePath” entry.  Indicate the required file path for the Active Directory log files using the “LogPath” entry.  Indicate the required file path for the SYSVOL volume using the “SYSVOLPath” entry.  Indicate the password for the “directory service restore mode administrator” account using the “SafeModeAdminPassword” entry.  For the paths to create an additional domain controller for an existing domain, or to create a new domain or tree in an existing forest, the following common configuration options are available:  Indicate the required user name for a user account with the authority to create a new domain controller (for example an account in the Domain Admins security group) using the “UserName” entry.  Indicate the password for the supplied user account credential using the “Password” entry. Note that it is possible to omit these values from the answer file, as they present a security risk following a compromise of the answer file. Omission of such values will force the Active Directory Installation Wizard to prompt for the values to proceed.  Indicate the name of the domain in which the user account credential supplied resides using the “UserDomain” entry.  For the path to create a new domain (in an new or existing forest), the following common configuration options are available:  Indicate the requirement to create a new domain using the “NewDomain” entry with a value of: • “Tree” to indicate the new domain is the root of a new tree within an existing forest • “Child” to indicate the new domain is a child of an existing domain • “Forest” to indicate the new domain is the root of a new forest of domain trees

Page 299 of 354

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

© 2004 Mustan Bharmal

 Indicate the requirement to permit or deny anonymous access (where preWindows 2000 servers authenticate end users from this domain or any trusting domain) using the “AllowAnonymousAccess” entry  The indication of the required function of the domain controller, from one of the following options:  To become another domain controller within an existing domain  To become a domain controller for a new domain, and that domain is: • A new domain in a new forest • A child domain in an existing tree for an existing forest • A new domain as a new tree within an existing forest  Where the domain controller is to join an existing domain, indicate this via the following entries in the [DCInstall] section of the answer file for dcpromo.exe:  Indicate this domain controller is to join an existing domain via the “ReplicaOrNewDomain=Replica” entry  Indicate the full DNS domain name for the existing domain via the “ReplicaDomainDNSName” entry  Where the domain controller is to join an existing domain, and the Active Directory Installation Wizard is to replicate the Active Directory from media, then indicate this via the following entries in the [DCInstall] section of the answer file for dcpromo.exe:  Indicate the requirement to replicate from media using the “ReplicationSourcePath” entry, and providing a fully qualified path to a folder on the local computer with a restored system state backup. Note the use of this option will force the Active Directory Installation Wizard to ignore any values provided for the “ReplicaDomainDNSName” entry, as the DNS domain name of the domain to which the restored system state files belong take precedence.  As a locally restored system state backup supports only the bulk of the replication, it is necessary for the Active Directory Installation Wizard to connect to an existing domain controller for the remaining replication. It is possible to control the domain controller the Active Directory Installation Wizard connects to, where the supporting network infrastructure is an issue, using the “ReplicationSourceDC” entry. Without specification of a value for this entry, the Active Directory Installation Wizard will select the closest domain controller for this domain to provide the remaining replication requirements.  Where the source domain controller for the system state back employs the “system key” security option, it is possible to configure the Active Directory Installation Wizard, when replicating from media, to use a supplied system key. Use the “Syskey” entry and either the associated value, or a null value if the restored files indicate that the end user is required to supply the value for the system key on a floppy drive. The Active Directory Installation Wizard will then search for the system key on drive “A:”.  Where the domain controller is to create a new domain in a new forest, indicate this via the following entries in the [DCInstall] section of the answer file for dcpromo.exe:  Indicate this domain controller is to create a new domain in a new forest via the entries:

Page 300 of 354

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

© 2004 Mustan Bharmal • “ReplicaOrNewDomain=Domain” (to indicate the requirement to create a new domain) • “TreeOrChild=Tree” (to indicate the requirement to create a new tree) • “CreateOrJoin=Create” (to indicate the requirement to create a new forest)  Indicate the full DNS domain name for the new domain via the “NewDomainDNSName” entry  Indicate the NETBIOS domain name for the new domain via the “DomainNetbiosName” entry  Indicate whether the Active Directory Installation Wizard is to set the DNS server addresses automatically, via the “DNSOnNetwork” entry  Indicate the requirement for the Active Directory Installation Wizard to automatically install and configure DNS via the use of the “AutoInstallAndConfigDNS” entry  Indicate the name of an existing Site where the new domain controller is to logically / physically reside via the “SiteName” entry  Where this domain controller is to create a new child domain in an existing tree for an existing forest, indicate this via the following entries in the [DCInstall] section of the answer file for dcpromo.exe:  Indicate this domain controller is to create a new child domain in an existing tree for an existing forest via the entries: • “ReplicaOrNewDomain=Domain” (to indicate the requirement to create a new domain) • “TreeOrChild=Child” (to indicate the requirement to use an existing tree within an existing forest)  Indicate the full DNS domain name for the parent domain via the “ParentDomainDNSName” entry  Indicate the full DNS domain name for the new child domain via the “ChildName” entry  Indicate the NETBIOS domain name for the new child domain via the “DomainNetbiosName” entry  Indicate the requirement for the Active Directory Installation Wizard to automatically configure DNS via the use of the “AutoConfigDNS” entry  Where this domain controller is to create a new domain as a new tree within an existing forest, indicate this via the following entries in the [DCInstall] section of the answer file for dcpromo.exe:  Indicate this domain controller is to create a new domain as a new tree within an existing forest via the entries: • “ReplicaOrNewDomain=Domain” (to indicate the requirement to create a new domain) • “TreeOrChild=Tree” (to indicate the requirement to create a new tree) • “CreateOrJoin=Join” (to indicate the requirement to join an existing forest)

Page 301 of 354

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

© 2004 Mustan Bharmal

 Indicate the full DNS domain name for the new domain via the “NewDomainDNSName” entry  Indicate the NETBIOS domain name for the new domain via the “DomainNetbiosName” entry  Indicate the requirement for the Active Directory Installation Wizard to automatically configure DNS via the use of the “AutoConfigDNS” entry It is not easily possible to script the execution, via unattended installation script, of the following Active Directory configuration tasks:  Configuration of a domain controller as a Global Catalog (GC) server (note the first domain controller for a forest is automatically a GC server)  The transferring of FSMO roles between domain controllers  The configuration of custom connection objects for domain controllers, and so on. All such tasks may hence require either customised scripts using the ADSI interface, or manual configuration following completion of the automated installation of a domain controller. Using the above information, execute an analysis to determine and document the design requirements for the configuration of Active Directory on a domain controller, for each required standard server build for Windows Server 2003 domain controllers. 8.9.5. Determination of the Required Mode(s) for Implementation of Domain Controllers Consider the following information when determining the design requirements for the mode(s) of implementation of the domain controllers within the production environment: • Factor B5: Understanding the requirement to determine the mode(s) of implementation of domain controllers ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the requirements for the determination and design of the mode(s) of implementation of domain controllers within the production environment. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Implementation of a Windows Server 2003 domain controller implies the following:  The deployment of the Windows Server 2003 operating system onto a server, and  The installation and initial configuration of Active Directory on the server to make the first or an additional domain controller for a domain It is necessary to determine and design the required mode(s) of implementation of domain controllers where it is possible to identify the following example requirements:  An organisation may wish to control and / or administer the deployment of domain controllers from a central physical location. The IT support function within the organisation must hence consider the logistics of either deploying a domain controller within a remote physical location using remote networking technologies.  This domain requires representation within multiple physical locations, connected to a main site via network links with low available bandwidth. A large Active Directory database for a domain may restrict the deployment options for this scenario. For

Page 302 of 354

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

© 2004 Mustan Bharmal

example, the deployment of a domain controller in a remote location may generate an increase in utilisation of the available bandwidth within the WAN links when the remote domain controller is required to replicate with an existing domain controller across a WAN link to retrieve a copy of the Active Directory database. Windows Server 2003 Active Directory supports install replica from media to support these scenarios (see later for details on “install replica from media”).  Remote administrators are not skilled or experienced in the installation and initial configuration of a Windows Server 2003 domain controller. There is hence a requirement to provide local administrators with an automated deployment solution that minimises their involvement and hence the risk of a badly configured domain controller.  This domain is required to support a large number of domain controllers, such as twenty or more, and hence there is a requirement to:  Minimise the time and resource involvement associated with the deployment and initial configuration of the domain controllers  Ensure the consistent deployment and initial configuration of all domain controllers within this domain • Factor B6: Understanding the potential modes of implementation of the Windows Server 2003 operating system ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the different potential modes for implementation of a standard build of a Windows Server 2003 operating system. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Most organisations designing and deploying a Windows Server 2003 Active Directory infrastructure will design one or more standard server builds. A standard server build will define a standard configuration for hardware components, operating system, utilities, applications, Windows components, and so on. As stated earlier, it is possible to translate a design for a standard server build into one of the following:  An entire image or snapshot of a Windows Server 2003 server  A scripted installation of a Windows Server 2003 server and domain controller  A set of prescriptive instructions for the manual installation and configuration of a standard server build for a domain controller When deciding between the use of one or more of these techniques, it is important to consider the following factors influential in the selection of the required mode(s) for implementation:  The requirements for the portability of the mode of implementation across multiple server platforms with differing hardware abstraction layer requirements  The requirements / limitations on time and cost of development and maintenance of the mode of implementation  The presence of trained and trusted administrators within remote locations where domain controllers for this domain require deployment

Page 303 of 354

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

© 2004 Mustan Bharmal

 The numbers of domain controllers for this domain that require deployment within the production environment(s) for an organisation. Some modes of implementation have prerequisites and other constraints that hence limit their application within an organisation. The following sections discuss these factors for each of the three potential modes of implementation of domain controllers within a production environment. Note that it is possible to use a combination of modes for implementation of the domain controllers within this domain. The implementation of the domain controllers involves the execution of the following four major steps:  The configuration of the server hardware  The installation and configuration of the Windows Server 2003 operating system  The installation and configuration of the programs, utilities, drivers, and so on for the Windows Server 2003 operating system and server hardware platform  The installation and initial configuration of Active Directory on the deployed server For example, it is possible to use the following combinations of the potential modes of implementation:  Manual configuration of the server hardware  Deployment of a image for a base operating system and applications, drivers, and so on  Manual installation and initial configuration of Active Directory on the deployed server • Factor A12: Determination of the requirement to use imaging techniques to implement standard builds for domain controllers ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the requirements for the use of imaging techniques to implement standard builds for domain controllers within their production environment. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Prior to the determination of the requirement for the use of imaging techniques, it is necessary to understand the process to generate an image of a standard build for a Windows Server 2003 server. The following represent the high-level steps involved in the process to generate an image for a computer:  Build a reference computer using server hardware and components identical to the target servers for the image.  Use the design for the standard server build for the domain controller to configure the operating system and all appropriate programs, drivers, and so on, on the reference server.  Generate an unattended script for the image (as a “sysprep.ini” file) (optional step)

Page 304 of 354

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

© 2004 Mustan Bharmal

 Prepare the server for imaging via execution of the Windows Server 2003 support tool “sysprep.exe”, which strips all security identifiers from the reference machine, and then power down the computer.  Power up the computer and generate an image of the computer, using a third-party imaging solution, before the mini-setup initiates. Note that an organisation may wish to consider the use of the built-in Windows Server 2003 “Remote Installation Services” (RIS), if not for actual image deployment, then for assisting the initiation of image deployment as a PXE-Server. When determining the requirement for the use of imaging techniques as the required mode of implementation of standard server builds, consider the following:  The following advantages are associated with the use of imaging techniques to implement standard server builds for domain controllers:  The process to deploy a standard server build using an image is very fast in comparison to all other techniques, taking a matter of a few minutes, rather than over an hour.  It is possible to automate the entire deployment process. This is hence ideal for scenarios where domain controllers require deployment in remote locations that employ untrained and / or un-trusted local administrators.  The use of imaging techniques may provide a fast, although last choice, emergency recovery process for a failed domain controller.  The use of this technique is associated with quicker development and testing phases than the other techniques.  Many inexpensive third-party products are available to generate a disk image of a computer.  The process to update the images is quick and simple, but depends on availability of a spare target computer compatible with an image.  The following disadvantages are associated with the use of imaging techniques to implement standard server builds for domain controllers:  Based upon the above typically high-level approach to the use of imaging techniques to deploy a large number of standard server builds, the following prerequisites exist for this technique: • Immediately following the deployment of an image of a Windows server build to a target server and rebooting the server, the server executes a “minisetup”, which emulates the “GUI-based” setup mode of a manual installation of a Windows server. This mini-setup for an image does not execute the “textmode” phase of installation of the operating system, and hence does not generate a custom the hardware abstraction layer (HAL) for the operating system. Thus, the image strictly reflects the hardware (and hence HAL) of the reference server. This restricts the deployment of an image only to servers with an identical hardware configuration as the reference machine. Where an organisation has several disparate server models and versions, then it may be necessary to generate an image for each model / version. This may prove too costly to generate and manage. • The use of the “Sysprep.exe” tool, to strip the reference computer of all security identifiers, hence requires that the reference computer be a standalone computer, and not a member computer or domain controller. Hence, it is not possible to image a domain controller and deploy this image.

Page 305 of 354

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

© 2004 Mustan Bharmal

Thus, using this technique still requires either manual intervention, or the use of a script to perform the installation and initial configuration of the Active Directory on the deployed server. Note that the use of a “sysprep.ini” file, to automate the mini-setup phase of an image deployment, supports the execution of post-installation scripts via the inclusion, within the [GuiRunOnce] section of the answer file the line "dcpromo /answer:answerfile" where answerfile specifies the name of the answer file that contains the domain controller values. It is also necessary to specify the values used by Dcpromo.exe in the [DCInstall] section of the “sysprep.ini” (or “unattend.txt”) answer file during unattended Setup or in a separate answer file that contains only the [DCInstall] section.  The use of imaging techniques will not automate the configuration of the server hardware prior to the deployment of the image. This may hence require manual intervention, supported by detailed instructions, depending on the manufacturer of the server hardware platform.  There is a requirement to provide storage media for the images, which may be several gigabytes in size. To support the use of this mode for implementation, it is necessary to determine the following design requirements:  Determine the number of server hardware platforms for the target domain controllers that will require receipt of an image for a standard server build. It is necessary to identify all hardware differences that will influence the generation of the HAL for the server, such as differences in the number and specifications of processors within the target servers, which will warrant discrete images.  As it is not possible to implement a configured domain controller using this technique, there may be the opportunity to consolidate multiple standard builds. To identify the opportunities for build consolidation, identify all standard builds that have common configuration requirements other than for Active Directory installation. As the Active Directory installation and initial configuration may be scripted, it is possible to generate “virtual” builds from one base build using different answer files as appropriate.  Determine the required mode for configuration of the server hardware, depending upon the manufacture-provided utilities for execution of these tasks. Where there are no utilities or support for automation of these tasks, it is necessary to determine the design requirements for a process to support the manual execution of the server hardware configuration.  Determine the requirement to either assign an answer file to automate the installation and initial configuration of the Active Directory on a new domain controller, or to provide explicit written instructions for the manual execution of the Active Directory Installation Wizard.  Determine the requirement to support the deployment of an additional domain controller for this domain using the new Windows Server 2003 Active Directory feature “replicate from media”. Where it is possible to identify this requirement, then it is necessary to provide a recent copy of a system state backup from a suitable existing domain controller within this domain. See above for details of the requirements to support the execution of this option by the Active Directory Installation Wizard.  Determine the required mode(s) for distribution of the images, and hence the appropriate media or server and file paths for the generated images. For example, determine the requirement to distribute the images on CD/DVD-ROMs or across the network, and so on.

Page 306 of 354

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

© 2004 Mustan Bharmal

 Determine the naming convention requirements for the images that require generation, to support differentiation between images. Using the above information, execute the following:  Determine and document the requirement for the use of imaging techniques as the required mode for implementation of the standard server builds for domain controllers.  Where it is possible to identify this requirement, then determine and document the design requirements for this technique. • Factor A13: Determination of the requirement to use fully automated scripted installation techniques to implement standard builds for domain controllers ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the requirements for the use of fully automated scripted installation techniques to implement standard builds for domain controllers within their production environment. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: With the use of an unattended script file, and any additional independent scripts and batch files, it is possible to automate the configuration of the following components of a standard server build for domain controllers:  Proprietary server hardware (via specific support utilities provided by the server OEM)  The installation and configuration of the Windows Server 2003 operating system  The installation and configuration of software, utilities, drivers, and so on  The installation and initial configuration of Active Directory When determining the requirements for the design and use of a fully automated scripted installation and configuration technique for the standard server builds for domain controllers, consider the following:  The following advantages are associated with this technique:  The use of an entirely scripted installation for the Windows Server 2003 operating system and Active Directory permits the generation of a hardware portable server build. Because the scripted installation will detect the hardware and install the appropriate HAL, it is possible to apply a single build to a variety of server platforms. Hence, there are fewer server builds required.  It is possible to generate several variations on a single server build to accommodate differences in standard build configurations via provision of multiple versions of script and batch files.  The use of this technique to implement domain controllers within a production environment is suitable for scenarios where untrained and / or un-trusted local administrators may be required to execute the implementation. Because it is possible to automate this process fully, this reduces the requirements for manual intervention by local administrators.  The use of this technique is simple to update to support future requirements, as it requires only modification of the script / batch files.

Page 307 of 354

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

© 2004 Mustan Bharmal

 The only disadvantage associated with this technique is that the development and testing phases for this technique, depending upon its scope, may be quite lengthy and demanding. However, where there is a small scope and fewer builds to generate, it may be quicker that other techniques. To support the use of this mode for implementation, it is necessary to determine the following design requirements:  Determine the scope for the fully automated scripted installation and configuration of the standard server build for domain controllers. The scope is determined by the inclusion or exclusion of the following components of a standard server build:  The configuration of the server hardware and components  The installation and configuration of the Windows Server 2003 operating system  The installation and configuration of the software, drivers, and so on for the server hardware and operating system  The installation and initial configuration of the Active Directory  Following the determination of the scope, determine the script requirements to support each required component. For example:  To automate the configuration of the server hardware and components, it may be necessary to employ the server OEM tools and utilities, such as “SmartStart” for HP ProLiant servers, or the “IBM System Installation Toolkit” for IBM x-series servers, and so on.  To automate the installation and configuration of the Windows Server 2003 operating system, determine the configuration requirements for the “unattend.txt” file.  To automate the installation and configuration of the software, drivers, and so on, consider the use of independent batch files initiated within the [GuiRunOnce] section of the “unattend.txt” answer file.  To automate the installation and initial configuration of the Active Directory, consult the standard server build requirements for the [DCInstall] section of an answer file for “dcpromo.exe”, initiated within the [GuiRunOnce] section of the “unattend.txt” answer file.  Determine the media / format for initiation and delivery of a fully automated standard server build. For example, consider the use of a bootable CD/DVD-ROM that contains all of the source files for the operating system, applications, drivers, and so on, and the batch files to automate the process.  Where there is a requirement to support the “replicate from media” option for an additional domain controller within an existing domain, it is necessary to support a recent (less than 60 days old) copy of the system state backup of an appropriate domain controller within the target domain. See above for details of the requirements to support this option by the Active Directory Installation Wizard. Using the above information, execute the following:  Determine and document the requirement for the design and use of a fully automated scripted installation and configuration technique to implement the required standard server builds.  Where it is possible to identify this requirement, then determine and document the design requirements to generate the fully automated build.

Page 308 of 354

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

© 2004 Mustan Bharmal • Factor A14: Determination of the requirement for the manual implementation of each required standard server build for Windows Server 2003 domain controllers. ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the requirement for the manual implementation of each required standard server build for Windows Server 2003 domain controllers for this domain. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: It is possible to execute all installation and configuration requirements for the standard server builds for Windows Server 2003 domain controllers manually. However, this design methodology does not recommend this approach unless it is possible to identify compliance within either or both of the following criteria:  The number of domain controllers for this domain that require implementation within the production environment is very small (for example, less than five domain controllers).  The implementation of the required domain controllers within the production environment will be the responsibility of resource(s) well trained and experienced in the installation and configuration of Windows Server 2003 domain controllers. When determining the requirements for the design and use of this mode for implementation of the standard server builds for the Windows Server 2003 domain controllers, consider the following:  The following advantages are associated with this mode of implementation of the standard server builds for the domain controllers:  The development phase is very short in comparison to the other techniques for implementation of domain controllers, and hence less costly.  It is very easy to customise this technique to support new installation and configuration requirements for the domain controllers.  The following disadvantages are associated with this mode of implementation of the standard server builds for the domain controllers:  Although the prescriptive “cookbooks” help to reduce the potential and number of instances of installation and configuration errors, it does not eliminate them. Lack of compliance with the prescriptive instructions by an undisciplined remote administrator can result in a faulty installed and configured domain controller. The presence of a faulty domain controller operating on the production environment may generate a negative influence on business continuity.  The manual installation and configuration process is labour and time intensive, thus securing valuable resources for longer periods. Hence, although it may be possible to realise cost savings associated with the development of this process, it is possible to identify increases in the overall costs associated with the implementation phase. To support the use of this mode for implementation, it is necessary to determine the following design requirements for prescriptive “cookbooks”, which detail the following:  The instructions for the configuration of each component of a standard server build (hardware, operating system, applications, and Active Directory)  Checklist for all pre-installation, installation, and post-installation tasks

Page 309 of 354

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

© 2004 Mustan Bharmal

 Checklists for all pre-configuration, configuration, and post-configuration tasks Using the above information, execute the following:  Determine and document the requirement for the design and use of prescriptive instructions for the manual installation and configuration of the required standard server builds.  Where it is possible to identify this requirement, then determine and document the design requirements for the prescriptive cookbooks. 8.9.6. Design for Domain Controllers Consider the following information when generating the design for the domain controllers for this domain. Presented within the following three sections are the considerations for the execution of this step within this process: 1. 2. 3. 8.9.6.1. Considerations for the generation of the design for the domain-level FSMO roles Considerations for the generation of the design for the standard server builds Considerations for the generation of the design for the required mode(s) of implementation of the domain controllers for this domain Generation of the Design for Domain-Level FSMO Roles Consider the following information when generating the design for the domain-level FSMO roles: • Factor D1: Generation of the design for domain-level FSMO roles ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified all relevant design requirements for the domain-level FSMO roles within this domain, and  Wishes to understand and generate the design for domain-level FSMO roles ♦ 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 domain-level FSMO roles is comprised of the following components:  A detailed design document identifying the permanent and temporary domain controller host for each domain-level FSMO role, and the other functions / operations the selected permanent and temporary host domain controllers may execute.  A diagram that illustrates the logical and physical placement of the permanent host domain controllers for each role within the supporting network infrastructure of the production environment for the domain  A diagram, illustrating the failover path for all of the domain-level FSMO roles, between the permanent and temporary host domain controllers Use the above to generate a design for the domain-level FSMO roles within this domain.

Page 310 of 354

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

© 2004 Mustan Bharmal

8.9.6.2.

Generation of the Design for Standard Server Builds Consider the following information when generating the design for the standard server build(s): • Factor D2: Generation of the design for standard server builds ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the design requirements for the standard server builds for the Windows Server 2003 domain controllers for this domain, and  Wishes to understand and generate the design for the standard server builds ♦ 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 standard server builds is comprised of the following components:  The design for the configuration of the server hardware components  The design for the installation and configuration of the Windows Server 2003 operating system  The design for the installation and configuration of any programs, utilities, drivers, and so on for the operating system server and server hardware platform  The design for the installation and configuration of Active Directory on a deployed Windows Server 2003 server Use the above to generate a design for the standard server builds for Windows Server 2003 domain controllers within this domain.

8.9.6.3.

Generation of the Design for the Required Mode(s) of Implementation of Domain Controllers Consider the following information when generating the design for the required mode(s) of implementation of the domain controllers: • Factor D3: Generation of the design for the require mode(s) of implementation of domain controllers ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the required mode(s) of implementation for each required standard server build  Has identified the design requirements for each required mode of implementation, and  Wishes to understand and generate the design for the required mode(s) of implementation ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: The components of the design for the required mode of implementation depend upon the mode(s) selected.

Page 311 of 354

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

© 2004 Mustan Bharmal

Where there is a requirement to use imaging techniques for the implementation of standard server builds for domain controllers, then this design methodology requires that the design comprise the following components for this mode of implementation:  The design of the process to build each required reference computer, identifying the detailed steps to:  Configure the server hardware (for example, to establish RAID arrays and so on)  Install and configure the Windows Server 2003 operating system  Install and configure any programs, utilities, drivers and so on for the Windows Server 2003 operating system and server hardware platform  The design of the “sysprep.ini” unattended installation script file  The design of the process to generate an image of a reference computer  The design of the process to deploy a generated image to a target computer  The design of the process for the manual installation and configuration of the Active Directory where this is not automated  The deign of checklists for the pre-image deployment, deployment, and post-image deployment tasks Where there is a requirement to use a fully automated scripted installation for the implementation of standard server builds for domain controllers, then this design methodology requires that the design comprise the following components for this mode of implementation:  A statement defining the scope of the automated installation mode  The design of the appropriate scripts and batch files for each in-scope component for the automated installation mode  The design of the media, where appropriate, to support the deployment of the automated installation mode  The design of checklists for pre-installation, installation & configuration, and postinstallation and configuration tasks Where there is a requirement to implement each required standard server build for domain controllers manually, then this design methodology requires that the design comprise the following components for this mode of implementation:  The design of the process to manually configure the server hardware in preparation for installation of the Windows Server 2003 operating system  The design of the process to manually install and configure the Windows Server 2003 operating system  The design of the process to manually install and configure programs, utilities, drivers, and so on for the Windows Server 2003 operating system and server hardware platform  The design of the process to manually install and initially configure the Active Directory on a deployed server Use the above to generate a design for the required mode(s) for implementation of the standard server builds for Windows Server 2003 domain controllers within this domain.

Page 312 of 354

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

© 2004 Mustan Bharmal

9.

Design of External Trust Relationships
This process requires execution by the owner(s) of this domain where it is possible to identify one or more of the following requirements: • The requirement to permit access to resources within this domain to security principals from within another domain outside of this forest, and / or • The requirement to support access to resources controlled by another domain outside of this forest by security principals within this domain • The requirement to qualify the retention and upgrade of one or more existing external trusts from legacy domain infrastructures due for migration to this domain

9.1.

Process Objective The objectives of this process are to assist the owner(s) of this domain in the execution of the following: • The design and implementation of one or more external trust relationships between this domain and one or more other Windows-based domains outside of the boundary of the forest that supports this domain, or with non-Windows Kerberos V5 realms, via a Kerberos V5 realm trust. • The qualification of the requirements to retain and upgrade one or more existing external trust relationships currently associated, or proposed for association, with this domain. Note that the prerequisite to the execution of this process is the identification of the requirement to share or access resources between this domain and an external domain. Where it is not possible to identify such requirements, then there is no requirement for the design and implementation of external trust relationships. The design of external trust relationships must address several variables. The background information section below discusses the variables that this process addresses.

9.2.

Process Scope This design methodology identifies the following in and out of scope components for this process to design one or more external trust relationships.

9.2.1.

In-Scope Components This design methodology considers the following trust relationship requirements as inside of the scope of this process: • The requirements to design external trust-relationships between this Windows Server 2003 Active Directory domain and: ♦ Another Windows (Windows 2000 or Windows Server 2003) domain in another forest ♦ A legacy Windows NT 4.0 domain ♦ A non-Windows Kerberos V5 realm • Most requirements for external trust relationships reflect long-term requirements to share and support inter-domain access to domain-controlled resources and services. However, it may be possible to identify temporary requirements for trust-relationships during, for example, migration from legacy Windows-based domain infrastructures. This process supports the design and deployment of external trust relationships for both long- and shortterm requirements.

Page 313 of 354

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

© 2004 Mustan Bharmal • Where there is a requirement to migrate one or more legacy Windows NT 4.0 or Windows 2000 domain infrastructures to this Windows Server 2003 Active Directory domain, then this design methodology considers all existing external trust relationships for these source domains as within the scope of this process. This process will hence evaluate all existing external trusts on the legacy domain infrastructures for migration, upgrade, and transfer to this domain. See the Migration Plan process “analysis of legacy domain infrastructures” for details of any existing trust relationships on in-scope legacy domain infrastructures that may require migration to this domain. 9.2.2. Out of Scope Components This design methodology considers the following trust relationship requirements as outside of the scope of this process: • All requirements to design forest trusts, between the forest root domains of Windows Server 2003 forests, are outside of the scope of this process. See the Organisation-Wide Active Directory Plan process “design of federated forest infrastructures” for details of forest trust requirements. • All requirements to design short-cut trust-relationships, between domains within a forest, are outside of the scope of this process. See the Forest Plan process “design of short-cut trust-relationships” for details of intra-forest short-cut trust requirements. • All “external” domains that reside within the scope of one or more intranet or extranet federated forest infrastructures, to which this domain is also a member, are outside of the scope of this process. Consult the results of the Organisation-Wide Active Directory process “design of federated forest infrastructures” to identify all intranet and extranet federated forest infrastructure requirements, and hence identify the out-of-scope external Windows-based domains. 9.3. Background Information Prior to the execution of this process to design external trust relationships between this domain and other Windows-based domains and non-Windows Kerberos V5 realms, it is necessary to understand the following concepts: • The function of external trust relationships • The features of external trust relationships • Trust terminology employed in this design process • The variables the design for external trust relationships is required to address 9.3.1. Function of External Trust Relationships External trust relationships support inter-domain access by security principals to accesscontrolled domain resources and services, via the use of security credentials native to the trusting domain of the security principals. Without trust relationships between domains, it is not possible to authenticate to that domain using native domain credentials, referred to as “pass-through authentication”. In this scenario, it would be necessary for a user in domain “A”, who requires access to resources in domain “B” (with which there is no trust relationship) to authenticate to domain “B” using credentials native to domain “B” and not “A”. Trust relationships hence provide the following: • The foundation for a “single-sign on” or “pass-through authentication” infrastructure to support inter-domain resource and service access, and hence reduce the number of user account credentials users are required to present and remember. Note that Active

Page 314 of 354

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

© 2004 Mustan Bharmal

Directory creates a “foreign security principal object” for all foreign security principals authenticating to this Windows Server 2003 Active Directory domain across an external trust relationship. It is possible for these foreign security principal objects, created in the “ForeignSecurityPrincipals” container in the root of the domain, to become members of Domain Local security groups in this domain. • They help to reduce administrative overheads in maintaining security credentials for nonnative users. 9.3.2. Features of External Trust Relationships As mentioned above, the objective of this process is to support the design of external trustrelationships to both Windows-based domains and non-Windows Kerberos V5 realms. Prior to the determination of the requirements for external trust-relationships, and their design, it is important to understand their features. A Windows Server 2003 Active Directory domain can generate a one-way or a two-way (is actually two one-way trusts in opposite directions) trustrelationship and, depending on the target external domain, the one or two-way trust relationship may be transitive or non-transitive. The following table illustrates the types of trust-relationships possible between a Windows Server 2003 Active Directory domain and other Windows-based domains and non-Windows Kerberos V5 realms:
Target for External Trust Windows NT 4.0 domain Windows 2000 Active Directory domain Windows Server 2003 Active Directory domain Non-Windows Kerberos V5 realm One-Way Trust Two-Way Trust Non-Transitive Trust Transitive Trust

   

   

   

  1 2

Table 38.1: Types and Features of Windows Server 2003 Active Directory Trust Relationships Notes:
1

Only a trust relationship between the forest root domains of two Windows Server 2003 forests (raised to the “Windows Server 2003” forest functional level) generated as a forest trust is transitive.
2

An external trust relationship with a non-Windows Kerberos V5 realm can be transitive in nature. All external trust-relationships between Windows-based domains are strictly nontransitive. 9.3.3. Trust Terminology Employed in this Design Process Prior to the generation of the design for external trust relationships for this domain, it is important to understand the following terms employed within this design process: • The term “external domain” refers to any Windows-based (Windows NT 4.0, Windows 2000, or Windows Server 2003) domain that resides outside of the boundaries of the forest that supports this domain, and any non-Windows Kerberos V5 realms. Note that an “external” domain may reside either inside or outside of the logical boundaries of the organisation.

Page 315 of 354

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

© 2004 Mustan Bharmal • The term “trusting” domain refers to the source for the local resources that users from an external domain require access across a trust relationship. • The term “trusted” domain refers to the source for the user accounts that travel across the trust to access resources within a trusting domain. • The term “connected domain / Kerberos V5 realm” refers to the domain or realm at the other end of an external trust relationship with this domain. • The term “outgoing trust” refers to a one-way trust from the perspective of a trusting domain towards a trusted domain (in diagrams, the trust “arrow” always points in the direction of the trusted domain). • The term “incoming trust” refers to a one-way trust from the perspective of a trusted domain from a trusting domain. 9.3.4. Variables in the Design of External Trust Relationships This process, to design external trust relationships, is required to identify and address the following six variables associated with external trusts: 1. The function of the external trust relationship(s), and whether there is a long or short-term requirement for each required trust relationship, or a requirement to upgrade and transfer an existing legacy external trust to this domain. The trusting and trusted Windows-based domains / non-Windows Kerberos V5 realm for an external trust relationship Where the trusted domain is a Windows-based domain, then the version of Windows (Windows NT 4.0, Windows 2000 Active Directory, or Windows Server 2003 Active Directory) The direction(s) of the external trust relationship (one-way or two-way) The nature of the trust relationship (transitive or non-transitive), where applicable The security requirements for external trust relationships

2. 3.

4. 5. 6. 9.4.

Process Approach When executing the process to design external trust relationships for this domain, the recommended approach is to “keep it simple”, with respect to the number of external trust relationships required and their configuration requirements. As it is very easy to generate external trust relationships to support short-term inter-domain resource access requirements, the security implications of such trust relationships are rarely considered. It is hence important to consider carefully each requirement for an external trust relationship, prior to its design and implementation. This design methodology proposes the following approach towards the design and implementation of one or more external trust relationships for this domain: 1. Identify the following requirements for external trust relationships: a. The requirement to permit access to resources within this domain to security principals from within another Windows domain outside of this forest or an external non-Windows Kerberos V5 realm b. The requirement to support access to resources controlled by another Windows domain outside of this forest / non-Windows Kerberos V5 realm by security principals within this domain

Page 316 of 354

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

© 2004 Mustan Bharmal

c.

The requirement to evaluate, upgrade, and transfer (to this domain) one or more existing trust relationships between legacy domain infrastructures (destined for migration to this domain) and other external domains

d. The types and directions for external trust relationships required to support identified inter-domain resource access requirements 2. 3. 4. 9.5. Qualify the identified requirements for one or more external trust relationships with one or more external Windows-based domains and / or non-Windows Kerberos V5 realms Determine the requirements to secure each required external trust relationship Generate the design for each required external trust relationship

Process Components Based upon the above approach, the process to design external trust relationships for this domain is composed of the following components: • Determination of the requirements for external trust relationships • Qualification of the identified requirements for external trust relationships • Determination of the security requirements for the external trust relationships • Generation of the design for external trust relationships for this domain

9.6.

Deliverables of Process Components The process to design external trust relationships will have the following deliverables: • The determination of the requirements for one or more external trust relationships • The qualification of the identified requirements for external trust relationships via: ♦ The determination of the criteria for the design and implementation of one or more new external trust relationships ♦ The determination of the criteria to qualify the retention, upgrade, and transfer of one or more existing external trusts, currently residing within legacy domain infrastructures, to this domain ♦ The determination of the actual number of external trust relationships required following the evaluation of the identified trust requirements against the defined criteria • The determination of the security implications for the organisation from the use of external trust relationships, and the design requirements to secure external trusts • The design of one or more external trust relationships

9.7.

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

Domain Plan – Inter-Component Dependencies for Process to Design External Trust Relationships START
Determination of the requirements for external trust relationships Qualification of external trust relationship requirements Determination of the requirements to secure the required external trust relationships Design of each required external trust relationships
© 2004 MUSTANSHI
R

BHAR

MAL

Page 317 of 354

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

© 2004 Mustan Bharmal 9.8.

Process to Design External Trust Relationships
Domain Plan – Process to Design External Trust Relationships
Execute B1 Execute A1 Execute B2 Execute A2 – A4 Execute B3 Execute A5 Execute D1

START

END
© 2 0 0 4 MU S T AN S H I R BH A R MAL

9.9.

Process Considerations Consider the following information when executing this process to design external trust relationships for this domain. Presented within the following four sections are the considerations for this process:

1. 2. 3. 4.

Considerations for the determination of the requirements for external trust relationships Considerations for the qualification of the identified external trust relationship requirements Considerations for the determination of the security requirements for external trust relationships Considerations for the generation of the design for external trust relationships Determination of the Requirements for External Trust Relationships Consider the following when determining the requirements for the design and implementation of external trust relationships: • Factor B1: Understanding inter-domain requirements that support external trust relationships ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the inter-domain requirements that do and do not support external trust relationships. ♦ 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 requirements for the design and implementation of external trust relationships for this domain, consider the following: Windows-based domains and Kerberos V5 realms represent security boundaries. One of the primary functions of these security boundaries is to control access to resources that reside within the realm of control of the domain. For a user, system, or application to gain access to resources within a domain, from either inside or outside of that domain, it must successful complete the following two steps, in the following order:  Authenticate to the domain as a principal known to the domain.  Provide credentials that match one or more access control entries on an access control list for the target resource, and that grant the appropriate level of access to the resource. This design methodology categorises requirements that support the design and implementation of external trust relationships into one of the following two categories:  The requirement to support outbound access to resources within an external domain by security principals, processes, and applications within this domain  The requirements to support inbound access to resources within this domain by security principals, processes, and applications within another external domain

9.9.1.

Page 318 of 354

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

© 2004 Mustan Bharmal

Typical examples of the resources to which security principals from external domains may require access include:  Computers  Print queues  Files  Applications and services, and so on • Factor A1: Determination of external trust relationship requirements to support inbound and outbound access ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to determine the requirements to support inter-domain authentication and authorisation via external trust relationships. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: Note that the identification of the requirements to support the design and implementation of external trust relationships must only identify, at this step within this process, the following:  “Proposed” new external trusts and  Existing external trusts on legacy domain infrastructures destined for migration to this domain, which may inherit the trusts (depending upon the required migration path). The next step within this process, to define criteria for the design and implementation of external trusts, will then determine the feasibility and viability of the proposed external trusts identified within this step. This design methodology proposes that it is only possible to design and implement the proposed external trusts that comply with the defined criteria for their feasibility and viability. This design methodology proposes the following approach towards the determination of the requirements to design and implement new external trust relationships:  Identify all the potential external Windows-based domains and non-Windows Kerberos V5 realms that reside on the internal network infrastructure for an organisation, and / or within the logical boundaries of the organisation / parent organisation.  Identify all requirements for local security principals to access resources in external domains via, for example, one or more of the following techniques:  Interviews with the heads of all departments / divisional structures within the organisation represented within this domain to identify the inter-domain resource access requirements by members of their department / divisional structure  Analyse the requirements that supported legacy trust relationships, and will support future requirements. For example, it may be possible to identify the requirement during a migration from a legacy Windows NT 4.0 domain infrastructure to regenerate external trust relationships between the new (Windows Server 2003 Active Directory) and the legacy domains.

Page 319 of 354

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

© 2004 Mustan Bharmal

 Identify all requirements to support access to local resources by security principals within external domains logically located upon the internal network infrastructure for the organisation.  Identify all requirements to support the inbound access to local resources by security principals within external domains that reside on an external network infrastructure to the organisation.  Identify all requirements to support the outbound access to remote resources controlled by external domains that reside on an external network infrastructure to the organisation.  Where an “external” domain includes a non-Windows Kerberos V5 realm, identify the requirements for the creation of a transitive external trust relationship between this domain and the non-Windows Kerberos V5 realm. There are significant securityrelated issues associated with the design and implementation of transitive external trust relationships, and hence require careful consideration.  This design methodology hence proposes the following approach to determine the requirements for the design and implementation of a transitive external trust relationship:  Identify all other Windows-based and non-Windows Kerberos V5 realms with which the target non-Windows Kerberos V5 realm has a transitive and nontransitive trust relationship.  The following example diagram illustrates the considerations discussed below:
“This domain” (Windows Server 2003 Active Directory) Non-transitive trust relationship Windows Server 2003 Active Directory domain in separate forest to “d3.net” Non-Windows Kerberos V5 Realm

Transitive trust relationship Data D5.net

Non-Windows Kerberos V5 Realm

Shared Folders D1.net Print Queues D3.net Print Queues D2.net New proposed external trust relationship D4.net Non-transitive trust relationship

Windows Server 2003 Active Directory domain in separate forest to “d3.net”

Transitive trust relationship

Print Queues D6.net
© 2004 MUSTANSHI
R

Non-Windows Kerberos V5 Realm
MAL

Non-transitive trust relationship

BHAR

Figure 38.1: Examples of Types of External Trust Relationships  In the above illustration, the domain “D3.net” represents “this domain”, in which there is a requirement to establish an external trust relationship with a nonWindows Kerberos V5 realm, denoted above as “D4.net”. It is possible to note the following facts about the above illustration: • “D3.net” has two two-way non-transitive external trust relationships with the external Windows Server 2003 Active Directory domains “D1.net” and “D2.net”. • “D4.net” has a two-way transitive external trust relationship with another Kerberos V5 realm (“D5.net”), and a one-way non-transitive external trust relationship with another Kerberos V5 realm (“D6.net”), where “D6.net” trusts “D4.net”.

Page 320 of 354

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

© 2004 Mustan Bharmal

 Using the above example, if the new proposed external trust relationship between “this domain” and “D4.net” was configured as a transitive trust relationship, then this trust relationship would permit security principals from the following Kerberos V5 realms access to this domain (where appropriate permissions for these external security principals exist in this domain): • Security principals from “D4.net” • Security principals from “D5.net” via the transitive trust relationship between “D5.net” and “D4.net” • Security principals from “D6.net” via two transitive trust relationships (between “D6.net” and “D5.net”, and between “D5.net” and “D4.net”)  Using the above example, if there was a requirement to restrict access to this domain only to security principals within “D4.net”, then the new proposed external trust relationship requires configuration as a non-transitive trust relationship. Note that as these external domains may reside within the control of external organisations, then the owner(s) of this domain may have little, if any, control over the other trust relationships implemented within these external domains.  Following the identification of all other trust relationships between the target external domain and other Windows-based domains and non-Windows Kerberos V5 realms, use the above information to determine the requirement to configure the proposed trust as a transitive or non-transitive trust relationship. This design methodology proposes the following approach towards the determination of the requirements to retain, upgrade, and transfer of existing external trust relationships (on legacy domain infrastructures destined for migration to this domain):  Use the results of the Migration Plan process “analysis of legacy domain infrastructures” to identify:  All in-scope legacy domain infrastructures destined for migration to this domain, and  The presence and details of any external trust relationships currently supported by the legacy domain infrastructure(s)  Generate a list of the legacy domain infrastructures, their external trusts, and the target Windows-based domains and / or non-Windows Kerberos V5 realms Using the above approach, execute an analysis to determine and document the following resource access requirements:  All potential outbound resource access requirements, listing the external domains and their resources, to which local security principals within this domain require access  All potential inbound resource access requirements, listing the security principals within external domains that require access to local resources within this domain  The requirement to configure potential trusts between this domain and one or more non-Windows Kerberos V5 realms as transitive or non-transitive trust relationships.  The identification of all existing legacy external trust relationships destined for migration (via their supported legacy domain infrastructures) to this domain.

Page 321 of 354

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

© 2004 Mustan Bharmal

This information will hence identify the direction(s) for each proposed external trust relationship, and the nature (transitive or non-transitive) for proposed external trusts with non-Windows Kerberos V5 realms. 9.9.2. Qualification of External Trust Relationship Requirements Consider the following when determining the criteria to qualify the design and implementation of the required external trust relationships, and evaluating identified requirements for external trusts against the defined criteria: • Factor B2: Understanding the requirements to define criteria for the design and implementation of external trust relationships ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to understand the requirements to define criteria for the generation of trust relationships between this domain and one or more external domains. ♦ 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 generate a new trust relationship within an external domain / nonWindows Kerberos V5 realm, requiring only the co-operation of the domain owner(s) within each domain. However, as it is possible to associate administrative and security overheads with each required external trust relationship, it is necessary to provide justification for their generation and to prove their long-term viability. All design decisions that generate finite overheads, which in turn influence financial budgets, project timelines, and so on, require justification. The definition of criteria and evaluation of identified trust requirements against the defined criteria provide the required justification and viability assessment for each required external trust relationship. Note that the onus is with the owner(s) of the domain and / or the organisation to take the initiative to define the specific criteria and evaluate identified trust requirements against their defined criteria. This design methodology proposes that the definition of criteria for the design and implementation of new external trust relationships must achieve the following two goals:  Prove feasible to design and implement via evaluation against defined feasibility criteria. If a proposed trust is feasible, it may be designed and implemented, and vice versa.  Following compliance with feasibility criteria, the proposed new external trusts must prove viable to use and manage within the production environment, via evaluation against the defined viability criteria. If a proposed trust may prove to be unviable following implementation within the production environment, further consideration is required as to its design and implementation. An unviable trust relationship cannot justify its existence and hence any associated administrative and financial overheads. The criteria to evaluate the feasibility of each proposed external trust relationship will identify whether the prerequisites for the generation of the trusts are met, and hence whether the trusts are feasible propositions. Note that it is possible to action the lack of compliance with these criteria and hence ensure the feasibility of a trust.

Page 322 of 354

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

© 2004 Mustan Bharmal

The criteria to evaluate the viability of each proposed external trust relationship will identify whether an implemented trust will be viable or not once implemented within the production environment. Note that although it is possible to remedy the lack of viability of an external trust relationship, these criteria will reflect the limitations and constraints of external trust relationships and hence the solutions may be difficult to attain. In these scenarios, there may be a requirement to consider alternative solutions to support the identified interdomain resource access requirements. Following the definition of the criteria for the design and implementation of external trust relationships, and the subsequent evaluation of identified trust requirements with the defined criteria, it will hence be possible to identify the following:  The feasibility status for each proposed new external trust relationship.  The viability status for each proposed new external trust relationship.  The requirements and details of an action plan for proposed new external trust relationships to attain compliance with previously failed criteria. This design methodology proposes that the definition of criteria for the retention, upgrade, and migration of all existing legacy external trust relationships must achieve the following three goals:  Prove necessary to retain, upgrade, and migrate via evaluation against defined retention criteria. Where an existing external trust relationship proves to be unnecessary to retain, upgrade, and migrate, then it requires exclusion from the scope of the remaining steps within this process.  Prove feasible to retain, upgrade, and migrate via evaluation against the same feasibility criteria defined for proposed new external trusts  Prove viable to use and manage within a production environment via evaluation against the same viability criteria defined for proposed new external trusts • Factor A2: Determination of the criteria for the design and implementation of new external trust relationships ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation wishes to define the criteria for the design and implementation of the proposed new external trust relationships. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: As stated above, the two goals for these criteria are to evaluate the feasibility and viability of proposed external trust relationships. When determining the criteria to evaluate the feasibility of a proposed trust relationship, consider the following:  The objectives for these criteria are to identify whether it is feasible to implement a proposed trust relationship for this domain with another external Windows-based domain and / or non-Windows Kerberos V5 realm. Hence, these criteria are necessary to identify support for compliance with all associated prerequisites to the design and implementation of external trust relationships.  Although the onus is with the organisation to define their criteria, this design methodology provides the following examples of criteria to evaluate the feasibility of each proposed trust relationship:

Page 323 of 354

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

© 2004 Mustan Bharmal

 The target external Windows-based domain / non-Windows Kerberos V5 realm will still exist at the time of implementation of the proposed new external trust. If the target domain is destined, for example, for decommissioning via a migration and consolidation exercise, then the proposed external trust is unfeasible.  The owners of this domain and the target external domain / Kerberos V5 realm for a proposed external trust concur to the establishment of a one or two-way external trust relationship between their domains / Kerberos V5 realm. Without concurrence from the owner(s) of both domains on the establishment of a one or two-way external trust relationship between their domains, a proposed trust is unfeasible.  There is adequate network connectivity between the domain controllers / key distribution centres (KDCs) for the two domains / domain and Kerberos V5 realm. For compliance with this criteria, it is necessary to establish the presence of a supporting network infrastructure that permits the generation of a permanent network connection between the domain controllers / KDCs for the two domains / domain and Kerberos V5 realm.  There is adequate network connectivity between the clients within each domain / Kerberos V5 realm and the resources in the other external domain / Kerberos V5 realm. Although domain controllers / KDCs within each corresponding domain / Kerberos V5 realm can have permanent network connectivity to each other, and hence establish and maintain the external trust, the clients within each domain that require use of the proposed trust may not have network connectivity to the resources in the corresponding domains. For example, a client in domain “A” (which has an external trust with domain “B”, which trusts domain “A”) may be a roaming user with a laptop computer. Where network access to domain “A” for this user is via a dial up connection, and that connection does not route traffic to domain “B”, then this client cannot use the trust and hence access resources on domain “B”.  The components and configuration of the name resolution infrastructure for each domain / domain and Kerberos V5 realm currently supports access to the corresponding domain controllers / KDCs, servers, and clients. Establishing a trust relationship relies on the provision of the domain / ream name (as a DNS domain name for Windows 2000, Windows Server 2003, and Kerberos V5 realms, or a NetBIOS domain name for Windows NT 4.0 domains) for the target domain. If the supporting name resolution infrastructure cannot resolve that domain name to an IP address for a corresponding domain controller / KDC, then it is not possible to establish the trust relationship. Note that the name resolution infrastructure is also required to support access to the target domain and its resources for member servers and clients within each domain, depending upon the direction of the trust. When determining the criteria to evaluate the viability of a proposed trust relationship, consider the following:  The objectives of these criteria are to identify whether a proposed trust relationship, once designed and implemented within a production environment, would remain a viable design decision, and hence justify any associated administrative and financial overheads. Hence, these criteria are necessary to identify support for the ongoing maintenance and use of proposed external trust relationships.  Although the onus is with the organisation to define their criteria, this design methodology provides the following examples of criteria to evaluate the viability of each proposed trust relationship:  The function and objectives of the proposed trust relationship justifies all actual and potential overheads associated with its design, implementation, and maintenance.

Page 324 of 354

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

© 2004 Mustan Bharmal

 Identify the functions and objectives of the proposed trust relationship and compare it collectively against the following example criteria: • Consider the number of users, applications, processes within the domain / Kerberos V5 realm that will user the trust relationship. For example, where a proposed trust relationship is to support the inter-domain resource access requirements for three users out of a few thousand within the trusting domain, then it may not be possible to justify all potential and actual associated overheads for the proposed trust. • Consider the role(s) of the users, applications, and processes within the organisation, which require the presence and use of the proposed trust relationship. For example, where only three users require the trust relationship, but these users are directors within an organisation, or an application that is mission critical to the organisation requires the trust relationship, then these requirements may justify the associated overheads. • Consider the longevity requirements for the proposed trust relationship. For example, where a proposed trust relationship requires design and implementation to support only a very short-term requirement (for example, one month) to access to resources within a target domain by local security principals, then this may not justify the associated overheads. Note that this criterion requires consideration in conjunction with the above criteria, as there may be, for example, a short-term requirement for a trust relationship, but it is required to support a migration from a legacy to a new domain infrastructure, and is hence a viable proposition.  The proposed trust relationship has the support of a high-availability and / or fault tolerance infrastructure. Without the support for the availability or fault tolerance of the trust, it may not be possible to consider the trust as a viable proposition. For example, failures in any of the following components are influential to the viability of a proposed trust relationship: • Consider the following factors about the domain controllers / KDCs in the source and target domains / realms: ♦ The number of domain controllers / KDCs in the source and target domains / realms can influence the viability of the trust relationship. For example, where there is only one domain controller / KDC in a target domain for a trust, then failure of that single domain controller will invalidate the trust. ♦ The specifications / configurations of the domain controllers / KDCs in the source and target domains / realms can influence the viability of the trust relationship. For example, a domain controller configured for fault tolerance with redundant power supplies, RAID HDD arrays, redundant NICs, and so on, will sustain the viability of a trust relationship. • Consider the following factors about the supporting network infrastructure between the source and target domains / realms: ♦ The resilience and fault tolerance of the network connections that link the domain controllers / KDCs for the source and target domains / realms can influence the viability of the trust relationship. Network links with a history for low availability, and the lack of redundant network links and routes can jeopardise the viability of a trust. ♦ The performance of the supporting network infrastructure can influence the viability of the trust relationship. For example, consistently low levels of

Page 325 of 354

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

© 2004 Mustan Bharmal

available bandwidth or high latency values for network traffic can affect the use and operation of the trust, and hence compromise its viability. • Consider the following factors about the administrators of the trust relationship within the source and target domains / realms: ♦ The skills and experience of the administrators of the trust relationship within the source and target domains / realms can influence the viability of the trust. For example, untrained or inexperienced administrators may not be able to execute troubleshooting exercises to resolve any issues with a trust relationship. This may hence compromise the viability of the trust relationship if it is possible to identify a lack of on going support for the trust. ♦ The availability of the administrators to manage a trust relationship can influence the viability of the trust. For example, a source or target domain with limited numbers of administrators, may assign trust administration operations a very low priority against other critical domain operations. Hence, their diminished availability for the execution of routine and troubleshooting exercises for trust relationships may compromise the viability of the trust.  The trust relationship supports services provided or accessed between the source and target domains / realms, and it is possible to comply with all criteria within associated SLAs for the services. For example, a proposed trust relationship will become essential to the operation of a business-critical application, the failure of which can generate substantial financial and administrative penalties. There is a hence a requirement to provide and comply with an SLA for the provision of this application. Due to the role of the trust relationship to the operation of this application, the SLA must control essential aspects of the operation, management, and availability of the trust relationship, failure of which will compromise the SLA. Using the above information and examples, execute the following:  Determine and document the criteria to evaluate the feasibility of the design and implementation of each proposed external trust relationship  Determine and document the criteria to evaluate the viability for each proposed trust relationship once designed and implemented into the production environment • Factor A3: Determination of the criteria for the retention, upgrade, and transfer of existing legacy external trust relationships to this domain ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the presence of one or more existing external trust relationships, and  Wishes to define the criteria for the retention, upgrade, and migration of the identified legacy external trust relationships ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: As stated above, the goal for these criteria is to evaluate the requirements to retain, upgrade, and transfer one or more existing legacy external trust relationships to this domain. When determining the criteria to evaluate these requirements for existing legacy external trust relationships, consider the following:

Page 326 of 354

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

© 2004 Mustan Bharmal

 The objectives for these criteria are to identify whether it is necessary to execute tasks to retain, upgrade, and transfer one or more existing legacy external trusts to this domain. Hence, these criteria are necessary to identify support for compliance with all associated prerequisites to the design and implementation of external trust relationships.  The following are examples of criteria to evaluate the requirements for the retention, upgrade, and transfer (to this domain) of each identified legacy external trust relationship:  The retention of an existing external trust is essential to the continuity of existing key business and / or technical processes that currently depend upon the trust relationship. Where it is not possible to identify any business or technical processes that depend upon the retention, upgrade, and transfer of an existing external trust relationship, then there is a requirement to abandon this trust and exclude it from all following steps within this process.  It is possible to identify one or more future business and / or technical requirements for the retention, upgrade, and transfer of an existing external trust relationship. The identification of such requirements following the decommissioning of an existing external trust relationship will require the redesign and re-implementation of that trust again. Use the above information and examples to determine and document the criteria for evaluation of the requirements to retain, upgrade, and transfer (to this domain) one or more existing external trust relationships. • Factor A4: Evaluation of proposed new and existing external trusts against defined criteria ♦ Criteria for Execution: Explore the considerations for the execution of this factor where an organisation:  Has identified the requirement for one or more new external trust relationships  Has identified the presence of one or more existing external trust relationships  Has defined the criteria to evaluate the feasibility and viability of each proposed new external trust relationship  Has defined the criteria to evaluate the requirements to retain, upgrade, and transfer one or more existing trust relationships, and  Wishes to evaluate each existing and new proposed external trust relationship against the defined criteria to determine their requirement, feasibility, and viability. ♦ Factor Considerations: Consider the following information where it is possible to identify compliance with the above criteria within an organisation: This design methodology proposes the following approach to evaluate the requirement, feasibility, and viability of each existing and new proposed external trust relationship for this domain:  Select an existing external trust relationship and evaluate it against each of the defined retention criteria to determine the requirements to retain, upgrade, and transfer it to this domain.  Select an existing or a new proposed external trust relationship for this domain and evaluate it against each of the defined criteria to determine its feasibility. Where there is a lack of compliance with a specific criterion for a proposed trust, then develop an action plan to permit compliance.

Page 327 of 354

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

© 2004 Mustan Bharmal

 Following the evaluation of all criteria to determine their feasibility, execute all action plan tasks to ensure compliance, where necessary. If there was a requirement to execute an action plan, re-evaluate the existing or new proposed trust relationship against the feasibility criteria. If it is not possible to attain compliance with all defined feasibility criteria, then abandon the proposition. Where it is possible to attain compliance with all feasibility criteria, proceed to the next step.  Evaluate all existing and new proposed trust relationships against the criteria to determine their viability once implemented within the production environment. Where there is a lack of compliance with a specific criterion for a proposed trust, then develop an action plan to permit compliance.  Following the evaluation of all criteria to determine their viability, execute all action plan tasks to ensure compliance, where necessary. If there was a requirement to execute an action plan, re-evaluate the existing and / or new proposed trust relationships against the viability criteria. If it is not possible to attain compliance with all defined viability criteria, then abandon the proposition. Where it is possible to attain compliance with all viability criteria, proceed with the next step in this process to:  Design and implement the new proposed external trust relationships, and / or  Retain, upgrade, and transfer existing external trust relationships The following are examples of the evaluation process against the example criteria defined above to determine the feasibility of each new proposed external trust relationship. The results of this evaluation process will be the identification of the feasibility of a trust and, where necessary, the action plan tasks to ensure compliance with defined criteria.  Criteria: The owners of this domain and the target external domain / Kerberos V5 realm for a proposed external trust concur to the establishment of a one or two-way external trust relationship between their domains / Kerberos V5 realm.  Evaluation: Where it is possible to identify a lack of compliance with this criteria, and hence there is no concurrency or agreement to establish the trust, then execute one of the following options as part of an action plan:  Negotiate an agreement between the owners of each domain / domain and Kerberos V5 realm to establish the trust, based (for example) upon the function, benefits, and longevity requirements of the trust, or  Seek alternatives to the establishment of the external trust relationship, such as the provisioning of alternative credentials in target domains, and so on.  Criteria: There is adequate network connectivity between the domain controllers / key distribution centres (KDCs) for the two domains / domain and Kerberos V5 realm.  Evaluation: Where it is possible to identify a lack of compliance with this criteria, and hence the absence of a supporting network infrastructure, then execute one of the following options as part of an action plan:  Negotiate to establish a permanent network connection between the domains that will support the establishment of the proposed trust relationship, or  Abandon the proposal for the external trust relationship, as without a network connection between the domains an external trust is not feasible.

Page 328 of 354

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

© 2004 Mustan Bharmal

 Criteria: There is adequate network connectivity between the clients within each domain / Kerberos V5 realm and the resources in the other external domain / Kerberos V5 realm.  Evaluation: Where it is possible to identify a lack of compliance with this criteria, and hence the presences of potential network connectivity or network routing issues that may prevent users from accessing the trust relationship, then execute the following tasks as part of an action plan:  Identify the users of the trust relationship that may experience network connectivity issues to the trust relationship  Identify the causes of the network connectivity issues and devise a solution to the identified issues  Criteria: The components and configuration of the name resolution infrastructure for each domain / domain and Kerberos V5 realm currently supports access to the corresponding domain controllers / KDCs, servers, and clients.  Evaluation: Where it is possible to identify a lack of compliance within this criteria, and hence an absence of support by the current configuration of the name resolution infrastructure to locate the domain controllers / KDCs for the target domain / Kerberos V5 realm, then execute the following tasks as part of an action plan:  Identify each component of a supporting name resolution infrastructure that is responsible for identification of the target domain. For example, a target domain for a proposed external trust relationship is a Windows NT 4.0 domain and the TCP/IP configuration of the Windows NT 4.0 domain controllers only use WINS for name resolution, and not DNS.  Ensure the appropriate configuration of this component in the supporting name resolution infrastructure, to permit access to the target domain / Kerberos V5 realm and its domain controllers / KDCs. In the above scenario where the target domain is a Windows NT 4.0 domain using WINS, this domain must have access to one of the following: • The same WINS database used by the Windows NT 4.0 domain controllers • A replicated copy of that WINS database on a local WINS server • A discrete WINS infrastructure with static entries for the target Windows NT 4.0 domain controllers  Note that it is necessary to ensure that the member servers and clients within this domain also have access to the appropriate name resolution component. The above options exclude an alternative option (the use of static entries within an LMHOSTS file), as this is not a feasible option to support multiple domain controllers, member servers, and clients within a domain. The following are examples of the evaluation process against the example criteria defined above to determine the viability of each proposed external trust relationship. Execute these evaluations for the viability of a proposed trust relationship only where the feasibility of the trust is successfully established. The results of this evaluation process will be the identification of the viability of a trust and, where necessary, the action plan tasks to ensure compliance with defined criteria.  Criteria: The function and objectives of the proposed trust relationship justifies all actual and potential overheads associated with its design, implementation, and maintenance. Evaluate against the following sub-criteria:

Page 329 of 354

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

© 2004 Mustan Bharmal

 Number of users, applications, processes within the domain / Kerberos V5 realm that will user the trust relationship  The role(s) of the users, applications, and processes within the organisation, which require the presence and use of the proposed trust relationship  The longevity requirements for the proposed trust relationship  Evaluation: Where it is possible to identify conflicts in the above sub-criteria, and hence a lack of support for the proposed function of the trust relationship, execute one of the following tasks as part of an action plan:  Identify solutions to each issue, where possible, to permit justification of the administrative and financial overheads associated with the proposed trust relationship, or  Abandon the proposition for the trust relationship as it may just justify its financial and administrative overheads based upon its function within the organisation.  Criteria: The proposed trust relationship has the support of a high-availability and / or fault tolerance infrastructure. Evaluate against the following sub-criteria:  The details of the domain controllers / KDCs in the source and target domains / realms  The details of the supporting network infrastructure between the source and target domains / realms  The details of the support model and environment for the proposed trust relationships  Evaluation: Where it is possible to identify lack of support for the availability or fault tolerance of a proposed trust relationship, then identify the cause and develop an action plan to counter the identified issues. Where it is not possible to attain full compliance with all sub-criteria, then it may be necessary to abandon the proposition for the trust relationship, as it may not be possible to assure its longterm viability.  Criteria: The trust relationship supports services provided or accessed between the source and target domains / realms, and it is possible to comply with all criteria within associated SLAs for the services.  Evaluation: Where it may not be possible to attain compliance with all relevant criteria within an associated SLA, then execute one of the following tasks as part of an action plan:  Identify the criteria / criterion within the supporting SLA and develop a solution to ensure compliance, or  Where it is not possible (technically, logistically, financially, and so on) to ensure compliance with the stated criteria, seek alternative solutions for the service provision. Using the above information and approach, execute the following:  Determine and document the tasks, where necessary and as part of an action plan, that require execution to ensure the feasibility for the design and implementation of a proposed external trust relationship.

Page 330 of 354

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

© 2004 Mustan Bharmal

 Determine and document the tasks, where necessary and as part of an action plan, that require execution to ensure the viability for the design and implementation of a proposed external trust relationship.  Determine and document the proposed external trust relationships for this domain that comply with all criteria for their feasibility and viability, and hence require design and implementation 9.9.3. Determination of the Security Requirements for External Trust Relationships Consider the following when determining the requirements to secure the required external trust relationships: