Best Practices for Delegating Active Directory Administration

Microsoft Corporation
Created: November 24, 2003
ii

Acknowledgements
Program Manager: Sanjay Tandon
Writers: Mary Hillman

We thank the following people for their contributions in the creation of the
Active Directory Delegation Appendices and the Dsrevoke tool:
Umit Akkus, Nona Allison, Colin Brace, Raman Chikkamagalur, Arren Conner,
Raju Dantuluri, Dmitry Dukat, Levon Esibov, Dmitri Gavrilov, Don Hacherl,
Saif Hasan, Xin He, David Hou, Gokay Hurmali, Khushru Irani, Kamal
Janardhan, Gregory Johnson, Ian Jose, Richa Kumar, Klaas Langhout, William
Lees, Xiaozhong Luo, Jaeger Mitchell, Nathan Muggli, Arun Nanda, Rich
Randall, Ullattil Shaji, Brett Shirley, Scott Turnbull, Andrea Weiss, Jeff
Westhead, and BJ Whalen.

We thank the following people for reviewing the guide and providing valuable
feedback:
Laurie Brown, John Craddock, Robert DeLuca, Christoph Felix, Eric
Fleischman, Guido Grillenmeier, Mike Hickey, David Kayano, Alain Lissoir,
Andreas Luther, Astrid McClean, Paul Rich, Joe Richards, and David Trulli.
 Introduction iii

Contents
Introduction................................................................................. ...........1
Abstract................................................................ ............................1
Scope................................................................................. ...............1
Intended Audience.......................................................... ..................2
Chapter 1: Delegation of Administration Overview.................................4
Business Case for Delegating Administration....................................4
Benefits of Delegation................................................................ .......6
Delegation at Work............................................. ..............................6
Active Directory Management................................................ ...........8
Creating a Successful Active Directory Delegation Model...............12
Chapter 2: How Delegation Works in Active Directory..........................19
Overview............................................................................... ..........19
Active Directory Administrative Tasks.............................................22
Active Directory Logical Structure and Data Storage......................23
Delegation and Access Control................................................... .....26
Chapter 3: Delegating Service Management........................................50
Level-of-Privilege Considerations in Delegating Service Management51
Recommended Approach to Service Management..........................52
Service Management Overview................................................. ......53
Creating a Service Management Delegation Model.........................77
Implementing the Service Management Delegation Model.............80
Maintaining the Service Management Delegation Model.................84
Chapter 4: Delegating Data Management............................................87
Recommended Approach to Data Management..............................87
Understanding Data Management..................................................88
Determining Data Management Stakeholder Needs........................95
Creating the Data Management Delegation Model..........................96
Implementing Your Data Management Delegation Model..............113
Maintaining Your Data Management Delegation Model.................130
Case Study: A Delegation Scenario.................................................. ...136
Company Overview......................................................... ..............136
Active Directory Infrastructure.................................... ..................137
Managing Contoso’s Active Directory Environment.......................142
Introduction
The Active Directory® directory service is an integral component of network
infrastructures that are based on the Microsoft® Windows Server™ Server 2003,
Standard Edition; Windows Server™ 2003, Enterprise Edition; Windows
Server™ 2003, Datacenter Edition, and Windows® 2000 Server,
Windows® 2000 Advanced Server, and Windows® 2000 Datacenter Server
operating systems. Successful management of Active Directory environments
requires distribution of administrative responsibilities among multiple
administrators according to organizational, operational, legal, and administrative
requirements. Having the necessary background information, requirements,
practices, and recommendations can help you delegate administration to more
securely and efficiently manage Active Directory services and data.

Abstract
Active Directory provides an enterprise-ready, scalable, distributed directory
service that allows organizations to centrally manage and share information
about network resources and users, and is at the heart of distributed network
security in a Windows Server–based enterprise. Active Directory thus plays a
major role in accomplishing the business goals of your organization, and your
ability to successfully manage Active Directory has a direct bearing on your
ability to accomplish these goals.
Delegation of administration, a key capability of Active Directory, provides a
means to successfully manage an Active Directory environment. This document
discusses in depth the issues involved in delegating administrative
responsibilities, and can help you plan for, implement, and maintain an
administrative delegation model that allows secure and efficient management of
Active Directory.

Scope
This document provides all the information required to create, implement, and
maintain a security-conscious and efficient delegation model to manage your
Active Directory environments. This information includes an overview of
delegation, in-depth explanations of the rationale for delegation, technical
descriptions of how delegation works in Active Directory, processes for creating
delegation models for both service and data management, the steps needed to
implement and maintain the models, and a detailed case study. Appendices to this
document provide an exhaustive reference, including a comprehensive list of
Active Directory administrative tasks and associated permissions required to
delegate every administrative task in Active Directory.
This document does not include Active Directory deployment instructions or
recommendations. For information about planning and deploying an Active
Directory environment, see Designing and Deploying Directory and Security
Services of the Microsoft® Windows® Server 2003 Deployment Kit on the Web
at http://go.microsoft.com/fwlink/?LinkID=4719.
2

Intended Audience
This document is intended for Information Technology (IT) professionals who
are responsible for managing an Active Directory environment. In most IT
infrastructures that consist of multiple integrated components and services, the
responsibility to deliver a specific component or service is typically entrusted to
a component or service owner, who is responsible for the overall delivery of the
component or service.
Ownership of Active Directory environments should be entrusted to two specific
owners or owner groups, whose roles are typically strategic and managerial –
service owners and data owners. Service owners and data owners have general,
overriding responsibility for Active Directory. These usually high-ranking
managers are respectively responsible for ensuring reliability and security in the
delivery of the directory service and for managing the security of Active
Directory content. To that end, they are responsible for delegating and
distributing among their administrators responsibility for managing services and
content. They do so by creating an administrative delegation model, which
documents the distribution of administrative responsibilities among various
administrative personnel.
Administrative responsibilities for delegating Active Directory management are
divided between:
• Service owners, who are responsible for:
• Planning, deployment, and long-term maintenance of the Active
Directory infrastructure.
• Ensuring that the directory continues to function reliably and at the
desired level of security.
• Ensuring that the goals established in service-level agreements are
maintained.
• Data owners, who are responsible for maintaining the information that is
stored in or protected by the Active Directory directory service, including:
• Management of user and computer accounts.
• Management of local resources, such as member servers and workstations
and the data they store.
• Service administrators, who represent the operational arm of service owners
and are responsible for carrying out the tasks that are required to maintain the
delivery of the directory service,
• Data administrators, who represent the operational arm of data owners and
are responsible for carrying out the tasks that are required to manage the
content that is stored in or protected by Active Directory.
This document is intended for service and data owners to help them create a
security conscious and efficient administrative delegation model that is tailored
to the specific requirements of their organization. It is also intended for the
 3

service and data administrators who are responsible for implementing the
delegation model.
To accommodate the needs of these different stakeholders, the information in this
document is divided into four chapters and a case study, as follows:
Chapter 1: Understanding Delegation of Administration
This chapter provides an overview of Active Directory
management categories and stakeholders and a roadmap
for successfully managing delegation of administration
in Active Directory. It is targeted at all stakeholders
involved in Active Directory management.
Chapter 2: How Delegation Works in Active Directory
This chapter takes an in-depth look at how delegation of
administration actually works in Active Directory and
presents all the technical aspects involved in delegation
of Administration. It contains a wealth of information
that will be useful for all stakeholders involved in
Active Directory management.
Chapter 3: Delegating Service Management
This chapter presents an end-to-end perspective of
Active Directory service management, and provides
guidance on how to create, implement, and maintain a
secure and efficient administrative delegation model for
service management. It is targeted at Service Owners
and Service Administrators.
Chapter 4: Delegating Data Management
This chapter presents an end-to-end perspective of
Active Directory data management, and provides
guidance on how to create, implement, and maintain a
secure and efficient administrative delegation model for
data management. Though it is targeted at Data Owners
and Data Administrators, Service Owners and Service
Administrators will also benefit from the information in
this chapter.
Case Study: A Delegation Scenario
The case study walks through the creation,
implementation, and maintenance of an administrative
delegation model for a fictitious Active Directory
environment based on the recommendations presented
in Chapters 3 and 4. While it is primarily targeted at
Service and Data administrators, service and data
owners will also benefit from the case-study.
4

Chapter 1: Delegation of Administration Overview

Active Directory serves as a central information repository in a Windows-based
network infrastructure, It stores identity, authorization, and application-specific
information, service-publication and discovery information, and directory service
configuration data. It is an inherent part of distributed security and identity
management, and plays a key role in the manageability of a Windows Server–
based enterprise.
Active Directory administration involves many different operations, which must
be distributed among many administrators in a large organization. Delegation of
administration, a key capability provided by Active Directory, provides scaleable
identity, security, service and data management across the enterprise. Through
delegation of administration, organizations can increase security and efficiently
manage IT resources while meeting administrative requirements. By increasing
administrative efficiency and decentralizing administration, delegation reduces
administrative costs and improves manageability of IT infrastructures.
Delegation of administration is the transfer of administrative responsibility for a
specific administrative task from a higher authority to a lower authority. From an
operational perspective, delegation of administration involves a higher-level
administrator conferring upon a lower-level administrator the authority to carry
out a specific administrative task. From a technical perspective, delegation of
administration involves a higher-level administrator granting a controlled set of
permissions to a lower-level administrator in order to carry out a specific
administrative task.

Business Case for Delegating Administration

Organizations are moving towards a model in which different divisions,
structural units, and business units share a common IT infrastructure in order to
increase collaboration and reduce the cost of maintaining the IT infrastructure.
The IT infrastructure of such organizations often spans multiple organizational
and geographic boundaries.
Such an environment might have the following requirements:
• Organizational structure requirements. Part of an organization might
participate in a shared infrastructure to save costs, but require the ability to
operate independently from the rest of the organization.
• Operational requirements. An organization or application might place unique
constraints on directory service configuration, availability, or security.
• Legal requirements. An organization might have legal requirements to
operate in a specific manner, such as restricting access to certain information.
• Administrative requirements. Different organizations might have different
administrative needs, depending on existing and planned IT administration
and support models.
 5

The first three requirements express themselves as needs for autonomy and
isolation. Autonomy is the ability of the administrators of an organization to
independently manage:
• All or part of service management (service autonomy).
• All of part of the data stored in or protected by Active Directory (data
autonomy).
Isolation is the ability of an administrator or an organization to prevent other
administrators from:
• Controlling or interfering with service management (service isolation).
• Controlling or viewing a subset of data in Active Directory or on member
computers that are joined to Active Directory the directory (data isolation).
Strict service or data isolation often requires creating a separate forest or domain.
Addressing network architecture design considerations for accommodating
autonomy and isolation requirements is beyond the scope of this document.
Instead, this document addresses the need and process for delegating
administrative authority based on an organization’s requirements for
administration of its IT resources.
For more information about accommodating autonomy and isolation
requirements, see “Designing the Active Directory Logical Structure” in
Designing and Deploying Directory and Security Services of the Windows
Server 2003 Deployment Kit (or see “Designing the Active Directory Logical
Structure” on the Web at http://go.microsoft.com/fwlink/?LinkId=4723).
For the purpose of understanding an organization’s needs for delegating
administrative authority, organizations can be classified in the following
categories, based on their size:
• Small organizations, which typically have 25 to 50 workstations and three to
five servers
• Medium organizations, which typically have 50 to 500 workstations and four
to five servers
• Large organizations, which typically have at least 500 workstations and 50
servers
Small and medium organizations typically have one or a few administrative
groups that are responsible for managing all aspects of Active Directory. Small
and medium organizations might not need to create an extensive delegation
model. Large organizations usually have a clear need to distribute and delegate
administrative authority to various administrative groups, possibly delegating
certain aspects of Active Directory management to centralized teams and
delegating other aspects to decentralized teams. While large organizations will
find the delegation capabilities of Active Directory most useful, small and
medium organizations can also achieve enhanced security, increased control,
more accountability, and reduced costs by implementing delegation.
6

Benefits of Delegation
By enabling efficient, security-conscious delegation and distribution of
administrative responsibilities among various administrative groups that
addresses the specific requirements imposed by participating business units,
delegation of administration provides the means to successfully manage an
Active Directory environment. Delegation of administration provides the
following benefits:
• Allows distribution of administrative responsibility among multiple
administrative groups, each with a defined scope of authority and a defined
set of responsibilities.
• Enables decentralization of administrative authority.
• Allows the security-conscious distribution of administrative responsibility.
In addition, delegation of administration allows organizations to efficiently
manage their IT infrastructures and enforce their security precautions by
enabling organizations to:
• Distribute administrative responsibilities on the basis of least privilege,
which ensures that the individual or group of individuals to whom the task
has been delegated can perform only the tasks that are delegated, and cannot
perform tasks that have not been explicitly delegated or authorized.
• Increase administrative efficiency by easily and conveniently assigning the
responsibilities for managing Active Directory content and the directory
service itself.
• Reduce administrative costs by facilitating shared administrative
responsibility. For example, administrative responsibility for providing
account support to all accounts in the organization can be easily achieved
within a matter of minutes.

Delegation at Work
A brief example at delegation at work will help you better understand the value
and the benefits of delegation that organizations can use to enhance security,
decrease TCO and make Active Directory and IT resource management more
tractable and efficient.
Contoso Pharmaceuticals, a fictitious company, has recently deployed Active
Directory. Contoso Pharmaceuticals is a large organization that has its
headquarters in Chicago, Illinois and has operations in five other locations in
North America and Europe. The Active Directory infrastructure consists of a
single forest, three domains, and six sites. The company has about 16,000 users,
20,000 end-user workstations and about 3000 servers spread across five physical
locations. Contoso has four business units that have a presence in each of the five
physical locations. These business units include:
• Research and Development
• Production
 7

• Business Management
• IT
With Active Directory delegation, Contoso was able to delegate responsibility in
the following areas:
• Workstation management. Contoso seamlessly and easily delegated all
aspects of workstation management to local administrative groups, one for
each physical location.
• Account management. Contoso delegated all aspects of account management
to the Account Admins of each business unit regardless of the physical
location of the managed users, while centrally retaining help desk operations.
• Security-sensitive operations. Contoso was able to grant Corporate Security
personnel sufficient authority to carry out security-sensitive operations on
every user account in the company, such as allowing Corporate Security
personnel to disable or lock out any user account in the entire company at the
click of a button.
• Resource management. Contoso delegated all aspects of resource
management to the appropriate resource owners, enabling the resource
owners to manage and retain control over their resources. This included the
following:
• A human resources portal on the intranet hosted on a small cluster of
three high-performance servers running Internet Information Services
(IIS). Contoso was able to delegate full control over the servers to the
administrators of this application and grant them the ability to authorize
access to their portal.
• Multiple in-house applications hosted on a set of high-performance
servers, with the administration of the servers entrusted to one set of
administrators in the data center and the administration of each
application entrusted to a separate set of administrators. Using delegation,
Contoso could easily delegate to the administrative group responsible for
managing the servers the ability to manage the servers while delegating to
the administrative group responsible for managing each application the
ability to manage their applications.
• Self-service user accounts. Contoso enabled self-service on user accounts,
and was able to finely control specific information that users could change
themselves. With delegation, Contoso could allow their users to modify their
phone numbers and personal information while retaining control over the
ability to modify sensitive data like the password-not-required flags on user
objects. Contoso was also able to grant other stakeholders like Human
Resources managers the ability to modify a user’s manager and office
location information.
8

• Active Directory–enabled applications. Contoso was able to delegate all

aspects of Microsoft Exchange mailbox administration to its Exchange
administrators, which increased productivity while achieving separation of
duties. In addition, Contoso had an in-house Line of Business (LOB)
application that stored data in Active Directory. Contoso administrators were
able to delegate complete control over the LOB application’s data to the
application’s administrators, including granting the ability to control access
to data by using account and resource groups.
• Service management. Contoso was able to distribute Active Directory service
management amongst specific administrative groups based on the principle
of least privilege. This increased accountability achieved a clear separation of
responsibility, and decreased the number of highly-trusted administrators that
Contoso needed to hire and maintain.
As demonstrated by the Contoso example, organizations can realize multiple
benefits from the delegation capabilities of Active Directory. These benefits
include distributing administrative responsibilities on the basis of least privilege,
increasing administrative efficiency by easily and conveniently assigning the
responsibilities for managing directory content and the directory service itself,
and reducing administrative costs by facilitating shared administrative
responsibility.

Active Directory Management

The objective of delegating administrative authority is to allow organizations to
efficiently manage their Active Directory environments and the data stored in or
protected by Active Directory in accordance with good security practices.
Delegation of administration makes Active Directory management easier and
allows organizations to address specific administrative needs. This section
discusses the areas of Active Directory management and describes the
stakeholders involved.
The administrative responsibilities of managing an Active Directory environment
fall into two categories:
• Service management. Administrative tasks involved in providing secure and
reliable delivery of the directory service.
• Data management. Administrative operations involved in managing the
content that is stored in or protected by the directory service.

Service Management
Service management includes managing all aspects of the directory service that
are essential to ensuring the uninterrupted delivery of the directory service across
the enterprise. Service management includes, but is not limited to, the following
administrative tasks:
• Adding and removing domain controllers
• Managing and monitoring replication
 9

• Ensuring the proper assignment and configuration of operations master roles

• Performing regular backups of the directory database
• Managing domain and domain controller security policies
• Configuring directory service parameters, such as setting the functional level
of a forest or putting the directory in the special List-Object security mode

Data Management
Data management includes managing the content that is stored in Active
Directory, as well as content that is protected by Active Directory. Data
management tasks include, but are not limited to, managing the following Active
Directory content:
• User accounts, which represent the identities of people who use the network
• Computer accounts, which represent the computers that are joined to
domains in the Active Directory forest
• Security groups, which are used to aggregate accounts for the purpose of
authorizing access to resources
• Application-specific attributes for Active Directory-enabled and -integrated
applications, such as Microsoft Exchange and Microsoft Real-Time
Communication service
In addition, Active Directory data management can also facilitate the distribution
and delegation of these management tasks:
• Workstation management, which includes managing all aspects of end-user
workstations
• Server management, which includes managing all aspects of all servers
joined to any domain in an Active Directory forest
• Resource management, which includes managing all aspects of services and
applications hosted on member servers joined to any domain in an Active
Directory forest, possibly including the server management aspects of the
servers on which the application or resource is being hosted

Management Stakeholders
Active Directory plays a central role in a Windows-based IT infrastructure and is
an inherent part of distributed security and identity management, touching almost
every critical aspect of an organization’s infrastructure. Thus, management of an
Active Directory environment involves multiple stakeholders, each having
specific responsibilities for managing the data, service, or security aspects of
Active Directory, and each requiring the ability to perform their assigned
administrative responsibilities.
For example, administrative groups who are responsible for managing user
identities require the ability to perform account management. Network operators
who are responsible for delivering network services that are required for Active
10

Directory to function, such as DNS, require the ability to manage DNS servers
and data. Corporate security personnel might require the ability to audit logon
events, and Help Desk operators might require administrative rights to perform
support operations like resetting passwords for users. Administrators of Active
Directory–enabled and –integrated applications require the ability to manage
application-specific data stored in the directory.
From a managerial and operational perspective, Active Directory management
stakeholders primarily include service and data owners and administrators.
However, because Active Directory plays a central role in a Windows Server–
based IT infrastructure, it is not uncommon to have other stakeholders, including
owners and administrators of other parts of the IT infrastructure who own,
manage, or are responsible for aspects of the IT infrastructure related to or
dependent on the organization’s Active Directory environment.
Service and Data Owners
In most IT infrastructures that consist of multiple, integrated components and
services, responsibility for delivering a specific component or service is typically
entrusted to an owner. This owner is responsible for the overall delivery of the
component or service, but does not actually perform the work. Rather, the role of
the owner is managerial and strategic, and the responsibility for the day-to-day
administrative tasks that are involved in managing Active Directory is assigned
by the owner to one or more administrators.
Ownership of all Active Directory environments should be entrusted to two
owner groups:
• Service owners. Responsible for planning and long-term maintenance of the
Active Directory infrastructure, ensuring that the directory service continues
to function, and ensuring that goals established in service-level agreements
are maintained. While the administrative responsibilities of managing the
directory service can be shared among administrative groups from different
business units, service ownership is typically not shared, but is held by a
centralized service owner.
• Data owners. Responsible for maintenance of the data that is stored in Active
Directory, as well as content that is protected by Active Directory. This data
includes user and computer accounts and local resources, such as member
servers and workstations. Because an Active Directory environment might
span multiple business units, these business units often require the ability to
manage their data autonomously. It is not atypical for data ownership to be
shared among multiple business units across the enterprise.
Service and data owners create an administrative model to distribute and
delegate administrative responsibilities among administrators, who are
responsible for performing Active Directory operations. Service owners employ
service administrators to manage the directory service, and data owners employ
data administrators to manage the content stored in or protected by the directory
service.
 11

Service and Data Administrators

The operation of Active Directory involves two types of administrators:
• Service administrators. Responsible for performing all administrative tasks
that are involved in configuring and administering an Active Directory
environment. Service administrators are highly trusted users who are
employed by the service owner to manage the directory service. Service
administrators implement policy decisions that are made by service owners,
and handle the day-to-day tasks that are associated with maintaining the
directory service and infrastructure.
• Data administrators. Responsible for maintaining data that is stored in Active
Directory, such as user and group accounts, and application-specific data.
Data administrators are employed by the data owners to manage the content
that is stored in or protected by the directory service. Data administrators
control subsets of objects within the directory, but have no control over the
installation or configuration of the directory service.
Other Stakeholders
Active Directory enables directory-integrated applications to store and modify
network-centric data in the directory and it also enables network services to
publish globally useful information in the directory. User identities are also
stored in the directory, as are security and distribution groups. Stakeholders
might have business requirements to modify or have access to data that is
controlled by data owners.
For example, administrators of Active Directory-enabled applications or human
resources personnel might need control over application or user data. Other users
might be Active Directory management stakeholders based on the applications
they administer. Usually, applications that store or modify data in Active
Directory have administrators who are responsible for the management of the
respective application-specific data. Additionally, users of these applications
might also need to read or modify application-specific data.
Still other users might have job-related reasons for performing administrative
tasks in Active Directory. For example, corporate security personnel might
require the ability to carry out certain security-sensitive operations, such as
auditing logon events. Help desk operators might require administrative rights to
perform support operations, such as resetting passwords for users.
Thus, in addition to service and data owners and administrators, other users
might be considered management stakeholders based on business needs that
require them to have control of or access to data stored in or protected by Active
Directory.
Service and data owners (and administrators) are collectively responsible for
ensuring that all stakeholders are granted sufficient access rights that are
minimally required to perform the administrative tasks that are associated with
their business roles in the organization.
12

Creating a Successful Active Directory Delegation Model

Managing a dynamic Active Directory environment typically involves many
different administrative tasks that differ in scope, impact, and sensitivity.
Administrative responsibility must be distributed and delegated among service
and data administrators, taking into account the specific administrative needs of
an organization. For example, an organization might have a specific need to
delegate administrative responsibility for all account and resource management
tasks to decentralized administrative groups while retaining centralized control
of account support and operations by delegating responsibility for providing
account support to centrally-based administrative groups.
Active Directory service and data owners are responsible for ensuring that the
administrative needs of all stakeholders are addressed and might need to
authorize administrative access or delegate the ability to carry out specific
administrative tasks to these stakeholders, allowing the stakeholders to
accomplish their assigned responsibilities based on their business role in the
organization.
A structured and methodical approach towards managing an Active Directory
environment can greatly enhance the security of the environment, reduce
administrative costs involved in managing the environment, and successfully
address the administrative needs of all stakeholders, thereby making Active
Directory management more tractable seamless, efficient and secure.
A structured and methodical approach to managing an Active Directory
environment generally involves the following recommended approach towards
planning, creating, and implementing a successful administrative delegation
model:
1. Understand all aspects of Active Directory management.
2. Understand the administrative needs of all stakeholders.
3. Create a delegation model that ensures that administrative coverage is
provided for all aspects of Active Directory management and that addresses
the administrative needs of all stakeholders.
4. Implement the delegation model in a secure and efficient fashion, ensuring
that the administrative needs of all delegated administrators and all
stakeholders are addressed while also ensuring that all administrative
access has been granted on the basis of least privilege.
5. Maintain the implemented delegation model, which involves making
modifications to the implemented delegation model in response to changes
in administrative requirements or needs.
A particularly effective method for managing an Active Directory environment is
to apply the concept of roles-based administration to creating, implementing and
maintaining a secure, tractable and efficient administrative delegation model.
The following sections introduce the concept of roles-based administration and
provide guidance on how this concept can be applied to increase security and
efficiency when managing Active Directory environments.
 13

A Roles-Based Approach to Active Directory Management

A particularly effective method for creating an efficient administrative delegation
model is to use administrative roles. IT infrastructures span geographical,
political, and administrative spectrums. A model that allows IT departments to
delegate administrative responsibilities on the basis of business functions and
administrative scopes lets organizations focus on business processes as opposed
to technology processes. Defining these functions and scopes in terms of
administrative roles enables business-driven administrative control while
affording the ability to securely scale administration.
Administrative Roles
A role is a collection of related administrative tasks that can be assigned to a
specific set of administrators in a specific scope of influence or authority. For
example, account support tasks are similar in nature and are usually assigned to a
specific set of administrators for a specific collection of user accounts. By
defining a role called Help Desk or Account Support Operators, you can
associate with that role a set of administrative tasks typically performed by
personnel in that business function. You can then create various instances of this
role, each represented by a unique security group, to provide account support in
different parts of the organization. For example, consider an organization that is
spread across four physical locations and has a decentralized account
management and support model. Having defined a role for account support, this
organization can simply create four instances of this role, one per physical
location, and seamlessly and easily provide account support.
A role definition consists of the following:
• A collection of one or more administrative tasks.
• The collective set of permissions required to perform this set of tasks.
An instance of a role definition applies to a specific scope of administrative
authority. A role instance consists of the following:
• A collection of one or more administrative tasks.
• The collective set of permissions required to perform this set of tasks.
• A specific scope of administrative authority.
To use administrative roles in your delegation model, you do not need to
undertake an extensive process of defining roles. Microsoft has engineered role
definitions for Active Directory management and recommends the use of these
roles for delegating administrative responsibilities for managing Active
Directory. For more information about these service and data management role
definitions and associated tasks, see “Chapter 3: Delegating Service
Management” and “Chapter 4: Delegating Data Management” later in this
document.
14

Administrative Tasks
Management of a dynamic Active Directory environment involves a wide variety
of tasks that differ in nature, scope, impact, and sensitivity. For a comprehensive
list of administrative tasks involved in Active Directory service and data
management, see “Appendix A: Active Directory Administration Tasks” in “Best
Practices for Delegating Active Directory Administration: Appendices,” which
accompanies this document. This list is organized into service and data
management categories. These categories are further subdivided on the basis of
logical similarities between tasks. For an overview of these categories, see
“Chapter 3: Delegating Service Management” and “Chapter 4: Delegating Data
Management” later in this document. Each task in every category maps to an
administrative role. In this way, all administrative tasks are covered by the set of
Microsoft-recommended administrative roles. The sum of all categories and their
related tasks provides full service and data administrative coverage for an Active
Directory environment. Thus, the entire realm of Active Directory service and
data management tasks can be assigned according to pre-defined management
roles. You can also customize the existing roles and define new ones tailored to
your organization.
A roles-based approach to Active Directory administration offers multiple
benefits. It makes management more tractable and provides the ability to
implement uniform administrative coverage that addresses similar administrative
needs across the organization. It also provides the ability to easily and reliably
delegate responsibility to, and subsequently revoke delegated responsibility
from, a set of administrators. This approach eliminates the need to specify
multiple sets of permissions across a large set of objects.
The following sections provide guidance on how a roles-based approach can be
used to create, implement, and maintain a security-conscious and efficient Active
Directory delegation model for managing an Active Directory environment.
Understanding Active Directory Management
A good understanding of both service management and data management is
essential to creating an administrative delegation model that efficiently
distributes administrative responsibility in accordance with your organization’s
security policies.
Service owners and service administrators are highly encouraged to gain a
thorough understanding of all aspects of service management and should gain at
least a good understanding of data management.
Data owners are highly encouraged to gain a complete and thorough
understanding of all aspects of data management. Data administrators are
encouraged to gain a good understanding of all aspects of data management
relevant to their administrative role and required to carry out their assigned
administrative responsibilities.
For an end-to-end perspective of all aspects of data and service management, see
“Chapter 3: Delegating Service Management” and “Chapter 4: Delegating Data
Management” later in this document.
 15

Understanding the administrative needs of stakeholders

It is important to identify all stakeholders that have a legitimate business need to
access and/or modify data stored in or protected by Active Directory. These
stakeholders generally include owners and administrators of other parts of the IT
infrastructure, who own, manage or are responsible for aspects of the IT
infrastructure that are related to or dependent on the organization’s Active
Directory environment. Administrators of an Active Directory–enabled or Active
Directory–integrated application or Corporate Security personnel are two
examples of such stakeholders.
Understanding and documenting the access requirements of these stakeholders
will help in determining the minimal set of permissions required to authorize
access to or delegate administrative authority to these stakeholders, which will
allow you to delegate administrative responsibility based on the principle of least
privilege.

Creating a Delegation Model

The service and data owners are collectively responsible for the creation of an
administrative model that efficiently distributes responsibilities among various
administrative groups, within their organization’s specific structural, operational,
legal, and administrative constraints. After having gained a clear understanding
of the full range of administrative tasks and responsibilities involved in
managing Active Directory, they should create a delegation model taking into
account specific administrative needs related to service and data management.
An Active Directory environment typically has one service owner, and one or
more data owners for every participating entity. Because service owners are
ultimately responsible for ensuring the secure and reliable delivery of the
directory service, they are responsible for creating an administrative delegation
model that distributes and delegates all service administrative responsibilities
among service administrators.
Similarly, because data owners are ultimately responsible for managing entity
content that is stored in or protected by Active Directory, they are responsible for
creating an administrative delegation model that distributes and delegates all data
administrative responsibilities that are required to manage content for their
entity.
In some cases, participating entities might choose to delegate certain aspects of
data management to a centralized group of administrators or to a group of
administrators that has collective representation from all entities. In such cases,
data owners from all participating entities must collaborate in creating the overall
administrative delegation model for data management.
Guidelines for Creating the Delegation Model
The process of creating a delegation model essentially involves understanding
the various aspects of Active Directory that need to be managed, identifying
specific administrative needs of all participating business units and stakeholders,
and then mapping these needs to a set of administrative roles that together
16

provide administrative coverage for all aspects of your Active Directory

environment.
Your organization might choose to define its own custom roles for Active
Directory management, which could be based in part on Microsoft recommended
roles, or your organization might choose to create a delegation model based
purely on Microsoft recommended roles. The creation of the delegation model
involves determining how many instances of each role the organization will
require (based on the guidance provided in the role description) to provide
administrative coverage for all aspects of your Active Directory environment,
taking into account specific administrative needs.
A good delegation model has the following attributes:
• Provides coverage for all aspects of Active Directory management
• Meets unique autonomy and isolation requirements
• Efficiently distributes administrative responsibilities
• Delegates administrative responsibilities in a security-conscious manner

Implementing the Delegation Model

Implementation of the delegation model created by owners is entrusted to a small
subset of the most highly trusted and skilled administrators. These administrators
are also usually responsible for maintaining the model subsequent to its
implementation. Typically, these administrators also assist the owners in creating
the administrative delegation model. These administrators are responsible for
rolling out the delegation model to enable all role instances for service and data
management, as defined in the delegation model for service and data
management.
The service management delegation model should be implemented by Enterprise
Administrators. Once the service management delegation model is in place, the
use of administrative accounts that are highly-privileged by default will be
minimized, resulting in a much lower possibility of inadvertent damage by
administrators who are logged on with higher credentials than are required for
the task they are performing. In addition, having fewer service administrators
will substantially lower the chance of inadvertent or malicious damage to the
directory service.
After the service management delegation model is in place, service
administrators should hand off data-management to a small, highly trusted subset
of data-administrators. The data owners for each participating entity in the
organization designate a small subset of their most highly trusted data
administrators to represent the data owners. These data administrators should in
turn be responsible for implementing the data management delegation model
which will involve delegating administrative responsibility for data management
to lesser privileged data administrators based on administrative roles.
As part of implementing the delegation model, this small subset of data
administrators is also responsible for designing an OU structure that will enable
 17

them to delegate administrative responsibility, taking into account administrative

requirements and Group Policy application requirements. These data
administrators design and propose an OU structure to the data owners. After
obtaining approval, the data administrators implement the OU structure and
implement the various data management role instances as required. This small,
highly trusted subset of data administrators who implement the data management
delegation model will also responsible for maintaining the implemented
delegation model.
Depending on the administrative needs of your organization, delegated
administrators might be given the authority to sub-delegate specific aspects of
data management within their scope of administrative authority.
Implementing a delegation model requires an understanding of how delegation of
administration actually works in active Directory. For more information about
the details of Active Directory delegation of administration, see “Chapter Two:
How Delegation Works in Active Directory” later in this document.
A well-implemented delegation model ensures that:
• Only delegated administrators can perform the assigned tasks.
• Delegated administrators can perform only the tasks that are assigned and
explicitly delegated to them.
Guidelines for Implementing the Delegation Model
The following recommendations can be used to guide the creation of a good
implementation:
• Represent every instance of every administrative role with a unique security
group.
• Use security groups that represent roles for the sole purpose of delegating the
roles. Do not use these security groups for other purposes. For example, do
not use the security group to authorize access to other resources in the
domain that are not associated with the ability to perform the administrative
role.
• When delegating data management, as far as possible, delegate permissions
only on OUs, which are provided specifically to facilitate delegation of
administration. Delegating permissions on OUs enables them to be easily and
reliably revoked.
• Unless absolutely required, do not specify permissions on individual objects
within an OU.
• To delegate a role, grant permissions sufficient only to perform the set of
administrative tasks assigned to the role
For more information about how to implement a delegation model for service
and data administration, see “Chapter 3: Delegating Service Management” and
“Chapter 4: Delegating Data Management” later in this document.
18

Maintaining the Delegation Model

Once the service and data management delegation models have been
implemented, all delegated administrators and stakeholders should be able to
carry out all assigned administrative tasks.
A well-planned and well-implemented delegation model will minimize the need
for much maintenance. However, over time, changes in administrative needs and
workforce changes might necessitate appropriate changes to the administrative
delegation model. Maintenance of the delegation model involves taking these
developments into account and making appropriate changes.
For each management category, service or data administrators might need to:
• Modify and/or re-delegate existing roles. For example, you might need to add
a new task to a role definition or to a specific instance of the role.
• Create and delegate customized roles. You might need to create and delegate
new roles that complement or supplement existing roles but that were not
included in the original delegation model.
• Remove delegation of existing roles. For example, you might need to remove
a user from an administrative role, which involves simply removing the user
from the administrative group. Alternatively, you might need to revoke a
specific capability of the role, or the entire role, which involves removing all
of the permissions that are delegated for either that capability (task) or for the
entire role.

Note
You can use a script or the command-line
tool Dsrevoke.exe to remove all permissions
for a group or user in the DACLs of all OU
objects in a specified scope. For more
information about using Dsrevoke.exe, see
“Appendix G: Active Directory Delegation
Tools” in “Best Practices for Delegating
Active Directory Administration:
Appendices,” which accompanies this
document.
For more information about maintaining service and data delegation models, see
“Chapter 3: Delegating Service Management” and “Chapter 4: Delegating Data
Management” later in this document.
 19

Chapter 2: How Delegation Works in Active Directory

This chapter provides an in-depth understanding of how delegation works in
Active Directory. Understanding how delegation works helps you to create,
implement, and maintain an efficient and security-conscious delegation model. It
helps to you address the needs of your stakeholders when you delegate
administrative authority to, or authorize access for, any stakeholder. Finally, a
better understanding of how delegation works helps you to make better informed
design decisions, taking into account the technical capabilities and issues
involved in delegating administrative authority.

Overview
Through delegation of administration, responsibility for administrative tasks is
transferred to the administrators who must perform the respective tasks, and to
no one else. From a technical perspective, delegation of administration involves
a higher-level administrator granting a controlled set of permissions to a
relatively lower-level administrator to give the lower-level administrator the
ability to perform a specific administrative task. In other words, a higher-level
administrator authorizes the delegated lower-level administrator to carry out a
specific administrative task.
Every administrative task involves effecting a change to the state of some data,
and changing the state of data involves performing a low-level operation on the
object that stores that data. As mentioned earlier in this document, there are two
major categories of administrative tasks in Active Directory – data management
asks and service management tasks:
• Data management tasks typically include such tasks as creating and
managing user and computer accounts, security groups, and application-
specific data, all of which are stored in Active Directory. In certain cases, a
small subset of tasks might involve the modification of Group Policy settings
to affect the configuration state of member computers. Creation of user
accounts and modification of group memberships are both examples of data
management tasks.
• Service management tasks include tasks that are related to the creation and
maintenance of Active Directory configuration data. For example, adding a
domain controller to a child domain, associating a new subnet to a site, and
extending the Active Directory schema are all Active Directory service
management administrative tasks that effect changes to configuration data. A
majority of Active Directory configuration data is stored in Active Directory
itself. However, certain aspects of Active Directory behavior can or must be
configured on a domain controller. The configuration data that is associated
with these tasks might be stored in the registry or file system of domain
controllers.
Thus, data and service management administration tasks primarily involve
effecting the change of data that is stored either in Active Directory, or in some
20

cases on the file system or registry of Domain Controllers and other computers
joined to Active Directory.
Every administrative task effects a change to the state of some data, and
changing the state of data involves performing a low-level operation on some
data represented by an object in the directory (or in some cases by an object on
the file system or registry of a computer or Domain Controller). For example, the
administrative task of resetting a user’s password involves a low-level write
operation on an attribute of the user object. Similarly, creating a new site
involves creating a corresponding site object. Similarly, modifying the level of
detail logged for security events involves modifying a registry key (data) on
Domain Controllers. These low-level operations that constitute an administrative
task typically involve creation, deletion, access to, modification of, or
verification of data.
All data stored in Active Directory is represented by directory objects, each of
which can be individually secured. Similarly, all data stored on the file system on
computers and in their registries is also represented by individually securable
objects. Individually securable refers to the fact that all low-level operations on
data (represented by objects) can be individually authorized. In other words, an
administrator can specify who can do what on every specific unit of data.
Since every Active Directory administrative task involves affecting the state of
some data by means of a low-level operation, and since all data can be
individually secured to allow or deny someone the ability to perform a low-level
operation on that data, it follows that the ability to carry out every administrative
task can be controlled by controlling the appropriate permissions that authorize
the execution of the corresponding low-level operation on the target data that is
involved in the administrative task.
Thus, by being able to individually authorize every low-level operation on data,
administrators can in effect authorize all administrative tasks that involve low-
level operations. Since all administrative tasks involve at least one low-level
operation, it follows that all administrative tasks can be individually authorized.
Since delegation involves a higher-level administrator authorizing the delegated
lower-level administrator to carry out a specific administrative task, every
administrative task in Active Directory can be delegated by controlling the
permissions required to perform the low-level operation involved in the
administrative task.
In summary:
• Delegation involves granting a controlled set of permissions to someone so
that can carry out an administrative task.
• Every administrative task involves performing some low-level operation on
data.
• Low-level operations on data can be (individually) authorized.
• By being able to authorize the corresponding low-level task, you can delegate
a task.
 21

The following example illustrates the crux of how delegation works in Active
Directory. Let us consider a day in the life of David Hamilton, a marketing
associate with Contoso Pharmaceuticals.
David Hamilton recently joined the company. When he joined the company, a
user account was created for him under the Business Division OU by the
Account Admins for the Business Division of the company. The creation of the
user account involved a create operation for an object of class User under the
parent object, which in this case happened to be the OU object for the Business
Division. Since the Account Admins had Create Child permissions on this OU,
they were able to create the account.
Once the account was created, David could log on to the Active Directory
domain and go about performing his assigned responsibilities. One day, David
forgot his password and thus could not log on. He then called the Help Desk for
help. Jeff Price, a member of the Help Desk operators group, received the call
and reset David’s password after verifying David’s identity. The reset password
operation involved modifying password related attributes on David’s user
account object and required that the Reset Password extended right on David’s
user account object be granted to the individual who should be able to reset
David’s password. During the implementation of the delegation model, the Help
Desk operators group, of which Jeff was a member, was granted this extended
right on all users in the domain. Thus, Jeff was authorized to reset David’s
password.
Within six months of employment, David was promoted to the position of senior
marketing associate and now reported to a new manager. Michelle Alexander, a
Contoso employee in the Human Resources department, needed to appropriately
update David’s manager information as stored on David’s user account in Active
Directory. Modifying a user’s manager information requires a low-level
operation involving the modification of the Manager attribute on user account
objects, and requires write-property permissions to the Manager attribute to
succeed. Account Admins had granted a group called Human Resources
Personnel, of which Michelle was a member, write-property permissions to
modify the manager attribute on all user objects. Michelle was thus able to
update David’s account by appropriately changing David’s manager information.
After one year with the company, David was offered a promotion and a new job
in the Research and Development (RandD) Division of the company. His user
account now needs to be moved to the OU for the RandD Division. Moving an
object involves multiple low-level operations, including the deletion of the object
from under its current parent object, the creation of a new object under the new
parent object, and the modification of the Common-Name and relative
distinguished name attributes on the object. (Note that technically the object is
not deleted – it only seems that it is deleted and re-created.) Michael Allen, a
member of the overall account management team for Contoso (which has
membership in the Contoso Account Admins group) was asked to move the
object between the two OUs. The Contoso Account Admins group is granted
sufficient permissions on both the source and target OUs to enable its members
to carry out object moves. Michael thus has the required Delete Child
22

permissions to carry out the low-level delete operation on the Business OU and
Create Child permissions to carry out the low-level create operation on the
RandD OU, and additionally has write-all-properties permissions on the user
object and was thus able to carry out the move operation for David’s user
account.

Active Directory Administrative Tasks

As mentioned earlier, Active Directory management can be separated into
service and data management.
Data management includes such tasks as creating and managing user and
computer accounts, security groups, and application-specific data, all of which
are stored in Active Directory. In certain cases, a small subset of tasks might
involve the modification of Group Policy settings to affect the configuration state
of member computers. Creation of user accounts and modification of group
memberships are both examples of data management tasks.
Data management tasks include, but are not limited to, managing the following
Active Directory content:
• User accounts, which represent the identities of people who use the network
• Computer accounts, which represent the computers that are joined to
domains in the Active Directory forest
• Security groups, which are used to aggregate accounts for the purpose of
authorizing access to resources
• Application-specific attributes for Active Directory–enabled and –integrated
applications, such as Microsoft Exchange and Microsoft Office Live
Communications Server 2003
Service management tasks are tasks that are related to the creation and
maintenance of Active Directory configuration data. For example, adding a
domain controller to a child domain, associating a new subnet to a site, and
extending the Active Directory schema are all Active Directory service
management administrative tasks that effect changes to configuration data. A
majority of Active Directory configuration data is stored in Active Directory
itself. However, certain aspects of Active Directory behavior can or must be
configured on a domain controller. The configuration data that is associated with
these tasks might be stored in the registry or file system of domain controllers.
Service management includes, but is not limited to, the following administrative
tasks:
• Adding and removing domain controllers
• Managing and monitoring replication
• Ensuring the proper assignment and configuration of operations master roles
• Performing regular backups of the directory database
 23

• Configuring forest-wide Lightweight Directory Access Protocol (LDAP)

settings
• Managing domain and domain controller security policies
• Configuring directory service parameters, such as setting the functional level
of a forest or putting the directory in the special List-Object security mode
For a comprehensive list of administrative tasks involved in Active Directory
service and data management, see “Appendix A: Active Directory Administrative
Tasks” in “Best Practices for Delegating Active Directory Administration:
Appendices,” which accompanies this document. For an overview of the
categories of administrative tasks, see “Chapter 3: Delegating Service
Management” and “Chapter 4: Delegating Data Management” later in this
document.

Active Directory Logical Structure and Data Storage

Effective delegation of Active Directory management tasks requires that you
understand the nature of Active Directory data and where the data is stored.
Since delegation of administration involves authorizing the ability to perform
low-level operations on data, understanding where the data on which these
operations is stored is essential to authorizing the ability to perform low-level
operations on this data. This section provides descriptions of the major logical
components of Active Directory as well as descriptions and locations of the top-
level domain and configuration containers.

Forests and Domains

An Active Directory forest represents an instance of Active Directory. A forest is
a collection of one or more domains with a shared configuration and schema,
represented by a single logical global catalog, and connected by a spanning tree
of transitive trusts. From a data perspective, Active Directory stores data for an
entire forest. “Directory” and “forest” can be considered as synonymous.
Although there is a single directory, data storage is distributed among one or
more domains. Servers that host the Active Directory directory service are called
domain controllers.

Directory Partitions
In Active Directory, data storage is partitioned into logical segments called
directory partitions, and each directory partition replicates its changes separately
among those domain controllers in the forest that store copies (replicas) of the
same directory partitions.
One specific directory partition stores forest-wide configuration information
essential to the proper functioning of the forest. Another specific directory
partition stores the Active Directory schema. Other directory partitions store
information, such as users, groups, and OUs, that is specific to individual
domains. Directory partitions that store domain information are replicated to
domain controllers in that domain only. Directory partitions that store
24

configuration and schema information are replicated to domain controllers in all

domains. In this way, Active Directory provides a data repository that is logically
centralized but physically distributed.

Note
There is a distinction between a directory partition and a
database partition. The Active Directory database is not
partitioned. Only the directory tree, which is the logical
representation of the data that is stored on a domain
controller, is partitioned.

Because all domain controllers store forest-wide configuration and schema

information, a domain controller in one domain can reference a domain
controller in any other domain if the information that a user requests is not stored
locally. In addition, domain controllers that are global catalog servers store a full
replica of one domain directory partition plus a partial replica of every other
domain in the forest. Thus, a domain controller that is a global catalog server can
be queried to find any object in the forest.
Configuration Directory Partition
There is only one configuration directory partition per forest, and it stores forest-
wide configuration data that is required for the proper functioning of Active
Directory as a directory service. For example, all information required to ensure
the proper functioning of replication is stored in the configuration partition,
which also houses information pertaining to the site topology. Information that
Active Directory uses to construct the directory tree hierarchy is also stored in
the configuration directory partition, as is network-wide, service-specific
information that applications use to connect to instances of services in the forest.
Every domain controller has one fully writeable copy of the configuration
directory partition.
Schema Directory Partition
Similarly, there is only one schema directory partition per forest. The schema
directory partition contains the definitions of all objects that can be instantiated
in Active Directory. It also stores the definitions of all attributes that can be a part
of objects in Active Directory. Every domain controller has one fully writeable
copy of the schema directory partition, although schema updates are allowed
only on the domain controller that is the schema operations master.
The schema directory partition root object contains one child object for each
class of objects that can be instantiated in the Active Directory forest and
contains one object for each attribute that can be part of an object in the Active
Directory forest.
Domain Directory Partitions
Every domain is represented by a domain directory partition. The domain
directory partition stores users, computers, groups, and other objects for that
domain. All domain controllers that are joined to the domain share a full
 25

writeable copy of the domain directory partition. Additionally, all domain

controllers in the forest that host the global catalog also host a partial read-only
copy of every other domain directory partition in the forest. For the most part,
domain directory partitions store domain content – that is, user, group, and
computer information. However, some domain-specific configuration data is also
stored in the System container of the domain directory partition.

Active Directory Hierarchy

Every Active Directory object can be referenced by a unique and unambiguous
name known as a distinguished name (also known as a DN). The distinguished
name identifies the complete path through the container hierarchy by which the
object is reached.
Every forest has one configuration directory partition, one schema directory
partition, and at least one domain directory partition that represents the forest
root domain. Every additional domain that belongs to a forest adds one domain
directory partition to the forest.
The three default Active Directory partitions have the following distinguished
names:
• Forest-root domain directory partition: DC=ForestRootDomain
• Configuration directory partition: CN=configuration,DC=ForestRootDomain
• Schema directory partition:
CN=schema,CN=configuration,DC=ForestRootDomain
For more information about the default container hierarchy of all Active
Directory partitions, see “Appendix I: Default Container Hierarchy for Active
Directory Partitions” in “Best Practices for Delegating Active Directory
Administration: Appendices,” which accompanies this document.

Data Storage From a Management Perspective

From a management perspective, it is helpful to identify where configuration
data is stored in Active Directory and where domain content is stored. This
information is essential in delegating administration because it helps identify
where permissions need to be specified to delegate service and data
administration tasks.
Location of Active Directory Service Configuration Data
Active Directory stores service configuration data primarily in the configuration
directory partition. From a service management perspective, schema
management is also a part of service management and therefore the schema,
which is stored in the schema directory partition, is also a part of configuration
data. Additionally, certain domain-specific configuration settings are also stored
in the System container in the domain directory partition, and thus this data is
also a part of configuration data. Finally, because some domain controller-
specific configuration data is stored in the registry and the file system on domain
controllers, this data is also a part of service configuration data.
26

From a management perspective, configuration data can be found in the

following places:
• Configuration directory partition
• Schema directory partition
• System container in domain directory partitions
• File system and registry on domain controllers
Location of Active Directory Content
Active Directory content is stored in domain directory partitions. Content in
directory partitions is typically stored in one of two kinds of containers – objects
of a generic object class container and objects of a special-purpose object class
called organizationalUnit as defined in the schema. Objects of the generic class
container are ordinary containers and are also used in the Configuration partition.
Objects of the class OrganizationalUnit are intended to be the primary containers
for domain content such as user, computer, and group accounts.
OUs differ from regular containers in that unlike regular container objects, OUs
can have Group Policy applied to them. The Group Policy distribution
mechanism ensures that a Group Policy object that is applied to an OU applies
directly to all users and computers in the OU and, by inheritance, to all users and
computers in OUs (and in generic Active Directory containers) further down the
Active Directory subtree rooted at an OU.
In addition to OUs, certain default Active Directory containers also contain
domain content. These containers are created during installation and contain
default administrative groups, users and other required data. The Builtin
container stores built-in groups. The Users container is the default storage area
for new user accounts that are created through legacy APIs that are not Active
Directory–aware. The Computers container is the default storage area for new
computer objects that were originally created through legacy APIs that are not
Active Directory–aware
From a management perspective, Active Directory content can be found in the
following places:
• OUs in domain directory partitions
• Builtin container in directory domain partitions
• Users container in directory domain partitions
• Computers container in directory domain partitions

Delegation and Access Control

Access control is the means by which administrators can control, or delegate, the
ability of other users to manipulate objects in Active Directory and also to
perform actions on domain controllers and file servers. Understanding the
access-control model in Active Directory is essential to being able to delegate
administration. This section provides an overview of the access control model in
 27

Active Directory and describes all relevant aspects of access control that are
required to delegate administrative authority.
Access control involves three components:
• The security credentials of the user attempting to access a resource
• Authorization data that protects the resource that is being accessed
• An access check that evaluates whether or not the requested access can be
granted
When a user (or a process that is running on behalf of the user) attempts to
perform a low-level operation on a securable object, the operation being
attempted is subject to an access check. The access check takes into account the
user security credentials and the authorization data on the object on which the
low-level operation is being requested to determine the abilities of the user in
relation to the respective object. If the access check determines that the security
credentials of the user requesting the operation and the authorization data on the
target object provides sufficient permissions to execute the operation, the
operation succeeds. If the user has insufficient permissions to execute the
operation that is being requested, the request fails.
The act of delegating Active Directory administrative responsibilities involves
identifying the low-level operation that corresponds to the administrative task
and the specific data on which it is being performed, and then appropriately
modifying authorization settings that protect the data.

Characteristics of the Access Control Model

As in Windows NT 4.0, the access-control model in Windows 2000 and
Windows Server 2003 has the following characteristics:
User-based authorization
Provides the ability of a system to identify a user and match that user to access
criteria for a resource. Any resource that can be manipulated by a program or
process is represented as a securable object. When a user (or a process running
on behalf of the user) attempts to perform an operation on a securable object, the
operation being attempted is subject to an access check and is only allowed to
succeed if the user performing the operation has been authorized to perform this
operation on the object in question.
Discretionary access to securable objects
Provides the ability to specify the users who have access to an object, and to
specify the access criteria. Every securable object has an owner. The owner is the
only security principal who has an inherent right to allow or deny permission to
gain access to an object. The first owner of an object is usually the security
principal that is associated with the thread that created the object. An object’s
owner can transfer ownership by giving permission to take ownership to another
security principal. Additionally, any security principal who has been granted the
privilege to take ownership of files or other objects on the computer can take
ownership of any object on the computer.
28

Inheritance of permissions
Allows administrators to easily assign and manage permissions for a large
collection of objects. This feature allows administrators to specify permissions
that can be applied automatically to all objects contained within a container by
having the specified permissions be inherited by all child objects in the container.
Administrative privileges
Allow an administrator of a computer system to control which users have the
right to perform various administrative functions, or to take any action that
affects system-wide resources. There are two types of administrative privileges –
user rights and privileges. User rights control the various ways in which users
can log on to a system. Privileges control a user’s ability to perform a specific
task, usually one that affects the entire computer system rather than a particular
object.
Auditing
Enables the tracking of user or system activity by recording specific (specifiable)
types of actions in security logs. Audit data can be used to detect attempts to
circumvent protections on resources and to create a record of administrative
actions on the computer system.
Low-level operations
As mentioned earlier, every administrative task involves some low-level
operation on data. An understanding of the various kinds of low-level operations
helps to understand the details of how an administrative task works.
The following are the low-level operations can be performed on data:
• Create an object. This low-level operation involves the creation of a new
object in Active Directory. For example, the administrative task of creating a
new user account involves a low-level operation of creating an object of class
User under some parent object in Active Directory
• View an object or all child objects of a specific object. This low-level
operation involves being able to view or see an object in Active Directory.
For example, when using one or more Active Directory administration tools,
viewing the contents of an OU or a domain involves performing multiple
low-level operations (one for each object displayed) to view objects in Active
Directory.
• Read object attributes. This low-level operation involves accessing and
reading the values of one or more attributes on an Active Directory object.
For example, any administrative task involving reading some information on
a user (for example, phone number or name) involves a low-level read
operation on one or more attributes (also referred to as a property) of the user
object representing the user’s account.
 29

• Modify object attributes. This low-level operation involves accessing and

modifying the values of one or more attributes on an Active Directory object.
For example, any administrative task involving modifying some information
on a user object (such as telephone number or office location) involves a low-
level modify operation. Changing a user’s password involves performing a
low-level modify operation modifying the password attribute of the user
object corresponding to the user’s account. Similarly, modifying the
association of a subnet to a specific Active Directory logical site involves a
low-level operation modifying the siteobject attribute on the objects
representing that specific subnet.
• Read the security descriptor of an object. Every securable object is protected
by a security descriptor which is stored as an integral part of that object and,
for Active Directory objects, is represented by the NTSecurity-Descriptor
attribute. The security descriptor contains among other information, a list of
access control entries specifying who can perform what low-level operations
on an object. Any administrative task involving viewing or changing
permissions involves the low-level operation of reading the security
descriptor of an object. For example, the administrative task of determining
who can modify a group’s membership involves a low-level operation that
reads the security-descriptor of the corresponding group object.

Note
An administrative task involving changing
permissions also involves the low-level
operation of modifying the access-control
list stored as part of the security descriptor,
as described in “Modify the access control
list protecting the object” later in this
document.
• Modify the access control list protecting the object. The security descriptor
contains, among other information, a list of access control entries specifying
who can perform what low-level operation on an object. Any administrative
task involving viewing or changing permissions involves the low-level
operation of reading and modifying the access control list stored in the
security descriptor of an object. For example, the administrative task of
delegating another administrative task or authorizing a user access to some
object involves the low-level operation of reading the security descriptor and
modifying the access-control list stored in the security-descriptor of the
corresponding object.
• Modify the owner of an object. Every securable object has an owner. The
owner of an object has the inherent ability to modify the access control list of
the object and to transfer the ownership. The identity of an object’s owner is
also stored in the security descriptor of the object. The administrative tasks of
taking ownership of an object or transferring ownership of an object involve
the low-level operation of modifying the owner of the object.
30

• Delete an object or delete an entire subtree of objects. This low-level

operation involves the deletion of an existing object from Active Directory.
For example, the administrative task of deleting an existing user account
involves a low-level operation of deleting the user class object representing
the user’s account from Active Directory.

Active Directory Permissions and Other Access Rights

Delegating an administrative task involves granting to the delegated
administrator the appropriate permissions that are required to perform the low-
level operations that the administrative tasks involve. Therefore, understanding
the various permissions that control low-level operations is essential to
delegating administration.
Active Directory permissions control who can do what on objects in Active
Directory. These permissions can be separated into two broad categories –
standard permissions and special permissions. Standard permissions control the
standard operations that can be performed on objects in Active Directory, such as
creating and deleting child objects, or reading and writing the object properties.
However, certain Active Directory administrative operations require access to be
controlled in a way that is not supported by the standard permissions. To
facilitate these operations, Active Directory allows the standard access control
mechanism to be extended through special permissions that control specific
Active Directory administrative tasks.
In addition to requiring permissions that control low-level operations on Active
Directory data, certain administrative tasks involve the ability to perform specific
actions on domain controllers (or in some cases on member workstations). User
rights can be specified that allow these actions. User rights are different from
permissions in that they control the various ways in which a user can log on to a
computer. User rights also control the user’s ability to perform specific
operations that typically have a system-wide effect.
Standard Permissions
Permissions regulate which users can gain access to an object (an Active
Directory object or a file system folder or file) and in what manner.

Note
Active Directory applies default security settings that are
designed to provide an out-of-the-box security configuration.
These security settings grant specific pre-configured
permissions to specific security groups that are created by
default.

The following standard permissions control the ability to perform the indicated
low-level operations:
• Create Child. The right to create children of the object.
• Delete Child. The right to delete children of the object.
 31

• Delete. The right to delete the object.

• Delete Tree. The right to delete all children of the object, regardless of the
permissions on the children.
• Read Permissions. The right to read data from the security descriptor of the
object, not including the data in the system access control list (SACL).
• Modify Permissions. The right to modify the discretionary access control list
(DACL) in the object security descriptor.
• Modify Owner. The right to assume ownership of the object.
• Read Property. The right to read properties of the object.
• Write Property, The right to write properties on the object.
• List Child. The right to list children of the object.
• List Object. The right to list a particular object. If the user is not granted such
a right, and the user does not have List Child set on the object parent, the
object is hidden from the user.

Note
This right is ignored if the third character of
the dSHeuristics attribute of the object has
a value of 0 or is not set. For more
information about this right, see
“Controlling Object Visibility” on the Web at
http://go.microsoft.com/fwlink/?LinkID=1982
8.
• Access System Security. The right to get or set the SACL in the object
security descriptor
For a detailed description of the standard Active Directory permissions, see
“Appendix C: Active Directory Standard Permissions” in “Best Practices for
Delegating Active Directory Administration: Appendices,” which accompanies
this document.
Special Permissions
In addition to the standard set of permissions that are applied in the DACLs of
Active Directory objects, other permissions are available to accommodate special
requirements that are not supported by the standard permissions. These
permissions fall into two categories:
• Validated writes
• Extended rights
Validated Writes
Certain administrative operations in Active Directory require that, before writing
a value to a property on an Active Directory object, the system perform value
checking, or validation, beyond that which is required by the schema. Validated
writes are a special type of permission that facilitates the ability to perform
32

validation prior to modifying a property on an Active Directory object. This type

of permission ensures that the value that is entered for the property conforms to
required semantics, is within a legal range of values, or undergoes some other
special checking that would not be performed for a simple low-level write to the
property. A validated write is associated with a special permission that is distinct
from the Write propertyName permission. The Write propertyName permission
allows any value to be written to the property with no value checking.
Extended Rights
Extended rights provide the ability to perform access checks on operations that
have some special significance in Active Directory and that are not covered by
the standard set of access rights. For example, the User class can be granted a
Send As right that can be used by a mail application to determine whether a
particular user can allow another user to send mail on his or her behalf. To
facilitate these special requirements, Active Directory extends the standard
access control mechanism through the controlAccessRight class of objects.
These objects are called extended rights.
Instances of the controlAccessRight class are created by the system. These
objects are stored in CN=Extended-
Rights,CN=Configuration,DC=ForestRootDomain. Rather than being
administratively set, properties of these objects automatically identify the type of
access in the DACL of the appropriate object.
For a list of all extended rights, see “Appendix D: Active Directory Extended
Rights” in “Best Practices for Delegating Active Directory Administration:
Appendices,” which accompanies this document.
Property Sets and Extended Rights
Active Directory also uses the controlAccessRight class of objects to represent
property sets. A property set is a subset of an object’s properties. For example,
the Personal-Information property set includes properties such as street address
and telephone number, both of which are properties of user objects. Property sets
are useful because they provide the means to specify access to a subset of
properties in a single ACE.
Existing documentation about control access rights might seem to suggest that
property sets are extended rights or are closely related to extended rights.
However, property sets are not related to extended rights in any way other than
the fact that they are represented in the system by the same class of objects.
User Rights
User rights are abilities to perform operations on a computer system. User rights
apply on every Windows-based computer, independent of Active Directory
membership. User rights are essential to service management on domain
controllers.
User rights differ from permissions in that permissions control access to
individual objects, whereas user rights control the various ways in which users
can log on to a system. They also control specific operations that have a system-
 33

wide effect on a computer. In the case of user rights on domain controllers, the
effect is on Active Directory, and thus on the entire domain.
User rights are set in the local policy on a computer. User rights are set in
Domain Controller Security Policy for rights on domain controllers, and in
Domain Security Policy for rights on all other computers in the domain. User
rights for computers that are joined to the domain can also be specified by using
Group Policy linked to OUs. User rights for all domain controllers in a domain
are specified in the Default Domain Controllers Policy Group Policy object
(GPO), which is applied to the Domain Controllers OU. Thus, all domain
controllers in a domain share the same set of user rights assignments.

Note
Although the system permits the specification of different user
rights values for different domain controllers in a domain, this
configuration is not supported. By design, all domain
controllers in the same domain are expected to have identical
user rights values.

User rights are of two types:

• Privilege. Specifies a user’s right to perform a specific task, usually one that
affects an entire computer system.
• Logon right. Specifies the way in which a user can log on to a system. For
example, a user might have the right to log on to a system remotely, but not
locally.
Administrators can assign specific rights to security group accounts or to
individual user accounts. These rights authorize users to perform specific actions,
such as logging on to a system interactively or backing up files and directories.
User rights define capabilities at the local level. Although user rights can apply to
individual user accounts, user rights are best administered to group accounts.
Doing so ensures that a user who logs on as a member of a group automatically
receives the rights that are associated with that group. By assigning user rights to
groups rather than to individual users, you simplify the task of managing user
rights assignments.
User rights that are assigned to a group are applied to all members of the group
as long as they remain members. If a user is a member of multiple groups, the
user’s rights are cumulative, which means that the user has more than one set of
rights. The only time that rights assigned to one group might conflict with those
assigned to another group is in the case of certain logon rights. In general, user
rights that are assigned to one group do not conflict with the rights assigned to
another group. To remove rights from a user, the administrator simply removes
the user from the group.
For more information about user rights, see “Appendix C - User Rights and
Privileges” in the Microsoft Windows 2000 Security Configuration Guide on the
Web at http://go.microsoft.com/fwlink/?LinkID=19829, and “Chapter 4 - User
34

Rights Assignment” in the Threats and Countermeasures Guide on the Web at

http://go.microsoft.com/fwlink/?LinkID=19830.

Components of an Access Check

All data that is stored in Active Directory is represented by objects, each of
which can be individually or collectively secured. Being secured means that
when a user or a process that is running on behalf of the user attempts to perform
an operation on an Active Directory object, the security system checks to
determine whether the user or process has legitimate access to the requested
object before granting the requested access.
The access check takes into account the following:
• Credentials of the security principal that is requesting the operation
• Authorization data on the target resource, which is stored in the properties of
the securable object
The access check is performed by the local security subsystem of the computer
on which the requested resource is stored. The access check compares the user’s
security credentials against the authorization data to determine the abilities of the
user on the respective object. If the access check determines that the
authorization data of the user or process that is requesting the operation includes
sufficient permissions to execute the operation, the operation succeeds. If the
user has insufficient permissions to execute the operation that is being requested,
the operation fails.

Security Principal Credentials

Any entity that can be authenticated by the system is referred to as a security
principal. Thus, a security principal could be a user, a computer, or a thread or
process that runs in the security context of a user or a computer. A security
context is information that describes a particular security principal’s identity and
capabilities on the computer. In Windows Server 2003, Windows 2000 Server,
and Windows NT, all activities take place in a security context. The security
subsystem uses the security context to determine what actions a process and its
threads of execution can perform on objects on the computer, and the identity of
the responsible security principal.
Security Identifier
A security principal is represented by a Security Identifier (SID), which is a
unique value that identifies that security principal. A SID is issued to every
security principal when it is created. Security groups are also security principals,
and therefore are uniquely identified by a SID. A user security principal can be a
member of multiple security groups. Consequently, a user’s credentials include
the SIDs of all groups of which the user is a member.
 35

Note
The exception to this rule is that the membership of a domain
local group that was created in Domain A does not appear in
the access token that is generated on a computer that is
joined to Domain B.

Access Token
A security principal’s security context is represented by an access token. When a
security principal logs on to a computer, the security subsystem on that computer
authenticates the security principal. After authentication, the security subsystem
creates an access token for the security principal. The access token is a data
structure that contains the SID for a security principal, SIDs for the groups that
the security principal belongs to (with the earlier-noted exception of domain
local groups from a different domain), and a list of the security principal’s
privileges (also known as user rights) on the local computer. An access token is
created for every security principal who logs on locally at the computer’s
keyboard, or remotely through a network connection.
The access token provides a security context for the security principal’s actions
on the computer to which the security principal is logged on. It is important to
note that when a user is logged on to a workstation and requests access to data in
Active Directory, a logon session is generated on the domain controller to which
the user binds, and a security context is generated for this user on the domain
controller. The access token that is created on the domain controller represents
the credentials of the user who is accessing Active Directory. Therefore, the
information in this access token, not information from the workstation to which
the user is logged on, is used by the access check.
For more information about SIDs, see “Access Control” in the Distributed
Systems Guide of the Windows 2000 Server Resource Kit, or see “Access
Control” on the Web at http://go.microsoft.com/fwlink/?LinkId=18852. For more
information about well-known SIDs, see “Appendix B: Default Active Directory
Security Groups” in “Best Practices for Delegating Active Directory
Administration: Appendices,” which accompanies this document.

Security Groups
Security groups are security principals that you can use to aggregate users into
categories and roles for the purpose of applying access control. Security groups
have scopes that define where they can be applied and membership requirements
that define the selection of members they can have and the groups of which they
can be members. The different types of security groups that are available and
whether or not they appear in a user’s access token is subject to the domain mode
(Windows 2000) and domain or forest functional level (Windows Server 2003)
that is in effect.
Security groups play a key role in delegation of administration. Security groups
are used to represent specific instances of administrative roles and contain as
members the user accounts of all delegated administrators who have been
36

assigned to the specific administrative role represented by this security group. An

understanding of the various types of security groups is thus beneficial in
implementing delegation, as the various security group types differ in their
scope, applicability, and uses.
There are four types of security groups, differing primarily in their application,
scopes, and membership criteria:
• Local groups (also referred to as Built-in groups)
• Domain Local groups
• Global groups
• Universal group
Group Scope
Using security groups effectively for delegation of administration requires a
strategy that makes use of the group scopes that are available in Active Directory.
The scope of a group identifies the extent (domain or forest) to which the group
can be applied:
• Domain local. A single domain; that is, domain local groups are visible for
administration in only the domain in which the group is created, and thus can
be assigned permissions on objects in only that domain. However, a domain
local group can have users and groups from its own domain and other
domains as members. For this reason, you can best use domain local groups
as resource groups to collect other groups that need the same level of access
to a resource. Rather than adding multiple groups to an ACL, add all the
groups to one domain local group and add only the domain local group to the
ACL for the target object.

Note
When specifying read access to specific
attributes of, or list access to, an Active
Directory domain object, do not use a
domain local group to set permissions if the
attribute or attributes are included in the
partial attribute set that is replicated to
global catalog servers. Instead, use a global
group.
• Global. All domains in a forest; that is, a global group is visible for
administration within its domain and all trusted domains and thus can be
assigned permissions on objects in all domains in the forest. Because global
groups have forest-wide visibility, they are best used to organize users or
groups of users into administrative roles.
 37

• Universal. All domains in a forest; that is, a universal group is visible for
administration within its domain and all trusted domains and thus can be
assigned permissions on objects in all domains in the forest. When multiple
roles require the same access to a resource, add global groups to a single
universal group and add the universal group to a domain local group for the
resource.
Group Scope Availability and Membership Rules
Group scopes vary according to functional conditions in the domain or forest.
Not all scopes are available under all conditions, and group membership is
subject to conditions in the domain or forest according to domain modes in
Windows 2000 forests and domain functional levels in Windows Server 2003. A
domain mode or functional level that indicates “mixed” provides functionality
that is consistent with Windows NT 4.0 domain controllers. For this reason,
features that are not compatible with Windows NT 4.0 are not available in mixed
domains.
The following rules limit the availability of group scopes:
• Domain local groups are always available.
• Global groups are always available.
• Universal groups are not available in:
• Windows 2000 mixed-mode domains.
• Windows Server 2003 domains that have a domain functional level of
Windows 2000 mixed.
The following rules limit the membership of security groups:
• Domain local groups:
• Can always contain individual user accounts and global groups from any
domain in the forest.
• Can also contain universal groups from any domain in the forest as well
as domain local groups from the same domain in Windows 2000 native-
mode domains or Windows Server 2003 domains that have a domain
functional level of Windows 2000 native or Windows Server 2003.
• Global groups:
• Can always contain users from the same domain.
• Can also contain global groups from the same domain in Windows 2000
native-mode domains or Windows Server 2003 domains that have a
domain functional level of Windows 2000 native or Windows
Server 2003.
• Universal groups, when available, can always contain user accounts, global
groups, and other universal groups from any domain in the forest.
For more information about group scope and membership rules, see Help and
Support Center for Windows Server 2003. For a list of the default administrative
38

groups that are created when Active Directory is installed, and their default
abilities, see “Appendix N: Default Active Directory Service Administrative
Groups” in “Best Practices for Delegating Active Directory Administration:
Appendices,” which accompanies this document.
Local Security Groups
Local groups can be used to grant access to local resources on a computer. As
such, each computer (workstation, server, or domain controller) that is running a
version of Windows has a set of default local group accounts. On domain
controllers, these security groups are domain local accounts that are stored in the
Builtin container. The domain controller itself does not have local computer
groups. On workstations and servers, these accounts are local to the computer
only.
SIDs for these default local accounts are always placed in a user’s token,
independent of the user’s domain and the computer’s domain. When a computer
(workstation or server) is joined to a domain, by default the Domain Admins
group is made a member of the Administrators local group on the computer.
Local groups can contain any security principal. One exception is that on domain
controllers, Builtin accounts cannot contain domain local groups.
For information about the abilities that are assigned to local groups by default,
see Help and Support Center for your version of Windows.
Group Membership Changes and Replication
Delegating administration might involve adding or removing members of large
groups. Changing the membership of a large group can result in a significant
volume of replication in Windows 2000 forests and in Windows Server 2003
forests that have Windows 2000 domain controllers. The reason for the increase
in replication is that group membership is stored in the single, linked,
multivalued Members attribute of the group object, and with Windows 2000
forests and domain controllers, the attribute is the smallest value that can be
replicated. Therefore, changing the membership of a group results in replication
of all group members, not just the changed member value. In addition, changes
can be lost if two administrators change the membership of the same group on
different domain controllers; only one of the changes can be written to the Active
Directory database during the same period of replication latency.
In Windows Server 2003 forests, group replication is improved to eliminate these
replication issues, but the improvements have functional level requirements. The
improvements are available in Windows Server 2003 forests that have a forest
functional level of:
• Windows Server 2003 (all domain controllers are running Windows
Server 2003), or
• Windows Server 2003 interim (all domain controllers are running either
Windows Server 2003 or Windows NT 4.0, but no domain controllers are
running Windows 2000).
 39

At these functional levels, the discrete values of linked, multivalued attributes

are replicated separately, not the entire attribute. At the Windows 2000 forest
functional level in a Windows Server 2003 forest (the default level that
accommodates Windows 2000 domain controllers that do not recognize certain
new features), or in all Windows 2000 forests, the attribute is still the smallest
unit of replication, and updating a large group (greater than 5,000 members) can
still result in excessive network bandwidth consumption and lost changes. For
this reason, groups that have greater than 5,000 members are not supported in
Windows 2000 forests.
For more information about Windows Server 2003 functional levels, see
“Enabling Advanced Windows Server 2003 Active Directory Features” in
Designing and Deploying Directory and Security Services of the Microsoft®
Windows® Server 2003 Deployment Kit (or see “Enabling Advanced Windows
Server 2003 Active Directory Features” on the Web at
http://go.microsoft.com/fwlink/?LinkId=6937).

Authorization Data on Directory Objects

All objects in Active Directory are securable by means of authorization data that
protects the object. This data is stored in the Security Descriptor property of each
object.
Security Descriptors
The security descriptor includes owner and group identifiers, as well as two
types of access control lists (ACLs):
• Owner. The security identifier (SID) for the current owner of the object. The
object owner is usually, but not always, the creator of the object.
• Group. The SID for the owner’s primary group. This component of the
security descriptor is not used by Active Directory access control, but is
available for Portable Operating System Interface for UNIX (POSIX)
compliance only.
• Discretionary access control list (DACL). A list of zero or more access
control entries (ACEs) that specify who has what access to the object.
• System access control list (SACL). A list of zero or more access control
entries that specify what audits to generate.
Object Owners and Creators
Every securable object has an owner. The owner is the only person who has the
inherent right to control who has permission to perform operations on the object
and in what way. An object’s owner can grant or deny permission for different
kinds of access to particular users or groups of users. An object’s owner can
transfer ownership by giving another security principal permission to take
ownership.
It is important to understand how the owner of an object is assigned and how
Note
Additionally, any security principal who has the Take
ownership of objects and other resources privilege on domain
controllers (specifiable in the Default Domain Controller
Security Policy) can take ownership of any and every Active
Directory object and every file and securable resource on
domain controllers in that domain. By default, the Builtin
Administrators group in Active Directory or on a local
computer is assigned a user right that allows this group to
take ownership of all objects on the computer.
40

principal that is associated with the thread that created the object. When a user
makes a request to create a new object in Active Directory, the information in the
user’s access token is used by the security subsystem on the domain controller to
establish object ownership. The information in the access token is generated by
the contacted domain controller. In addition to other information, the access
token contains the following information about the user:
• User. A field (Token-user) that contains the SID of the user who is logging
on.
• Default object owner A field (Default-owner-in-token) that contains the
SID of the user or security group that becomes the owner of any object that
this user creates.
When the access token is created, the user’s SID is inserted into the Default-
owner-in-token field unless the user is a member of certain administrative
groups. In this case, the SID of the group is inserted into the field and any
member of the administrative group can manage the object. If the user is a
member of more than one such administrative group, the group with the highest
level of authority is the object owner. As the object owner, you cannot change the
owner to another user or group; that is, you cannot change the value in the owner
field to specify an owner. However, you can apply a user right that allows
another user to take ownership.
For more information about how the list of the administrative groups that
become default object owners differs in Windows 2000 and Windows
Server 2003, see “Appendix J: Default Owners of Active Directory Objects” in
“Best Practices for Delegating Active Directory Administration: Appendices,”
which accompanies this document.
DACL
DACLs contain ACEs that identify the security principals that have access to the
object. Each ACE has fields that specify the abilities (permissions) for the
respective security principal. For each security principal that you add to the
access control list, you can define a set of permissions that specify the extent to
which that user or group of users can manipulate the object. If a user does not
appear in an ACE, either individually or as a member of a group, that user has no
access to the object.
SACL
The SACL is similar to the DACL except that it is used to audit rather than
control access to an object. When an audited action occurs, the operating system
records the event in the security log. Each ACE in a SACL has the following
elements: a header that indicates whether auditing is triggered by success,
failure, or both; a SID that specifies a particular user or security group to
monitor; and an access mask that lists the operations to audit. The content of the
SACL is controlled by security administrators for the local computer. Security
administrators are users who have been assigned the Manage auditing and
security log privilege. By default, this privilege is assigned to the built-in
Administrators group.
 41

DACLs and ACEs

For the most part, delegation involves specifying permissions on Active
Directory objects in order to authorize delegated users to carry out administrative
tasks. As mentioned earlier, these administrative tasks involve low-level
operations each of which can be individually authorized. Authorizing a low-level
operation involves identifying the object representing the data being targeted in
the low-level operation and appropriately modifying permissions in the DACL of
the target object’s security descriptor. This authorization is usually expressed in
the form of an access control entry (ACE). An understanding of the various
aspects of DACLs and ACEs is essential to being able to successfully delegate
administration. This section describes DACLs and ACEs in detail.
Where DACLs come from
It is important to understand where the ACEs in a DACL come from. When you
create an object in Active Directory programmatically, as the object’s owner you
can create and pass in through the API an explicit security descriptor.
Permissions are specified in the Security Descriptor Definition Language
(SDDL). If you create an explicit security descriptor, the ACEs in the DACL in
this security descriptor are merged with any inheritable ACEs that this object
would inherit from its parent object’s security descriptor. If you do not specify an
explicit security descriptor, a default security descriptor is applied to the new
object. Every object class definition in the schema has an attribute called
Default-Security-Descriptor. This default security descriptor becomes the
security descriptor of the object if an explicit security descriptor is not specified
during creation. In this case, the ACEs in the DACL of the default security
descriptor are merged with any inheritable ACEs that this object would inherit
from its parent object’s security descriptor.
Over the lifetime of the object, it continues to inherit any inheritable ACEs that
are present in the DACL of the parent object’s security descriptor. The addition
of new inheritable ACEs on the parent object results in the inheritance of these
new ACEs by the object. These inherited ACEs might be effective or ineffective,
depending on whether the Inherited-object type field is set and to what value.
Similarly, the removal of any inheritable ACEs on the parent object or any object
from which the parent inherits will result in the removal of that inheritable ACE
on this object.
Inheritance enables the access control information that is defined for a container
object in Active Directory to apply to any subordinate objects, including other
containers and their objects. Inheritance eliminates the need to apply permissions
each time a child object is created.
42

Note
If necessary, you can change the default permissions that are
specified in the default security descriptor for an object class
in the schema. However, as a best practice, you should avoid
changing the default permissions in the default security
descriptor for an object class unless you need to effect a
change in the default security for all instances of that class
across all domains in the forest.
As a best practice, you should also avoid removing any ACEs
from the DACL of the domain root object. Doing so could
impact the functionality of certain aspects of Active Directory
components or applications that depend on, and have access
to, Active directory data by virtue of the effective permissions
in the DACL of the domain root object.

Default Security Descriptor Protection on Service Administrator

Accounts
To prevent the security descriptors on the key service administrator accounts in
each domain from being modified and possibly becoming unusable, a
background process runs on the primary domain controller (PDC) emulator that
periodically checks and applies a standard security descriptor on the protected
accounts. This process ensures that if a hostile user or other administrator does
manage to modify the security descriptor on one of the administrative accounts,
the change will be overwritten with the protected settings. This process starts
15 minutes after the system starts, and then runs once every half hour after that.
This refresh interval is not configurable.
In Windows Server 2000 Active Directory, the following service administrative
accounts and all their nested member groups and users are protected by this
process:
• Enterprise Admins
• Schema Admins
• Administrators
• Domain Admins
• Server Operators
• Backup Operators
• Print Operators
In Windows Server 2003 Active Directory, the Account Operators account is also
protected by this process.
The master security descriptor for these service administrator accounts is stored
as the security descriptor attribute of the AdminSDHolder object, which is
located in the system container of the domain directory partition
(CN=AdminSDHolder,CN=System,DC=DomainName).
The security descriptor on this object serves two purposes:
 43

• It controls access to the AdminSDHolder object itself.

• It acts as the master security descriptor, which is periodically applied to the
service administrator groups and their members to ensure that they remain
protected.
For the default settings in the master security descriptor of the AdminSDHolder
object, see “Appendix K: Default Settings in the Master Security Descriptor of
the AdminSDHolder Object” in “Best Practices for Delegating Active Directory
Administration: Appendices,” which accompanies this document.
If you want to modify the security descriptor on one of the service administrator
groups or on any of its member accounts, you must modify the security
descriptor on the AdminSDHolder object so that it will be applied consistently.
Care must be taken when making these modifications because you are also
changing the default settings that will be applied to all of your protected
administrative accounts. For more information about changing the security
descriptor on AdminSDHolder, see “Changing the Security Descriptor on
AdminSDHolder” in “Appendix: Procedures” in the Best Practice Guide for
Securing Active Directory Installations: Part I on the Web at
http://go.microsoft.com/fwlink/?LinkID=21258.
Order of ACEs in a DACL
The DACL contains a sequential list of ACEs. The order of ACEs in the DACL
affects the outcome of the access check. By default, ACLs have a preferred order
called the canonical order. Although a DACL can be in a non-canonical order,
most UI tools canonicalize the DACL during an operation on the object.
The access check algorithm checks the ACEs in the DACL in sequence. For each
permission that is requested by the user, the algorithm stops at the first ACE that
allows or denies the requested access. Thus, the outcome of the access check
depends on the relative ordering of ACEs within the DACL.
The following is the canonical order of ACEs in a DACL:
• Explicit ACEs precede inherited ACEs
• Within a given set of explicit or inherited ACEs, Deny ACEs precede Allow
ACEs
This effect can be summarized by the following canonicalized DACL:
Explicit Deny Ace 1
…
Explicit Deny Ace n
Explicit Allow Ace 1
…
Explicit Allow Ace n
Inherited Deny Ace 1
…
44

Inherited Deny Ace n

Inherited Allow Ace 1
…
Inherited Allow Ace n
Further, within the set of Deny inherited ACEs and Allow inherited ACEs,
inheritable ACEs that are specified on the parent object precede inheritable ACEs
that are specified on the parent object’s parent object, and so on upward until
reaching the ACEs that are specified on the domain root object. Thus, in the
event of a conflict of permissions, permissions specified in an inheritable ACE
set on the parent object will override the permissions specified in an inheritable
ACE set on an object higher up in the object hierarchy.
A security descriptor might contain no DACL if a security descriptor that is
passed in programmatically has no DACL specified, and no ACEs are inherited
from the parent object. A security descriptor can also have a DACL that contains
no ACEs.

Note
A DACL can be set to null programmatically (that is, no DACL
is passed) at creation time or at any later time.

The effect on security of having no DACL as opposed to having a DACL that has
no ACEs is significant:
• No DACL in the security descriptor has the effect of granting unconditional
access to Everyone.
• An empty DACL has the effect of not granting access to anyone.
In the case of an empty DACL, the owner of the object always has the inherent
right to modify the DACL and grant permissions. If no DACL exists, the owner
can create a DACL programmatically and then grant permissions.
For more information about using SDDL to specify permissions
programmatically, see the Microsoft Platform Software Development Kit (SDK)
link on the Web Resources page at http://go.microsoft.com/fwlink/?LinkID=291.
Protected DACLs
The DACL of an object can be marked as protected. Marking a DACL as
protected will block the inheritance of any permissions from the parent object.
Any inheritable permissions in the DACL of the parent objects will not be
inherited by this object. Additionally, child objects of an object whose DACL is
marked protected will also no longer inherit any permissions specified on the
protected object’s parent. However, they will continue to inherit all inheritable
permissions specified in the DACL of the protected object unless the child
objects also have their DACLs marked as protected.
 45

ACEs
An ACE contains authorization intent for a specific security principal for whom
access is allowed, denied, or audited.
Every ACE in the DACL has the following structure:
(ACE Type ; ACE Flags ; Permissions ; Object Type ; Inherited Object Type ;
Trustee)
The following is a brief description of the various fields of an ACE:
• ACE Type – This field specifies whether the ACE is an Allow type ACE or a
DENY type ACE. An ALLOW type ACE allows access and a DENY type
denies access.
This field can take on one of six values:
• Allow – Indicates that the ACE is of the standard ACCESS ALLOWED
type, where the ObjectType and InheritedObjectType fields are NULL.
• Deny – Indicates that the ACE is of the standard system-audit type, where
the ObjectType and InheritedObjectType fields are NULL.
• System Audit – Indicates that the ACE is of the standard system type,
where the ObjectType and InheritedObjectType fields are NULL.
• Object Allow – Indicates that the ACE grants access to an object or a
subobject of the object, such as a property set or property. The
ObjectType or InheritedObjectType field or both contain a GUID that
identifies a property set, property, extended right, or type of child object.
• Object Deny – Indicates that the ACE denies access to an object or a
subobject of the object, such as a property set or property. The
ObjectType or InheritedObjectType field or both contain a GUID that
identifies a property set, property, extended right, or type of child object.
• Object System Audit – Indicates that the ACE audits access to an object
or a subobject of the object, such as a property set or property. The
ObjectType or InheritedObjectType field or both contain a GUID that
identifies a property set, property, extended right, or type of child object.
• ACE Flags – This field contains multiple inheritance related flags that govern
the inheritance aspects of the ACE.
This field can take values including but not limited to one or more of the
following:
• Container Inherit – Child objects will inherit this access-control entry
(ACE). The inherited ACE is inheritable unless the
ADS_ACEFLAG_NO_PROPAGATE_INHERIT_ACE flag is set.
• No Propagate – The system will clear the
ADS_ACEFLAG_INHERIT_ACE flag for the inherited ACEs of child
objects. This prevents the ACE from being inherited by subsequent
generations of objects.
46

• Inherit Only – Indicates an inherit-only ACE that does not exercise access
control on the object to which it is attached. If this flag is not set, the
ACE is an effective ACE that exerts access control on the object to which
it is attached.
• Inherited – Indicates whether or not the ACE was inherited. The system
sets this bit.
• Permissions – This field contains the specification of the permissions granted
or denied to the trustee (the security principal for whom the permissions
specified in this ACE will apply). This field can take one of the following
values:
• RC – Read Control
• SD – Standard Delete
• WD – Write DACL
• WO – Write Owner
• RP – Read Property
• WP – Write Property
• CC – Create Child
• DC – Delete Child
• LC – List Child
• LO – List Object
• SW – Validated write
• DT – Delete Tree
• CR – Extended Right
For more information about these rights, see “Appendix C: Active Directory
Standard Permissions” in “Best Practices for Delegating Active Directory
Administration: Appendices,” which accompanies this document.
• Object Type – This field can contain the GUID representing an object’s class.
The GUID refers to a property or a property-set if the permissions specified
are Read-Property or Write-Property permissions. The GUID specifies an
object class when the permissions specified are Create Child or Delete Child
permissions
• Inherited Object Type – This field can contain the GUID of an object class.
When such a GUID is set, the ACE is an effective ACE only on objects of the
class referred to by the GUID.
• Trustee – This field contains the SID of the security principal for whom the
permissions specified in this ACE will apply.
For a detailed description of the various fields of an ACE, see
“IADsAccessControlEntry” in the MSDN Library on the Web at
http://go.microsoft.com/fwlink/?LinkID=21262.
 47

Example ACEs
The following example ACEs illustrate how ACEs specify delegation intent:

Note
To provide clarity in following examples, the display name of
the class or attribute has been shown instead of the actual
GUID for the class, and the name of the group has been used
instead of the SID for Account Admins. In actual ACEs, GUIDs
and SIDs are used instead of the display names shown here.

• An ACE that grants Account Admins the ability to create user objects in an
OU and in all OUs within the subtree rooted at this OU:
• (OA ; CI ; CC ; User Class ; Organizational Unit class ; Account Admins)
• An ACE that grants Account Admins the ability to reset user passwords in an
OU but only on User objects:
• (OA ; CI ; CR; Reset Password ; User class ; Account Admins)
• An ACE that grants Account Admins the ability to modify the membership of
all group objects (but only group objects) in a specific OU (on which this
ACE is being applied). This ACE does not give Account Admins the
permission to modify the group memberships of any groups that might exist
as child objects of other OUs that might be child objects of the OU on which
the ACE is being applied.
• (OA ; ; WP; Member ; Group class ; Account Admins)
Note the absence of any inheritance flags in this ACE.
Inheritance and Organizational Units
Active Directory data is stored in containers. While some containers are general
purpose containers, other containers have a specialized purpose in that they are
specific in the nature of data that they are intended to store. Generic containers
are represented by objects of the generic class Container, while specific
containers are represented by specific object classes. An example of a generic
container would be the Services container in the Configuration partition, which is
intended to contain various kinds of objects representing service specific
information. An example of a specific class of container is the Sites container in
the Configuration partition which is intended to contain site and subnet related
information and is represented by an object of class SitesContainer. While
different kinds of configuration information can be stored in different kinds of
containers, domain data is typically stored in a special purpose class of objects
called Organizational Units (OUs).
OUs are special purpose containers in that they are intended to contain domain
data like user accounts, computer accounts, and groups. Additionally, OUs can
contain other OUs within them. In this manner, domain data is stored within a
hierarchy of OUs which serve the role of containers for domain data. OUs are
different from other containers in that Group Policy can be applied to them. The
48

application of Group Policy to an OU results in the inheritance of the applied

Group Policy by user and computer objects, on which that Group Policy
becomes effective subject to the precedence order of the application of Group
Policy.
OUs are used to form a hierarchy of special purpose containers within a domain
for the purpose of storing user and computer accounts and security groups and
applying Group Policy onto a collection of user and computer accounts.
Organizations create an OU hierarchy structure based on their Group Policy
requirements and collectively store user and computer accounts and groups
within specific OUs depending on the Group Policy requirements for these user
and computer accounts.
Organizational units also play a major role in delegation of administration.
Delegation of administration involves granting an administrative group sufficient
permissions to allow the group the ability to perform specific administrative
tasks. Usually, administrative authority is delegated to manage a set of users.
While it is possible to grant an administrative group permissions on the specific
user accounts that belong to a set of users, individually modifying the DACL of
every single user account in a set is usually unmanageable and impractical. To
simplify the application of the permissions required to delegate authority and
control access, the inheritance feature of Active Directory enables the application
of inheritable permissions on objects.
Instead of having to explicitly specify permissions in the DACL of every
managed object, administrators can simply specify the same permission on an
OU or any object that contains one ore more objects and mark the specified
permissions as inheritable. The inheritance feature of Active Directory will take
any permission specified as inheritable and propagate them down to all child
objects within the container on which the permission was applied and to all child
objects of any container objects within the subtree rooted at the container object
on which the inheritable ACE was applied.
Since domain information is typically stored in OUs, inheritable permissions are
typically applied on OU objects, and inheritance takes care of propagating all
inheritable permissions down to all objects in the subtree rooted at the OU on
which these inheritable permissions were applied.
Organizations should take into account two primary requirements when
designing their OU structures:
• Group Policy application requirements
• Delegation of Administration requirements
When Active Directory is installed, only one OU, Domain Controlers, is
automatically created. Domain Controllers is the default container for new
domain controllers.
In addition, a number of other containers are automatically created, two of
which, Computers and Users, are of interest from the perspective of domain data
storage:
 49

• Computers represents the default storage area for new computer objects that
were originally created through legacy APIs that are not Active Directory–
aware.
• Users represents the default storage area for new user accounts that are
created through legacy APIs that are not Active Directory–aware.
By default, when computers are joined to the domain, the computer accounts for
these computers are created in the Computers container. Because these two
containers are not OUs, Group Policy cannot be applied to them.

Note
Even though they are not OUs, inheritable permissions can
still be applied to the Computers and Users containers,
because the concept of inheritance of permissions applies to
other containers as well as to OUs. Inheritance works the
same in every directory partition, whether the Configuration
partition, the Schema partition, or a domain partition.

Thus, after the deployment of Active Directory, an organization must typically

create an OU structure to store domain data including user and computer
accounts and groups. When designing an OU structure, organizations must take
into account Group Policy application requirements and requirements around
delegation of administration.
For best practices and design considerations for creating an effective OU
structure, see “Chapter 4: Delegating Data Management” later in this document.
50

Chapter 3: Delegating Service Management

Service management involves managing all aspects of the Active Directory
directory service that are required to provide security and reliability in the
delivery of the directory service. Overall responsibility for service management
is entrusted to service owners who are responsible for the planning and long-term
maintenance of the Active Directory infrastructure, ensuring that the directory
continues to function, and ensuring that goals established in service-level
agreements are met. To achieve these goals, service owners create an
administrative delegation model to distribute the various administrative
responsibilities among service administrators. Service administrators thus
represent the operational arm of the service owners.
Service owners choose a small and select group of highly trusted and skilled
administrators from among their service administrators and confer upon this
small set of administrators the highest level of privilege by designating them as
Enterprise Administrators of the forest. While service owners are responsible for
the creation of a delegation model for service management, service
administrators assist them during the creation of the model by providing an
operational perspective, including the capabilities and the limitations of the
system. Upon the completion of the creation of a well-designed delegation model
for service management, Enterprise Administrators implement the delegation
model to enable the service management administrators team to carry out its
assigned responsibilities.
This chapter provides guidance on how to use delegation to provide
administrative coverage for all aspects of service management in an Active
Directory environment. The chapter presents an overview of the various
categories that comprise service management and provides recommendations for
how to efficiently delegate all aspects of service management in a security
conscious manner.
To help service owners to create the service delegation model, and to help high-
level administrators to implement the model, this chapter provides the following
information:
• Overview of the categories of service tasks that require management
• Overview of the default service administration groups and their levels of
privilege
• Recommendations for how to delegate all service management
responsibilities in an efficient and security-conscious manner by using
service administration roles
• Best-practices for implementing the service delegation model by creating
service administration groups for each administrative role, assigning
appropriate permissions, and populating the groups
 51

Level-of-Privilege Considerations in Delegating Service

Management
Closely associated with the concept of delegating administration is the implicit
notion that since delegation involves authorizing a lesser privileged administrator
the ability to carry out a specific set of administrative tasks, it is usually fair to
assume that the nature, scope and impact of a delegated administrative task is
less security-sensitive and cannot be used to elevate privilege to the same level
as that of the administrator delegating the task.
While this notion is generally true, it does not hold for delegation of service
management. Service management involves providing administrative coverage to
help ensure security and reliability in the delivery of the Active Directory
directory service. Thus, by its very nature, it is fair to assume that most
administrative tasks involved in promoting security and reliability can and
usually do have a significant impact on the security worthiness and the
availability of the directory service.
While some administrative tasks are extremely security-sensitive and can have a
forest-wide impact, thus requiring highly elevated privileges, most administrative
tasks do not require such high levels of privilege. The administrative tasks that
do require elevated levels of privilege should only be entrusted to the most
highly trustworthy and skilled set of administrators. While most service
management administrative tasks do not require elevated levels of privilege, they
do require more privileges than those required for data management tasks and
they need to be assigned to sufficiently trustworthy personnel.
The level of skill and trust required of these administrators represents a
significant cost to the organization. To minimize the total cost of operation and
increase the security worthiness of an Active Directory environment, the number
of these most highly trustworthy and skilled set of administrators should be
minimized by delegating responsibility for relatively less security-sensitive
service management administrative tasks to relatively less highly trusted and
skilled administrators.
Additionally, since malicious or inadvertent, careless use of needlessly broad
administrative credentials can result in irreversible damage, such as accidental
deletion of data, inadvertent assignment of wrong values to sensitive data, and
inappropriate configuration of essential services, it makes sense to grant service
administrators only the level of administrative authority that is required to carry
out the set of administrative tasks assigned and none other. For instance, by
default Domain Administrators and Enterprise Administrators are sufficiently
privileged to carry out just about every service administration task in Active
Directory. A majority of these tasks do not require such high-levels of privilege
and can be delegated to lesser-privileged administrators so as to minimize the set
of highly trusted and privileged administrators and minimize the chance of
inadvertent or malicious use of such high and sweeping levels of privilege.
Finally, delegation can be used to achieve a clear separation of assigned
responsibilities, thereby making service management more tractable, and
52

increasing accountability and the security worthiness of an Active Directory

environment.
For example, assigning responsibility for all aspects of forest-wide replication
(but only forest-wide replication) to a specific administrative group not only
ensures that a critical aspect of service has been provided administrative
coverage, but also increases accountability and helps ensure service delivery. For
example, in the event of a replication issue, there is a clearly identifiable set of
administrators to which the issue can be escalated, The same set of
administrators can be held accountable should there be suspicion that a
replication related administrative task was carried out with malicious intent.
For all these reasons, while delegation of service management does not
necessarily lead to lesser-privileged delegated administrators, it does make an
Active Directory environment measurably more secure and helps reduce the total
cost involved in managing the directory service while continuing to ensure the
highest levels of security and availability of service.
Note that it is critical and imperative to understand that each and every service
administrator should be equally and highly trusted. Every single service
administrator is sufficiently privileged to adversely impact the security and
reliability of the delivery of the directory service and can consequently adversely
impact the data stored in or protected by Active Directory. The importance of
ensuring that all service administrators meet the highest bar of trust cannot be
overstated.

Recommended Approach to Service Management

As mentioned in “Chapter 1: Delegation of Administration Overview” earlier in
this document, a structured and methodical approach to managing an Active
Directory environment can greatly enhance the security of the directory service,
reduce administrative costs involved in managing Active Directory, and
successfully address the administrative needs of all stakeholders, thereby making
Active Directory management more tractable seamless, efficient and secure.
A structured and methodical approach to managing the service aspects of an
Active Directory environment generally involves the following recommended
steps:
1. Understand all aspects of Active Directory service management.
2. Understand the administrative needs of all stakeholders.
3. Create a service management delegation model that ensures that
administrative coverage is provided for all aspects of Active Directory
management and that the administrative needs of all stakeholders are
addressed.
4. Implement the service management delegation model in an efficient and
security-conscious fashion, ensuring that the administrative needs of all
delegated administrators and all stakeholders are addressed while also
 53

ensuring that all administrative access has been granted on the basis of
least privilege.
5. Maintain the implemented delegation model, which involves making
modifications to the implemented delegation model in response to changes
in administrative requirements or needs.

Service Management Overview

This section provides an overview of all service management categories that is
aimed at helping you gain a better understanding of all aspects of Active
Directory service management. It also presents Microsoft recommended roles
that should be sufficient for providing administrative coverage for all aspects of
Active Directory service management, taking into account the administrative
needs of the service owners and administrators, who are the main stakeholders in
Active Directory service management.

Service Management Categories

Service management includes managing all aspects of the directory service that
are essential to ensuring the uninterrupted delivery of the directory service across
the enterprise. Service management includes, but is not limited to, the following
administrative tasks:
• Adding and removing domains and domain controllers
• Managing and monitoring replication
• Ensuring the proper assignment and configuration of operations master roles
• Performing regular backups of the directory database
• Managing domain and domain controller security policies
• Configuring directory service parameters, such as setting the functional level
of a forest or putting the directory in the special List-Object security mode
Active Directory service management can be divided into several categories of
essential components that require administration. Each service management
category has a set of associated tasks that can be delegated to provide for
management of every aspect of that category.
Active Directory service management can be separated into the following
Note
Several service administrative security groups are created by
default when you install Active Directory. Some of these
groups are used by the high-level administrators who
implement the delegation model. Other default groups can
also be used to implement service administration roles. For
more information about the default service administrator
groups and accounts in active, Directory, see “Appendix N:
Default Active Directory Service
Administrative Groups” in “Best Practices
for Delegating Active Directory
Administration: Appendices,” which
accompanies this document.
54

• Installation management
• Schema management
• Trust management
• Knowledge reference management
• Operations master roles management
• Backup and restore management
• LDAP policy management
• Directory service configuration management
• Replication management
• Functional level management
• Directory database management
• Security policy management
• DNS management
• Domain Controller management
For a complete list of the tasks that map to these categories, see “Appendix A:
Active Directory Administrative Tasks” in “Best Practices for Delegating Active
Directory Administration: Appendices,” which accompanies this document. Note
that this list does not include the list of tasks involved in managing the server
management aspects of domain controllers.
Installation Management
Active Directory is hosted on domain controllers across the enterprise. A forest is
created by installing Active Directory on one server that is running Windows
Server 2003 or Windows 2000 Server. After the forest root domain is installed,
subsequent installations of Active Directory on member servers result in the
creation of either new child domains in the forest, or additional domain
controllers in an existing domain.
Administrative tasks in this category include the creation and deletion of child
domains and the installation of additional domain controllers in domains. The
creation of child domains is typically an infrequent operation. Child domains are
usually created during deployment of Active Directory. Subsequent to initial
deployment, the addition of child domains does not happen frequently. In
contrast, the addition of new domain controllers to an existing domain must be
performed as and when required, typically either to address domain controller
failures in remote sites that have only one domain controller or to provide
domain controllers in new locations as needed.
For more information about managing domain controllers, see the Active
Directory Operations Guide on the Web at
http://go.microsoft.com/fwlink/?LinkID=21268.
 55

Schema Management
The Active Directory Schema contains definitions for the set of objects that can
be stored in Active Directory, and it enforces the rules that govern both the
structure and the content of Active Directory. The schema consists of a set of the
classes, attributes, and syntaxes that represent an instance of one or more classes
in the schema. The schema also specifies the relationships between classes of
objects. The base schema that ships with Active Directory contains all class and
attribute definitions that are used by Windows 2000 Server and Windows
Server 2003 and their components. Schema objects can be modified to
accommodate needed object classes or attributes that are not available in the
default schema, or to remove existing class or attribute schema objects so that
instances cannot be created in Active Directory.
Administrative tasks in this category involve the extension and modification of
the Active Directory schema,
For more information about managing the schema, see the Active Directory
Operations Guide on the Web at http://go.microsoft.com/fwlink/?LinkID=21268.
Trust Management
A trust relationship is a link that is established between domains to enable users
in one domain to be authenticated by a domain controller in the other domain.
Trust relationships are authentication pipelines that must be present so that users
in one domain can be authorized for access to resources in another domain. All
domains in a forest have automatic, two-way, transitive trust relationships.
In addition to these automatic trust relationships, four other types of trusts can be
created in an Active Directory environment.
• Shortcut trust. Can be set up between two domains within a Windows
Server 2003 forest to improve user logon times between the domains.
• External trust. Can be set up to provide access to resources that are located
in Windows NT 4.0 domains or in domains that are located in a separate
Windows 2000 or Windows Server 2003 forest that is not joined by a forest
trust.
• Forest trust. In a Windows Server 2003 forest, can be used to link two
disjoined Windows Server 2003 forests together to form uni- or bi-directional
transitive trust relationships. A bi-directional cross-forest trust relationship
forms a transitive trust relationship between every domain in both forests.
• Non-Windows Kerberos realm trust. Can be set up between a non-
Windows-brand operating system Kerberos version 5 realm, such as a UNIX
realm, and an Active Directory domain.
Administrative tasks in this category involve the creation, deletion and
management of all aspects of trust relationships in the forest.
For more information about managing trusts, see the Active Directory
Operations Guide on the Web at http://go.microsoft.com/fwlink/?LinkID=21268.
56

Knowledge Reference Management

Active Directory stores information about the existence and location of directory
partitions, including the names of all directory partitions, global catalog servers
that hold partial, read-only copies of the directory partitions, and domain
controllers that hold writable copies of the directory partitions. This information
is used by the directory service to generate referrals to other domain controllers
in the form of knowledge references.
Three kinds of knowledge references can be returned in response to an LDAP
query:
• A subordinate reference, which is knowledge of a directory partition (or
partitions) that are directly adjacent (usually below) in the naming hierarchy
to a directory partition that is held by the domain controller.
• A cross-reference, which is knowledge of one directory partition and is stored
in a cross-reference object in the Partitions container. On a specific domain
controller, the combination of all cross-references provides knowledge of all
directory partitions in the forest, regardless of their locations in the directory
tree.

Note
The state of cross-reference knowledge at
any specific time is subject to the effects of
directory replication latency.
• A superior reference, which is knowledge of a specifically designated referral
location that is used whenever the domain controller has no knowledge of the
search base.
Knowledge references are represented by crossRef objects in Active Directory
and are stored in the Configuration partition in the Partitions container.
Administrative tasks in this category include pre-creation of cross-references and
the specification of superior references.
Operations Master Roles Management
To provide conflict prevention, Active Directory enforces the requirement that
certain operations can be performed on only a single domain controller per forest
or per domain, depending on the operation. The domain controllers that are
designated as being able to perform these single-master operations are called
operations masters. Each operations master has a role that identifies the type of
operations for which it is solely responsible.
Active Directory defines five operations master roles. Two are forest-wide roles
and three are domain-wide roles:
• Schema master. The only domain controller in a forest that can perform
write operations to the schema directory partition.
• Domain naming master. The only domain controller in a forest that can add
or remove domain or application directory partitions.
 57

• Relative identifier (RID) master. The only domain controller in a domain

that can assign RIDs to a domain controller. RIDs are required by domain
controllers to create new security principals.
• Primary domain controller emulator. The only domain controller in a
domain that can provide PDC functionality. The PDC is required to interact
with Windows NT 4.0 workstations, member servers, and backup domain
controllers.
• Infrastructure master. The only domain controller in a domain that can
update the group-to-user references whenever the members of groups are
renamed or changed within a domain.

Note
The schema master and domain naming
master are per-forest roles and should be
held by domain controllers that belong to
the forest root domain. The schema master
and domain naming master roles should
always be placed on the same domain
controller, and this domain controller must
be a global catalog server.
Administrative tasks in this category include the transfer and the seizure of the
five operations master roles.
For more information about managing operations masters, see the Active
Directory Operations Guide on the Web at
http://go.microsoft.com/fwlink/?LinkID=21268.
Backup and Restore Management
Backing up and restoring data is critical to failure recovery management. From a
management perspective, the only administrative operations in this category are
backing up and restoring Active Directory. Each of these operations is performed
on domain controllers and each is individually controlled by separate user rights.
For more information about Active Directory backup and restore, see the Active
Directory Operations Guide on the Web at
http://go.microsoft.com/fwlink/?LinkID=21268.
LDAP Policy Management
LDAP, an industry standard directory service protocol, is the directory access
protocol used to query and retrieve information from Active Directory. LDAP
defines how a directory client accesses a directory server, shares directory data,
and performs directory operations. LDAP enables clients to query, create, update,
and delete information stored in a directory service. Because LDAP is a query
protocol, certain behavioral aspects of how queries are handled are configurable.
By default, all domain controllers in the forest have the same LDAP policy.
58

Administrative tasks in this category include the configuration of the default

LDAP policy and the creation and configuration of domain-controller specific
query policies if needed.

Note
Although query policies can be configured on a per–domain
controller basis, it is advisable not to specify different LDAP
policies for different domain controllers. Also note that some
domain–controller specific LDAP policies can lead to a denial of
service if configured incorrectly.

Directory Service Configuration Management

Certain configuration aspects of the directory service can be specified on a per–
domain controller basis. For example, the directory service on a domain
controller can be forced to immediately refresh the security group cache by
contacting an available global catalog server. The directory service on a domain
controller can also be forced to perform an online defragmentation of the
directory database. These configurable parameters affect directory service
delivery on that specific domain controller.
Administrative tasks in this category include the configuration of the various
parameters that affect directory service delivery on that specific domain
controller.
Replication Management
Active Directory replication is the process by which the changes that are made
on one domain controller are synchronized with all other domain controllers in
the domain or forest that store replicas of the same data.
Administrative tasks in this category include the creation and maintenance of all
aspects of the replication topology (including sites, site-links, subnets and
subnet-to-site associations, bridgehead specification and configuration) and
monitoring all operational aspects of replication.
For more information about managing replication, see the Active Directory
Operations Guide on the Web at http://go.microsoft.com/fwlink/?LinkID=21268.
Functional Level Management
Active Directory functional levels ensure the proper environment for enabling
new Active Directory features. Active Directory features added in successive
versions of Windows are not always compatible with earlier versions. Functional
levels allow you to safely enable such features when all domain controllers in the
domain or forest are running an appropriate version of Windows.
Administrative tasks in this category include setting the appropriate functional
levels when your Active Directory environment meets the requirements of a
specific functional level and you are ready to activate that functional level.
 59

Directory Database Management

The directory database is a self-maintained system wherein growth is managed
by periodically compacting data and reorganizing free space into contiguous
pages. Other than regular backup, the directory database requires no maintenance
during ordinary operation. The only requirement is adequate space to
accommodate normal growth.
In Windows 2000 environments, large-scale changes, such as bulk deletions and
changes to inherited security descriptors, can cause significant database growth.
Improved processing in Windows Server 2003 makes these conditions less
problematic. However, database growth must be monitored, and if growth is
significant, steps must be taken to reduce the size of the database. Database
management includes defragmenting the database offline to release free space to
the file system. On domain controllers that are running Windows Server 2003,
you can also schedule online defragmentation, which is automatic by default.
Database management tasks also include moving database and log files to
different locations when hardware maintenance is required. Service
administrators who are responsible for database management also perform tests
to troubleshoot database corruption and take steps to restore the database files.
For more information about managing the database, see the Active Directory
Operations Guide on the Web at http://go.microsoft.com/fwlink/?LinkID=21268.
Security Policy Management
Default security policy settings for the domain and for domain controllers are
specified and stored in the form of Group Policy objects (GPOs). These settings
take on default (but configurable) values when Active Directory is installed, and
they are applied to all new domains. Group Policy settings apply to either users
or computers, depending on the nature of the policy.
In a new Windows Server 2003 domain, the following default GPOs protect the
domain and all domain controllers:
• Default Domain Policy, which is linked to the domain object and affects all
users and computers in the domain (including computers that are domain
controllers) through policy inheritance
• Default Domain Controllers Policy, which is linked to the Domain
Controllers OU and affects only domain controllers, because by default,
computer accounts for domain controllers are kept in the Domain Controllers
OU
Security policy settings are organized into the following categories:
• Account Policies, which include:
• Password Policy, which controls password enforcement and lifetimes on
domain accounts
• Account Lockout Policy, which determines the circumstances and length
of time that an account will be locked out of the system
60

• Kerberos Policy, which determines Kerberos-related settings, such as

ticket lifetimes and enforcement
• Local Policies, which include:
• Audit Policy, which tracks system security events on computers
• User Rights Assignment, which controls user and administrative actions
on computers
• Security Options, which affects Active Directory, network, file system,
and user logon abilities
• Event Log Policy, which defines attributes that are related to the application,
security, and system event logs
The management of these security policies falls under service management
because these domain controller security policies control security settings for
domain controllers and improper configuration of these policy settings can
adversely affect the security of the directory service. Additionally, the domain
security policy settings are applied on any Windows 2000 workstation or server
that is a member of the domain. An individual could change these settings to
weaken the security policy of the domain so that security could be compromised.
For instance, if the account policy dictating password strength is set to allow
weak passwords, passwords can be broken and thus the security of the system
can be compromised.
Administrative tasks in this category include managing the default domain
controller security policy and managing the password, account lockout, and
Kerberos account policies.
Service Admin Groups and Accounts Management
Clearly, administrators who have control of the membership of the powerful
administrative group accounts can easily escalate their privilege to become
service administrators or make another user a service administrator, thereby
being able to negatively impact many aspects of the directory service. Should
such administrators acquire malicious intent or be coerced, they can easily
disrupt delivery of the directory service. In the worst case scenario,
untrustworthy administrators can cause irreversible damage, including disabling
or destroying the forest or exposing content that is stored in or protected by the
directory service.
DNS Management
Windows Server 2003 and Windows 2000 Server use DNS for name resolution
instead of the Windows Internet Name Service (WINS) NetBIOS name
resolution method, which is used in Windows NT 4.0–based networks. It is still
possible to use WINS for applications that require it; however, Active Directory
requires DNS. DNS enables users to use friendly names that are easy to
remember to connect to computers and other resources on IP networks.
 61

Active Directory uses the name resolution services that DNS provides to enable
clients to locate domain controllers and to enable the domain controllers that host
the directory service to communicate with each other.
Active Directory is designed to enable easy integration of the Active Directory
namespace into an existing DNS namespace. Features such as Active Directory–
integrated zones make it easier to deploy DNS by eliminating the need to set up
secondary zones and configure zone transfers.
When DNS servers running on domain controllers store their zones in Active
Directory, it is not necessary to configure a separate DNS replication topology
that uses ordinary DNS zone transfers. Instead, all zone data is replicated
automatically by means of Active Directory replication. Therefore, service
administration of Active Directory–integrated DNS principally involves
managing DNS data that is stored on domain controllers.
The DNS infrastructure supports the Active Directory logical structure to provide
computer name resolution throughout the forest and the Internet. The forest
owner assigns an Active Directory DNS owner for the forest. The Active
Directory DNS owner has a thorough understanding of the existing DNS
infrastructure and the existing namespace of the organization.
The Active Directory DNS owner for the forest is responsible for overseeing the
deployment of the Active Directory DNS infrastructure and making sure that, if
necessary, domain names are registered with the proper Internet authorities.
The Active Directory DNS owner is responsible for the Active Directory DNS
design for the forest. If your organization is currently operating the DNS service,
then the DNS designer for the existing DNS service works with the Active
Directory DNS owner to delegate the forest root DNS name to DNS servers
running on domain controllers.
The Active Directory DNS owner for the forest also maintains contact with the
DHCP and DNS teams of the organization and coordinates the plans of any
individual DNS owners of each domain in the forest with these groups. The DNS
owner for the forest ensures that the DHCP and DNS teams are involved in the
Active Directory DNS design process so that each group is aware of the DNS
design plan and can provide input early on.
For more information about configuring DNS, see “Designing the Active
Directory Logical Structure” in Designing and Deploying Directory and Security
Services and “Deploying DNS” in Deploying Network Services of the Windows
Server 2003 Deployment Kit (or see “Designing the Active Directory Logical
Structure” on the Web at http://go.microsoft.com/fwlink/?LinkID=4723 and
“Deploying DNS” on the Web at http://go.microsoft.com/fwlink/?LinkID=4709).
Domain Controller Management
Domain Controllers are member servers that host the Active Directory directory
service. Unavailability of a domain controller directly impacts availability of the
Active Directory directory service, and a security breach involving unauthorized
access to a Domain Controller can directly undermine the security of an Active
Directory environment. Thus, providing adequate administrative coverage for all
62

server management aspects of domain controllers and ensuring that domain

controllers are always running with up to date software and proper
configurations is of primary importance for ensuring delivery of the directory
service.
Administrative tasks in this category include managing all server management
aspects of domain controllers including managing the hardware on domain
controllers, ensuring adequate file-system space, and making sure that the
domain controller is up to date in terms of the application of all security patches
and hot-fixes.
For more information about managing domain controllers, see the Active
Directory Operations Guide on the Web at
http://go.microsoft.com/fwlink/?LinkID=21268.

Recommended Roles for Service Management

Microsoft has engineered a set of recommended roles for delegating service
management. These role recommendations take into account defined sets of
logically related administrative tasks and the security sensitivity and impact of
these tasks.
The following is the set of recommended roles for delegating service
management:
• Forest Configuration Operators
• Domain Configuration Operators
• Security Policy Administrators
• Service Admin Managers
• Domain Controller Administrators
• Backup Operators
• Schema Administrators
• Replication Management Administrators
• Replication Monitoring Operators
• DNS Administrators
Forest Configuration Operators Role
A number of administrative operations can affect the security of the entire forest.
For example, the creation or removal of child domains can have far-reaching
consequences on a forest. In the wrong hands, the ability to create child domains
could be used to launch a denial of service attack against the entire forest. Thus,
any operation that has a forest-wide impact, in the wrong hands, represents a
significant threat to forest security. Microsoft recommends that all administrative
tasks that affect the configuration of the forest should be aggregated and assigned
to the Forest Configuration Operators role. Administrators in this role are
responsible for tasks that include but are not limited to:
 63

• Creating and deleting child domains

• Creating, deleting, and managing all trust relationships for the forest
• Creating, deleting, and managing cross-reference objects
• Transferring and seizing the forest-wide operations master roles
• Modifying forest-wide LDAP settings
• Raising the forest functional level
Microsoft recommends the implementation of one instance of this role for every
forest in an Active Directory environment. Microsoft also recommends that no
more than two or three administrators be assigned to this role.
Domain Configuration Operators Role
A number of administrative operations can affect the security of an entire
domain, and possibly by extension affect the entire forest. For example, the
addition or removal of a domain controller can have far-reaching consequences
on a domain, and by extension, the forest. In the wrong hands, the ability to
create child domains could be used to obtain access to the entire domain’s data
and possibly inject malicious changes into a domain. Thus, any operation that
has a domain-wide impact, in the wrong hands, represents a significant threat to
domain security and by extension to forest security.
Microsoft recommends that all administrative tasks that affect the configuration
of a domain should be aggregated and assigned to the Domain Configuration
Operators role. Administrators in this role are responsible for tasks that include
but are not limited to:
• Adding and removing replica domain controllers
• Transferring and seizing the domain-wide operations master roles
• Protecting and managing the default Domain Controllers OU
• Protecting and managing the content stored in the System container
• Restoring Active Directory from backup if and when required
Microsoft recommends the implementation of one instance of this role for each
domain in an Active Directory forest. Microsoft also recommends that no more
than two or three administrators be assigned to this role.
64

Note
It might seem logical to eliminate the Domain Configuration
Operators role and to assign these tasks to the Forest
Configuration Operators role. However, it is usually advisable
to separate the responsibility for a domain from the
responsibility for the entire forest. Generally, all service
management tasks can have a forest-wide impact; therefore,
it can be argued that all such tasks should be assigned to the
Forest Configuration Operators role. However, the purpose of
the Forest Configuration Operators role is to address highly
security-sensitive administrative tasks, each of which has a
clearly visible forest-wide impact. The purpose of the Domain
Configuration Operators role is to separate powers among
different sets of administrators and assign responsibility for
managing highly security-sensitive administrative tasks, each
of which has a clearly visible domain-wide impact, though it is
true that these administrative tasks in the wrong hands could
be used to cause forest-wide impact. However, the objective is
not simply to grant restricted abilities — the objective is to
make service management more tractable.

Security Policy Administrators Role

Security policies applied through Group Policy settings affect every user and
computer in a domain and also protect domain controllers.
The Domain Security Policy contains settings that apply to any workstation or
server in the domain that is running a version of Windows 2000 Server, the
Microsoft® Windows XP® Professional operating system, or Windows
Server 2003. Domain Security Policy also includes account policy settings that
apply to every user account in the domain. Changes to these settings can weaken
the security policy of the domain.
For example, if the Account Policies\Password Policy settings that define
password strength are set to allow weak passwords, system security might be
compromised. Because all domain accounts are subject to the Domain Security
Policy, a weak password policy also compromises service administrator
accounts. The consequences of a compromised service administrator account are
potentially disastrous to the security of the domain and the forest.
Domain Security Policy tasks include administering:
• Password policy settings
• Account Lockout settings
• Kerberos Policy settings
Similarly, every domain has a Domain Controller Security Policy that applies to
all domain controllers in the domain. This security policy includes User Rights
Assignment settings, which contain both logon rights and privileges. User Rights
Assignment settings that apply to domain controllers are extremely security-
sensitive. For example, the set of security principals who can log on to a domain
controller is defined by the Allow log on locally User Rights Assignment setting
 65

in the Domain Controller Security Policy. Similarly, User Rights Assignment

settings also define the set of security principals who can perform various highly
security-sensitive operations on domain controllers, such as the Load and unload
device drivers user right. Users who have this right can inject code that runs in
kernel-mode. The Take ownership of files or other objects User Rights
Assignment setting enables an individual to take ownership of any files or
objects on the domain controller, which includes any directory partition in Active
Directory.

Note
The lowest level at which you can apply user rights for the
Domain Controllers OU is the default OU. The Domain
Controllers OU is the default container for all domain controller
objects in a domain directory partition, and moving domain
controllers out of this OU is not recommended and not
supported. The user rights that apply to this OU apply to all
domain controllers in the OU, and thus, in the domain. The
default policies are applied to the Domain Controllers OU in a
manner that prohibits the effective use of child OUs for
domain controllers. Unlike other OUs, child OUs of the Domain
Controllers OU cannot be used to override the policy that is
applied at the Domain Controllers OU parent level. For this
reason, creating child OUs and delegating administration for
subsets of domain controllers is not supported.

Consequently, any individual who controls the Domain Controller Security

Policy of any domain is very highly privileged. Such an individual can gain
complete and unrestricted access to every object in Active Directory and every
securable resource that is a part of the forest (for example, files and databases on
servers that are joined to the domain). This individual can also restrict any and
every other individual – including members of the Enterprise Admins, Builtin
Administrators, and Domain Admins groups – from being able to log on or gain
access to any resource in the forest.
Microsoft thus recommends entrusting responsibility for managing all aspects of
Domain Controller Security policy for every domain in the forest, and managing
the password, account lockout, and Kerberos aspects of the Domain security
policy for every domain in the forest to a single group of administrators who take
on the Security Policy Administrators role. Administrators in this role are
responsible for the following tasks:
• Managing all aspects of the Domain Controller Security Policy for all
domains in the forest
• Managing the following aspects of Domain Security Policy for all domains in
the forest:
• Password Policy
• Account Lockout
• Kerberos Policy
66

Microsoft recommends the implementation of one instance of this role for each
Active Directory forest. Microsoft also recommends that no more than two or
three administrators be assigned to this role.

Note
It might seem logical to eliminate the Security Policy Admins
role and to assign these tasks to the Forest Configuration
Operators role. However, it is usually advisable to separate
the responsibility for security policy management from the
responsibility for the entire forest. Generally, all service
management tasks can have a forest-wide impact; therefore,
it can be argued that all such tasks should be assigned to the
Forest Configuration Operators role. However, the purpose of
the Forest Configuration Operators role is to address highly
security-sensitive administrative tasks, each of which has a
clearly visible forest-wide impact. The purpose of the Security
Policy Admins role is to separate powers among different sets
of administrators and assign responsibility for managing all
sensitive security policies for the entire forest to a specific set
of administrators, though it is true that these administrative
tasks in the wrong hands could be used to cause forest-wide
impact. However, the objective is not simply to grant
restricted abilities — the objective is to make service
management more tractable. An organization could very well
decide to make the same set of administrators members of
more than one service management role.

Service Admin Managers Role

Because of the elevated power that is attached to service administrator accounts,
it is advisable to dedicate a role to protecting and managing all service
administrator accounts across the forest.
Microsoft recommends the implementation of the Service Admin Managers role
to protect the service administrator group memberships across the forest.
Administrators assigned to this role must be the only ones in the forest that are
allowed to manage and modify service administrator group memberships and
manage service administrator accounts. Microsoft thus recommends that there be
only one instance of this role in a forest. The size of your Active Directory
infrastructure determines the number of service administrator groups and
accounts in your environment, and that number determines the number of service
administrators to assign to this role. As a best practice, you should strive to keep
the number of administrators assigned to this role down to a bare minimum.
To state the responsibilities assigned to this role again, administrators in the
Service Admin Managers role should be the only ones responsible for the
creation, management, protection, and deletion of all service administration
accounts and security groups in an Active directory forest.
 67

Note
It might seem logical to eliminate the Service Admin Managers
role and to assign these tasks to the Forest Configuration
Operators role. However, it is usually advisable to separate
the responsibility for service administrator group and member
management from the responsibility for the entire forest.
Generally, all service management tasks can have a forest-
wide impact; therefore, it can be argued that all tasks should
be assigned to the Forest Configuration Operators role.
However, the purpose of the Forest Configuration Operators
role is to address highly security-sensitive administrative
tasks, each of which has a clearly visible forest-wide impact.
The purpose of the Service Admin Managers role is to protect
and manage all service admin groups and accounts in the
entire forest. It is true that these administrative tasks in the
wrong hands could be used to cause forest-wide impact.
However, the objective is not simply to grant restricted
abilities — the objective is to make service management more
tractable. An organization could very well decide to make the
same set of administrators members of more than one service
management role.

Domain Controller Administrators Role

Managing Domain Controllers and keeping domain controllers running with
current software and proper configurations is of primary importance throughout
the forest for ensuring delivery of the directory service. In addition to managing
services, administrators who manage domain controllers are responsible for
managing the data in the file systems of domain controllers that is also critical to
delivery of the directory service.
Microsoft thus recommends entrusting responsibility for managing all aspects of
Domain Controllers to the Domain Controller Administrators role.
Administrators in this role are responsible for tasks that include but are not
limited to the following operations on domain controllers:
• Installing and modifying software
• Installing service packs and hot-fixes
• Configuring directory service settings in the registry
• Maintaining and backing up event logs
• Configuring the Service Control Manager
• Managing directory service files and Sysvol
• Starting and shutting down domain controllers
• Other security-sensitive operations, including directory database offline
operations
Domain controllers should always be placed in highly secure locations. Most
organizations deploy multiple domain controllers in a central datacenter and also
68

deploy multiple domain controllers in several remote datacenters to provide

global coverage.
Some organizations might have a large number of satellite sites for branch
offices that have only one or two domain controllers. In this situation,
organizations are very highly encouraged to evaluate and deploy a remote
administration solution, such as Remote Insight Lights-Out (RILO) to provide
complete remote administration and management of domain controllers based in
remote locations by a centrally managed administrative team. RILO-based
remote server management solutions enable central management of remote
servers from the primary operations center. These products are typically
hardware-based and allow an administrator to remotely perform almost any
function that can be performed locally, other than actually modifying the
hardware on the remote servers. Organizations that have a large number of
branch office sites should ideally have an administrative group that is located at
the primary operations center for the Active Directory environment. The
centrally located group is responsible for remotely managing domain controllers
in all branch offices.
Use the following criteria to determine how many instances of the Domain
Controller Administrators role to assign:
• When datacenters are deployed in different locations, assign one instance of
the role for every physical location that houses multiple domain controllers.
Assign administrators to this role on the basis of the number of domain
controllers that must be managed. It is recommended that the number of
administrators assigned to each instance of this role be kept to an absolute
minimum. In the situation where domain controllers are housed in a data
center that also houses other servers providing various applications and
services, if at all possible do not make administrators responsible for
managing other servers and services members of this role, and select and
appoint only the most highly trusted and skilled administrators to this role.
• When domain controllers are located in a large number of branch office sites,
assign an additional instance of the role to carry out branch office
administration from the datacenter where the domain controllers for the
forest root domain are located. Assign administrators to this role on the basis
of the number of domain controllers that must be managed. Again, if at all
possible, minimize the number of administrators assigned to this role but
ensure that you can provide continues coverage.
For more information about products that enhance remote administration of
Windows-based servers, search the Windows Server Catalog. To find the
Windows Server Catalog, see the Windows Server Catalog link on the on the
Web Resources page at http://go.microsoft.com/fwlink/?LinkID=291.
 69

For more information about planning for remote server management, see
“Planning for Remote Server Management” in Planning Server Deployments” of
the Windows Server 2003 Deployment Kit (or see “Planning for Remote Server
Management” on the Web at http://go.microsoft.com/fwlink/?LinkId=15309.

Note
It might seem completely logical to eliminate the Domain
Controller Admins role and to assign these tasks to the Forest
Configuration Operators role. However, the objective is to
separate responsibility in order to make service management
more tractable. The purpose of the Domain Controller Admins
role is to provide adequate coverage to ensure that the server
management aspects of Domain Controllers are more than
adequately taken care of. If a Domain Controller goes down,
its impact is immediately noticeable and usually unaffordable.
It is true that these administrative tasks in the wrong hands
could be used to cause forest-wide impact. Thus, as is the
case with all service management roles, ensure that you
assign only extremely trustworthy and highly skilled
administrators to all service management roles. An
organization could very well decide to make the same set of
administrators members of more than one service
management role.

Backup Operators Role

Backing up data is critical to every computer environment. As part of normal
operational practices, you should regularly back up domain controllers and
secure the backup media to minimize the risk of data tampering or theft.
Backing up Active Directory is performed by backing up system state. System
state includes Active Directory, the domain controller registry, and Sysvol.
Because the system state backup contains all directory service–related data, theft
of the backup media presents the same risks as theft of the domain controller or
theft of a disk drive from the domain controller. The attacker could restore the
information elsewhere and gain unauthorized access to Active Directory data.
Administrative tasks that involve backing up Active Directory can be aggregated
and assigned to the Backup Operators role. Administrators in this role are
responsible for backing up system state on a specified schedule.
For an Active Directory single-forest environment, create one instance of this
role for every domain in the forest. For the single instance of this role, assign not
more than two or three administrators. In addition, from an operational
perspective, it is recommended that a specific domain controller be used to
perform regular backup operations; a domain controller located in a main
datacenter would make an ideal candidate.
70

Note that the administrative task of restoring Active Directory has been assigned
to the Domain Configuration Operators role. This is because the act of restoring
Active Directory, unlike backing up Active Directory, is not a regular or frequent
task – it is only performed when an Active Directory partition needs to be
restored from backup.

Note
It might seem completely logical to eliminate the Domain
Controller Admins role and to assign these tasks to the Forest
Configuration Operators role. After all, a Backup operator is
sufficiently privileged to be able to log on to a Domain
Controller and back up Active Directory. Should an
administrator in this role turn malicious or be coerced, he or
she could modify the backed up data to inject malicious
changes. However, the objective is to separate responsibility
to make service management more tractable. It is true that
these administrative tasks in the wrong hands could be used
to cause forest-wide impact. Thus, as is the case with all
service management roles, ensure that you assign only
extremely trustworthy and highly skilled administrators to all
service management roles. An organization could very well
decide to make the same set of administrators members of
more than one service management role.

Schema Administrators Role

Because the schema is common to the entire forest, its modification has a forest-
wide impact. Improper modifications can result in disrupting the operation of
existing applications or in corrupting the directory. In addition, the ability to
modify the schema provides the ability to modify the default security descriptors
of classes. Default security descriptors protect newly created objects in the
directory. Therefore, through certain changes to the default security descriptor, a
malicious administrator can gain the ability to compromise security by creating
user objects that have highly elevated privileges. To isolate this responsibility to
a few select administrators, a separate role is assigned for schema management.
Administrators who are assigned to the Schema Administrators role are
responsible for all aspects of schema management. This includes making changes
that involve the extension of the Active Directory schema as well as making
changes that involve deactivating existing classes or attributes and/or specifying
that an attribute be replicated to the Global Catalog.
 71

For an Active Directory single-forest environment, create one instance of this

role. For the single instance of this role, assign one or a maximum of no more
than two administrators.

Note
It might seem completely logical to eliminate the Schema
Admins role and to assign these tasks to the Forest
Configuration Operators role. After all, a Schema Administrator
could modify default security descriptors and escalate his or
her privilege. Should an administrator in this role, turn
malicious, or be coerced, he or she could modify the Schema
and in the worst case cause Active Directory to stop
functioning. However, the objective is to separate
responsibility to make service management more tractable. It
is true that these administrative tasks in the wrong hands
could be used to cause forest-wide impact. Thus, as is the
case with all service management roles, ensure that you
assign only extremely trustworthy and highly skilled
administrators to all service management roles. An
organization could very well decide to make the same set of
administrators members of more than one service
management role.

Replication Management Administrators Role

Active Directory replication automatically synchronizes data among domain
controllers in a forest that store replicas of the same directory partitions.
Replication is critical to ensure that all domain controllers provide current data.
Although replication between domain controllers in the same site requires no
manual configuration, replication between domain controllers in different sites
must be manually configured to optimize network bandwidth and set replication
latency between sites to acceptable levels. While Active Directory replication
was designed to require minimal administrative intervention, ensuring healthy,
timely and optimal replication of Active Directory requires that the replication
topology be set up properly and be appropriately configured when a change is
required, and that replication be monitored to ensure uninterrupted and reliable
delivery of service
Microsoft recommends that all administrative tasks that involve setting up and
configuring replication topology and all tasks that involve managing the
operational aspects of replication (changing replication configuration) be
assigned to the Replication Management Administrators role. Administrators in
this role are responsible for tasks that include but are not limited to:
• Creating, managing, and deleting sites
• Associating subnets to sites
• Creating, managing, and deleting site links and site-link bridges
• Adding and removing sites from site links and site-link bridges
• Modifying the replication schedule and replication interval on site links
72

• Creating and deleting manually created connections

• Forcing replication between two domain controllers
• Force a full replication synchronization
Note that once the replication topology is initially set up, it will not require
frequent changes unless new requirements call for the modification of the
existing replication topology.
For an Active Directory single-forest environment, create one instance of this
role. For the single instance of this role, depending on the size of the Active
Directory environment, this role should have only the minimum number of
administrators required at any given time to react to replication related issues.
Replication Monitoring Operators Role
Microsoft recommends that all administrative tasks that involve monitoring
replication activity be assigned to the Replication Monitoring Operators role.
Administrators in this role are responsible for tasks that include but are not
limited to:
• Monitoring replication
For an Active Directory single-forest environment, create one instance of this
role. Since the replication monitoring requirements are usually dependent on the
size and complexity of an organization’s Active Directory environment, the
number of administrators to assign to this role should be determined based on the
smallest number of administrators that need to be monitoring replication during a
single work shift, multiplied by the number of work shifts in the organization.
Responsibility for replication management is thus divided between two roles:
• A role to manage replication topology, including creating and maintaining
sites and subnets, site links, and site link bridges, as well as configuring site
links and make configuration changes as required
• A role to monitor replication
Although all replication tasks could be assigned to just one role, separating
administration of tasks that are specific to managing the replication topology
from tasks that are specific to monitoring and configuring replication provides
separation of responsibilities and increases accountability. It is for this reason
that Microsoft recommends two separate roles for complete replication
management.
 73

Note
It might seem logical to eliminate the Replication Management
Admins and Replication Monitoring Operators roles and to
assign these tasks to the Forest Configuration Operators role.
After all, any administrator in either role could disrupt service,
thereby causing forest–wide impact. However, the objective is
to separate responsibility to make service management more
tractable. It is true that these administrative tasks in the
wrong hands could be used to cause forest-wide impact. Thus,
as is the case with all service management roles, ensure that
you assign only extremely trustworthy and highly skilled
administrators to all service management roles. An
organization could very well decide to make the same set of
administrators members of more than one service
management role.

DNS Administrators Role

Microsoft recommends that all administrative tasks involved in managing Active
Directory–integrated DNS be assigned to the DNS Administrators role. This role
provides complete administrative coverage of Active Directory–integrated DNS
management.
Administrators in this role are responsible for tasks that include but are not
limited to:
• Installing the DNS Server service on domain controllers
• Configuring domain controllers that are running DNS to use either
forwarding or root hints for recursive name resolution, depending on which
method the existing DNS service uses
• Configuring the forest root domain controller to host the DNS zone that
corresponds to the forest root DNS name
• Configuring the domain controllers for each regional domain to host the DNS
zone that corresponds to the DNS name of the domain
• Configuring the zone containing the forest-wide locator records to replicate
to every DNS server in the forest by using the forest-wide DNS application
partition
For an Active Directory single-forest environment, create one instance of this
role. The number of administrators required for this role depends on the size of
the environment and the number of domain controllers that are DNS servers. It is
recommended that the number of administrators in this role be limited to an
operationally required minimum.
For more information about DNS integration with Active Directory, see
“Deploying DNS” in Deploying Network Services of the Windows Server 2003
Deployment Kit (or see “Deploying DNS” on the Web at
http://go.microsoft.com/fwlink/?LinkId=4709.
74

Note
Any DNS administrator could disrupt service, thereby causing
a forest–wide impact. However, the objective is to separate
responsibility to make service management more tractable. It
is true that these administrative tasks in the wrong hands
could be used to cause forest-wide impact. Thus, as is the
case with all service management roles, ensure that you
assign only extremely trustworthy and highly skilled
administrators to all service management roles. An
organization could very well decide to make the same set of
administrators members of more than one service
management role.

Summary of Recommended Roles

The set of 10 Microsoft recommended roles listed earlier in this document is
sufficient to provide administrative coverage for all aspects of Active Directory
management and does so in an efficient and security-conscious fashion that
enhances the security worthiness of your Active Directory service, reduces the
risk of inadvertent misuse of high levels of privilege, eliminates requiring a large
number of highly-privileged administrators (such as Domain Admins), increases
accountability, clearly separates responsibilities, and ensures that all aspects of
your Active Directory environment have adequate administrative coverage.
The set of recommended roles together provides coverage for all categories of
service management described earlier, as shown in Table 1.
Table 1 Service Management Categories and Service
Management Roles
Service Management Category Service Management Role
Installation management Forest Configuration
Operators
Domain Configuration
Operators
Schema management Schema Administrators
Trust management Forest Configuration
Operators
Knowledge Reference Forest Configuration
management Operators
Operations Master Roles Forest Configuration
management Operators
Domain Configuration
Operators
Backup and Restore Backup Operators
management Domain Configuration
Operators
 75

LDAP Policy management Forest Configuration

Operators
Directory Service Configuration Domain Controller
management Administrators
Replication management Replication Management
Administrators
Replication Monitoring
Operators
Functional Levels management Forest Configuration
Operators
Directory Database Domain Controller
management Administrators
Security Policy management Security Policy
Administrators
Service Admin Groups and Service Admin Managers
Accounts management
DNS management DNS Administrators
Domain Controller Domain Controller
management Administrators

Table 2 presents a role-centric view of the various service management

categories covered by each role.
Table 2 Role-Centric view of Service Management Category
Coverage
Service Management Role Service Management Covered
Category

Forest Configuration Installation management

Operators Trust management
Knowledge Reference
management
Operations Master Roles
management
LDAP Policy management
Functional Levels management
Domain Configuration Installation management
Operators Operations Master Roles
management
Backup and Restore
management
Security Policy Security Policy management
Administrators
76

Service Admin Managers Service Admin Groups and

Accounts management
Domain Controller Directory Service Configuration
Administrators management
Directory Database
management
Domain Controller management
Backup Operators Backup and Restore
management
Schema Administrators Schema management
Replication Management Replication management
Administrators (topology and operational
aspects)
Replication Monitoring Replication management
Operators (health monitoring)
DNS Administrators DNS management

Default Service Administrative Groups

Every installation of Active Directory has a number of default service
administrative groups, some of which are sufficiently privileged to carry out all
service-management administration tasks. For example, members of the
Enterprise Admins, Domain Admins, and Built-In Administrators groups can
perform all administrative tasks that are involved in managing an Active
Directory service environment. For all practical purposes, these groups can be
considered to have equal abilities.
By default, these accounts are granted access to directory and server resources
when Active Directory is installed. “Appendix N: Default Active Directory
Service Administrative Groups” in “Best Practices for Delegating Active
Directory Administration: Appendices,” which accompanies this document, lists
every default service administrator group and account and provides a brief
description of each group and account, including the qualities that make each
group a service administrative group.
This deserves mention because once a delegation model based on Microsoft-
recommended roles is created and implemented, most of these security groups
should theoretically no longer be required. Thus an organization could choose to
gradually empty the memberships of most of these groups after carefully
ensuring that the groups are no longer required. However, the following groups
should ideally not be emptied: Enterprise Admins, Domain Admins, Builtin
Admins, and Schema Admins. These groups should be retained either because
they might be used to implement a Microsoft recommended role (for example,
Backup operators or Schema Admins) or they might be required in the event of
 77

an emergency situation that warrants some action to be taken by Enterprise or

Domain Admins.
The decision to consider emptying and possibly discontinuing some of these
groups is purely at the discretion of service owners and is dependent on whether
or not an organization chooses to implement all the Microsoft-recommended
roles. Some organizations might choose to customize and delegate some or a few
Microsoft-recommended roles while others might choose to stick to the default
service administrative group, and still others might completely embrace and
implement a service management delegation model based on Microsoft-
recommended roles.

Creating a Service Management Delegation Model

The process of creating an administrative delegation model that addresses service
management needs must be guided by security and efficiency considerations. By
following the recommendations that are presented in this section, you can create
a documented administration model that ensures that:
• Administrative coverage has been provided for all aspects of Active
Directory service management.
• Administrative responsibilities have been distributed among appropriate
administrative groups in accordance with sound security practices.
Many service administrative tasks require permissions that allow an
administrator to make potentially harmful changes to the directory service.
Harmful changes might be made in error, by a malicious administrator, or by an
unauthorized administrator who has usurped permissions. Avoiding errors is the
reason for selecting the most highly skilled administrators to perform security-
sensitive administrative tasks. Avoiding malicious changes is the reason for
selecting the most highly trusted service administrators. And avoiding the ability
of an unauthorized administrator to wrongfully gain permissions is the reason for
incorporating security measures into the delegation model itself.
The efficiency of the administrative delegation model requires that tasks be
divided among the appropriate number and level of administrators to provide an
optimal workload, while also providing complete coverage. Both the efficiency
and security of the administrative delegation model are served by assigning the
least privileges that are required to perform each task.
78

Note
The information in this document applies to Active Directory
infrastructures that have an existing forest and domain
structure. For information about creating a forest and domain
structure, see “Designing the Active Directory Logical
Structure” in Designing and Deploying Directory
and Security Services of the Windows
Server 2003 Deployment Kit (or see
“Designing the Active Directory Logical
Structure” on the Web at
http://go.microsoft.com/fwlink/?LinkId=4723
).
Guidelines for Creating a Service Delegation Model
Creating an efficient and security-conscious model based on these roles involves
the following steps:
1. Understand the nature of the responsibilities assigned to each Microsoft-
recommended role and, if needed, customize the definition of these roles
by adding or removing assigned tasks from the recommended role
definitions.
2. Determine the number of instances of the role that are required for your
environment. The number of instances of each Microsoft-recommended
role is presented earlier in this document and is summarized in Table 3:
Table 3 Service Management Roles and Recommended
Number of Instances
Service Management Role Recommended Number of
Instances
Forest Configuration One instance per forest
Operators
Domain Configuration One instance per domain
Operators
Security Policy One instance per forest
Administrators
Service Admin Managers One instance per forest
Domain Controller 1. One instance for every set of
Administrators domain controllers physically
located in a centrally or
remotely located datacenter
2. One instance for the set of all
domain controllers physically
located in remote locations
but centrally managed via
remote management
solutions
 79

3. Optionally, one instance for

every domain controller that
is locally managed at a
branch office, assuming that
a remote management
solution is not being used.
Backup Operators One instance per domain
Schema Administrators One instance per forest
Replication Management One instance per forest
Administrators
Replication Monitoring One instance per forest
Operators
DNS Administrators One instance per forest

3. Based on the size and specifics of your Active Directory environment,

determine the number of administrators to assign to each instance of the
role.
4. For each instance of each role, identify the specific administrators that shall
be assigned to the role. Document these role assignments.

Documenting Your Service Administrative Delegation Model

After completing the process for creating the administrative delegation model,
service owners should document the model and then maintain this document on
an ongoing basis. When changes in service administration are required due to
organizational changes or growth, the model must be changed to reflect the new
requirements.
The administrative delegation model document should include the following:
• A list of all roles that are being used
• The number of instances of every role
• A list of administrators that are assigned to each role instance
• The administrative responsibilities that are assigned to each role
Later in the process, when the delegation model is implemented, update this
document to include the following information:
• The specific security group that is used to represent each role instance
• The specific permissions granted to each security group
• All audit settings that are set to monitor administrative operations
Table 4 is a template you can use to document your role instances.
80

Table 4 Template to Document Specific Role Instances (With

Example Values)
Field Assignment Information
Role Instance Name: Contoso Sec Pol Admins
Instance of: Security Policy Admins
Instance #: 1 of 1
Assigned Administrators: Michael Allen
Assigned Tasks: No customization – based on
Microsoft-recommended role-
to-task assignments.
Refer to document located
at: document location
Security Group To be supplied during
Implementation phase
Permissions Assigned To be supplied during
Implementation phase
Notes Members in this role are
based in Chicago
Security Clearance
requirements met for all
administrators

Implementing the Service Management Delegation Model

Implementing the service administrative delegation model involves the creation
of security groups to represent role instances and the granting of sufficient
permissions for every security group representing a role instance so as to enable
the administrators in each role (represented by membership in corresponding
security groups) to carry out their assigned responsibilities. The implementation
process is performed by a select few service administrators who are trusted by
the service owner to faithfully delegate the administrative roles according to the
delegation model. These administrators are usually members of the Enterprise
Admins group.
To implement each role, the administrator responsible for implementing the
service management delegation model performs the following general tasks:
1. Define a location to store the security groups that represent all role
instances.
2. Create a new group to represent the role or designate an existing default
administrative group (for example, Schema Admins) for each role instance.
3. Enable each instance of the role by doing the following:
 81

a. Assign the collective set of permissions (required to perform the set of

all administrative tasks assigned to a role) to the security group
representing the specific instance of the role.
b.Assign the collective set of user rights (required to perform the set of all
administrative tasks assigned to a role) to the security group representing
the specific instance of the role for all operations that the administrators
must perform on the system (usually the domain controller).
4. Delegate the role that you have enabled by adding the user accounts of the
assigned administrators to the appropriate group.
Make sure that the groups that you use to implement the role are used only
for that role and contain only the assigned administrators as members.

Storing Security Groups for Service Management

Most security groups for service management will be created in, and managed
from, the forest root domain. Thus, it is appropriate to create and store the
security groups that represent service administration role instances in a specific
location so that they can be managed easily.
Create an OU in the forest root domain, directly under the domain object. Name
the OU “Service Management” or choose a similar name that adequately
conveys the purpose of the OU.
Figure 1 shows a domain hierarchy with the Service Management OU.
Figure 1 OU for Service Management Group Accounts
82

Creating or Assigning Security Groups

Table 5 shows a recommended list of names to use for the security groups that
represent various instances of service management roles.
Table 5 Recommended Names for Service Management Role
Instances
Service Management Recommended Names
Role
Forest Configuration Forest Name Forest Config Ops
Operators
Domain Configuration Domain Name Domain Config Ops
Operators
Security Policy Forest Name Security Policy
Administrators Admins
Service Admin Managers Forest Name Service Admin
Managers
Domain Controller Domain Name location DC
Administrators Admins
location could refer to:
4. A set of domain controllers
physically located in a centrally
or remotely located datacenter
5. A set of all domain controllers
physically located in remote
locations but centrally managed
via remote management
solutions
6. Every domain controller that is
locally managed at a branch
office, assuming that a remote
management solution is not
being used.
Backup Operators Use the pre-defined Backup
Operators group for this role

Schema Administrators Use the pre-defined Schema

Admins group for this role

Replication Management Forest Name Repl Mgmt Admins

Administrators
Replication Monitoring Forest Name Repl Monitoring Ops
Operators
DNS Administrators Forest Name DNS Admins
 83

Enabling Service Management Administrative Roles Instances

“Appendix L: Implementing Service Management Delegation Roles” in “Best
Practices for Delegating Active Directory Administration: Appendices,” which
accompanies this document, provides the guidelines for implementing each
service management role and provides the set of permissions that should be
granted to implement each role. Implementing each role instance by granting the
set of permissions provided for each role enables each role instance.

Protecting Service Management Administrative Role Instances

After you have implemented your service management administrative role
instances, it is recommended that you adequately protect all security groups
representing the various administrative role instances and their members.
One way of doing this is to make every security group representing a role
instance a member of one of the default service administrator groups protected
by the AdminSDHolder object . Certain administrative roles instances can be
represented by existing service administrator groups in Active Directory – these
security groups do not need to be members of another service administrator
group. This will ensure that only the Service Admin Managers and Enterprise
Administrators can modify the memberships of all service admin accounts and of
all administrative roles.
It is recommended that you make all these groups members of the Print
Operators group in the specific domain to which the security groups representing
the roles belong, and take away the Load and unload device drivers privilege
from Print Operators (by modifying the default Domain Controller security
policy in each domain). This will ensure that all security groups representing
administrative roles are protected. Note that there is nothing special about the
Print Operators group. The use of this group to protect service admin role
instances is only being recommended because it is one of the less used service
administrative groups.

Delegating Role Instances

To delegate role instances, modify the group memberships of the respective
security groups representing each role by adding the user accounts of all
administrators that were assigned to each role during the model creation phase.
Do not forget to update your documentation for each role, noting specifics such
as the collective set of permissions assigned and the specific security group used
to implement each service administration role instance.
84

Maintaining the Service Management Delegation Model

Service delegation models require minimal maintenance under most operating
conditions. Tasks that are required to maintain the service delegation model can
include:
• Adding (delegating) or removing (undelegating) members to or from service
administration role instances
• Adding new instances of roles in the event of infrastructure changes such as,
but not limited to:
• Addition of a new branch site that has domain controllers for the domain
of the business unit
• Removal of a branch site
• Modifying a role by assigning or revoking a new or existing task from the
role definition
• Creating new custom roles if the need arises
• Undelegating a role completely by revoking all permissions that are granted
to the group that represents the role

Adding or Removing Members from Role Instances

To add or remove members from existing role instances, simply modify the
membership of the security group representing the role.

Adding New Role Instances

To add a new role instance, follow steps 2 through 4 listed in “Implementing the
Service Management Delegation Model” earlier in this document.

Modifying a Role Definition

To modify an existing role definition, perform the following steps:
1. Modify the documented set of administrative tasks assigned to a specific
role definition by adding a new task, removing an existing task.
2. Identify all existing instances of this role and appropriately modify the
permissions granted to the role as follows:
a. If a new task was added to the role, determine the minimal and precise
set of permissions required to delegate the new task by referring to
“Appendix A: Active Directory Administration Tasks” in “Best Practices
for Delegating Active Directory Administration: Appendices,” which
accompanies this document, and appropriately grant the security group
representing the specific instance of this role the set of permissions
determined earlier (as indicated in “Appendix A”).
b. If an existing task was removed from the role definition, determine the
minimal and precise set of permissions that are required to delegate this
 85

task by referring to “Appendix A: Active Directory Administration

Tasks” in “Best Practices for Delegating Active Directory
Administration: Appendices,” which accompanies this document, then
ensure that the same setoff permissions (or even one of them) is not
required to perform any other tasks in the role definition, and then
appropriately revoke assigned permissions for the security group
representing the specific instance of this role (as indicated in “Appendix
A”).

Creating New Custom Roles

To create a new custom role, perform the following steps:
1. Understand and document the purpose of the new role.
2. Assign a set of administrative tasks to this new role.
3. Determine the minimal and precise set of permissions required to delegate
the set of administrative tasks identified earlier.
4. Document the general scope where permissions must be applied in the
directory (or perhaps on the file system or registry or Group Policy on
Domain Controllers).
To enable new instances of this role, follow steps 2 through 4 listed in
“Implementing the Service Management Delegation Model” earlier in this
document.

Undelegating Role Instances

To undelegate existing role instances, perform the following steps:
1. Revoke all permissions granted to the security group representing the
specific instance of the role. This might involve revoking user rights in the
Domain Controller Security policy.
2. Optionally, empty the group membership of the security group representing
the specific instance of the role.
3. To ensure that all permissions have been removed, double-check your
documentation and make sure that permissions have been removed from all
places where they were initially granted.
Creating custom roles involves using the delegation process that described earlier
Note
Dsrevoke.exe, a command-line tool that
automatically revokes permissions, can be
used to revoke delegated authority, but only
on an OU. Because most of the data that is
protected by service management role
permissions is stored in the configuration
and schema directory partitions in Active
Directory, or in the file system or registry of
a domain controller, manual intervention is
usually required to undelegate a service
administration role.
86

Chapter 4: Delegating Data Management

Data management involves managing all aspects of the data stored in or
protected by Active Directory. This content includes domain data, which
primarily consists of accounts for users and computers, security groups, and
application-specific data.
User accounts represent the identities of an organization’s users, and thus data
management includes identity management. Security-groups enable aggregation
of a set of users for the purpose of authorization, and thus security group
management plays a key role in securing an organization’s IT resources. Security
group management is also a key data management category. Active Directory–
integrated and –enabled applications can store application specific data in Active
Directory, and management of application-specific data is also a part of data
management.
Finally, computers can be viewed as providing resources in an IT infrastructure.
From end-user workstations to file servers, and from hosting a Web farm to
running enterprise applications, computers provide resources in an organization’s
IT infrastructure. Thus resource management is yet another data management
category.
This chapter provides guidance for how to use delegation to provide
administrative coverage for all aspects of data management in an Active
Directory environment. The chapter presents an overview of the various
categories that data management includes and provides recommendations about
how to efficiently delegate all aspects of data management in a security-
conscious manner.

Recommended Approach to Data Management

As mentioned in Chapter 1, a structured and methodical approach towards
managing an Active Directory environment can greatly enhance the security of
the environment, reduce administrative costs involved in managing the
environment and successfully address the administrative needs of all
stakeholders, thereby making Active Directory management more tractable
seamless, efficient and secure.
It is not uncommon for multiple business units to participate in a shared Active
Directory environment. Each business unit ,while participating in a shared Active
Directory environment, can have its own domain data and IT resources. Each
business unit should be assigned a data owner who should have overall
responsibility for all aspects of data management for that business unit. Business
unit owners appoint a small set of their most highly trusted administrators to the
role of Business Unit Admins – this administrative group represents the
operational arm of the data owner.
Since data owners are entrusted with overall accountability for the security-
conscious, efficient, and effective management of the content stored in Active
Directory and on computers joined to Active Directory, it is their responsibility
 87

to create a delegation model under which administrative responsibility for

managing business unit data is distributed among and delegated to their data
administrators also in an effective, efficient, and security-conscious manner..
It is important to note that this chapter provides best-practices for delegation
only on a per domain basis. Thus, if your Active Directory environment has
multiple domains, you should apply the best-practices and guidelines presented
in this chapter for creating a delegation model to each domain in your Active
Directory environment.
A structured and methodical approach towards Active Directory data
management generally involves the following recommended steps:
1. Service owners hand-off data management of each business unit to the
respective data owners of each business unit.
2. Business Unit data owners in turn create, implement and maintain a
delegation model for managing business unit data.
This approach offers two primary benefits. It clearly separates responsibility for
service management and data management. Additionally, it grants responsibility
for data management of data that belongs to a specific business unit to the
business unit owners themselves. . This gives them the flexibility to create,
implement and maintain their data in a manner that best addresses the specific
administrative needs and requirements of that business unit.
After service owners have handed off responsibility for data management to data
owners, the data owners, together with their high-level administrators, should do
the following:
1. Understand all aspects of Active Directory data management.
2. Understand the administrative needs of all stakeholders.
3. Create a delegation model that ensures that administrative coverage is
provided for all aspects of Active Directory management and that the
administrative needs of all stakeholders are addressed.
4. Implement the Active Directory data management delegation model in an
efficient and security-conscious fashion, ensuring that the administrative
needs of all delegated administrators and all stakeholders are addressed,
while also ensuring that all administrative access has been granted on the
basis of least privilege.
5. Maintain the implemented delegation model, which involves making
modifications to the model in response to changes in administrative
requirements or needs.

Understanding Data Management

The following section provides an overview of all data management categories
and is aimed at helping you gain a better understanding of all aspects of Active
Directory data management. This section also presents Microsoft-recommended
roles that should be sufficient for providing administrative coverage for all
88

aspects of Active Directory data management, taking into account the

administrative needs of the service owners and administrators, who are the main
stakeholders in Active Directory data management.

Data Management Categories

Data management involves managing all aspects of the data stored in or
protected by Active Directory. This content includes domain data, which
primarily consists of accounts for users and computers, security groups, and
application-specific data. As mentioned earlier in this chapter, data management
includes account management, security-group management, resource
management and application-specific data management.
Account Management
Account management entails managing all aspects of user accounts – from
creating new accounts to maintaining them and providing account support to
disabling and finally deleting accounts that are no longer needed. For example,
when a user joins a business unit, either a new account must be created or an
existing account must be moved from an existing business unit. During its
existence, the account requires maintenance and support. Account support
includes administrative operations like resetting passwords and unlocking user
accounts. At some point, the user leaves the business unit and the account must
be discontinued: Account management includes the administrative tasks for
disabling and finally deleting user accounts.
Security Group Management
A security group is a collection of security principals. Security-groups enable
aggregation of a set of users for the purpose of authorization. Security group
management typically includes such administrative tasks as creating security
groups, provisioning security groups to grant access to various resources,
managing the membership of security groups, and discontinuing security groups.
Security groups typically have two main uses:
• Accounts Groups – Security groups can serve as resource groups that are
used to grant access to resources.
• Resource Groups – Security groups can also serve to aggregate security
principals to collectively authorize access to resources, which is usually
achieved by making an account group a member of a resource group.
Security groups play a major role in implementing an organization’s IT
authorization strategy, and thus security group management should not be taken
lightly.
Resource Management
An organization’s IT resources typically include end-user workstations, servers,
and applications and resources that are running or hosted on member servers, and
in some cases on end-user workstations. All of the these collectively constitute
an organization’s IT resources, and all require administrative coverage. Resource
 89

management thus plays an important role in managing an IT infrastructure and

Active Directory plays a central role in facilitating resource management.
Resource management involves providing the means for administrators to:
• Manage end-user workstations – Provide general IT support, including
installation and troubleshooting.
• Manage individual servers – Manage the physical computer, including
monitoring, hardware maintenance, and installation.
• Manage resources hosted on servers – Manage the service aspects of
resources and applications (including business applications and portals) that
are hosted on one or more servers.
The delegation capabilities of Active Directory can be used to meet the
administrative needs of organizations of all sizes. Active Directory can facilitate
the distribution and delegation of administrative responsibility for managing all
aspects of an organization’s IT resources, taking into account administrative
needs specific to the organization.
Workstation Management
Workstations that are used in day-to-day operations require administrative
support. Administrators or operators who are responsible for workstation
management need administrative access to these workstations. The access they
require is provided as a part of delegating administrative authority for data
management.
Server Management
In every IT organization, servers play a major role in providing essential
services, from serving files to hosting databases and business applications. For
example, one set of servers might collectively play the role of file servers, while
another set hosts a database application such as Microsoft® SQL Server™. A set
of servers might host parts of a distributed application that provides middle-tier
functionality, while another set of servers might host internal Web portals for
business applications. These servers and the applications and services that they
host need to be managed.
As part of resource management, administrators who are responsible for
managing computers need appropriate access to these servers, including the
ability to monitor the health of the servers, manage event logs, modify hardware
and install drivers, install service packs and hot-fixes, and perform other similar
tasks.
Server Resource Management
Services and applications hosted on a collection of one or more servers also need
to be managed and require administrative coverage, often by personnel different
from those who manage the physical computer. Managing the service aspects of
the applications that are hosted on servers includes administrative tasks such as
monitoring the service, performing configuration changes to the service, and
ensuring that the service continues to be delivered as specified by service level
90

agreements. These administrators might also require the ability to authorize

access to the services that are provided by these servers. For example,
administrators for a Web application might require the means to authorize the set
of end-users that have access to the application.
Application-Specific Data Management
Active Directory–integrated and –enabled applications, such as Microsoft
Exchange Server, usually store application-specific data in Active Directory. As a
part of managing their applications, administrators for these applications usually
require administrative access to their application-specific data stored in Active
Directory. Additionally, administrators of these applications might also require
the ability to authorize the users of their applications to access and/or modify
their application data. Application-specific data management involves facilitating
the required access for all stakeholders of an Active Directory–integrated or –
enabled application and typically involves delegating management of
application-specific data to an application’s stakeholders.

Recommended Roles for Data Management

A particularly effective method for creating an efficient administrative delegation
model is to use administrative roles. A model that allows IT departments to
delegate administrative responsibilities on the basis of business functions and
administrative scopes lets organizations focus on business processes as opposed
to technology processes. Defining these functions and scopes in terms of
administrative roles enables business-driven administrative control while
affording the ability to securely scale administration.
A roles-based approach to delegation makes management of delegated
responsibility more tractable and increases the security of Active Directory.
Additionally, it allows you meet additional needs for delegation in a simple yet
deterministic fashion. Thus a roles-based approach to delegating data
management is highly recommended.
Microsoft has engineered a set of recommended roles for delegating data
management. These role recommendations take into account the sets of logically
related administrative tasks and the security sensitivity and impact of these tasks.
The following is the set of recommended roles for delegating service
management:
• Business Unit Admins
• Account Admins
• Workstation Admins
• Server Operators
• Resource Admins
• Security Group Admins
• Help-Desk Operators
 91

• Application-Specific Admins
Depending on its specific administrative needs, an organization might choose to
create and implement a delegation model based on Microsoft-recommended
roles or a set of custom roles (which might or might not be based on Microsoft
recommended roles) defined by the organization.
Business Unit Admins Role
It is not uncommon for multiple business units to participate in a shared Active
Directory environment. Each business unit, while participating in a shared Active
Directory environment, can have its own domain data and IT resources. Each
business unit should be assigned a data owner who should have overall
responsibility for all aspects of data management for that business unit.
Each business unit data owner should have a Business Unit Admins
administrative role representing the operational arm of data owners. This role
should be assigned at least one administrator and no more than a small number of
administrators. This administrative group will have complete authority over all
business unit data in the directory. Administrators in this role are the business
unit’s highest-ranking data administrators and are responsible for implementing
and maintaining the administrative delegation model for business unit data
management. Business Unit Admins also work closely with data owners during
the creation of the OU structure to advise about how features such as inheritance
of permissions and Group Policy affect the OU structure.
Typically, organizations will choose to first create and implement their service
management delegation model, following which the data management model
will be implemented. As a part of this process, the service owners should hand
over responsibility for Active Directory data management to data owners. During
the transfer of responsibility for data management to the data owner, the service
owner should create one instance of this role for every business unit. Depending
on the size of the business unit, this role should be assigned to no more than a
few administrators. Administrators in this role delegate responsibility for the
business unit by creating an OU hierarchy and creating and populating
administrative groups to manage each OU in the hierarchy.
For more information about the creation and delegation of this role, see
“Transferring Data Management to Business Unit Owners” later in this
document.
Account Admins Role
Every business unit has user accounts that need to be created, managed, and
supported. Microsoft recommends the role of Account Admins for providing
administrative coverage to manage user accounts. Responsibilities for user
account management include creating accounts, populating account attributes,
managing and maintaining accounts, and deleting accounts. Responsibility for
account support should ideally be assigned to the Help Desk Operators, thereby
removing that burden from the Account Admins role.
92

The Business Unit administrator of each business unit is responsible for creating
one or more instances of the Account Admins role to provide administrative
coverage for all aspects of Account management for all business unit user
accounts, depending on the OU structure and the distribution of accounts among
sub-units that the business unit might contain.
Workstation Admins Role
The Workstation Admins role is recommended for managing workstations.
Depending on the administrative model, a business unit can have one or more
instances of this role. For example, a business unit might be spread across
multiple locations and might staff each location with a local administrative group
that is responsible for managing these workstations. In this case, each local group
must be delegated responsibility for managing all workstations for the business
unit in that location. The number of members in each role depends on the
requirements for each role instance and is typically a function of the number of
workstations that need to be supported by a specific role instance.
Server Operators Role
Microsoft recommends the role of Server Operators to provide administrative
coverage for managing an organization’s server computers. Administrators
assigned to the role are typically responsible for managing servers.
Resource Admins Role
Microsoft recommends the Resource Admins role for facilitating administrative
coverage of a collection of one or more servers and the common services hosted
on this set of one or more servers. Administrators who are assigned to this role
are responsible for managing the resource (application, database, or files) and the
set of servers on which the resource is hosted. For instance, an organization
might choose to create a cluster out of a small number of physical servers, and
this cluster of servers might serve as a single virtual file server. Administrators
who have been granted responsibility for managing this single virtual file server
will require the ability to manage each of these servers and manage the virtual
file server. One instance of this role should be created for every such resource in
the business unit.
In some cases, depending on the administrative model, the group of
administrators who manage the servers is different from the group of
administrators who manage the services that are hosted on these servers. This
role can also be used to facilitate management of only the services hosted on one
or more servers. Thus, the meaning and the nature of tasks assigned to specific
instance of this generic role can differ from one instance to another.
Security Group Admins Role
Microsoft recommends the role of Security Group Admins for managing all
security groups required to meet the authorization needs of a Business Unit.
Administrators in this role are responsible for creating and managing both
account and resource security groups, and delegating the ability to manage the
 93

membership of some of these groups while retaining control over group

membership of other security groups, as needed.
Microsoft recommends the implementation of one instance of this role per
business unit. The reason that only one instance of this role is recommended is
that any individual who can create more than 1015 security groups can misuse
his or her authority or be coerced into launching a denial of service attack that
could impact the ability of every user in the forest to log on.
Administrators for the various IT resources will typically require resource groups
for the purpose of being able to authorize access to their resources and will also
typically require account groups for the purpose of being able to aggregate a set
of users to whom access can be then granted. IT resource administrators should
request the creation and provisioning of required account and resource groups
from the administrators in the Security Group Admins role. Administrators in this
role are responsible for validating requests and then creating and provisioning
the requested security groups so as to enable resource administrators to be able to
use the requested groups.
Application-Specific Admins Roles
Active Directory–enabled or –integrated applications might store application-
specific data in different places in Active Directory, and each such application
might differ in its administrative requirements for managing application data
stored in the directory. For example, certain applications might extend the class
definition of user objects and store their application-specific user information on
those extended user objects, while other applications might create their own OUs
and store application-specific data in those application-specific OUs.
In either case, owners of such applications will typically request administrative
access for their administrators to be able to manage application data. Microsoft
recommends the use of Application-Specific Admins role to facilitate the access
required by administrators of such applications. Use a separate custom
Application-Specific Admins role for every application that stores application-
specific data in Active Directory and whose administrators need administrative
access to this data.
In addition to the administrators of the application, you might have to provision
access for the following accounts which will typically require the ability to
perform operations on the application data:
• Instances of the application, running in some security context (LocalSystem
or a service account)
• Users of the application
When creating the delegation model, the service owner for each such application
makes a request to the data owner to create the role. The service owner specifies
the location of the application-specific data, the accounts that require access to
the data, and the scope of the access. The data owner relays this information to
the Business Unit administrator, who then facilitates this access by implementing
instances of this role.
94

Custom Roles
Microsoft-recommended roles are intended to facilitate the creation and
implementation of a well managed and efficient Active Directory data
management delegation model. They are by no means the only way to address
the delegation requirements of an organization.
In addition to the roles recommended by Microsoft, organizations can choose to
create custom roles to address unique administrative requirements. Creating a
custom role involves the following steps:
1. Understand and document the purpose of the new role.
2. Assign a set of administrative tasks to this new role.
3. Determine the minimal and precise set of permissions required to delegate
the set of administrative tasks identified earlier in this chapter.
4. Document the general scope where permissions must be applied in the
directory.
After making these decisions, you can determine the number of instances that are
required, create the groups to represent each instance of the role, assign
permissions to enable the role, and populate the groups with the appropriate
administrative user accounts.

Determining Data Management Stakeholder Needs

In order to provide administrative coverage for all aspects of data management,
you first have to understand your data management administrative needs. This
involves evaluating administrative requirements specific to your organization for
each aspect of data management.
1. The following approach is useful in understanding and documenting the
administrative needs of all data Identify the number of business units
participating in the domain.
2. For each business unit, determine the following:
management stakeholders:
• User Accounts. Determine the total number of accounts and the number
of administrative groups involved in account management or that require
the ability to manage accounts.
• Workstations. Determine the total number of workstations, the number
of locations, and the number of administrative groups involved in
workstation management or that require the ability to manage
workstations.
• Member Servers. Determine the total number of servers, the number of
locations, and the number of administrative groups involved in server
management or that require the ability to manage servers.
 95

• Resources. Resources can include Web, file, application, or database

servers or services. Determine the total number of servers and services,
the number of locations, and the number of administrative groups
involved in resource management or that require the ability to manage
resources.
3. For each business unit, determine the Group Policy requirements.

Creating the Data Management Delegation Model

The data owners of each business unit should create an administrative delegation
model to distribute and delegate administrative responsibility among the data
administrators.
Creating a delegation model involves the following steps:
1. Determine your role requirements and determine the number of instances
and scope of administrative authority of each data management role.
2. Plan an OU hierarchy based on the administrative delegation and Group
Policy requirements of the business unit.
3. Assign specific administrators or administrative groups to the role
instances.
4. Document the model.
At the end of this process, business unit data owners should have a documented
administrative delegation model that ensures the following:
• Administrative coverage has been provided for all aspects of content
management.
• Administrative responsibilities have been distributed according to sound
security practices among the instances of the various roles.
• Administrators and administrative groups have been mapped to the
various instances of the data administration roles.
Responsibilities for each category of data administration tasks are delegated by
using administrative roles that are instantiated as security groups. As mentioned
earlier, organizations can choose to create their delegation model around
Microsoft recommended roles or around custom created roles which might or
might not depend on Microsoft-recommended roles.

Determining Role Requirements

The first step in the creation of your delegation model is to determine the
following:
• The number of instances and the scope of administrative authority of each
data management role.
• The specific set of administrators that will be assigned to each role instance.
96

Required Data Management Roles

The following are the recommended set of roles for Active Directory data
management:
• Business Unit Admins
• Account Admins
• Workstation Admins
• Server Operators
• Resource Admins
• Security Group Admins
• Help-Desk Operators
• Application-Specific Admins
Business Unit Admins
One instance of this role will be required for every business unit.
Account Admins
One instance of this role will be required for every administrative group that
needs the ability to manage user accounts. For each such administrative group,
document the scope of authority by documenting the set of users that should be
managed by this group. Also, for each instance, determine the set of
administrative tasks that incumbents of the role should be allowed to perform.
The following is a list of common administrative tasks that belong to this
category:
• Create user accounts
• Delete user accounts
• Move user accounts
• Reset a user’s password
• Unlock user accounts
• Modify non-security sensitive information, such as phone numbers
• Modify security-sensitive information
Examples of security-sensitive information include whether or not a
password is required on the account, whether the account is trusted for
delegation, and modifying the UPN of the user account.
• Authorize access to the account
For each instance, evaluate the needs for and document the set of administrative
tasks that incumbents of the role should be allowed to perform. This information
will be used during the implementation phase to delegate each of these
administrative role instances.
 97

Workstation Admins
One instance of this role will be required for every administrative group that
needs the ability to manage workstations. Most organizations have one or more
administrative groups for every location that houses workstations. For each such
administrative group, document the scope of authority by documenting the set of
workstations that should be managed by this group.
Workstation management typically includes being able to manage all aspects of
workstations; thus, incumbents in this role typically are Local Administrators on
member workstations.
Server Operators
One instance of this role will be required for every administrative group that
requires the ability to manage servers. Most organizations have one or more
administrative groups for every location that houses servers. For each such
administrative group, document the scope of authority by documenting the set of
servers that should be managed by this group.
Server management typically includes being able to manage all aspects of
member servers; thus, incumbents in this role typically are Local Administrators
on member servers.
Resource Admins
One instance of this role will be required for every administrative group that
needs the ability to manage resources (services or applications being hosted on a
set of one or more servers and collectively managed by a single group of
administrators). For each such administrative group, document the scope of
authority by documenting the set of servers and the specific service that
constitute the resource that should be managed by this group.
Resource management typically includes being able to manage all aspects of the
service and manage all aspects of the servers on which the service is being
hosted, although this might not always be the case. In some cases, the
responsibility might be restricted to being able to manage only the service that is
being hosted on or more servers.
Security Group Admins
There should only be one instance of this role for every business unit. Depending
on the specific administrative needs of the business unit, the business unit data
owners might decide to create more than one instance of this administrative role.
For each instance determine the set of administrative tasks that incumbents of the
role should be allowed to perform.
The following is a list of common administrative tasks that belong to this
category:
• Create security groups
• Modify the membership of security groups
• Modify other properties, such as managed-by information
• Delete security groups
98

For each instance evaluate the need for and document the set of administrative
tasks that incumbents of the role should be allowed to perform. This information
will be used during the implementation phase to delegate each of these
administrative role instances.
Help Desk Operators
One instance of this role will be required for every administrative group that
needs the ability to provide account support to a subset of user accounts or to all
user accounts. For each such administrative group, document the scope of
authority by documenting the set of users for whom this group will provide
account support.
The following is a list of common administrative tasks that belong to this
category:
• Reset passwords on user accounts
• Unlock user accounts
• Optionally, a business unit might also decide to grant its help desk operators
the ability to modify certain attributes on user objects; these attributes will
typically be non-securitysensitive attributes that users cannot themselves
modify
For each instance, evaluate the need for and document the set of administrative
tasks incumbents of the role should be allowed to perform. This information will
be used during the implementation phase to delegate each of these administrative
role instances.
Application-Specific Admins
One instance of this role will be required for the administrative group of every
Active Directory–enabled or Active Directory–integrated application that
requires the ability to manage application-specific data stored in Active
Directory. For each such administrative group, document the scope of authority
by documenting the set of application-specific data that this group will require
the ability to manage.
The nature of administrative tasks in this category is typically a function of the
specific Active Directory–enabled or Active Directory–integrated application
deployed and the specific administrative requirements of that application. The
administrators of these applications should have a good understanding of these
administrative requirements. The business unit data owners should understand
these requirements and plan for facilitating the required access to enable these
administrators to carry out their administrative tasks.
Assigning Administrators to Role Instances
For each instance of every data management role required, document the
identities of all administrators who will be assigned to these role instances.
 99

Planning an OU Hierarchy
Planning an OU hierarchy based on the administrative delegation and Group
Policy requirements of the business unit is one of the first steps in creating a
delegation model. A well-designed OU hierarchy should adequately address an
organization’s Group Policy requirements while also facilitating the delegation of
administrative authority based on the organization’s administrative requirements.
This section provides recommendations for creating a well-designed OU
hierarchy.
An OU for every Business Unit
In the section “Implementing Your Data Management Delegation Model” later in
this document, as part of the handoff process wherein service owners hand off
data management delegation to data owners, a single high-level OU named
Business Units will be created with the purpose of creating a subtree to contain a
single high-level OU for each business unit. That way, all domain data can be
contained within this one OU subtree rooted at the Business Units OU instead of
at the Domain root. This recommended approach has the following advantages:
• This facilitates delegation of administration of each business unit to the
respective business unit administrator while allowing the specification of any
permissions that might be required to delegate administrative authority over
data across all business units at the Business Units OU instead of at the
Domain root. This prevents the inheritance of any ACEs applied in the
System container and in the DNS containers, thereby substantially reducing
the number of ACEs, which might impact the size of that database
significantly in Windows 2000. In Windows 2003, the concept of single-
instances makes this a non-issue. For example, if the administrative needs of
Contoso Pharmaceuticals required that a single centralized administrative
group be delegated the authority to provide Account support for all business
units in the domain, their administrators would typically grant the security
group representing the operators in the Account support role inheritable
permissions expressed in three or four ACEs applied on the domain root
object. While this would have the effect of the ACEs flowing down to all user
objects in all business units, it would also result in these ACEs flowing down
on all DNS record objects in the DNS container; assuming that there are
about 5000 records in the DNS container, this approach would result in 5000
additional ACEs in Windows 2000, significantly impacting the database size.
On the other hand, if these inheritable ACEs were applied on the Business
Units OU in the recommended approach, they would only be inherited by
objects stored in the subtree rooted at the Business Units OU.
• This also increases the manageability of domain data by eliminating the need
to create multiple OUs that are peers of the OUs that exist by default. It
increases manageability because it leaves the top-level OU hierarchy
unchanged with the exception of the addition of a single OU, thereby
minimizing the possibility of confusion.
100

Each business unit is then represented by an OU directly under the Business

Units OU, and as is presented in “Implementing Your Data Management
Delegation Model” later in this document, the handoff process also involves
granting the Business Unit Admins of each business unit full control over their
OUs. Business unit data owners and Business Unit Admins are then free to create
their own OU sub-structure to manage business unit content.
The next issue to consider is the creation of an OU structure for the business unit
so that responsibility for managing business unit content can be delegated while
also taking into account Group Policy requirements. The general approach is to
first create an OU sub-structure for the business unit based on delegation of
administration requirements, and then apply Group Policy on existing OUs or
add additional OUs, possibly in various parts of the OU tree, for the purpose of
applying Group Policy. There should be a well-understood reason for the
presence of every OU in the OU structure.
An OU for Storing Delegated Roles
An organization that plans to create and implement a roles based delegation
model will require an OU to store the security groups representing the various
roles. Dedicating one OU to storing the security groups allows the Business Unit
Admins to easily identify all delegated roles and have a single point of
administration to control the set of administrative roles and the set of
administrators assigned to each administrative role. Thus it is recommended to
create an OU dedicated to storing all administrative roles, as a child object of the
OU representing the Business Unit.
Creating the First Level of OUs
The following recommendations are aimed at creating an OU structure that
meets your organizations needs while remaining simple and flexible, thereby
allowing room for change, extensibility, and any modifications that might be
needed to address changing administrative needs. To create the first level of
OUs, perform the following tasks:
1. Create a single OU under the Business Unit OU for storing all business unit
user accounts.
You should plan on storing all your user accounts in this OU.
Recommendations for how to create an OU hierarchy within this OU to
address specific administrative requirements for account management are
provided later in this section.
2. Create a single OU under the Business Unit OU for storing all business unit
security groups
You should plan on storing all security groups required to meet the
authorization needs of your IT resources in this OU. Recommendations on
how to create an OU hierarchy within this OU to address specific
administrative requirements around account management are provided
later in this section.
 101

3. Create a single OU under the Business Unit OU for storing all business unit
user resources
You should plan on storing computer accounts for all your workstations
and servers within this OU. Recommendations on creating an OU
hierarchy within this OU to address specific administrative requirements
around workstation and server management and facilitate delegation of
resource management to specific administrative groups are provided later
in this section.
Figure 2 shows a representative OU structure based on the recommendations
presented earlier in this section. Note that Product Development and Business
Management are the two Business Unit OUs, one for each of the two business
units in the fictitious organization represented in the example.
Figure 2 High-Level OU Structure for a Business Unit OU

The OU structure thus far can be used to perform the following delegations:
• An organization can delegate account management of all business unit
accounts to a single administrative group by granting appropriate permissions
on the Accounts OU. This is sufficient for a small organization with a single
location and a relatively small number of users.
102

• An organization can delegate workstation management of all business unit

security groups to a single administrative group by granting appropriate
permissions on the Security Groups OU. This is sufficient for a small
organization with a single location and needing relatively small numbers of
security groups to address its authorization requirements.
• An organization can delegate overall resource management of all business
unit IT resources to a single administrative group by granting appropriate
permissions on the Resources OU. This is sufficient for a small organization
with a single location and a relatively small number of IT resources to
manage.
• An organization can delegate account support for all business unit user
accounts to a single administrative group by granting appropriate permissions
on the Accounts OU. This is sufficient to meet the needs of an organization
of any size that has a single administrative group that provides centralized
account support
Creating OUs to Delegate Account Management
For most small organizations where there is only one group responsible for
account management, the OU structure for account management described
earlier in this section should be sufficient to delegate account management to that
administrative group.
Depending on your administrative needs for delegating account management, an
OU subtree can be created under the Accounts OU to facilitate distribution of
account management responsibilities among various groups.
For every Account management role identified earlier in this section that requires
the ability to manage a specific set of users, create a single OU under the
Accounts OU and store in this OU the user accounts of the specific set of users
that this group is responsible for managing. For example, if the business unit
contains four divisions, and each division requires the ability to manage its own
users, create one OU for each division and store all user accounts that should be
managed by the administrators of a specific division in the OU corresponding to
the division.
The creation of an additional level of OUs will enable the delegation of account
management to the Account Admins of each division. In some cases, the Account
Admins of a division might want to sub-delegate account management to other
Account Admins within the division, one for each sub-division. An organization
can create an additional set of OUs under each divisional OU to sub-delegate
account management to other Account Admins within the division.
In general, an OU typically corresponds to a unit of delegation, in that it can be
used to apply a set of permissions that become effective on all objects in the
subtree rooted at the OU. From that perspective, a new OU or a new level of
OUs can be added to facilitate delegation of administrative responsibility.
The following are some common scenarios of administrative requirements that
can be addressed by the recommendations described earlier in this section:
 103

• Assume that your organization is spread across multiple locations and your
IT model requires delegation of account management to locally based
administrative groups. In this scenario, you can create an additional set of
OUs, one for each location, and then store user accounts in the OU
representing the physical location where the user account is based. You can
then distribute and delegate account management by specifying permissions
on these OUs.
Figure 3 illustrates the three-location OU structure that accommodates user
accounts that must be managed separately in Locations A, B, and C.
Figure 3 Decentralized Account Administration for Four
Locations

Each location in Figure 3 has a different set of administrators in the role of

Account Admins. To implement this scenario, the Business Unit Admin creates
four instances of the Account Admins role, each represented by a unique security
group. The Business Unit Admin can grant either Full Control over their
respective OUs or specific permissions to delegate specific administrative tasks
within the Accounts OU to each instance of Account Admins.
104

• Assume that your IT model requires that different categories of users be

managed by separate administrative groups. For example, suppose your IT
model requires that all user accounts for contracting employees are to be
managed by one administrative group while all user accounts for full-time
employees are to be managed by another administrative group. You can
create an additional level of OUs, one representing contracting employees
and the second representing full-time employees.
• Taking this one step further, suppose that an additional constraint requires
that all user accounts for all company executives are to be separately
managed by yet another administrative group. In this case, you can create a
third level of OUs under the OU representing full-time employees, separate
regular full-time employees from executives, and accordingly grant
permissions on both OUs to delegate account management to different
groups.
• You can use the same OU structure to apply a different Group Policy to
contractors and full-time employees. Thus, most of the time, you can also
derive the additional benefit of being able to meet your administrative
requirements and address Group Policy requirements.
• Assume that you have no requirements for further distributing account
management. You can still create a second level of OUs to meet Group
Policy application needs. For example, assume that corporate policy dictates
that a stricter user policy be applied to user accounts of all users who travel
extensively. You could create a second level OU structure for the purposes of
applying Group Policy to a specific set of users.
These scenarios are only meant to illustrate the creation of an OU structure for
addressing administrative and policy enforcement requirements. Other
administrative requirements similar to those illustrated here can also be similarly
addressed by the creation of an appropriate OU structure.
Creating OUs to Delegate Security Group Management
Most organizations can benefit from the creation of an additional level of OUs
within the OU assigned for storing and managing security groups. A well-
designed OU subtree within the Security Group OU can also make managing
security groups for administering IT resources more tractable.
The following is a recommended structure for OUs within the Security Group
OU
Create the following OU structure under the Security Group OU:
• An OU for storing common account groups; a suggested name is Common
Account Groups
• An OU for storing Account and Resource groups for specific IT resources; a
suggested name is Resource Specific Groups
Use the Account Groups OU to store and manage common account groups for
your business unit. Examples include Business Unit Users, Location A, Division
 105

B Users, Division C Managers, Business Unit Executives, and Business Unit

Executive Assistants.
Use the Resource Specific Groups OU to manage resource-specific account and
resource groups as follows. Within the Resource Specific Groups OU, perform
the following steps to create the OU structure:
• Create one OU for the different kinds of resources in your organization.
Examples include Web-Servers, File-Servers, Application servers, and
Database servers.
• Within each resource-specific OU, create one OU for each specific resource.
For example, within the OU for Web server security groups, create an OU for
the Web servers hosting the Human Resources Web application and another
OU for the Web servers hosting one of the Intranet Web sites.
• Within the OU for a specific resource, create one OU for storing the account
groups and another OU for storing the resource groups that resource
administrator might require to authorize access to the resource. For example,
the administrator of a Web portal will require at least multiple resource
groups to specify who can access the Web portal and to what extent. The
resource administrator will also require the ability to specify a collection of
users that can access the Web portal in a particular way. For instance, the
Web portal administrator might use an account group FT to collect all full-
time employees and a separate account group CT to collect all contractors.
The administrator would then make the FT group a member of the resource
group that was used to specify to the Web application all users who have
unrestricted access to all parts of the portal, while making the CT group a
member of the resource group that was used to specify to the Web application
all users who have restricted access to all parts of the portal.
The OU structure recommended earlier in this section can be used to simplify
security group management and make it more tractable.
Figure 4 shows an example OU structure that collects account groups in the
Account Groups OU and separates resource groups into OU trees according the
resources. This OU structure associates the groups with their respective resources
for easier management.
106

Figure 4 Security Groups OU Structure for Account and

Resource Groups

Note that the recommendations described earlier in this section are by no means
the only way to facilitate management of security groups. Organizations should
take their specific administrative needs into account when designing their OU
structures. For example, one alternative to storing resource specific security
groups in the Security Groups OU is to create an OU to store all security groups
for a specific resource under the specific OU representing this resource in the
Resource OU subtree, as presented later in this section. This has the additional
advantage of storing the security groups associated with a resource along with
the servers representing the resource, thereby storing all aspects of a resource in
one small subtree.
What is important is to understand how an OU enables delegation of
administrative authority and to apply this understanding to the creation of an OU
structure that addresses your organization’s administrative delegation and Group
Policy requirements.
 107

Creating OUs to Delegate Resource Management

The benefits of a well-designed OU structure are most evident in the delegation
of resource management. This section describes a recommended structure to
facilitate delegating resource management.
Note that the recommendations presented here are by no means the only way to
facilitate resource management. Organizations should take their specific
administrative needs into account when designing their OU structures.
To create the recommended OU structure for delegating resource management,
within the Resources OU, perform the following steps to create the OU structure:
• Create one OU to store all workstation accounts; a suggested name is
Workstations.
• Create one OU each for every type of resource in your business unit;
examples include file servers, Web portals, applications and databases.
Workstation management
The Workstations OU can be used to store computer accounts for all
workstations in your business unit. An additional level of OUs can be used to
address specific administrative requirements. Workstation management is
typically delegated to local administrative groups. Thus, an organization could
create an additional level of OUs, one for each physical location where the
business unit has a presence, and all workstations for a specific physical location
can be stored in the OU representing that physical location. Such an OU structure
can be used to easily delegate workstation management to all administrative
groups. In general, the various instances of the Workstation Admins role will
usually correspond to the OUs under the Workstations OU; this is because in
general, each OU serves to separate workstation accounts for the purpose of
provisioning management of these accounts by a separate administrative group.
Delegating workstation management typically involves granting complete
control over the computer account representing the workstation and using the
restricted groups feature of Group Policy to make an administrative group a
member of the administrators group on these workstations. Since OUs can
facilitate both the granting of full control and the application of Group Policy,
they can be used to delegate workstation management.
Figure 5 shows the OU structure that illustrates this decentralized approach to
managing workstations.
108

Figure 5 Regional OU Structure for Workstation Resource

Management

Resource Management
A well-designed OU structure can also be used to manage servers and to delegate
management to the respective administrative groups of the various IT resources
that are hosted by a collection of servers. The recommendation earlier in this
chapter to create one OU for every type of resource under the Resources OU aids
in increasing manageability of resources.
Under the OU created for each resource type, introduce an additional level of
OUs with each OU in this level representing a specific resource. For example,
under the Web Servers OU, create a specific OU for storing the computers of all
servers on which the Human Resources Web portal is collectively hosted.
Figure 6 illustrates such an OU structure.
 109

Figure 6 Grouped File Server Resource OUs

The OU hierarchy structure for resource management that is recommended

earlier in this chapter offers the following benefits:
• It allows you to delegate administrative authority for all resources of a
specific type to a specific administrative group. For example, you could
delegate overall management of all file servers to an administrative group
responsible for overall file-server management by granting sufficient
permissions on the File Servers OU. This group will then be able to manage
all file servers within the organization.
• It allows you to delegate administrative authority of specific IT resources to
only those administrative groups that have been assigned the responsibility to
manage that specific resource. For example, you could specify appropriate
permissions on the various OUs representing specific file servers to delegate
management of those file servers to specific administrators.
These recommendations are by no means the only way to facilitate resource
management. Organizations should take their specific administrative needs into
account when designing their OU structures.
After you have created your OU hierarchy structure based on your organization’s
administrative requirements and needs, you should then consider your
organization’s Group Policy application requirements.
110

Considering Group Policy Application Requirements

An OU hierarchy structure should be based on administrative delegation
requirements and Group Policy application requirements. Group Policy can be
associated with OUs and is applied onto all user and computer accounts stored in
the OU. Thus, Group Policy application requirements also impact the OU
structure.
It is recommended that the OU hierarchy be first designed based on delegation of
administration requirements, and then be appropriately modified to address
Group Policy application requirements. The following examples illustrate this
guideline. Assume that an organization has decided on the OU structure
presented in Figure 7.
Figure 7 Representative OU Structure for a Business Unit OU

In the first example, assume that Group Policy requirements for this organization
include that a location-specific Group Policy be applied to all computers based
on their location, irrespective of the role of the computers. To accommodate this
requirement, the OU hierarchy structure in
 111

Figure 7 can be modified as follows:

• In the Resources OU, directly below the Resources OU, introduce a single
level of OUs, one for each physical location in the business unit. Within each
such OU representing a physical location, recreate the same set of OUs as
initially designed. Thus, each OU representing a specific location should
have one child OU for Workstations and one child OU each for the different
types of resources within the business unit. Each of these OUs in turn should
continue to have the same sub-structure as was initially created. The primary
difference in the modified OU hierarchy structure is that an additional level
of OUs has been introduced for the sole purpose of applying Group Policy.
Note that these OUs are not being used for delegating administrative
authority, although nothing prevents using them for this additional purpose if
necessary.
In the second example, assume that Group Policy requirements for this
organization include that a location-specific Group Policy be applied to all
workstations, based on their location:
• To accommodate this requirement the OU hierarchy structure will not need to
be modified, because an organization might already typically have in place a
level of OUs separating workstation accounts based on their location. These
OUs can then be used to apply Group Policy to workstations based on their
location
In the third example, assume that Group Policy requirements for this
organization include that a specific Group Policy be applied to all users that
belong to a specific division within the business unit:
• In this case, depending on the OU structure within the Accounts OU, an
additional level of OUs could be introduced to separate the accounts by
division, if they are not already separated, and Group Policy can then be
applied to the specific OUs representing each division with the business unit.
These examples illustrate how an OU hierarchy model primarily based on
delegation of administration requirements can be suitably modified to address
Group Policy application requirements.
Having gained an understanding of how OUs can be used to both delegate
administrative authority and meet Group Policy application requirements, you
can proceed to create an OU hierarchy based on your administrative delegation
requirements and your Group Policy application requirements. After you have
created the OU hierarchy, you are ready to document your delegation model and
move to the implementation phase.

Documenting Your Delegation Model

Before proceeding to the implementation phase, be sure to document your
administrative roles requirements, your OU hierarchy, and your Group Policy
requirements. Table 6 is a template that you can use to document your role
instances.
112

Table 6 Template to Document Specific Role Instances (With

Example Values)
Field Assignment Information
Role Instance Name: Division I Account Admins
Instance of: Account Admins
Instance Number: 1 of 4
Assigned Administrators: Clair Hector
Assigned Tasks: Create user accounts
Manage all properties
Control access to accounts
Delete user accounts
Sub-delegate
Refer to document located
at: document location
Security Group To be filled during
Implementation phase
Permissions Assigned To be filled during
Implementation phase
Notes Sub-delegation allowed
Most group members based
out of Chicago
Group contact: (555)-123-
4567 e-mail: DIAccAdm

In addition, for each OU in the OU hierarchy structure, document the following:

• Primary purpose – Delegation and/or Group Policy application
• Secondary purpose (if any) – Also being used for Delegation and/or Group
Policy application
• Details – Document all necessary details
• Administrative Contact – Provide administrative contact details

Implementing Your Data Management Delegation Model

After the data owners of each business unit have created their administrative
delegation models, Business Unit Administrators should implement their
respective delegation models. However, before Business Unit Administrators can
delegate their models, service owners need to hand off data management to data
owners and provision the Business Unit Admin roles.
Implementing the delegation model involves setting permissions on Active
Directory objects. Active Directory ships with a set of delegation tools that can
be used to apply and manage permissions in Active Directory. For a list of these
 113

administration tools and for details about how to use them, see “Appendix G:
Active Directory Delegation Tools” in “Best Practices for Delegating Active
Directory Administration: Appendices,” which accompanies this document. It is
recommended that you invest the time to gain familiarity with these tools, as
these tools are required to manage permissions. One alternative to using these
tools is to use scripting to manage permissions.

Handing Off Data Management to Data Owners

Typically, organizations will choose to create and implement their service
management delegation model, following which the data management model
will be implemented. As a part of this process, the service owners should hand
over responsibility for Active Directory data management to data owners by
handing off data management to the respective business unit administrators, who
represent the data owners. These high-level data administrators have overall
responsibility for managing business unit content in Active Directory. They
represent the data owners in implementing the respective business unit
delegation models.
High-level service administrators represent the service owners in performing the
tasks that are required to hand off data management to data owners. To hand off
data management to business unit data owners, a member of the Domain
Configuration Operators role or the Domain Admins group performs the
following tasks in each domain:
1. Create a new OU as an immediate child of the domain object. A suggested
name for this OU is Business Units. It serves as a high-level container for
all domain content.
2. Within the Business Units OU, create one OU for each participating
business unit, and name them appropriately following a standard
convention.
3. Within the Business Units OU, create an additional OU for storing the
security groups that will be used for representing the Business Unit Admins
administrative role instances and instances of any other role that will
require access to all business unit OUs. A suggested name for this OU is
Delegation.
4. Within the Delegation OU, create one security group for every instance of
the Business Unit Admins role; that is, create one domain local group for
each business unit. Name each security group appropriately: a
recommended name format is BusinessUnitName Admins.
5. On each of the security group objects that you create in step 4, grant the
following permissions to the security group account itself:
a. Property permission Read All Properties
b. Property permission Write Members
6. On each business unit OU object, to the security group that represents the
Business Unit Admins role for that business unit, grant Full Control.
114

7. Create one user account for each Business Unit Admins administrator in his
or her respective business unit OU (these accounts will be moved to an
appropriate OU within the respective Accounts OU by the business unit
administrator after delegation of the business unit OU is implemented).
8. Add each user account to the respective security group that represents the
Business Unit Admins role instance for the business unit.
Figure 8 shows a prototype domain-level OU structure that is created by a
service administrator for handing off data administration to data owners in a
domain that has two business units.
Figure 8 Domain-Level OU Structure and Groups for
Transferring Data Administration

This completes the handoff process of transferring responsibility for data

management to data owners, who are represented by respective Business Unit
Admins, the operational arm of the data owners for the various business units
sharing the domain.
Depending on the size of the organization, it might very well be that there is only
one business unit in the entire domain. The handoff described in this section is
beneficial in that situation too, as it creates an extensible OU structure which can
easily accommodate the addition of new business units to the domain should the
need arise.

Implementing Business Unit Delegation Models

Handing off the responsibility for data management results in the creation of one
high-level OU for every business unit. It also involves enabling the Business
Unit Admins roles and leaves Business Unit OUs ready to be managed by their
 115

Business Unit Admins. Business Unit Admins now have complete control over
their Business Unit OUs and can proceed to implement their delegation models.
This section provides recommendations for implementing an efficient and
security-conscious delegation model.
The following are the recommended tasks involved in implementing the business
unit delegation model:
1. Implement the OU hierarchy structure.
2. Create security groups to represent the various administrative role
instances.
3. Enable Administrative Roles.
4. Delegate Administrative Roles.
Implementing the OU Structure
The first step in implementing the delegation model is to create the OU structure
in the directory. This step is usually simple and straightforward: The Business
Unit Admins create all OUs according to the documented OU structure for the
business unit.
Creating Security Groups to Represent Role Instances
The next step in implementing the OU structure is to create security groups to
represent all required administrative role instances as documented during the
creation of the model. This step is also very straightforward and involves the
following tasks:
1. For every required administrative role instance, the Business Unit Admins
create one security group in the Delegation OU, a child of the Business
Unit OU. These groups are typically Domain Local groups, as their scope
of application is the Domain.

Note
When specifying read access to specific attributes of, or list
access to, an Active Directory domain object, avoid using
domain local groups to set permissions if the attribute or
attributes are included in the partial attribute set that is
replicated to global catalog servers. Instead, consider using a
global group. Users of domain local groups might not be able
to access these attributes if they are outside the domain that
hosts the global catalog to which they are bound. Note,
however, that this affects only read and list access because
Global Catalogs are Read-Only by design.

2. After creating each group, Business Unit Admins can optionally choose to
grant these groups the ability to modify their own group memberships,
thereby allowing administrators in these roles to add or remove other
administrators without Business Unit Admin intervention. This step is
purely a function of the administrative requirements of an organization, and
116

an organization might choose to individually assess this option for every

role instance.
Enabling Administrative Roles
The next step in implementing the delegation model involves enabling all the
required instances of the various administrative roles. Enabling a role involves
granting the security group representing each role instance the minimal set of
permissions required to allow members of this administrative group the ability to
perform all administrative tasks assigned to this administrative role instance.
Enabling account management roles
Every business unit will typically have at least one instance of the Account
Admins role that is granted overall responsibility for managing all aspects of all
user accounts. Additionally, other role instances can be delegated account
management responsibilities for specific sets of users.
To delegate an instance of the Account Admins role, perform the following tasks:
1. Refer to the documented role instance descriptions and identify the scope
of administrative authority. Then map this scope to an OU subtree in the
Accounts OU. Based on this information, determine the point of delegation
for delegating this role instance. The point of delegation is the usually the
object whose DACL will have to be modified to grant the set of
permissions required to delegate this role instance. Note that in some cases,
the point of delegation might actually map to more than one object
depending the nature of the responsibilities being delegated and whether
the objects representing the target of delegation are stored in more than one
location in the OU hierarchy.
For example, assume that the Account Admins role that has been granted
has overall responsibility for all user accounts in the Business Unit. The
point of delegation in this case will be the Accounts OU itself because the
subtree of objects rooted at this OU contains the entire scope of authority
for this role, which in this case refers to all the user accounts in the
business unit.
As a second example, assume that the Account Admins role that has been
granted has account management responsibilities for all accounts in
Division A. The scope of administrative authority is thus all accounts in
Division A. Mapping this to the OU subtree in the Accounts OU reveals
that there is an OU for Division A. This OU contains (or will contain) all
user accounts for Division A. Thus, the point of delegation for this role is
the Division A OU under the Accounts OU.
2. Based on the documented role instance descriptions, determine the minimal
set of permissions required to delegate all assigned administrative tasks by
referring to “Appendix A: Active Directory Administrative Tasks” in “Best
Practices for Delegating Active Directory Administration: Appendices,”
which accompanies this document. This appendix documents the minimal
and precise set of permissions required to delegate every Active Directory
administrative task.
 117

For example, assume that the business unit data owners decided to
delegate only the following tasks to the Account Admins for the Division
A:
• Create user accounts
• Modify all attributes that belong to the Personal Information property-set
According to “Appendix A,” the following are the permissions required to
perform these administrative tasks:
• Create user accounts
• Create Child on parent object
• Modify all attributes that belong to the Personal Information property-set
• Write-Property to the Personal-Information property-set
Thus, in order to delegate this role, the security group representing the
Division A Account Admins role will need to be granted the following
permissions:
• Create Child on parent object
• Write-Property to the Personal-Information property-set
Also, note the specifics of where these permissions are required. Since the
Create Child permission is required on the parent object, which in this case
happens to the be the Division A OU, there is no need to mark that
permission as inheritable. On the other hand, since the Write-Property
permission will actually be required on the user objects, this permission will
need to be marked as inheritable.
3. Once you have determined the point of delegation and the minimal set of
permissions required to delegate the various roles, modify the DACL on
the object that corresponds to the point of delegation and grant the security
group representing each administrative role the identified set of
permissions.
Once these steps have been completed, all administrative roles for account
management will have been delegated.
Enabling security group management roles
Your business unit should have only one instance of the Security Group Admins
role that is responsible for security group management for the entire business
unit.
To delegate an instance of the Security Group Admins role, perform the
following tasks:
1. Refer to the documented role instance descriptions and identify the scope
of administrative authority. Then map this scope to an OU subtree in the
Security OU. Based on this information, determine the point of delegation
for delegating this role instance.
118

2. Based on the documented role instance descriptions, determine the minimal

set of permissions required to delegate all assigned administrative tasks by
referring to “Appendix A: Active Directory Administrative Tasks” in “Best
Practices for Delegating Active Directory Administration: Appendices,”
which accompanies this document. This appendix documents the minimal
and precise set of permissions required to delegate every Active Directory
administrative task.
3. Once you have determined the point of delegation and the minimal set of
permissions required to delegate the various roles, modify the DACL on
the object that corresponds to the point of delegation and grant the security
group representing each administrative role the identified set of
permissions.
In the case of the single administrative role that has been assigned overall
responsibility for security group management, this point of delegation will
correspond to the Security Groups OU. Since this group will typically be
assigned responsibility to manage all aspects of security group
management, although individual permissions for every administrative task
can be granted, this security group could be granted Full Control on all
objects of the class Group.
In some cases, the business unit might decide to delegate security group
management to more than one group. In this case, for each role instance,
determine the point of delegation and the cumulative set of permissions
required to delegate these roles. Then grant the security groups
representing these roles the identified set of permissions by modifying
DACL on the object that corresponds to the point of delegation.
Once these steps have been completed, all administrative roles for account
management will have been delegated.
Enabling resource management roles
Your organization will have typically multiple instances of each resource
management role.
The implementation aspects of delegating resource management are a little
different than those for account or security group management. This is primarily
because delegating resource management usually involves using the delegation
capabilities of Active Directory to make delegated administrators local
administrators on member computers, in addition to granting these administrators
the full-control over the computer account representing the computer. In cases
where these administrative groups only require the ability to manage the service
aspects of a service that they are responsible for, these administrative groups
need not be made local administrators on these computers; it is sufficient to make
them members of local groups that are authorized to manage these services.
Making administrative groups in Active Directory members of local
administrative groups involves the application of a specific feature of Group
Policy – restricted groups. The Restricted Groups feature allows an administrator
to control membership by creating a list that restricts the members of a group and
 119

the groups to which a group can belong. The policy restricts membership by
enforcing the list: any members who are not on the list are removed from the
group; any security principals in the list that are not members of the group are
added to the group.
For more information about restricted groups, see “Restricted Groups” in Help
and Support Center for Windows Server 2003. For more information about
restricted groups, see article 810076, “Updates to Restricted Groups (“Member
of”) Behavior of User-Defined Local Groups” in the Microsoft Knowledge base.
To find this article, see the Microsoft Knowledge Base link on the on the Web
Resources page at http://go.microsoft.com/fwlink/?LinkID=291.
The following example illustrates the application of this feature to delegation of
the workstation management role.
The Production business unit of Contoso Pharmaceuticals has operations in two
physical locations – Chicago and Atlanta. 60 percent of the users of this business
unit are based in Chicago and 40 percent in Atlanta. Every user is typically
assigned one end-user workstation.
Contoso’s OU hierarchy thus has two OUs within the Workstations OU, one
representing Chicago and the other Atlanta. Computer accounts for all
workstations located in Chicago are stored in the Chicago OU. Accordingly,
computer accounts for all workstations located in Atlanta are stored in the
Atlanta OU. Contoso’s data owners have assigned the responsibility of managing
all workstations in the Chicago location to a locally based administrative group
called Chicago Workstation Admins. Members of this administrative group
require the ability to manage all aspects of computer management for these
workstations. They might be called upon to perform a variety of administrative
tasks including, but not limited to, troubleshooting operating system issues,
adding hardware, configuring drivers, and installing patches. Most of these tasks
require administrative access to these workstations.
Contoso’s administrators easily facilitated making this administrative group local
administrators on all workstations by performing the following steps:
1. Creating a security group called Chicago Workstation Admins to represent
this role
2. Granting this security group inheritable full-control on all computer objects
by modifying the DACL of the Chicago OU within the Workstations OU
3. Using the restricted groups feature of Group Policy to make this group a
member of the Local Administrators group on all workstations in Chicago
by applying Group Policy on the Chicago OU and specifying that the
Chicago Workstation Admins be made a member of the Local
Administrators group on all workstations whose computer accounts are
present in the Chicago OU
Enabling resource management administrative roles essentially involves
repeating the steps involved in this example for all administrative roles. The
following recommendations can be used to enable resource management roles.
120

Perform the following steps to enable the various instances of the Workstation
Admins role:
1. Refer to the documented role description for this instance and identify the
scope of administrative authority. Map this scope to an OU subtree in the
Workstations OU. Based on this information, determine the point of
delegation for delegating this role instance.
2. Grant the security group representing this role instance the following
inheritable permission on the point of delegation:
• Full-Control on Computer objects
3. Use the Restricted Groups feature of Group Policy by applying a GPO to
the OU that represents the point of delegation,to make this make the
security group representing the specific role instance a member of the local
Administrators group on all member workstations that are stored in the
OU.
Once these steps have been completed, all administrative roles for workstation
management will have been delegated.
For each instance of the Server Operators role, perform the following steps to
enable the instance:
1. Refer to the documented role description for this instance and identify the
scope of administrative authority. Then map this scope to an OU subtree in
the Resources OU. Based on this information, determine the point of
delegation for delegating this role instance. Refer to your OU model to
determine the specific OU created with the purpose of storing non resource
specific servers. You might have more than OU if you created a high-level
OU under the Resources OU to store non resource specific servers and
possibly created an additional level of OUs within this OU, one for each
physical location that has servers located and depends on local
administrative groups for management of these servers.
2. Grant the security group representing this role instance the following
inheritable permissions on the point of delegation:
• Full-Control on Computer objects
3. Use the Restricted Groups feature of Group Policy by applying a GPO to
the OU that represents the point of delegation, to make this make the
security group representing the specific role instance a member of the local
Administrators group on all member workstations that are stored in the
OU.
Once these steps have been completed for all instances of the Server Operators
role, all administrative roles for server management will have been delegated.
For each instance of the Resource Admins role, perform the following steps to
enable the instance:
1. Refer to the documented role description for this instance and identify the
scope of administrative authority. Map this scope to an OU subtree in the
 121

Resources OU. Based on this information, determine the point of

delegation for delegating this role instance. Refer to your OU model to
determine the specific OU created with the purpose of storing the set of
servers that hosts this specific resource. In an OU hierarchy that was based
on the recommendations in this document, the specific OU for this resource
should be under the corresponding resource-specific OU.
For example, when delegating resource management for the Human
Resources Web portal that is hosted on a set of high-performance Web
servers, there should be one OU under the Web-Servers OU (which is
under the Resources OU) for the Human Resources Web portal. This OU
should contain the set of servers that collectively hosts this Web portal.
This OU is the point of delegation for delegating this role.
2. Grant the security group representing this role instance the following
inheritable permission on the point of delegation:
• Full-Control on Computer objects
3. If the administrative requirements for this role instance require that
administrators in this role be able to manage all aspects of server
management on the servers hosting this resources, use the Restricted
Groups feature of Group Policy (by applying a GPO to the OU that
represents the point of delegation) to make the security group representing
the specific role instance a member of the local Administrators group on all
member servers that are stored in the OU.
4. Use the Restricted Groups feature of Group Policy by applying a GPO to
the OU that represents the point of delegation. The GPO should make the
security group representing the specific role instance a member of the local
group on all member servers stored in the OU that is sufficiently authorized
to manage all service aspects of the service that administrators in this group
will be responsible for managing.
Once these steps have been completed for all instances of the Resource Admins
role, all administrative roles for resource management will have been delegated.
Authorizing access to resources
Administrators who are responsible for managing specific resources might also
require the ability to authorize access to their resources. For this purpose,
Resource Admins can request security groups for each resource.
For example, the Portal A Admin requires the ability to specify who can access
the portal. To authorize access to resources, the Resource Admin can perform the
following tasks:
1. Contact the Security Group Admin and request creation of account and
resource groups as follows:
• A resource group for access to the service
• Account groups to specify collections of users who can access this
service; these groups are added to the resource group
122

2. Request that the Security Admins group grant to the Resource Admins
group the ability to modify the membership of these groups. On each
security group object, grant the following permissions to the security group
account itself:
• Property permission Read All Properties
• Property permission Write Members
The Security Group Admins can evaluate the request and if approved, create the
specific security groups in an appropriate location, thereby enabling Resource
Admins to authorize access to their resources.
Enabling help-desk roles
Every business unit will typically also have at least one instance of the Help
Desk Operators role. Administrators in this role are responsible for providing
account support for user accounts, and typical helpdesk operations include
resetting user passwords and unlocking user accounts. Since most of the
administrative tasks assigned to this role involve providing account support,
most of these administrative tasks involve low-level operations on user account
objects.
To delegate an instance of the Help Desk Operators role, perform the following
tasks:
1. Refer to the documented role instance descriptions and identify the scope
of administrative authority. Map this scope to an OU subtree in the
Accounts OU. Based on this information, determine the point of delegation
for delegating this role instance. For most business units, the scope of
delegation will typically map to the Accounts OU, since in most
organizations a single administrative group is responsible for providing
account support.
2. Based on the documented role instance description, determine the minimal
set of permissions required to delegate all assigned administrative tasks by
referring to “Appendix A: Active Directory Administrative Tasks” in “Best
Practices for Delegating Active Directory Administration: Appendices,”
which accompanies this document. This appendix documents the minimal
and precise set of permissions required to delegate every Active Directory
administrative task.
As mentioned earlier in this section, typical account support tasks include
the following:
• Resetting user passwords
• Unlocking locked out accounts
According to “Appendix A,” the following are the permissions required to
perform these administrative tasks:
• Resetting user passwords
• Reset User Password Extended right on the user account
• Unlocking locked out accounts
 123

• Write-Property permission to the user object

Thus, in order to delegate this role, the security group representing the Help
Desk Operators role for this business unit will need to be granted the
following permissions:
• Reset User Password Extended right on the user account
• Write-Property to the user object
Also, note the specifics of where these permissions are required. Since all
user accounts are stored in the Accounts OU, the application of inheritable
permissions on the Accounts OU should be sufficient to delegate the two
administrative tasks that this group is responsible for.
3. Once you have determined the point of delegation and the minimal set of
permissions required to delegate this role, modify the DACL on the object
that corresponds to the point of delegation and grant the security group
representing this administrative role the identified set of permissions.
Once the earlier steps have been completed, the Help Desk Operators
administrative role will have been delegated.
Note that in some organizations, a single administrative group might be
responsible for providing account support for all Business Units. In this case, the
following recommended approach should be used:
1. Domain Administrators should create a security group within the
Delegation OU that was used to store the security groups representing the
Business Unit Admin role instances.
2. Business Unit Admins of all business units should delegate the Help Desk
Operators role as described earlier in this section.
3. Business Unit Admins of all business units should then add the security
group created by the Domain Administrators to the security group
representing the specific instances of the Help Desk Operators role created
in their business units.
Enabling application-specific data management roles
It is not uncommon for organizations to have Active Directory–enabled or Active
Directory–integrated applications deployed. These applications typically store
application specific data in Active Directory. These applications also have
administrators that might need to manage this data. Business Unit Admins can
create instances of the Application Specific Data Admins roles for the purpose of
delegating all administrative tasks that these administrators might need to
perform to manage their application data.
Active Directory–enabled or –integrated applications might store application
specific data in different places in Active Directory. For example, certain
applications might extend the class definition of user objects and store their
application specific user information on user objects, while other applications
might create their own OUs and store application specific data in these
application specific OUs.
124

Thus, before delegating instances of the Application Specific Data Admins roles,
it is important to identify precisely where the application data is being stored.
This information will be required to determine the point of delegation and the
manner in which application is delegated. For example, if the application stores
data in a separate OU that it creates and this OU happens to be outside of any
Business Unit OU (for example, if it is a child of the Domain object), then the
Domain Admins will be responsible for delegating these roles and the scope of
delegation will typically be the specific OU. On the other hand, if this
application stores application specific data on user attributes (for example, the
application could extend the schema and store user specific information on user
objects), then this falls within the scope of administrative authority of the
Business Unit Admin and the scope of delegation then becomes the Accounts
OU.
To delegate an instance of the Application Specific Data Admins role, perform
the following tasks:
1. Refer to the documented role instance descriptions and identify the scope
of administrative authority. Map this scope to an OU subtree if it maps to
an OU within the business unit. If it maps to an OU outside of the Business
Unit, transfer responsibility for delegating this role to Domain Admins.
Based on this information, determine the point of delegation for delegating
this role instance.
Based on the documented role instance description, determine the minimal
set of permissions required to delegate all assigned administrative tasks by
consulting the application’s administrators.
2. Once you have determined the point of delegation and the minimal set of
permissions required to delegate this role, modify the DACL on the object
that corresponds to the point of delegation and grant the security group
representing this administrative role the identified set of permissions.
Once these steps have been completed, the Application Specific Data Admins
administrative role will have been delegated.
Delegating self-service on user accounts
User accounts store information about users in the form of properties, or
attributes, of the user object. For example, some of these properties include such
information as the user’s home phone number, mailing address, manager, cell
phone number, and so on. Active Directory defines certain property sets that are
collections of such properties. Specifically, a user object has the following
property sets:
• Personal-Information
• Email-Information
• Web-Information
• RAS-Information
• User-Account-Restrictions
 125

• Membership
• General Information
• User Logon
• Domain Password
For more information about the membership of these property sets, refer to
“Appendix E: Active Directory Property Sets” in “Best Practices for Delegating
Active Directory Administration: Appendices,” which accompanies this
document.
The default security descriptor for user objects, as defined in the Active
Directory schema, grants users the ability to modify the following property sets:
• Personal-Information
• Email-Information
• Web-Information
User in your business unit might require the ability to modify other properties on
user objects in addition to the properties that are covered by these three property
sets. In this case, additional administrative steps are required to grant users the
required permissions. To grant additional access to users, perform the following
tasks:
1. Identify the specific properties that users are to be able to modify.
2. To all users, grant Write-Property permissions (inheritable) to SELF.

Note
Alternatively, your organization might
choose to revoke the user’s ability to modify
certain attributes that users can modify by
default. Additional administrative steps are
also required to revoke specific permissions
from users.
For the exact set of permissions that are required to modify a specific property or
a collection of properties, see “Appendix A: Active Directory Administrative
Tasks” in “Best Practices for Delegating Active Directory Administration:
Appendices,” which accompanies this document.
Delegating Administrative Roles
The next step in implementing the delegation model involves delegating all the
required instances of the various administrative roles. Delegating a role simply
involves modifying the group memberships of the security groups of all
administrative roles that have been enabled. The act of making an administrator a
member of a security group that represents an administrative role results in the
role having been delegated to an administrator.
To delegate the various administrative roles that have been enabled, do the
following for each role instance:
126

• Modify the group membership of the security group representing this

instance of the administrative role by adding to the membership the user
account of every administrator that has been assigned to this role. Refer to
the documented description for the role instance to obtain the list of all
administrators that have been assigned to this role.
The delegation model for your business unit is now completely implemented and
ready to use. All administrators should now be able to perform all administrative
tasks assigned to them.

Best Practices for Implementing Delegation

The following list summarizes the set of recommended best practices for
implementing delegation:
• Use security groups that represent roles for the sole purpose of delegating the
roles. Do not use these security groups for other purposes. For example, do
not use the security group to authorize access to other resources in the
domain that are not associated with the ability to perform the administrative
role.
• When delegating data management, as far as possible, delegate permissions
only on OUs, which are provided specifically to facilitate delegation of
administration. Delegating permissions on OUs enables them to be easily and
reliably revoked.
• Unless absolutely required, do not specify permissions on individual objects
within an OU.
• To delegate a role, grant permissions sufficient only to perform the set of
administrative tasks assigned to an administrative role

Using Inheritance
You can use inheritance of permissions to more easily implement delegation. The
use of inheritance of permissions allows administrators to easily apply
permissions on a collection of objects without having to explicitly modify the
DACL of every object. This capability allows administrators to easily manage
and control permissions on large sets of objects by applying and managing
permissions on a relatively small set of objects, from which other objects inherit
permissions.
When using inheritance to specify permissions, administrators can control the
various ways in which an inheritable permission is propagated. The following
guidelines can help you use inheritance effectively:
• When specifying inheritable permissions on an object, if these permissions
need to apply only to a specific object class, specify the object class instead
of letting the permission apply onto all child objects. This will ensure that
these permissions, when inherited, are effective only on objects of the
specific class on which they are intended to be effective.
 127

• When specifying inheritable permissions on an object, if the permissions

being specified are meant for child objects only, specify that these
permissions apply to child objects only. This will ensure that the applied
permissions are not effective on the object on which these permissions are
being specified.
• When specifying inheritable permissions on an object, if these permissions
need to be applicable only on immediate child objects, and do not need to be
inherited further down, specify that these permissions should be inherited
only one level below.
• When using inheritance, it is useful to take into consideration the precedence
order of ACEs:
• Any inheritable DENY permissions applied on the parent object will
precede any inheritable DENY permissions applied on the grandparent
object. Thus, when using DENY permissions, apply inheritable ACEs as
close to the target objects as possible and ensure that all target objects of
the permission are contained in the subtree rooted at the OU on which the
permissions are being applied. In general, as far as possible, avoid the use
of DENY permissions.
• Remember that an inheritable permission cannot override an explicit ACE
on an object. Thus, before using inheritance, it is recommended that you
check to see that there are no explicit ACEs on target objects that will
override the inheritable ACE.

Note
Any user who has the ability to modify the DACL of any OU in
the OU hierarchy can use inheritance to grant him or
herself or any other user any permission on
any object in the subtree rooted at that OU.
Therefore, carefully grant permissions to
modify the DACL of an OU object.
Taking Ownership of Objects
Some features of object ownership can complicate management of Active
Directory data, and you should be aware of them when planning and
implementing delegation of administrative authority. Every object in Active
Directory has an owner. The owner of an object is the only person who has the
inherent right to control who has permission to perform operations on the object
and in what way – the owner has the inherent right to modify permissions on an
object even if he or she is explicitly denied all access to the object in the object’s
DACL. An object’s owner can also grant or deny permission for different kinds
of access to particular users or groups of users. An object’s owner can also
transfer ownership by giving another security principal permission to take
ownership. The creator of an object is usually also the owner of the object; the
only exception to this rule is that if an object is being created programmatically,
an owner can be explicitly specified. Thus, when a user creates an object, he or
she usually becomes the owner of the object.
128

This aspect of object ownership affects how Active Directory data can be
managed. Consider the scenario in which administrative authority has been
delegated to a group of administrators by implementing an administrative role.
As part of carrying out delegated responsibilities, one of the members of the
administrative role creates an object. As the creator of the object, this specific
administrator also becomes the owner of the object. At a later date, this
administrator might no longer be a member of this administrative role. If this
administrator is no longer a member of this administrative role, he or she should
ordinarily no longer be able to manage this object. Since this administrator is no
longer a member of the administrative group representing the administrative role
that he or she was a member of, and since inheritable permissions were used to
delegate control of these objects to members of this administrative role, it seems
reasonable to conclude that this administrator will no longer have access to this
object. However, the administrator will still have access to this object by virtue
of the fact that as the creator of the object, he or she still owns the object. This
can obviously complicate delegation of administrative authority.
While this issue can be addressed by putting in place business policies to add
certain checks when an administrator is removed from an administrative role,
such administrative checks will not be fool-proof. A business unit can enforce
policy that requires that when an administrator is removed from an
administrative role, a check is made to see what objects the administrator owns
and that ownership of all objects be appropriately transferred. However, this
check is not fool-proof because the administrator might have used his authority
as owner to grant himself or herself (or another user) sufficient permissions to
modify the DACL of this object, or permissions to perform other operations.
The following precaution is recommended to adequately address this issue with
respect to managing user and group objects: Create a script that runs in the
security context of a Domain Admin account on a periodic basis (like daily or
weekly). This script should perform the following actions:
1. Walk through a specifiable subtree of objects, rooted at some OU, and for
every object do the following:
a. Check the owner field of the object; if the owner field is not set to
Domain Admins, change the owner field to Domain Admins.
b. Additionally, check the DACL of the object to ensure that the only
explicit ACEs in the DACL are the ones that are found in the default
security descriptor for that object class in the Schema. This check
ensures that creator of the object did not modify the DACL explicitly to
grant anyone (including himself or herself) any additional permissions. If
any explicit ACEs are found that do not exist in the default security
descriptor for that object class, report their existence and remove these
ACEs.
The reason this approach will work only for user and group objects is that the
default Note
security descriptors of these object classes do not contain any ACEs for
ThisOwner
the Creator checkTrustee.
will limit an organization’s
The general abilityOwner ACEs on
problem with Creator
to apply explicit ACEs on objects. This
other object classes, however, is that some default security descriptors can
limitation can be overcome by having the
script report the existence of such ACEs and
prompt for manual deletion. This approach,
while continuing to allow the use of explicit
ACEs, will require manual intervention and
might require significant manual
intervention if many explicit ACEs are used.
However, if explicit ACEs have been used
sparingly and minimally, this approach can
be very useful.
 129

contain ACEs for the Creator Owner Trustee, because during object creation, the
user field in any ACE for this trustee is replaced with the SID of the user creating
the object. Thus, when checking to see that only ACEs that were in the default
security descriptor are present, any ACE that was mapped to the SID of the
creator will show up as an explicit ACE that was not in the default security
descriptor and, if removed, could impact functionality.

Note
If your organization should decide to implement the script
approach described here, it is strongly advised
that this approach be thoroughly tested in
non-production environments before being
implemented in your production
environment.
Maintaining Your Data Management Delegation Model
Over time, your data management administrative delegation model might need to
be modified to address changing needs and requirements. The data management
tasks required to maintain a changing data management delegation model are the
same as those required to maintain a service management delegation model.
Tasks that are required to maintain the service delegation model can include:
• Adding (delegating) or removing (undelegating) members to or from data
administration role instances
• Adding new instances of roles in the event of changes in administrative needs
• Modifying a role by assigning or revoking a new or existing task from the
role definition
• Creating new custom roles if the need arises
• Undelegating a role completely by revoking all permissions that are granted
to the group that represents the role

Modifying the Administrators Assigned to a Data Administration

Role
To address personnel changes that affect the set of administrators who are
assigned to a data administration role, you typically need to perform one of the
following tasks:
• Add new administrators to an existing role.
• Remove one or more assigned administrators from a role.
To add one or more data administrators to a role, simply add the user accounts of
these administrators to the security group that represents the role. To remove one
or more assigned data administrators from a role, simply remove the user
accounts of these data administrators from the related security group.
130

Adding New Instances of Existing Roles

Organizational or operational changes might necessitate the introduction of new
role instances. For example, the introduction of a new business unit might
require creating an entire set of data management role instances to provide
administrative coverage. Similarly, the introduction of a new location might
require new instances of the Workstation Admins or Resource Admins roles, or
both, to facilitate administration of the IT resources at the new location.
To introduce a new role instance, understand the new administrative requirement
and decide whether or not this requirement can be addressed by an existing role
definition. If this requirement cannot be addressed by an existing role definition,
create a custom role to meet this requirement. See “Creating New Custom Data
Administration Roles” later in this document.
If the requirement can be addressed by an existing role definition, take the
following steps:
1. Document the requirements that call for the creation of a new role instance.
2. Determine the scope of influence of the new instance, which affects how
and where this role is granted the required permissions in Active Directory.
If needed, create a new OU or move an existing OU to ensure that the
target of administration is appropriately located in the OU structure.
For example, if a new location is being added and the new location will
have on-site workstations, you should add a new OU under the
Workstations OU in the Business Unit’s OU structure. This new OU should
contain all of the computer accounts for the workstations that will be
physically located at this location. If you have one OU for every unique
location, you will have to add a new OU for this location. If you are
moving an entire OU from one business unit to another, you could simply
move the OU to this new location under the Workstations OU.
3. Create a new security group to represent the new role instance. Depending
on your administration model, the Business Unit administrator might or
might not have delegated the authority to sub-delegate administrative
authority.
• If this new requirement is being addressed by sub-delegated
administrators, this new security group should be created by the sub-
delegated administrators in the OU where they have stored existing
security groups representing delegated roles.
• If a new role instance is required, the Business Unit administrator can
create a security group in the OU that is used by the Business Unit
administrator to delegate other roles instances.
4. After the security group has been created, appropriate permissions must be
assigned to it so that the administrators in that role can perform the
responsibilities of the role. Refer to the documentation that you created
during your role definition process and assign this new security group all
required permissions in the appropriate administrative scope. For more
 131

information about how to implement recommended roles, see

“Implementing Your Data Management Delegation Model” earlier in this
document.
5. Add the user accounts that represent the administrators who will be
assigned to this role to the corresponding security group.
6. Document the new role instance by using the role instance template to
specify the scope of influence, the security group that represents the role
instances, the detailed set of permissions that are granted, and the
administrators who are assigned to the role.

Modifying Administrative Tasks Associated With a Data

Administration Role
If the set of administrative tasks that is associated with a role must be modified,
you might need to add one or more new tasks to a role or remove one or more
assigned tasks from the role.
For example, suppose that there are three existing instances of the Help Desk
role, one for each business unit, and that this role is initially assigned the
following two tasks:
• Reset Passwords
• Unlock User Accounts
Six months later, it is decided that responsibility for the administrative task of
unlocking user accounts will be given solely to the Corporate Security role.
Addressing this new requirement involves revoking this ability from all instances
of the Help Desk role.
There are two ways to revoke these permissions:
• Modify the DACLs of the three OUs where the required permissions were
granted and remove the permissions that allow the security group
representing each role the ability to unlock user accounts.
• Remove and reassign the role, as follows:
• Revoke all the permissions granted to the security group that represents
the Help Desk role
• Re-grant the set of permissions that are required to perform the new and
updated set of administrative tasks.
Although in this example the approach of modifying the DACLs might appear
easy to grasp and implement, it is complicated to use in the following cases:
• The precise set of permissions required for every administrative task cannot
be mapped to one specific permission.
• Full Control has been granted.
• A number of permissions were specified for a given role.
132

In such cases, it is preferable to remove and re-assign the role. The Dsrevoke
command-line tool can be used to easily and reliably remove all permissions that
are granted to a security principal. For more information about using this tool,
see “Undelegating a Data Administration Role” later in this document.
To add a new task to a role for each role instance that needs to be modified,
perform the following tasks:
1. Identify the set of permissions that are required to perform the task.
2. Identify the location (specific OU or OU tree) in the OU hierarchy where
permissions have been granted to the security group that represents the role
instances.
3. Either revoke all permissions and then re-apply the updated set of
permissions, or grant this security group the additional minimal set of
permissions that are required to perform the new administrative task.
Depending on the requirement, you might need to update the set of
administrative tasks that are assigned to a specific instance of the role or to all
instances of the role.

Creating New Custom Data Administration Roles

Although the set of recommended roles should meet most of your data
administration needs, unique requirements or special needs might call for the
creation of new custom role definitions. Because the specific requirements can
vary, the actual definition of a custom role is necessarily variable.
You can, however, use the following steps to aid in creating and implementing
new custom roles:
1. Analyze and obtain a good understanding of the requirements of the role.
2. Create a new role to address these requirements.
3. Define the scope of administrative authority for this role.
4. Define the precise set of administrative tasks for which administrators in
this role will be responsible.
5. Identify the minimal and precise set of permissions that are required to
delegate the set of administrative tasks.
6. Create a naming convention for the security groups that represent instances
of this role.
7. Understand how the administrative scope of the role maps to the OU
structure in your organization.
After the data owner creates this model, the Business Unit Admin or a data
administrator who has been delegated the ability to sub-delegate should
implement the required number of instances of the role.
 133

Undelegating a Data Administration Role

If a business unit no longer has a need for a specific instance of some role, the
Business Unit Admin needs to discontinue it. For example, an organizational
change might result in the discontinuation of business at a physical location,
either by moving assets and operations from that location to another location, or
by completely stopping operations in that location. In this circumstance, you
might no longer need the administrative roles that were initially implemented to
manage workstations, resources, and perhaps users in that location.
To completely discontinue the role instance:
1. Revoke all the permissions that are granted to the security group that
represents the role.
2. Empty the membership of this security group.
3. Delete the security group.
In another case, your organization might decide to temporarily halt operations at
a location for four months due to construction. During this time, none of the IT
resources or users in that location will require administrative coverage, so you
might want to disable these roles during that period. In this situation, you will
want to only temporarily disable the role of the security group representing the
role instance.
Revoking All Permissions for a Security Principal
For the first scenario, you can use the Dsrevoke command-line tool to revoke all
permissions granted to the security group representing the role instance.
The Dsrevoke command-line tool provides the ability to remove ACEs that have
been applied for a security principal on the domain object or on OU objects. By
specifying the security group that represents the instantiated role and the OU or
domain on which the security group that represents the role has been granted
permissions, you can undelegate the role. However, Dsrevoke removes only
permissions. If a role has user rights applied, you must manually remove these
from the group.
For a specified user or security group, Dsrevoke removes ACEs on the specified
root object and on all OU objects below that root in the hierarchy. If a domain
root is specified, the tool searches the domain root and all OUs below that root.
If an OU root is specified, the tool searches the OU tree, beginning at the
specified root. Dsrevoke reports the explicit ACEs that exist for the specified
security principal. When you remove the ACEs, for each explicit ACE that
Dsrevoke removes, all inheritable ACEs that apply onto child OUs are also
removed.
Dsrevoke works only on domain objects and OUs. If you delegate permissions
on a container object or if you explicitly set permissions on an object within a
container or OU, you must manually remove these ACEs. For this reason, as a
best practice, it is recommended that permissions always be applied to OUs
rather than to specific objects within OUs, and that permissions be applied to
134

child OUs by using inheritance. For ease of management, always use security
groups to apply permissions.
Using Dsrevoke
Dsrevoke.exe has the following syntax:
dsrevoke /report|/remove [/domain:domainname] 
[/username:username]
[/password:password|*] [/root:domain/OU] 
securityprincipal
Descriptions for each option are as follows:
• /report: Reports the explicit ACEs that are currently set for the specified
security principal on OU objects in the specified domain or an OU subtree.
By default, the command dsrevoke /report starts at the domain root and
searches every OU below that root for explicit ACEs that are granted to the
specified security principal. If you are sure that the permissions for a security
group are set only on or below a specific OU, you can specify the scope of
the search by using the /OU switch to make the search more efficient.
• /remove: Reports all explicit ACEs and then, after prompting for
confirmation, removes the ACEs that are currently set for the security
principal, including all inherited ACEs.
• /domain: The DNS or NetBIOS name of the domain in which the permissions
are to be removed. This value must be specified only when the ACEs that you
want to remove are set on OUs in a domain other than the domain of the
logged-on user.
• /username: The user name of the user who is using the tool. This value is
required when:
• The user is not logged on as an administrator.
• ACEs are being removed in a domain other than the domain of the
logged-on user.
• /password: The password of the tool user. If the command is entered with an
asterisk (*) in place of a password, the tool prompts the user for a password.
• /root: The OU or domain root at which to start the search for ACEs. If no
value is specified, the search begins at the root of the specified domain. If no
domain is specified, the search begins at the root of the domain of the
logged-on user. When specifying a root domain or OU, you must use the
distinguished name (for example,
/root:OU=BusUnits=DC=DomainA,DC=com). If spaces occur in any part of
the distinguished name, enclose the entire option in quotation marks (for
example, “/root:OU=Product Development,OU=Delegation,OU=Business
Units,DC=DomainA,DC=com”).
 135

• /securityprincipal: The identity of the user or group in the form

DomainName\UserName or DomainName\GroupName. Use the DNS name
or NetBIOS name of the domain.
For more information about using Dsrevoke.exe and to obtain the tool, see
“Appendix G: Active Directory Delegation Tools” in “Best Practices for
Delegating Active Directory Administration: Appendices,” which accompanies
this document.

Case Study: A Delegation Scenario

To help you better understand the various phases of the delegation process, this
section provides a walk-through example of the creation and implementation of
service and data delegation models by a hypothetical multinational corporation.
By following this walkthrough, you can become more familiar with the
delegation process.

Company Overview
Contoso Pharmaceuticals is a large organization that has its headquarters in
Chicago, Illinois and has operations in five other locations in North America and
Europe. The Active Directory infrastructure consists of a single forest, three
domains, and six sites.

Physical Locations
The company has operations in six physical locations, three in North America
and three in Europe:
• North America — Chicago, New York, Atlanta
• Europe — London, Paris, Rome

Business Units
Contoso has four business units. Table 7 shows the business units and their
locations.
Table 7 Contoso Business Units and Locations
Business Units Locations
Research and Development Chicago
Production Atlanta
Business Management Chicago, New York, London,
Paris, Rome
IT Chicago, Atlanta, New York,
London, Paris, Rome
136

Users, Workstations, and Servers

Table 8 shows the distribution of users, workstations, and servers per business
unit.
Table 8 Contoso Business Units and Contents
Business Unit Users Workstations Servers
Research and 5,000 10,000 1,000
Development
Production 3,000 5,000 520
Business 5,500 7,000 250
Management
IT 2,500 5,000 100

Servers
The servers include file servers, Web servers, database servers, and application
servers.
Table 9 shows the numbers of servers of each type and their respective business
units.
Table 9 Business Unit Server Numbers and Types, By Business
Unit
Business File Web Database Application
Unit Servers Servers Servers Servers
Research 800 50 100 50
and
Developm
ent
Production 300 20 100 100
Business 120 45 50 35
Managem
ent
IT 30 30 20 20

Active Directory Infrastructure

Contoso has chosen to deploy Active Directory based on the Regional Domain
Model. There is one regional domain each for the two major geographic
locations (North America and Europe), connected by a Wide Area Network
(WAN). The regional domain model enables Contoso to maintain a stable
environment over time. This model consists of a forest root domain and two
regional domains, as shown in Figure 9.
 137

Figure 9 Active Directory Domain Model for Contoso

Pharmaceuticals

Site Topology
The Contoso site topology consists of six logical Active Directory sites, one for
each of the six physical locations, as shown in Figure 10.
Figure 10 Active Directory Site Topology for Contoso
Pharmaceuticals

Domain Controller Placement

Contoso has deployed a total of 17 domain controllers — two domain controllers
per site and three additional controllers for the forest root domain.
138

Table 10 shows the distribution of domain controllers per domain across sites.
Table 10 Domain Controllers Per Domain in Each Site
Number of Domain Controllers per Domain
Site Concorp.cont NOAM.concorp.co Europe.concorp.co
oso.com ntoso.com ntoso.com
Chica 3 2 2
go
Atlant 2
a
New 2
York
Londo 2
n
Paris 2
Rome 2

Domain Controller Placement

Domain controllers for each domain are placed in the sites as shown in Table 11.
The letter “G” indicates that the domain controller is a global catalog server.
Table 11 Domain Controllers in Contoso sites
Site
Domain
Controller Chica Atlant New Londo Paris Rome
go a York n
CONTOSO- G
DC1
CONTOSO-
DC2
CONTOSO-
DC3
NOAM-DC1
NOAM-DC2 G
NOAM-DC3 G
NOAM-DC4
NOAM-DC5 G
NOAM-DC6
EUROPE-
 139

DC1
EUROPE-
DC2
EUROPE- G
DC3
EUROPE-
DC4
EUROPE- G
DC5
EUROPE-
DC6
EUROPE- G
DC7
EUROPE-
DC8

All domain controllers are placed in highly secure physical locations to which
only authorized personnel are granted access. All domain controllers in remote
locations are equipped with a remote administration solution, such as Remote
Insight Lights-Out (RILO), so that administrators can control both hardware and
software on domain controllers remotely to manage systems where no IT staff
are stationed.

DNS Server Placement

To provide fault tolerance, the DNS Server service runs on every domain
controller in the Contoso forest. Zones are distributed as follows:
• Domain controllers in the forest root domain host the forest root DNS name.
• Domain controllers for each regional domain host the DNS zone that
corresponds to the DNS name of the domain.
• The zone containing the forest-wide domain controller locator records
replicates to every DNS server in the forest by using the forest-wide DNS
application directory partition, ForestDnsZones.

Global Catalog Server Placement

All sites in the Contoso environment have at least 100 users. To facilitate user
logon requests and forest-wide searches, Contoso follows the general Windows
Server 2003 deployment recommendation for placing a global catalog server in
any site where there are at least 100 users. Two global catalog servers are placed
in Chicago to accommodate the large number of users in that site.
For more information about global catalog server placement, see “Designing the
Site Topology” in Designing and Deploying Directory and Security Services of
140

the Windows Server 2003 Deployment Kit (or see “Designing the Site Topology”
on the Web at http://go.microsoft.com/fwlink/?LinkId=4724).

Operations Master Roles Placement

Contoso places the operations master roles according to the best practices that
are recommended in the Active Directory Operations Guide Version 1.5, on the
Web at http://go.microsoft.com/fwlink/?LinkId=19827.
Forest-wide Role Placement
The two forest-wide roles are domain naming master and schema master. By
default, all operations master roles (including the domain-wide roles) are placed
on the first domain controller that is installed in the forest root domain.
Contoso assigns the two forest-wide operations master roles to the original forest
root domain controller, CONTOSO-DC1. Both roles are compatible with a
global catalog server.

Note
In Windows 2000, the domain naming
master must be placed on a global catalog
server.
Domain-wide Role Placement
The first domain controller that is installed in a domain has the three domain-
wide roles by default. Because the concorp.contoso.com domain is the forest root
domain, the first domain controller that is installed to create the forest root
domain contains the three domain roles and is also a global catalog server.
Because the infrastructure master must not be located on a global catalog server,
Contoso moves that role, as well as the other two domain-wide roles, to
CONTOSO-DC2, which is not a global catalog server.
The first domain controllers that are installed in noam.concorp.contoso.com and
in europe.concorp.contoso.com are not global catalog servers. Therefore, the
domain-level roles are left on these domain controllers, as shown in Table 12.
Table 12 Domain-Wide Operations Master Role Placement
Domain PDC Infrastructure RID Master
Master Master
concorp.contoso. CONTOSO CONTOSO-DC2 CONTOSO-
com -DC2 DC2
noam.concorp.co NOAM- NOAM-DC1 NOAM-DC1
ntoso.com DC1
europe.concorp.c EUROPE- EUROPE-DC1 EUROPE-
ontoso.com DC1 DC1
 141

Domain Modes and Functional Levels

The Contoso environment does not use domain controllers that are running
Windows NT 4.0 or Windows 2000, and therefore can run all domain controllers
in native mode. The following functional levels are in effect:
• Domain functional level — Windows Server 2003 in all domains
• Forest Functional Level — Windows Server 2003
At these functional levels, all new features in Windows Server 2003 are available
throughout the forest. For more information about domain and forest functional
levels, see “Enabling Advanced Windows Server 2003 Active Directory
Features” in Designing and Deploying Directory and Security Services of the
Microsoft® Windows® Server 2003 Deployment Kit (or see “Enabling Advanced
Windows Server 2003 Active Directory Features” on the Web at
http://go.microsoft.com/fwlink/?LinkID=6937).

Managing Contoso’s Active Directory Environment

To manage the Active Directory environment, Contoso uses the following
process:
1. Create the service management administrative delegation model.
2. Implement the service management administrative delegation model.
3. Hand off data management to data administrators.
4. Create the data management administrative delegation model for every
business unit:
a. Create an OU structure for every business unit.
b.Create an administration model for data management.
5. Implement the data management administrative delegation model for every
business unit.
The IT department is responsible for managing the Active Directory
environment. The IT department is based in the Chicago headquarters and has
the following components and users:
• CIO
• Core Infrastructure (100)
• Connectivity (30)
• Messaging (30)
• Business Applications (50)
• IT Security (50)
• Support Services (75)
142

Active Directory Administrative Personnel Overview

Of the approximately 325 employees in the IT business unit, 135 will be
responsible for Active Directory service and data management, including
managing the Active Directory directory service, user accounts, and all
workstations, servers, and resources in the Contoso organization. They will also
provide help desk support to the entire organization. The remaining 190
administrative personnel provide administrative coverage for network
connectivity, messaging, and other network services.
Table 13 shows the types and numbers of administrative personnel in each
administrative category.
Table 13 Active Directory Administrative Personnel
Role Number of IT Personnel
Management 10
Service Administrators 25
Data Administrators 50
Help Desk Operators 50

This team of administrators will create and implement the service and data
delegation models for the organization.

Step 1 — Create the Contoso Service Management Administrative

Delegation Model
The service owners create the service delegation model according to the
following criteria:
• Objective: Create a delegation model to distribute service management
among service administrators by enabling efficient, security-conscious
delegation and distribution of administrative responsibilities among various
administrative groups.
• Stakeholders: Service owners.
• Approach: Identify the number of instances of each service management role
that are needed and the administrative personnel who are assigned to each
role.
Service Management Roles
For the service administrative delegation model, Contoso requires the following
management roles:
• Forest Configuration Operators
• Domain Configuration Operators
• Schema Admins
• Replication Management Admins
 143

• Replication Monitoring Operators

• DNS Admins
• Security Policy Administrators
• Service Admin Managers
• Domain Controller Admins
• Backup Operators
Template for Creating the Delegation Model
Contoso uses the information in Table 14 as a template for assigning each role.
Table 14 Role Assignment Template
Template Fields Phase During Which to
Complete Assignment
Role Instance Name Creation
Instance of Creation
Instance Number Creation
Assigned Administrators Creation
Assigned Tasks Creation
Security Group Implementation
Permissions Assigned Implementation
Notes Creation and implementation

Assigning the Roles During Role Creation

Fields for each role are filled in by using the role template.
Assigning Forest Configuration Operators
The service owner follows the recommendation for creating only one instance of
this role.
144

Table 15 shows the model creation entries in the template for this role.
Table 15 Model Creation Template for Forest Configuration
Operators Role
Field Assignment Information
Role Instance Name Contoso Forest Config Ops
Instance of Forest Configuration
Operators Role
Instance Number 1 of 1
Assigned Administrators Joe, Sally, Kevin

Assigned Tasks
Security Group
Permissions Assigned
Notes Based in Chicago

Assigning Domain Configuration Operators

The service owner follows the recommendation for creating only one instance of
this role per domain. Because there are three domains, three instances are
defined.
Table 16 shows the model creation entries in the template for this role.
Table 16 Model Creation Template for Domain Configuration
Operators Role
Field Assignment Information
Role Instance Name Contoso Root Dom Config
Ops
Instance of Domain Configuration
Operators Role
Instance Number 1 of 3
Assigned Administrators Michael, Sally, Gordon
Assigned Tasks
Security Group
Permissions Assigned
Notes Based in Chicago
Field Assignment Information
Role Instance Name NOAM Dom Config Ops
Instance of Domain Configuration
 145

Operators Role
Instance Number 2 of 3
Assigned Administrators John, Sandra
Assigned Tasks
Security Group
Permissions Assigned
Notes Based in Chicago
Field Assignment Information
Role Instance Name EUROPE Dom Config Ops
Instance of Domain Configuration
Operators Role
Instance Number 3 of 3
Assigned Administrators Christoph, Anna
Assigned Tasks
Security Group
Permissions Assigned
Notes Based in London

Assigning Schema Admins

The service owner follows the recommendation for creating only one instance of
this role.
Table 17 shows the model creation entries in the template for this role.
Table 17 Model creation template for Schema Admins role
Field Assignment Information
Role Instance Name Contoso Schema Admins
Instance of Schema Admins Role
Instance Number 1 of 1
Assigned Administrators Joe (also assigned to Forest
Config Ops role)
Assigned Tasks
Security Group
Permissions Assigned
Notes Based in Chicago
Only group authorized to
perform schema
146

modifications

Assigning Replication Management Admins

The service owner follows the recommendation for creating only one instance of
this role.
Table18 shows the model creation entries in the template for this role.
Table 18 Model Creation Template for Replication Management
Admins Role
Field Assignment Information
Role Instance Name Contoso Repl Mgmt Admins
Instance of Replication Management
Admins
Instance Number 1 of 1
Assigned Administrators Sally (also assigned to Forest
Config Ops role)
Kevin (also assigned to
Forest Config Ops role)
Assigned Tasks
Security Group
Permissions Assigned
Notes Based in Chicago

Assigning Replication Monitoring Operators

The service owner follows the recommendation for creating only one instance of
this role.
Table 19 shows the model creation entries in the template for this role.
Table 19 Model Creation Template for Replication Monitoring
Operators Role
Field Assignment Information
Role Instance Name Contoso Repl Monitoring Ops
Instance of Replication Monitoring
Operators
Instance Number 1 of 1
Assigned Administrators Tom, Russ
Assigned Tasks
Security Group
Permissions Assigned
 147

Notes Based in Chicago

Assigning DNS Admins

The service owner follows the recommendation for creating one instance of this
role for the entire forest and one instance for each domain.
Table 20 shows the model creation entries in the template for this role.
Table 20 Model Creation Template for DNS Admins Role
Field Assignment Information
Role Instance Name Contoso Forest DNS Admins
Instance of DNS Admins
Instance Number 1 of 4
Assigned Administrators Mark (also assigned to
Service Admin Managers,
Security Policy Admins)
Assigned Tasks
Security Group
Permissions Assigned
Notes Based in Chicago
Field Assignment Information
Role Instance Name Contoso DNS Admins
Instance of DNS Admins
Instance Number 2 of 4
Assigned Administrators Andrew
Assigned Tasks
Security Group
Permissions Assigned
Notes Based in Chicago
Field Assignment Information
Role Instance Name NOAM DNS Admins
Instance of DNS Admins
Instance Number 3 of 4
Assigned Administrators Jay
Assigned Tasks
Security Group
148

Permissions Assigned
Notes Based in Chicago
Field Assignment Information
Role Instance Name EUROPE DNS Admins
Instance of DNS Admins
Instance Number 4 of 4
Assigned Administrators Laurie, Samuel
Assigned Tasks
Security Group
Permissions Assigned
Notes Based in Chicago

Assigning Security Policy Administrators

The service owner follows the recommendation for creating one instance of this
role.
Table 21 shows the model creation entries in the template for this role.
Table 21 Model creation template for Security Policy
Administrators Role
Field Assignment Information
Role Instance Name Contoso Sec Pol Admins
Instance of Security Policy Admins
Instance Number 1 of 1
Assigned Administrators Mark (also assigned to
Service Admin Managers,
DNS Admins)
Assigned Tasks
Security Group
Permissions Assigned
Notes Based in Chicago

Assigning Service Admin Managers

The service owner follows the recommendation for creating one instance of this
role.
 149

Table 22 shows the model creation entries in the template for this role.
Table 22 Model Creation Template for Service Admin Managers
Role
Field Assignment Information
Role Instance Name Contoso Srvc Admin
Managers
Instance of Service Admin Managers
Instance Number 1 of 1
Assigned Administrators Lisa
Mark (also assigned to
Security Policy Admins, DNS
Admins)
Assigned Tasks
Security Group
Permissions Assigned
Notes Based in Chicago

Assigning Domain Controller Admins

Contoso implements two instances of the Domain Controller Admins role. One
instance is based in Chicago and is responsible for managing all domain
controllers that are located in Chicago and for remotely managing all domain
controllers that are located in the other two sites in North America. Similarly, one
instance of the Domain Controller Admins role is based in London and is
responsible for managing all domain controllers in the London site and for
remotely managing all domain controllers that are located in the other two sites
in Europe.
Contoso has implemented RILOs in remote sites so that all aspects of their
domain controllers can be managed remotely from the hub site. The only
operation that cannot be performed on RILO-based systems is physically starting
and shutting down the domain controllers in a remote location. For this
administrative operation, one local administrative group is assigned the
responsibility for shutting down and starting domain controllers when needed.
Table 23 shows the model creation entries in the template for this role.
Table 23 Model Creation Template for Domain Controller
Admins Role
Field Assignment Information
Role Instance Name Contoso Root and NOAM DC
Admins
Instance of Domain Controller Admins
Instance Number 1 of 2
150

Assigned Administrators Paul, Andy

Assigned Tasks
Security Group
Permissions Assigned
Notes Based in Chicago
Field Assignment Information
Role Instance Name Europe DC Admins
Instance of Domain Controller Admins
Instance Number 2 of 2
Assigned Administrators James, Jessica
Assigned Tasks
Security Group
Permissions Assigned
Notes Based in London

Assigning Backup Operators

According to the recommendations for this role, there should be one instance for
each domain. Although there are three instances of this role in the model, the
service owner decides to assign the same group of administrators to each of the
three instances. The administrators in this group are all located in Chicago. This
one group is responsible for backing up Active Directory for all three domains.
Table 24 shows the model creation entries in the template for this role.
 151

Table 24 Model Creation Template for Backup Operators Role

Field Assignment Information
Role Instance Name Contoso Root Backup
Operators
Instance of Backup Operators
Instance Number 1 of 3
Assigned Administrators Maria
Assigned Tasks
Security Group
Permissions Assigned
Notes Based in Chicago
Field Assignment Information
Role Instance Name NOAM Backup Operators
Instance of Backup Operators
Instance Number 2 of 3
Assigned Administrators Kris
Assigned Tasks
Security Group
Permissions Assigned
Notes Based in Chicago
Field Assignment Information
Role Instance Name Europe Backup Operators
Instance of Backup Operators
Instance Number 3 of 3
Assigned Administrators Brian
Assigned Tasks
Security Group
Permissions Assigned
Notes Based in Chicago
152

Service Role Assignment Summary

Table 25 provides a summary of the roles and instances that have been assigned
for service management.
Table 25 Summary of Assigned Contoso Service Management
Roles
Role Instance Comments
s
Forest Configuration 1 One role per forest
Operators
Domain Configuration 3 One role per domain
Operators
Schema Admins 1 One role per forest
Replication 1 One role per forest
Management Admins
Replication Monitoring 1 One role per forest
Operators
DNS Admins 4 One forest-wide role
and one role per domain
Security Policy 1 One role per forest
Administrators
Service Admin 1 One role per forest
Managers
Domain Controller 2 One role per continent
Admins (North America and
Europe)
Backup Operators 3 One role per domain

Now that the creation phase is complete, Contoso has a delegation model that
documents the division of responsibility for service management of the Active
Directory infrastructure. In the next step, the Enterprise Admins group will
implement the Active Directory directory service management model.

Step 2 — Implement the Administrative Delegation Model for

Contoso Service Management
The service administrators implement the service delegation model according to
the following criteria:
• Objective: Implement the service management delegation model
• Stakeholders: Enterprise Admins
• Approach: Implement each role instance according to the delegation model
design document
 153

• Assumption: The three domains have been installed and are running
Out-of-Box Container Hierarchy for the Forest Root Domain
When the first domain controller is installed to create the forest root domain of
the Contoso forest, the default set of containers shown in Figure 11 is created:
Figure 11 Default Forest Root Domain Containers
154

Creating an OU to Store Security Groups That Represent Service

Roles
To more easily manage the instances of the Business Unit Admins role, Contoso
follows the recommendation to store all instances of the Business Unit Admins
roles in one place. A member of the Enterprise Admins group creates an OU
called Service Management in the forest root domain, as shown in Figure 12.
Figure 12 Service Management OU

Implementing the Service Administration Role Instances

Contoso implements the service administration role instances according to the
service delegation model.
Implementing Forest Configuration Operators
A member of Enterprise Admins creates one instance of this role by carrying out
the following steps.
To implement the Forest Configuration Operators role
1. In the concorp.contoso.com domain, create the following security group
under the Service Management OU:
Group Name: Contoso Forest Config Ops
 155

Group Type: Universal if the forest root domain is in native mode, otherwise
global

Note
“Native mode” has the following meaning,
depending on the operating system:
 Windows Server 2003: the domain
functional level is Windows 2000 native
 Windows 2000: the domain mode is
native
2. Grant the following permissions to Contoso Forest Config Ops:
Extended rights:
• DS-Replication-Get-Changes on
CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Get-Changes on
CN=Schema,CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Get-Changes-All on
CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Get-Changes-All on
CN=Schema,CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Manage-Topology on
CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Manage-Topology on
CN=Schema,CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Monitor-Topology on
CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Monitor-Topology on
CN=Schema,CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Synchronize on
CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Synchronize on
CN=Schema,CN=Configuration,DC=concorp,DC=contoso,DC=com
• Change-Schema-Master on
CN=Schema,CN=Configuration,DC=concorp,DC=contoso,DC=com
• Change-Domain-Master on
CN=Partitions,CN=Configuration,DC=concorp,DC=contoso,DC=com
Permissions on
CN=Sites,CN=Configuration,DC=concorp,DC=contoso,DC=com:
• Inherit-only Full-Control permissions on all objects of class NTDS-
Settings
156

• Inherit-only Create Child permissions to be able to create and delete

objects of class Server
• Inherit-only Delete Child permissions to be able to delete objects of class
NTDS-Settings
• Inherit-only Delete Child permissions to be able to delete objects of class
Server
Inheritable Full Control permissions on:
• CN=Partitions,CN=Configuration,DC=concorp,DC=contoso,DC=com
• CN=sites,CN=Configuration,DC=concorp,DC=contoso,DC=com
Property permissions Read-Property and Write-Property to the FSMO-Role-
Owner property on the following objects:
• CN=Schema,CN=Configuration,DC=concorp,DC=contoso,DC=com
• CN=Partitions,CN=Configuration,DC=concorp,DC=contoso,DC=com
Property permissions Read-Property and Write-Property to the LDAP-
Admin-Limits property on the following object:
• CN=Default Query Policy,CN=Query-Policies,CN=Directory
Service,CN=Windows
NT,CN=Services,CN=Configuration,DC=concorp,DC=contoso,DC=com
Property permissions Read-Property and Write-Property to the ms-DS-
Behavior-Version property on the following objects:
• CN=Partitions,CN=Configuration,DC=concorp,DC=contoso,DC=com
Inheritable Full Control permissions on the following objects:
• CN=System,DC=concorp,DC=contoso,DC=com
• CN=System,DC=noam,DC=concorp,DC=contoso,DC=com
• CN=System,DC=europe,DC=concorp,DC=contoso,DC=com

Note If the forest root domain is not in native mode, universal

groups are not available. In this case, create a new domain
local group in each domain and grant that group the
permissions specified earlier in this procedure. Then make the
Contoso Forest Config Ops global group a member of these
domain local groups.

Create Child permissions on the following OUs:

• OU=Domain Controllers,DC=concorp,DC=contoso,DC=com
• OU=Domain Controllers,DC=noam,DC=concorp,DC=contoso,DC=com
• OU=Domain Controllers,DC=europe,DC=concorp,DC=contoso,DC=com
3. Grant the Creator Owner trustee Full Control on the following objects:
Note If the forest root domain is not in native mode, universal
groups are not available. In this case, create a new domain
local group in each domain and grant that group the
permissions specified earlier in this procedure. Then make the
Contoso Forest Config Ops global group a member of these
domain local groups.
 157

• The computer object that represents the server that will be promoted to
create a new domain.
• CN=sites,CN=Configuration,DC=concorp,DC=contoso,DC=com
4. Add Contoso Forest Config Ops to the local Administrators group of any
member server that is to be promoted to a Domain Controller.
Implementing Domain Configuration Operators
A member of Enterprise Admins creates three instances of this role, one for each
domain, by performing the following steps.
To implement the Domain Configuration Operators role, forest
root domain instance, for concorp.contoso.com
1. In the concorp.contoso.com domain, create the following security group
under the Service Management OU:
Group Name: Contoso Root Dom Config Ops
Group Type: Universal if the forest root domain is in native mode, otherwise
global

Note
“Native mode” has the following meaning,
depending on the operating system:
 Windows Server 2003: the domain
functional level is Windows 2000 native
or higher
 Windows 2000: the domain mode is
native
2. Grant the following permissions to Contoso Root Dom Config Ops:
Extended rights:
• DS-Install-Replica on DC=Contoso,DC=com
• DS-Replication-Get-Changes on DC=contoso,DC=com
• DS-Replication-Get-Changes on
CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Get-Changes on
CN=Schema,CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Get-Changes-All on DC=contoso,DC=com
• DS-Replication-Get-Changes-All on
CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Get-Changes-All on
CN=Schema,CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Manage-Topology on DC=contoso,DC=com
• DS-Replication-Manage-Topology on
CN=Configuration,DC=concorp,DC=contoso,DC=com
158

• DS-Replication-Manage-Topology on
CN=Schema,CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Monitor-Topology on DC=contoso,DC=com
• DS-Replication-Monitor-Topology on
CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Monitor-Topology on
CN=Schema,CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Synchronize on DC=contoso,DC=com
• DS-Replication-Synchronize on
CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Synchronize on
CN=Schema,CN=Configuration,DC=concorp,DC=contoso,DC=com
• Change-RID-Master on CN=RID
Manager$,CN=System,DC=contoso,DC=com
• Change-Infrastructure-Master on DC=contoso,DC=com
• Change-PDC on DC=contoso,DC=com
Permissions on
CN=Sites,CN=Configuration,DC=concorp,DC=contoso,DC=com:
• Inherit-only Full-Control permissions on all objects of class NTDS-
Settings
• Inherit-only Create Child permissions to be able to create and delete
objects of class Server
• Inherit-only Delete Child permissions to be able to delete objects of class
NTDS-Settings
• Inherit-only Delete Child permissions to be able to delete objects of class
Server
Inheritable Full Control permissions on:
• CN=System,DC=contoso,DC=com
• CN=System,DC=noam,DC=concorp,DC=contoso,DC=com
• CN=System,DC=europe,DC=concorp,DC=contoso,DC=com
Create Child permissions on:
Note If the forest root domain is not in native mode, universal
groups are not available. In this case, create a new domain
local group in each domain and grant that group the
permissions specified earlier in this procedure. Then make the
Contoso Root Dom Config Ops global group a member of these
domain local groups.

• OU=Domain Controllers,DC=contoso,DC=com
• OU=Domain Controllers,DC=noam,DC=concorp,DC=contoso,DC=com
 159

• OU=Domain Controllers,DC=europe,DC=concorp,DC=contoso,DC=com

Note If the forest root domain is not in native mode, universal

groups are not available. In this case, create a new domain
local group in each domain and grant that group the
permissions specified earlier in this procedure. Then make the
Contoso Root Dom Config Ops global group a member of these
domain local groups.

Property permissions Read-Property and Write-Property to the FSMO-Role-

Owner property on:
• DC=concorp,DC=contoso,DC=com
• CN=RID Manager$,CN=System,DC=concorp,DC=contoso,DC=com
• CN=Infrastructure,DC=concorp,DC=contoso,DC=com
3. Grant the Creator Owner Trustee Full Control on:
• The computer object that represents the server that will be promoted to
create a new domain
• CN=sites,CN=Configuration,DC=concorp,DC=contoso,DC=com
4. Grant the permission Enable computer and user accounts to be trusted for
delegation by adding Contoso Root Dom Config Ops to the User Rights
Assignment setting in Domain Controller Security Policy for
concorp.contoso.com.
5. Prior to creating a new domain, add Contoso Root Dom Config Ops to the
local Administrators group of the member server that is to be promoted to a
domain controller.
To implement the Domain Configuration Operators role,
NOAM.contoso.com domain instance
1. In the concorp.contoso.com domain, create the following security group
under the Service Management OU:
Group Name: NOAM Dom Config Ops
Group Type: Universal if the forest root domain is in native mode, otherwise
global
2. Grant the following permissions to NOAM Dom Config Ops:
Extended rights:
• DS-Replication-Get-Changes on
DC=noam,DC=concorp,DC=contoso,DC=com
• DS-Replication-Get-Changes on
CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Get-Changes on
CN=Schema,CN=Configuration,DC=concorp,DC=contoso,DC=com
160

• DS-Replication-Get-Changes-All on
DC=noam,DC=concorp,DC=contoso,DC=com
• DS-Replication-Get-Changes-All on
CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Get-Changes-All on
CN=Schema,CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Manage-Topology on
DC=noam,DC=concorp,DC=contoso,DC=com
• DS-Replication-Manage-Topology on
CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Manage-Topology on
CN=Schema,CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Monitor-Topology on
DC=noam,DC=concorp,DC=contoso,DC=com
• DS-Replication-Monitor-Topology on
CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Monitor-Topology on
CN=Schema,CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Synchronize on
DC=noam,DC=concorp,DC=contoso,DC=com
• DS-Replication-Synchronize on
CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Synchronize on
CN=Schema,CN=Configuration,DC=concorp,DC=contoso,DC=com”
• Change-RID-Master on CN=RID
Manager$,CN=System,DC=noam,DC=concorp,DC=contoso,DC=com
• Change-Infrastructure-Master on
DC=noam,DC=concorp,DC=contoso,DC=com
• Change-PDC on DC=noam,DC=concorp,DC=contoso,DC=com
Permissions on
CN=Sites,CN=Configuration,DC=concorp,DC=contoso,DC=com:
• Inherit-only Full-Control permissions on all objects of class NTDS-
Settings
• Inherit-only Create Child permissions to be able to create and delete
objects of class Server
• Inherit-only Delete Child permissions to be able to delete objects of class
NTDS-Settings
• Inherit-only Delete Child permissions to be able to delete objects of class
Server
 161

Inheritable Full Control permissions on:

• CN=System,DC=noam,DC=concorp,DC=contoso,DC=com

Note If the forest root domain is not in native mode, universal

groups are not available. In this case, create a new domain
local group in each domain and grant that group the
permissions specified earlier in this procedure. Then make the
NOAM Dom Config Ops global group a member of these
domain local groups.

Create Child permissions on:

• OU=Domain Controllers,DC=noam,DC=concorp,DC=contoso,DC=com

Note If the forest root domain is not in native mode, universal

groups are not available. In this case, create a new domain
local group in each domain and grant that group the
permissions specified earlier in this procedure. Then make the
NOAM Dom Config Ops global group a member of these
domain local groups.

Property permissions Read-Property and Write-Property permissions to the

FSMO-Role-Owner property on:
• DC=noam,DC=concorp,DC=contoso,DC=com
• CN=RID
Manager$,CN=System,DC=noam,DC=concorp,DC=contoso.com
• CN=Infrastructure,DC=noam,DC=concorp,DC=contoso,DC=com
3. Grant the Creator Owner trustee Full Control on:
• The computer object that represents the server that will be promoted to
create a new domain
• CN=sites,CN=Configuration,DC=concorp,DC=contoso,DC=com
4. Grant the permission Enable computer and user accounts to be trusted for
delegation by adding NOAM Dom Config Ops to the User Rights
Assignment setting in Domain Controller Security Policy for the
noam.concorp.contoso.com.
5. Prior to creating a new domain, add NOAM Dom Config Ops to the local
Administrators group of the member server that is to be promoted to a
domain controller.
To implement the Domain Configuration Operators role,
Europe.contoso.com domain instance
1. In the concorp.contoso.com domain, create the following security group
under the Service Management OU:
Group Name: EUROPE Dom Config Ops
162

Group Type: Universal if the forest root domain is in native mode, otherwise
global
2. Grant the following permissions to EUROPE Dom Config Ops:
Extended rights:
• DS-Replication-Get-Changes on
DC=europe,DC=concorp,DC=contoso,DC=com
• DS-Replication-Get-Changes on
CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Get-Changes on
CN=Schema,CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Get-Changes-All on
DC=europe,DC=concorp,DC=contoso,DC=com
• DS-Replication-Get-Changes-All on
CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Get-Changes-All on
CN=Schema,CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Manage-Topology on
DC=europe,DC=concorp,DC=contoso,DC=com
• DS-Replication-Manage-Topology on
CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Manage-Topology on
CN=Schema,CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Monitor-Topology on
DC=europe,DC=concorp,DC=contoso,DC=com
• DS-Replication-Monitor-Topology on
CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Monitor-Topology on
CN=Schema,CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Synchronize on
DC=europe,DC=concorp,DC=contoso,DC=com
• DS-Replication-Synchronize on
CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Synchronize on
CN=Schema,CN=Configuration,DC=concorp,DC=contoso,DC=com
• Change-RID-Master on CN=RID
Manager$,CN=System,DC=europe,DC=concorp,DC=contoso,DC=com
• Change-Infrastructure-Master on
DC=europe,DC=concorp,DC=contoso,DC=com
• Change-PDC on DC=europe,DC=concorp,DC=contoso,DC=com
 163

Permissions on
CN=Sites,CN=Configuration,DC=concorp,DC=contoso,DC=com:
• Inherit-only Full-Control permissions on all objects of class NTDS-
Settings
• Inherit-only Create Child permissions to be able to create and delete
objects of class Server
• Inherit-only Delete Child permissions to be able to delete objects of class
NTDS-Settings
• Inherit-only Delete Child permissions to be able to delete objects of class
Server
Inheritable Full Control permissions on:
• CN=System,DC=europe,DC=concorp,DC=contoso,DC=com

Note If the forest root domain is not in native mode, universal

groups are not available. In this case, create a new domain
local group in each domain and grant that group the
permissions specified earlier in this procedure. Then make the
EUROPE Dom Config Ops global group a member of these
domain local groups.

Create Child permissions on:

• OU=Domain Controllers,DC=europe,DC=concorp,DC=contoso,DC=com

Note If the forest root domain is not in native mode, universal

groups are not available. In this case, create a new domain
local group in each domain and grant that group the
permissions specified earlier in this procedure. Then make the
EUROPE Dom Config Ops global group a member of these
domain local groups.

Property permissions Read-Property and Write-Property permissions to the

FSMO-Role-Owner property on:
• DC=europe,DC=concorp,DC=contoso,DC=com
• CN=RID
Manager$,CN=System,DC=europe,DC=concorp,DC=contoso.com
• CN=Infrastructure,DC=europe,DC=concorp,DC=contoso,DC=com
3. Grant the Creator Owner trustee Full Control on:
• The computer object that represents the server that will be promoted to
create a new domain
• CN=sites,CN=Configuration,DC=concorp,DC=contoso,DC=com
4. Grant Enable computer and user accounts to be trusted for delegation
by adding EUROPE Dom Config Ops to the User Rights Assignment
164

setting in Domain Controller Security Policy for the

europe.concorp.contoso.com.
5. Prior to creating a new domain, add EUROPE Dom Config Ops to the local
Administrators group of the member server that is to be promoted to a
domain controller.
Implementing Schema Admins
A member of Enterprise Admins creates one instance of this role.
To implement the Schema Admins role
• Move the default security group Schema Admins from its default location in
the Users container to the Service Management OU. By default, the Schema
Admins group has sufficient permissions to manage the Active Directory
schema.
Implementing Replication Management Admins
A member of Enterprise Admins creates one instance of this role.
To implement the Replication Management Admins role
1. In the concorp.contoso.com domain, create the following security group
under the Service Management OU:
Group Name: Contoso Repl Mgmt Admins
Group Type: Universal if the forest root domain is in native mode, otherwise
global

Note
“Native mode” has the following meaning,
depending on the operating system:
 Windows Server 2003: the domain
functional level is Windows 2000 native
or higher
 Windows 2000: the domain mode is
native
2. Grant the following permissions to Contoso Repl Mgmt Admins:
Extended rights:
• DS-Replication-Manage-Topology on
DC=concorp,DC=contoso,DC=com
• DS-Replication-Manage-Topology on
DC=noam,DC=concorp,DC=contoso,DC=com
• DS-Replication-Manage-Topology on
DC=europe,DC=concorp,DC=contoso,DC=com
• DS-Replication-Manage-Topology on
CN=Configuration,DC=concorp,DC=contoso,DC=com
 165

• DS-Replication-Manage-Topology on
CN=Schema,CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Monitor-Topology on
DC=concorp,DC=contoso,DC=com
• DS-Replication-Monitor-Topology on
DC=noam,DC=concorp,DC=contoso,DC=com
• DS-Replication-Monitor-Topology on
DC=europe,DC=concorp,DC=contoso,DC=com
• DS-Replication-Monitor-Topology on
CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Monitor-Topology on
CN=Schema,CN=Configuration,DC=concorp,DC=contoso,DC=com
Full Control permissions on
CN=Sites,CN=Configuration,DC=concorp,DC=contoso,DC=com:
Implementing Replication Management Admins
A member of Enterprise Admins creates one instance of this role.
To implement the Replication Management Admins role
1. In the concorp.contoso.com domain, create the following security group
under the Service Management OU:
Group Name: Contoso Repl Monitoring Ops
Group Type: Universal if the forest root domain is in native mode, otherwise
global

Note
“Native mode” has the following meaning,
depending on the operating system:
 Windows Server 2003: the domain
functional level is Windows 2000 native
or higher
 Windows 2000: the domain mode is
native
2. Grant the following permissions to Contoso Repl Monitoring Ops:
Extended rights:
• DS-Replication-Monitor-Topology on
DC=concorp,DC=contoso,DC=com
• DS-Replication-Monitor-Topology on
DC=noam,DC=concorp,DC=concorp,DC=contoso,DC=com
• DS-Replication-Monitor-Topology on
DC=europe,DC=concorp,DC=contoso,DC=com
166

• DS-Replication-Monitor-Topology on
CN=Configuration,DC=concorp,DC=contoso,DC=com
• DS-Replication-Monitor-Topology on
CN=Schema,CN=Configuration,DC=concorp,DC=contoso,DC=com

Note environment is a
If your Active Directory
Windows 2000 environment, the
Replication-Monitor-Topology extended right
is not available. In this case, grant the
Replication-Manage-Topology extended right
on all of the objects specified in the
preceding step.
Full Control permissions on
CN=Sites,CN=Configuration,DC=concorp,DC=contoso,DC=com:
Implementing DNS Admins
A member of Enterprise Admins creates four instances of this role, as follows:
• Contoso Forest DNS Admins for the entire forest
• Contoso DNS Admins for the concorp.contoso.com domain
• NOAM DNS Admins for the noam.concorp.contoso.com domain
• Europe DNS Admins for the europe.concorp.contoso.com domain
To implement the DNS Admins role, Concorp instance
First the domain instances are implemented, and then the forest root instance,
which must be added to the security groups for each domain instance.
1. In the concorp.contoso.com domain, create the following security group
under the Service Management OU:
Group Name: Concorp DNS Admins
Group Type: Universal if the forest root domain is in native mode, otherwise
global

Note
“Native mode” has the following meaning,
depending on the operating system:
 Windows Server 2003: the domain
functional level is Windows 2000 native
or higher
 Windows 2000: the domain mode is
native
2. Grant the following permissions to Concorp DNS Admins:
• Full Control on
CN=MicrosoftDNS,CN=System,DC=concorp,DC=contoso,DC=com
 167

• Full Control on
CN=MicrosoftDNS,DC=DomainDnsZones,DC=concorp,DC=contoso,D
C=com
To implement the DNS Admins role, NOAM DNS Admins instance
1. In the concorp.contoso.com domain, create the following security group
under the Service Management OU:
Group Name: NOAM DNS Admins
Group Type: Universal if the forest root domain is in native mode, otherwise
global
2. Grant the following permissions to NOAM DNS Admins:
Full Control on
CN=MicrosoftDNS,CN=System,DC=noam,DC=concorp,DC=contoso,DC=c
om
Full Control over
CN=MicrosoftDNS,DC=DomainDnsZones,DC=noam,DC=concorp,DC=con
toso,DC=com
To implement the DNS Admins role, Europe instance
1. In the concorp.contoso.com domain, create the following security group
under the Service Management OU:
Group Name: Europe DNS Admins
Group Type: Universal if the forest root domain is in native mode, otherwise
global
2. Grant the following permissions to Europe DNS Admins:
Full Control on
CN=MicrosoftDNS,CN=System,DC=europe,DC=concorp,DC=contoso,DC=
com
Full Control over
CN=MicrosoftDNS,DC=DomainDnsZones,DC=europe,DC=concorp,DC=co
ntoso, DC=com
To implement the DNS Admins role, Contoso Forest instance
1. In the concorp.contoso.com domain, create the following security group
under the Service Management OU:
Group Name: Contoso Forest DNS Admins
Group Type: Universal if the forest root domain is in native mode, otherwise
global
2. Add the Contoso Forest DNS Admins group to the following groups:
• Concorp DNS Admins
• NOAM DNS Admins
• Europe DNS Admins
168

3. Grant the following permissions to Contoso Forest DNS Admins:

• Full Control on
CN=MicrosoftDNS,DC=ForestDnsZones,DC=concorp,DC=contoso,DC=
com
Implementing Security Policy Admins
A member of Enterprise Admins creates one instance of this role.
To implement the Security Policy Admins role
1. In the concorp.contoso.com domain, create the following security group
under the Service Management OU:
Group Name: Contoso Sec Pol Admins
Group Type: Universal if the forest root domain is in native mode, otherwise
global

Note
“Native mode” has the following meaning,
depending on the operating system:
 Windows Server 2003: the domain
functional level is Windows 2000 native
or higher
 Windows 2000: the domain mode is
native
2. Grant the following permissions to Contoso Sec Pol Admins on each of the
following objects:
Objects:
• DC=concorp,DC=contoso,DC=com
• DC=noam,DC=concorp,DC=contoso,DC=com
• DC=europeDC=concorp,DC=contoso,DC=com
• OU=Domain Controllers,DC=concorp,DC=contoso,DC=com
• OU=Domain Controllers,DC=noam,DC=concorp,DC=contoso,DC=com
• OU=Domain Controllers,DC=europe,DC=concorp,DC=contoso,DC=com
Permissions:
• Read-property permissions to read the GP-Link property
• Write-property permissions to read the GP-Link property
• Read-property permissions to read the GP-Options property
• Write-property permissions to read the GP-Options property
3. In the properties page for the Domain Controllers OU in each domain, on
the Group Policy tab, select the Default Domain Controllers GPO and on
the Security tab, grant Full Control to Contoso Sec Pol Admins.
 169

Implementing Service Admin Managers

A member of Enterprise Admins creates one instance of this role.
To implement the Service Admin Managers role
1. In the concorp.contoso.com domain, create the following security group
under the Service Management OU:
Group Name: Contoso Srvc Admin Managers
Group Type: Universal if the forest root domain is in native mode, otherwise
global

Note
“Native mode” has the following meaning,
depending on the operating system:
 Windows Server 2003: the domain
functional level is Windows 2000 native
or higher
 Windows 2000: the domain mode is
native
2. In each domain in the forest, modify permissions on the object
CN=AdminSDHolder,CN=System,DC=Domain Name, as follows:
a. Grant Contoso Srvc Admin Managers Full Control on the object.
b. Revoke permissions granted to the Domain Admins and Builtin
Administrators groups.

Note Although Builtin Administrators will no longer have control

over service administrative accounts because of the security
descriptor changes in step 2, Builtin Administrators have the
privilege Take ownership of objects and other files (a User
Rights Assignment setting in Default Domain Controller
Security Policy). This privilege can be exercised to take
ownership of (and subsequently modify the DACL of) any
object, including the service administrative groups and all
accounts that are members of these security groups.

3. Mark the DACL of the Service Management OU as Protected.

4. Grant Contoso Srvc Admin Managers inheritable Full Control over the
Service Management OU.
5. Modify the DACLs of every group that is created for the purpose of
representing roles, as follows:
a. Revoke all permissions that are granted to Domain Admins.
b. Revoke all permissions that are granted to Account Operators.
Implementing Domain Controller Admins
A member of Enterprise Admins creates two instances of the Domain Controller
Admins role:
170

• Contoso Root & NOAM DC Admins

• Europe DC Admins
To implement the Domain Controller Admins role, Contoso Root
& NOAM DC Admins instance
1. In the concorp.contoso.com domain, create the following security group
under the Service Management OU:
Group Name: Contoso Root & NOAM DC Admins
Group Type: Universal if the forest root domain is in native mode, otherwise
global

Note
“Native mode” has the following meaning,
depending on the operating system:
 Windows Server 2003: the domain
functional level is Windows 2000 native
or higher
 Windows 2000: the domain mode is
native
2. Add Contoso Root & NOAM DC Admins to the security group
CN=Administrators,CN=Builtin,DC=contoso,DC=com
3. Add Contoso NOAM DC Admins to the security group
CN=Administrators,CN=Builtin,DC=noam,DC=concorp,DC=contoso,DC=
com
4. Make sure no other group is a member of the Builtin Administrators group
in noam.concorp.contoso.com.
To implement the Domain Controller Admins role, Europe DC
Admins instance
1. In the concorp.contoso.com domain, create the following security group
under the Service Management OU:
Group Name: Europe DC Admins
Group Type: Universal if the forest root domain is in native mode, otherwise
global
2. Add Contoso Europe DC Admins to the security group
CN=Administrators,CN=Builtin,DC=europe,DC=concorp,DC=contoso,DC
Note
=com
“Native mode” has the following meaning,
depending on the operating system:
 Windows Server 2003: the domain
functional level is Windows 2000 native
or higher
 Windows 2000: the domain mode is
native
 171

3. Make sure no other group is a member of the Builtin Administrators group

in europe.concorp.contoso.com.
Implementing Backup Operators
A member of Enterprise Admins creates three instances of this role, one for each
domain.
To implement the Backup Operators role
1. In the concorp.contoso.com domain, create the following security groups
under the Service Management OU:
Group Name:
• Contoso Root Backup Operators
• NOAM Backup Operators
• Europe Backup Operators
Group Type: Universal if the forest root domain is in native mode, otherwise
global

Note
“Native mode” has the following meaning,
depending on the operating system:
 Windows Server 2003: the domain
functional level is Windows 2000 native
or higher
 Windows 2000: the domain mode is
native
2. In Domain Controller Security Policy in each domain, grant the following
user rights under User Rights Assignment to the respective instance of the
Backup Operators role:
• Allow log on locally
• Back up files and directories
• Shut down the system
3. In Domain Controller Security Policy in each domain, modify the User
Rights Assignment settings to remove all user rights settings that are
granted by default to the Builtin\Backup Operators group, which are:
• Allow log on locally
• Back up files and directories
• Restore files and directories
• Shut down the system
4. Make sure that no other group is granted these user rights.
172

Step 3 — Hand Off Data Management to Contoso Data

Administrators
Before the data management administrative delegation model can be
implemented, control over data needs to be transferred to data administrators.
Conceptually, the service owner hands off ownership and responsibility of
content management to data owners. From an implementation perspective, high-
level service administrators, who represent the service owners, delegate full
control of business unit content to data administrators, who represent data
owners.
Service administrators perform the following tasks to hand off data management:
1. Create a Business Units OU in each domain, and one OU for every
business unit within the Business Units OU in each domain.
Contoso has decided not to use the forest root domain for storing business
accounts, but to store all business unit data in the NOAM and Europe
regional domains.
2. Create a Delegation OU in each domain to store the security groups that
represent the instances of Business Unit Admins roles.
3. Create security groups to represent the Business Unit Admins role
instances.
4. Grant the security groups full control over the respective business unit
OUs.
5. Optionally, grant these security groups the ability to modify their own
group memberships.
6. Create user accounts for the Business Unit Admins role holders.
7. Add Business Unit Admins user accounts to the respective security groups
that represent instances of this role.
Creating a Business Units OU Hierarchy in Each Domain
A member of Domain Configuration Operators in each domain creates one OU
called Business Units in the respective domain. Below this OU, the administrator
creates one OU for each business unit.
The following steps are performed by a member of NOAM Domain Config Ops
and Europe Config Ops in their respective domains.
1. Create Business Units OU roots for each domain by creating the objects in
Table 26.
Table 26 Business Units OUs for NOAM and Europe Domains
Object DN Object Class
OU=Business organizationalUnit
Units,DC=noam,DC=concorp
,DC=contoso,DC=com
 173

OU=Business Units,DC= organizationalUnit

europe,DC=concorp,DC=con
toso,DC=com

2. Create one OU for each business unit within the Business Units OU in each
domain by creating the objects in Table 27.
Table 27 OUs for Each Business Unit in NOAM and Europe
Domains
Object DN Object Class
OU=RandD,OU=Business organizationalU
Units,DC=noam,DC=concorp,DC=contoso, nit
DC=com
OU=Production,OU=Business organizationalU
Units,DC=noam,DC=concorp,DC=contoso, nit
DC=com
OU=BusMgmt,DC=noam,DC=concorp,DC organizationalU
=contoso,DC=com nit
OU=BusMgmt,DC= organizationalU
europe,DC=concorp,DC=contoso,DC=com nit
OU=IT,DC=noam,DC=concorp,DC=contos organizationalU
o,DC=com nit
OU=IT,DC=europe,DC=concorp,DC=conto organizationalU
so,DC=com nit

Creating a Delegation OU in Each Domain

In each domain that will store business unit data, a member of the Domain
Configuration Operators role for each domain (NOAM Domain Config Ops and
Europe Domain Config Ops) creates one OU named Delegation within the
Business Units OU for the domain. This OU is used to store the security groups
that represent as many instances of the Business Unit Admins role as are needed
(usually equal to the number of business units in the domain). It is also used to
store any data management roles that need to be granted administrative authority
across all business units.
To create the Delegation OUs, a Domain Configuration Operator for each
domain creates the objects in Table 28.
Table 28 Delegation OUs for each Domain in NOAM and Europe
Object DN Object Class
OU=Delegation,OU=Business organizational
Units,DC=noam,DC=concorp,DC=contoso, Unit
DC=com
OU=Delegation,OU=Business organizational
174

Units,DC=europe,DC=concorp,DC=contoso Unit
,DC=com

Figure 13 shows the resulting domain and OU structures for NOAM and Europe.
Figure 13 High-Level Business Unit OU Structure for NOAM and
Europe Domains

Creating Security Groups to Represent the Business Unit Admins

Role Instances
The Domain Configuration Operator next creates one security group to represent
each instance of the Business Unit Admins role for each business unit in the
respective domains.
Table 29 shows the group objects that the Domain Configuration Operators
create in the Delegation OU within the Business Units OUs in the respective
domains.
Table 29 OUs for Each Business Unit in NOAM and Europe
Domains
 175

Object DN Object Class

CN=RandD Bus Unit Security group
Admins,OU=Delegation,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,
DC=com
CN=Production Bus Unit Security group
Admins,OU=Delegation,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,
DC=com
CN=BusMgmt Bus Unit Security group
Admins,OU=Delegation,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,
DC=com
CN=BusMgmt Bus Unit Security group
Admins,OU=Delegation,OU=Business
Units,DC=europe,DC=concorp,DC=contos
o,DC=com
CN=IT Bus Unit Security group
Admins,OU=Delegation,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,
DC=com
CN=IT Bus Unit Security group
Admins,OU=Delegation,OU=Business
Units,DC=europe,DC=concorp,DC=contos
o,DC=com

Figure 14 shows the domain and OU structures for each domain, including the
security groups within their respective Delegation OUs.
176

Figure 14 Business Unit OU Structure and Business Unit Admins

Groups

Granting Business Unit Admins Full-Control Over Business Unit

OUs
The Domain Configuration Operators for each domain grant each instance of the
Business Unit Admins role full control over their respective business unit OUs in
 177

the domain. To do so, they modify the permissions on each business unit OU and
grant the appropriate security group full control over the OU.
Table 30 shows the business unit OUs and the respective security groups that
represent the Business Unit Admins role and receive Full Control permissions on
the OU.
Table 30 OUs and Business Unit Admins Groups That Receive
Full Control
OUs Allow Full Control To
OU=RandD,OU=Business RandD Bus Unit Admins
Units,DC=noam,DC=concorp,DC=
contoso,DC=com
OU=Production,OU=Business Production Bus Unit
Units,DC=noam,DC=concorp,DC= Admins
contoso,DC=com
OU=BusMgmt,OU=Business BusMgmt Bus Unit
Units,DC=noam,DC=concorp,DC= Admins
contoso,DC=com
OU=IT,OU=Business IT Bus Admins
Units,DC=noam,DC=concorp,DC=
contoso,DC=com
OU=BusMgmt,OU=Business BusMgmt Bus Admins
Units,DC=europe,DC=concorp,DC
=contoso,DC=com
OU=IT,OU=Business IT Bus Admins
Units,DC=europe,DC=concorp,DC
=contoso,DC=com

Granting the Ability to Modify Administrative Group

Memberships
In some cases, the Domain Configuration Operators group might grant security
groups that represent the various role instances of the Business Unit Admins role
sufficient permissions to modify the membership of these groups. The objective
is to allow Business Unit Admins the ability to control their own group
membership. Based on the administrative requirements of the Contoso
organization, the service owners decide to grant this ability to the groups that
represent instances of the Business Unit Admins role.
To enable group members to change the membership of their respective groups, a
member of NOAM Domain Config Ops and Europe Domain Config Ops grants
to each Business Admins security group the Write property permission to modify
the Member attribute on their own group object:
• A member of the NOAM Domain Config Ops group grants each of the
following security groups permission to modify the Member attribute on the
object that represents the respective security group:
178

• RandD BU Admins
• Production BU Admins
• BusMgmt BU Admins
• IT BU Admins
• A member of the Europe Domain Config Ops group grants each of the
following security groups permission to modify the Member attribute on the
object that represents the respective security group:
• BusMgmt BU Admins
• IT BU Admins
At this point, all of the Business Unit Admins roles have been enabled by
creating the Business Unit Admins groups and granting them permissions to
manage their respective OUs. To delegate the roles, the Domain Configuration
Operators next create the user accounts that will perform each role and add them
to the appropriate groups.
Creating User Accounts for Business Unit Admins Groups
Data owners for each business group have communicated the identities of the
users who will serve as the Business Unit Admins to the Domain Configuration
Operators. The Domain Configuration Operators create these user accounts in the
respective business unit OUs, as shown in Table 31.
Table 31 Business Unit Administrator Accounts
Business Unit/Domain Business Unit Admins Role
Assignments
RandD/NOAM John
Chris
Production/NOAM Mary
Joe
Bus Mgmt/NOAM Sally
IT/NOAM Kevin
Bus Mgmt/Europe Frank
IT/Europe Anna

Accordingly, the Domain Config Operators, on behalf of the service owners,

create the following user objects:
• CN=John,OU=RandD,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
• CN=Chris,OU=RandD,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
 179

• CN=Mary,OU=Production,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
• CN=Joe,OU=Production,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
• CN=Sally,OU=BusMgmt,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
• CN=Frank,OU=BusMgmt,OU=Business
Units,DC=europe,DC=concorp,DC=contoso,DC=com
• CN=Kevin,OU=IT,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
• CN=Anna,OU=IT,OU=Business
Units,DC=europe,DC=concorp,DC=contoso,DC=com
Note that user accounts for Business Unit Admins of the BusMgmt and IT
business units are created in different domains in order to spread them across all
domains that have the same business unit.
Adding Business Unit Admins User Accounts to Administrative
Security Groups
To actually delegate the Business Unit Admins role and to complete the data
management handoff, the Domain Configuration Operators add the users whose
accounts they have created to the security groups that represent the respective
Business Unit Admins roles.
Table 32 shows the resulting Business Unit Admins group memberships:
Table 32 Business Unit Admin Role Security Groups and Added
Members
Group for User Business Unit Domain
Business Unit Accounts OU
Admins Role
RandD BU John RandD NOAM
Admins Chris
Production BU Mary Production NOAM
Admins Joe
Bus Mgmt BU Frank Bus Mgmt NOAM
Admins
IT BU Admins Kevin IT NOAM
Bus Mgmt BU Sally Bus Mgmt Europe
Admins
IT BU Admins Anna IT Europe

At this point, the data management handoff is complete. All Business Unit
Admins have full control over their business unit OUs.
180

Step 4 — Create the Contoso Data Management Administrative

Delegation Model
With the business unit OUs and Business Unit Admins role instances in place,
Contoso data owners are ready to create their delegation model according to the
following criteria:
• Objective: Create a delegation model to distribute data management among
data administrators by enabling efficient, security-conscious delegation and
distribution of administrative responsibilities among various administrative
groups
• Stakeholders: Data owners of all business units
• Approach: Each business unit data owner creates a delegation model for his
or her business unit data, as follows:
• Understand administrative delegation and Group Policy application
requirements.
• Create an OU structure that meets administrative delegation and Group
Policy application requirements.
• Identify the number of instances of each data management role according
to business unit requirements and identify the administrative personnel
who are assigned to each role.
Contoso has four business units spread across two domains and six locations.
Table 33 shows the locations of the users, workstations, and servers that are
managed by each business unit.
Table 33 Distribution of Users, Workstations, and Servers in
Contoso Business Units
Business Locations Users Workstatio Servers
Units ns
Research Chicago 5,000 10,000 1000
and
Developm
ent
Production Atlanta 3,000 5,000 520
Business Chicago, 5,500 7,000 250
Managem New York,
ent London,
Paris,
Rome
IT Chicago, 2,500 5,000 100
Atlanta,
New York,
London,
Paris,
Rome
 181

Table 34 shows the distribution of servers across the Contoso business units by
type of server.
Table 34 Distribution of Servers by Type in Contoso Business
Units
Business File Web Database Application
Unit Servers Servers Servers Servers
RandD 800 50 100 50
Production 300 20 100 100
Bus Mgmt 120 45 50 35
IT 30 30 20 20

To support the delegation model, Contoso assigns the following data

management roles:
• Account Admins
• Workstation Admins
• Resource Admins
• Application-specific roles
• Custom roles
Creating the Delegation Model for the RandD Business Unit
This business unit is based in Chicago and is the main research and development
unit. All of its 500 employees are located in a single building. The workstation-
to-employee ratio is roughly 2:1, resulting in a total of 1,000 workstations.
Additionally, there are about 1,000 servers, including file, Web, database, and
application servers.
Servers play different roles and are administered by different groups of
administrators, depending on the resource to which they belong.
Table 35 shows the number of users, workstations, and servers that are stored in
the RandD business unit in the Chicago location.
Table 35 Users, Workstations, and Servers in the RandD
Business Unit
Location Users Workstations Servers
Chicago 5,000 10,000 1,000

Table 36 shows the numbers of server types that RandD stores.

Table 36 Distribution of Server Types in RandD Business Unit
Location ServersFile Web Database Application
Servers Servers Servers
182

Chicago 800 50 100 50

RandD Administrative and Group Policy Requirements

Administrative requirements for the RandD business unit include the
management of users, workstations, and resources, as follows:
• User Account Management. All users are managed by a single account
management team.
• Workstation Management. All workstations are managed by a single
workstation management team that is located on site.
• Resource Management. Four types of resources must be managed: file
servers, Web portals, database servers, and applications that are hosted on
servers. For every type of resource, there is one administrative group that has
overall responsibility for that type of resource. These administrative groups
require the ability to sub-delegate resource management to different
administrative teams.
Group Policy requirements include the settings that must be applied for different
types of user accounts, for workstations (both desktop and portable computers),
and for resources according to resource type, as follows:
• User Accounts. Requirements for folder redirection and other user
configuration settings necessitate that different Group Policy settings be
applied for development accounts and research accounts.
• Workstations. Requirements for scripts and other computer configuration
settings necessitate that different Group Policy settings be applied for
desktop and portable computers.
• Resources. Computer configuration settings necessitate that different Group
Policy settings be applied for different kinds of resources and might require
the application of specific Group Policy settings for the various specific
resources.
RandD OU Structure Based on Administrative and Group
Policy Requirements
Figure 15 shows the OU structure for the RandD OU that accommodates its
administrative and Group Policy requirements.
 183

Figure 15 RandD OU Structure

Table 37 shows the rationale for the OU structure shown in Figure 15.
Table 37 Purpose of Each OU in the RandD Business Unit OU
Hierarchy
Organizational Unit Purpose
User Accounts Main OU to store user
accounts
Delegation point for Account
Admins role
User Accounts\Research Used to apply Group Policy
for research user accounts
User Accounts\Development Used to apply Group Policy
for development user
accounts
Workstations Main OU to store computer
accounts for workstations
Delegation point for
Workstation Admins role
Workstations\Desktops Used to apply Group Policy
184

for computer accounts for

desktops
Workstations\Laptops Used to apply Group Policy
for computer accounts for
laptops
Resources Main OU to store computer
accounts for servers hosting
resources
Delegation point for
Resource Admins role
Resources\File Servers Main OU to store computer
accounts for file servers
Used to apply Group Policy
for file servers
Resources\Web Servers Main OU to store computer
accounts for Web servers
Used to apply Group Policy
for Web servers
Resources\Database Servers Main OU to store computer
accounts for database
servers
Used to apply Group Policy
for database servers
Resources\Application Main OU to store computer
Servers accounts for application
servers
Used to apply Group Policy
for application servers

RandD Role Instances Based on Business Unit Requirements

On the basis of the RandD business unit requirements, the following role
instances must be created:
• User Account management. Because a single group is responsible for all
aspects of user account management, one instance of the Account Admins
role should meet the requirements.
• Workstation management. Because a single group is responsible for all
aspects of workstation account management, one instance of the Workstation
Admins role should meet the requirements.
 185

• Resource management. Because a single administrative group has overall

responsibility for resource account management, one instance of the
Resource Admins role is required for this group. Additionally, this group
requires the ability to sub-delegate authority to other administrative groups
and thus is responsible for creating as many instances of the Resource
Admins role as needed.
Note that the role instance for the single Resource Admins group that has power
to sub-delegate encompasses all aspects of resource administration. Although the
specific instances that are sub-delegated receive more limited authority, they are
still Resource Admin roles. By granting this one Resource Admins role the
ability to sub-delegate, the data owners understand that they are effectively
granting this role instance the ability create OUs, and hence to create data such
as users and workstations. Although the data owners have made these actions
technically possible for the administrators to whom the role is delegated, the data
owners have implemented specific business policies stating that should these
Resource Admins misuse their granted authority, they will be subject to punitive
action up to and including termination of employment.
Table 38 shows the model creation template that the data owners fill out to
document the RandD Account Admins role.
Table 38 Model Creation Template for RandD Account Admins
Role
Field Assignment Information
Role Instance Name RandD Account Admins
Instance of Account Admins
Instance Number 1 of 1
Assigned Administrators Joe, Mike, Sara, Kevin
Assigned Tasks Manage all aspects of
account management
Security Group Implementation
Permissions Assigned Implementation
Notes Creation/Implementation

Table 39 shows the model creation template that the data owners fill out to
document the RandD Workstation Admins role.
Table 39 Model Creation Template for RandD Workstation
Admins Role
Field Assignment Information
Role Instance Name RandD Workstation Admins
Instance of Account Admins
Instance Number 1 of 1
186

Assigned Administrators Eugene, Larry, Andy, Peter

Assigned Tasks Manage all aspects of
workstation management
Security Group Implementation
Permissions Assigned Implementation
Notes Creation/Implementation

Table 40 shows the model creation template that the data owners fill out to
document the RandD Resource Admins role.
Table 40 Model Creation Template for RandD Resource Admins
Role
Field Assignment Information
Role Instance Name: RandD Resource Admins
Instance of: Account Admins
Instance Number: 1 of n, where n = as many as
needed over time
Assigned Administrators: Deborah, Paul
Assigned Tasks: Overall responsibility for all
aspects of resource
management
Security Group Implementation
Permissions Assigned Implementation
Notes Creation/Implementation

Creating the Delegation Model for the Production Business Unit

This business unit is based in Atlanta and is responsible for all content for the
Atlanta production facility. Approximately 300 employees work for this business
unit and approximately 500 workstations are in use at the production facility.
Approximately 320 servers provide various required services.
Atlanta has two physical locations that are approximately five miles apart. The
servers in these locations play different roles and are managed by different
groups of administrators according to resource type.
Because all data for this business unit is physically located in Atlanta, all of its
content is stored only in the noam.concorp.contoso.com domain.
Table 41 shows the number of users, workstations, and servers that are stored in
the Production business unit in the Atlanta location.
 187

Table 41 Users, Workstations, and Servers in the Production

Business Unit
Location Users Workstations Servers
Atlanta 300 500 320

Table 42 shows the numbers of server types that Production stores.

Table 42 Distribution of Server Types in the Production Business
Unit
File
Location Servers Web Database Application
Servers Servers Servers
Atlanta 300 20 100 100

Production Administrative and Group Policy Requirements

Administrative requirements for the Production business unit include the
management of users, workstations, and resources, as follows:
• User Account Management. All user accounts are managed by a single
account management team.
• Workstation Management. Each physical location has a separate team that
is responsible for managing workstations.
• Resource Management. Three production applications are run in the
production facility. Each application has its own file, Web, database, and
application servers. In addition, some file, Web, database, and application
servers are common to the entire facility. Each of the three applications has
its own administrators, and one group of administrators is responsible for
managing the common servers.
Group Policy requirements include the settings that must be applied for different
types of user accounts, for workstations (both desktops and laptops), and for
resources according to the resource type, as follows:
• User Accounts. One common Group Policy applies to all user accounts in
the production business unit.
• Workstations. Requirements for scripting and other computer configuration
settings necessitate different Group Policy settings for desktop and portable
computers.
• Resources. Computer configuration settings necessitate that different Group
Policy settings be applied for different kinds of resources and might require
the application of specific Group Policy settings for the various specific
resources.
Production OU Structure Based on Administrative and
Group Policy Requirements
Figure 16 shows the OU structure for the Production OU that accommodates its
administrative and Group Policy requirements.
188

Figure 16 Production OU Structure

Table 43 shows the rationale for the OU structure shown in Figure 16.
 189

Table 43 Purpose of Each OU in the Production Business Unit

OU Hierarchy
Organizational Unit Purpose
Accounts Main OU to store accounts
Delegation point for Account
Admins role
Workstations Main OU to store workstation
computer accounts
Delegation point for
Workstation Admins role
Workstations\Desktops Used to apply Group Policy
for desktops
Workstations\Laptops Used to apply Group Policy
for portable computers
Resources Main OU to store servers
comprising resources
Resources\Production Main OU to store all servers
Application 1 that are part of Application 1
— includes file, Web,
database and application
servers
Resources\Production Main OU to store all servers
Application 2 that are part of Application 2
— includes file, Web,
database and application
servers
Resources\Production Main OU to store all servers
Application 3 that are part of Application 3
— includes file, Web,
database and application
servers
Resources\Common Main OU to store all servers
Resources that are part of the common
resource pool

Production Role Instances Based on Business Unit

Requirements
On the basis of the Production business unit requirements, the following role
instances will be created:
• Account Management. Because a single group is responsible for all aspects
of account management, one instance of the Account Admins role should
meet the requirements.
190

• Workstation Management. Because a different administrative group is

required for each of the two physical locations in Atlanta, two instances of
the Workstation Admins role should meet the requirements.
• Resource Management. Based on the business unit requirements, a total of
four Resource Admins role instances is required — one each for the three
production applications and one for the common set of resources.
Table 44 shows the model creation template that the data owners fill out to
document the Production Account Admins role.

Table 44 Model Creation Template for Production Account

Admins Role
Field Assignment Information
Role Instance Name Production Account Admins
Instance of Account Admins
Instance Number 1 of 1
Assigned Administrators Sandra
Assigned Tasks Manage all aspects of
account management
Security Group Implementation
Permissions Assigned Implementation
Notes Creation and implementation

Table 45 shows the model creation template that the data owners fill out to
document the Production Workstation Admins role in the first Atlanta location.
Table 45 Model Creation Template for Production Workstation
Admins Role in Location 1
Field Assignment Information
Role Instance Name Production Location 1
Workstation Admins
Instance of Workstation Admins
Instance Number 1 of 2
Assigned Administrators Michael, Dave
Assigned Tasks Manage all aspects of
workstation management for
Location 1
Security Group Implementation
Permissions Assigned Implementation
 191

Notes Creation and implementation

Table 46 shows the model creation template that the data owners fill out to
document the Production Workstation Admins role in the second Atlanta
location.
Table 46 Model creation template for Production Workstation
Admins role in Location 2
Field Assignment Information
Role Instance Name Production Location 2
Workstation Admins
Instance of Workstation Admins
Instance Number 2 of 2
Assigned Administrators Adam, Charlotte
Assigned Tasks Manage all aspects of
workstation management for
Location 2
Security Group Implementation
Permissions Assigned Implementation
Notes Creation and implementation

Table 47 shows the model creation template that the data owners fill out to
document the Production Resource Admins role for the first application.
Table 47 Model Creation Template for Production Resource
Admins Role for Application 1
Field Assignment Information
Role Instance Name Production Application 1
Resource Admins
Instance of Resource Admins
Instance Number 1 of 4
Assigned Administrators Nick, Wade
Assigned Tasks Overall responsibility for all
aspects of resource
management for application
1
Security Group Implementation
Permissions Assigned Implementation
Notes Creation and implementation
192

Table 48 shows the model creation template that the data owners fill out to
document the Production Resource Admins role for the second application.
Table 48 Model Creation Template for Production Resource
Admins Role for Application 2
Field Assignment Information
Role Instance Name Production Application 2
Resource Admins
Instance of Resource Admins
Instance Number 2 of 4
Assigned Administrators Jennifer, Brad
Assigned Tasks Overall responsibility for all
aspects of resource
management for application
2
Security Group Implementation
Permissions Assigned Implementation
Notes Creation and implementation

Table 49 shows the model creation template that the data owners fill out to
document the Production Resource Admins role for the third application.
Table 49 Model Creation Template for Production Resource
Admins Role for Application 3
Field Assignment Information
Role Instance Name Production Application 3
Resource Admins
Instance of Resource Admins
Instance Number 3 of 4
Assigned Administrators Scott, Laura
Assigned Tasks Overall responsibility for all
aspects of resource
management for application
3
Security Group Implementation
Permissions Assigned Implementation
Notes Creation and implementation

Table 50 shows the model creation template that the data owners fill out to
document the Production Resource Admins role for the common set of resources.
 193

Table 50 Model Creation Template for Production Resource

Admins Role for Common Resources
Field Assignment Information
Role Instance Name Production Common
Resource Admins
Instance of Resource Admins
Instance Number 4 of 4
Assigned Administrators Jim, Justin
Assigned Tasks Overall responsibility for all
aspects of resource
management common to the
Production business unit
Security Group Implementation
Permissions Assigned Implementation
Notes Creation and implementation

Creating the Delegation Model for the Bus Mgmt Business Unit
This business unit has two main divisions — business management and sales.
The business management unit is based in Chicago and includes the product
planning, legal, marketing, and other groups. The marketing and legal business
management teams and the sales team are spread over different physical
locations across North America and Europe.
Approximately 550 employees work for the Bus Mgmt business unit. The sales
division is the largest division, with 400 employees. Each sales representative
has a portable computer. All users in this business unit have a portable computer
and a desktop, making a total of 700 managed workstations. Additionally, about
250 servers provide various required services.
Table 51 shows the number of user, workstation, and server accounts that are
stored in the Bus Mgmt business unit in the Chicago and London locations.
Table 51 Users, Workstations, and Servers in the Bus Mgmt
Business Unit
Locations Users Workstations Servers
Chicago, 5,500 7,000 250
London

Table 52 shows the number of user, workstation, and server accounts that are
stored in the Bus Mgmt business unit in the Chicago and London locations,
separated by each division. Because business unit users are based across two
different continents, business unit content is distributed across the two domains
noam.concorp.contoso.com and europe.concorp.contoso.com.
194

Table 52 Users, Workstations, and Servers in the Bus Mgmt

Business Unit
Division Locations Users Workstatio Servers
ns
Planning Chicago 300 600 50
Marketing Chicago, 500 1,000 40
London
Legal Chicago, 300 600 30
London
Sales Chicago, 4,000 4,000 100
New York,
London,
Paris,
Rome
Other Chicago 400 800 30

Table 53 shows the numbers of server types that Bus Mgmt stores.
Table 53 Distribution of Server Types in Bus Mgmt Business
Unit
File
Locations Servers Web Database Application
Servers Servers Servers
Chicago, 120 45 50 35
London

Bus Mgmt Administrative and Group Policy Requirements

Administrative requirements for the Bus Mgmt business unit include the
management of users, workstations, and resources, as follows:
• User Account Management. All user accounts in North America are
centrally managed by one administrative group based in Chicago. All user
accounts in Europe are centrally managed by one administrative group based
in London.
• Workstation Management. Each physical location has a separate team
responsible for managing workstations.
• Resource Management. All business applications are hosted on servers in
Chicago and managed by one administrative group based in Chicago. Each
location has one local administrative group responsible for managing all
locally hosted resources.
Group Policy requirements include the settings that must be applied for different
types of accounts, for workstations (both desktop and portable computers), and
for resources according to the resource type, as follows:
 195

• User Accounts. All user accounts in North America need one Group Policy
for user configuration settings. Similarly, all accounts in Europe need one
Group Policy for user configuration settings. Additionally all users in each
division need a common user configuration policy.
• Workstations. Requirements for scripts and other computer configuration
settings necessitate that different Group Policy settings be applied for
desktop and portable computers.
• Resources. Computer configuration settings necessitate that different Group
Policy settings be applied for different kinds of resources and might require
the application of specific Group Policy settings for the various specific
resources.
Bus Mgmt OU Structure Based on Administrative and Group
Policy Requirements
Figure 17 shows the OU structure for the Bus Mgmt OU that accommodates the
administrative and Group Policy requirements for the
noam.concorp.contoso.com domain.
Figure 17 Bus Mgmt OU Structure for
noam.concorp.contoso.com
196

Table 54 shows the rationale for the OU structure for noam.concorp.contoso.com

shown in Figure 17.
Table 54 Purpose of Each OU in the Bus Mgmt Business Unit OU
Hierarchy in noam.concorp.contoso.com
 197

Organizational Unit Purpose

198

User Accounts Main OU to store user

accounts
Delegation point for Account
Admins role
User Accounts\Planning Used to apply Group Policy
for all users in Planning
User Accounts\Marketing Used to apply Group Policy
for all users in Marketing
User Accounts\Legal Used to apply Group Policy
for all users in Legal
User Accounts\Sales Used to apply Group Policy
for all users in Sales
User Accounts\Other Used to apply Group Policy
for all other users in the
business unit
Workstations Main OU to store workstation
computer accounts
Delegation point for
Workstation Admins role
Workstations\Chicago Used to delegate workstation
management for all
workstations in Chicago to
the local administrative
group
Workstations\New York Used to delegate workstation
management for all
workstations in New York to
the local administrative
group
Resources Main OU to store servers
comprising resources
Resources\Business Used to delegate resource
Applications management of all servers
involved in hosting all
business applications to one
administrative group
Resources\Business Used to collectively store and
Applications\Application 1..n manage all servers that are
part of some business
application
Resources\Chicago Used to delegate resource
management for all other
resources in Chicago to the
local administrative group
 199

Resources\New York Used to delegate workstation

management for all other
resources in New York to the
local administrative group
Resources\X\File, Web, OU Structure to store servers
Database, Application for common resources in
servers location X
200

Figure 18 shows the OU structure for the Bus Mgmt OU that accommodates the
administrative and Group Policy requirements for the
europe.concorp.contoso.com domain.
Figure 18 Bus Mgmt OU Structure for
europe.concorp.contoso.com
 201

Table 55 shows the rationale for the OU structure for

europe.concorp.contoso.com shown in Figure 18.
202

Table 55 Purpose of Each OU in the Bus Mgmt Business Unit OU

Hierarchy in europe.concorp.contoso.com
Organizational Unit Purpose
Accounts Main OU to store accounts
Delegation point for Account
Admins role
Accounts\Legal Used to apply Group Policy
for all users in Legal
Accounts\Sales Used to apply Group Policy
for all users in Sales
Accounts\Other Used to apply Group Policy
for all other users in the
business unit
Workstations Main OU to store workstation
computer accounts
Delegation point for the
Workstation Admins role
Workstations\London Used to delegate workstation
management for all
workstations in London to
the local administrative
group
Workstations\Paris Used to delegate workstation
management for all
workstations in Paris to the
local administrative group
Workstations\Rome Used to delegate workstation
management for all
workstations in Rome to the
local administrative group
Resources Main OU to store servers
comprising resources
Resources\Business Used to delegate resource
Applications management of all servers
involved in hosting all
business applications to one
administrative group
Resources\Business Used to collectively store and
Applications\Application 1..n manage all servers that are
part of some business
application
Resources\London Used to delegate workstation
management for all other
 203

resources in London to the

local administrative group
Resources\Paris Used to delegate workstation
management for all other
resources in Paris to the local
administrative group
Resources\Rome Used to delegate workstation
management for all other
resources in Rome to the
local administrative group
Resources\X\ File, Web, OU Structure to store servers
Database, Application for common resources in
servers location X in an organized
fashion

Bus Mgmt Role Instances Based on Business Unit

Requirements
On the basis of the Bus Mgmt business unit requirements, the following role
instances must be created:
• User Account Management. Because one group is responsible for account
management for North America and one for Europe, two instances of the
Account Admins role will be needed.

Note
One group is instantiated in the
noam.concorp.contoso.com domain and one
in the europe.concorp.contoso.com domain.
• Workstation Management. Because a different administrative group is
required for each of the five physical locations, five instances of the
Workstation Admins role are required.

Note
Certain groups are shared across both
noam.concorp.contoso.com domain and the
europe.concorp.contoso.com domain.
• Resource Management. Based on the business unit requirements, one
Resource Admins role instance is required to manage all servers that belong
to all the business applications hosted in Chicago and one instance of the
Resource Admins role is required for every physical location of this business
unit, for a total of six role instances.
Table 56 shows the model creation template that the data owners fill out to
document the Bus Mgmt NOAM Account Admins role.
204

Table 56 Model Creation Template for Bus Mgmt NOAM Account

Admins Role
Field Assignment Information
Role Instance Name Business Mgmt NOAM
Account Admins
Instance of Account Admins
Instance Number 1 of 2
Assigned Administrators Danielle, Jason
Assigned Tasks Manage all aspects of
account management for all
accounts in North America
Security Group Implementation
Permissions Assigned Implementation
Notes Creation and implementation

Table 57 shows the model creation template that the data owners fill out to
document the Bus Mgmt Europe Account Admins role.
Table 57 Model Creation Template for Bus Mgmt Europe
Account Admins Role
Field Assignment Information
Role Instance Name Business Mgmt Europe
Account Admins
Instance of Account Admins
Instance Number 2 of 2
Assigned Administrators Robert, Michelle
Assigned Tasks Manage all aspects of
account management for all
accounts in Europe
Security Group Implementation
Permissions Assigned Implementation
Notes Creation and implementation

Table 58 shows the model creation template that the data owners fill out to
document the Bus Mgmt Chicago Workstation Admins role.
Table 58 Model creation template for Bus Mgmt Chicago
Workstation Admins role
Field Assignment Information
 205

Role Instance Name Business Mgmt Chicago

Workstation Admins
Instance of Workstation Admins
Instance Number 1 of 5
Assigned Administrators Janet, Harold
Assigned Tasks Manage all aspects of
workstation management for
all workstations in Chicago
Security Group Implementation
Permissions Assigned Implementation
Notes Creation and implementation

Table 59 shows the model creation template that the data owners fill out to
document the Bus Mgmt London Workstation Admins role.
Table 59 Model creation template for Bus Mgmt London
Workstation Admins role
Field Assignment Information
Role Instance Name Business Mgmt London
Workstation Admins
Instance of Workstation Admins
Instance Number 2 of 5
Assigned Administrators Stuart, Ken
Assigned Tasks Manage all aspects of
workstation management for
all workstations in London
Security Group Implementation
Permissions Assigned Implementation
Notes Creation and implementation

Table 60 shows the model creation template that the data owners fill out to
document the Bus Mgmt New York Workstation Admins role.
Table 60 Model Creation Template for Bus Mgmt New York
Workstation Admins Role
Field Assignment Information
Role Instance Name Business Mgmt New York
Workstation Admins
Instance of Workstation Admins
206

Instance Number 3 of 5
Assigned Administrators Linda, Steve
Assigned Tasks Manage all aspects of
workstation management for
all workstations in New York
Security Group Implementation
Permissions Assigned Implementation
Notes Creation and implementation

Table 61 shows the model creation template that the data owners fill out to
document the Bus Mgmt Paris Workstation Admins role.
Table 61 Model Creation Template for Bus Mgmt Paris
Workstation Admins Role
Field Assignment Information
Role Instance Name Business Mgmt Paris
Workstation Admins
Instance of Workstation Admins
Instance Number 4 of 5
Assigned Administrators Marc, Sara
Assigned Tasks Manage all aspects of
workstation management for
all workstations in Paris
Security Group Implementation
Permissions Assigned Implementation
Notes Creation and implementation

Table 62 shows the model creation template that the data owners fill out to
document the Bus Mgmt Rome Workstation Admins role.
Table 62 Model Creation Template for Bus Mgmt Rome
Workstation Admins Role
Field Assignment Information
Role Instance Name Business Mgmt Rome
Workstation Admins
Instance of Workstation Admins
Instance Number 5 of 5
Assigned Administrators Victor, Rosa
Assigned Tasks Manage all aspects of
 207

workstation management for

all workstations in Rome
Security Group Implementation
Permissions Assigned Implementation
Notes Creation and implementation

Table 63 shows the model creation template that the data owners fill out to
document the Bus Mgmt Application Admins role.
Table 63 Model Creation Template for Bus Mgmt Application
Admins Role
Field Assignment Information
Role Instance Name Business Mgmt Application
Admins
Instance of Resource Admins
Instance Number 1 of 6
Assigned Administrators Fred, Glenn
Assigned Tasks Manage all aspects of all
business management
business unit applications
Security Group Implementation
Permissions Assigned Implementation
Notes Creation and implementation

Table 64 shows the model creation template that the data owners fill out to
document the Bus Mgmt Chicago Resource Admins role.
Table 64 Model Creation Template for Bus Mgmt Chicago
Resource Admins Role
Field Assignment Information
Role Instance Name Business Mgmt Chicago
Resource Admins
Instance of Resource Admins
Instance Number 2 of 6
Assigned Administrators Kristen, Terry
Assigned Tasks Manage all aspects of other
business management
business unit resources in
Chicago
Security Group Implementation
208

Permissions Assigned Implementation

Notes Creation and implementation

Table 65 shows the model creation template that the data owners fill out to
document the Bus Mgmt London Resource Admins role.
Table 65 Model Creation Template for Bus Mgmt London
Resource Admins Role
Field Assignment Information
Role Instance Name Business Mgmt London
Resource Admins
Instance of Resource Admins
Instance Number 3 of 6
Assigned Administrators Ron, Allison
Assigned Tasks Manage all aspects of other
business management
business unit resources in
London
Security Group Implementation
Permissions Assigned Implementation
Notes Creation and implementation

Table 66 shows the model creation template that the data owners fill out to
document the Bus Mgmt New York Resource Admins role.
Table 66 Model Creation Template for Bus Mgmt New York
Resource Admins Role
Field Assignment Information
Role Instance Name Business Mgmt New York
Resource Admins
Instance of Resource Admins
Instance Number 4 of 6
Assigned Administrators Chris, Julian
Assigned Tasks Manage all aspects of other
business management
business unit resources in
New York
Security Group Implementation
Permissions Assigned Implementation
Notes Creation and implementation
 209

Table 67 shows the model creation template that the data owners fill out to
document the Bus Mgmt Paris Resource Admins role.
Table 67 Model Creation Template for Bus Mgmt Paris Resource
Admins Role
Field Assignment Information
Role Instance Name Business Mgmt Paris
Resource Admins
Instance of Resource Admins
Instance Number 5 of 6
Assigned Administrators Albert, Emile
Assigned Tasks Manage all aspects of other
business management
business unit resources in
Paris
Security Group Implementation
Permissions Assigned Implementation
Notes Creation and implementation

Table 68 shows the model creation template that the data owners fill out to
document the Bus Mgmt Rome Resource Admins role.
Table 68 Model Creation Template for Bus Mgmt Rome
Resource Admins Role
Field Assignment Information
Role Instance Name Business Mgmt Rome
Resource Admins
Instance of Resource Admins
Instance Number 6 of 6
Assigned Administrators David, Thomas
Assigned Tasks Manage all aspects of other
business management
business unit resources in
Rome
Security Group Implementation
Permissions Assigned Implementation
Notes Creation and implementation
210

Creating the Delegation Model for the IT Business Unit

The IT business unit includes all the administrative personnel responsible for
managing all IT resources and providing IT support for Contoso
Pharmaceuticals.
Approximately 250 administrative personnel and 500 workstations are
distributed across all physical locations of this business unit. Approximately 100
servers provide various services to users. For example, an internal Web-based
application allows end-users to report issues and request assistance. One set of
servers provides Web-based documentation. Another set of servers provides an
internal tracking and monitoring system.
Table 69 shows the number of user accounts, workstations, and servers that are
stored in the IT business unit.
Table 69 Users, Workstations, and Servers in the IT Business
Unit
Locations Users Workstations Servers
Chicago, 2,500 5,000 100
Atlanta, New
York, London,
Paris, Rome

Table 70 shows the numbers of server types that the IT business unit stores.
Table 70 Distribution of Server Types in the IT Business Unit
Business File Web Database Application
Unit Servers Servers Servers Servers
IT 30 30 20 20

IT Administrative and Group Policy Requirements

Administrative requirements for the IT business unit include the management of
accounts, workstations, and resources, as follows:
• User account management. All user accounts in the IT business unit in
North America are centrally managed by one administrative group based in
Chicago. All user accounts in Europe are centrally managed by one
administrative group based in London.
• Workstation Management. All workstations in the IT business unit are
locally managed by separate administrative groups.
• Resource Management. All IT applications are hosted on servers in Chicago
and managed by one administrative group based in Chicago. Each location
has a one local administrative group that is responsible for managing all
locally hosted resources.
Group Policy requirements include the settings that must be applied for different
types of user accounts, workstations (both desktop and portable computers), and
resources according to resource type, as follows:
 211

• User Accounts. All user accounts in North America require one Group
Policy for user configuration settings. Similarly, all accounts in Europe need
one Group Policy for user configuration settings.
• Workstations. All workstations in North America require one Group Policy
for computer configuration settings and all workstations in Europe need one
Group Policy for computer configuration settings.
• Resources. Computer configuration settings necessitate that different Group
Policy settings be applied for different kinds of resources and might require
the application of specific Group Policy settings for the various specific
resources.
IT OU Structure Based on Administrative and Group Policy
Requirements
Figure 19 shows the OU structure for the IT OU that accommodates the
administrative and Group Policy requirements for the
noam.concorp.contoso.com domain.
212

Figure 19 IT OU Structure for noam.concorp.contoso.com

 213

Figure 20 shows the OU structure for the IT OU that accommodates the

administrative and Group Policy requirements for the
europe.concorp.contoso.com domain.
Figure 20 IT OU Structure for europe.concorp.contoso.com

IT Role Instances Based on Business Unit Requirements

On the basis of the IT business unit requirements, the following role instances
must be created:
214

• User Account Management. Because one group is responsible for account

management for North America and one for Europe, two instances of the
Account Admins role are needed.

Note
One group is instantiated in the
noam.concorp.contoso.com domain and one
in the europe.concorp.contoso.com domain.
• Workstation Management. Because a different administrative group is
required for each of the five physical locations, five instances of the
Workstation Admins role are required.

Note
Certain groups are shared across both
noam.concorp.contoso.com domain and the
europe.concorp.contoso.com domain
• Resource Management. Based on the business unit requirements, one
instance of the Resource Admins role is required to manage all the servers
that belong to all the IT applications in Chicago and one instance of the
Resource Admins role is required for every physical location where this
business unit is located.
Table 71 shows the model creation template that the data owners fill out to
document the IT NOAM Account Admins role.
Table 71 Model Creation Template for IT NOAM Account Admins
Role
Field Assignment Information
Role Instance Name IT NOAM Account Admins
Instance of Account Admins
Instance Number 1 of 2
Assigned Administrators Roderick, Francisco
Assigned Tasks Manage all aspects of acct
mgmt for all IT accounts in
North America
Security Group Implementation
Permissions Assigned Implementation
Notes Creation and implementation

Table 72 shows the model creation template that the data owners fill out to
document the IT Europe Account Admins role.
 215

Table 72 Model Creation Template for IT Europe Account

Admins Role
Field Assignment Information
Role Instance Name IT Europe Account Admins
Instance of Account Admins
Instance Number 2 of 2
Assigned Administrators Eric, Valerie
Assigned Tasks Manage all aspects of acct
mgmt for all IT accounts in
Europe
Security Group Implementation
Permissions Assigned Implementation
Notes Creation and implementation

Table 73 shows the model creation template that the data owners fill out to
document the IT Chicago Workstation Admins role.
Table 73 Model Creation Template for IT Chicago Workstation
Admins Role
Field Assignment Information
Role Instance Name IT Chicago Workstation
Admins
Instance of Workstation Admins
Instance Number 1 of 5
Assigned Administrators Larry, John
Assigned Tasks Manage all aspects of
workstation mgmt for all IT
business unit workstations in
Chicago
Security Group Implementation
Permissions Assigned Implementation
Notes Creation and implementation

Table 74 shows the model creation template that the data owners fill out to
document the IT London Workstation Admins role.
Table 74 Model Creation Template for IT London Workstation
Admins Role
Field Assignment Information
216

Role Instance Name IT London Workstation

Admins
Instance of Workstation Admins
Instance Number 2 of 5
Assigned Administrators Roland, Jonathan
Assigned Tasks Manage all aspects of
workstation mgmt for all IT
business unit workstations in
London
Security Group Implementation
Permissions Assigned Implementation
Notes Creation and implementation

Table 75 shows the model creation template that the data owners fill out to
document the IT New York Workstation Admins role.
Table 75 Model Creation Template for IT New York Workstation
Admins Role
Field Assignment Information
Role Instance Name IT New York Workstation
Admins
Instance of Workstation Admins
Instance Number 3 of 5
Assigned Administrators Neil, Paulette
Assigned Tasks Manage all aspects of
workstation mgmt for all IT
business unit workstations in
New York
Security Group Implementation
Permissions Assigned Implementation
Notes Creation and implementation

Table 76 shows the model creation template that the data owners fill out to
document the IT Paris Workstation Admins role.
Table 76 Model Creation Template for IT Paris Workstation
Admins Role
Field Assignment Information
Role Instance Name IT Paris Workstation Admins
Instance of Workstation Admins
 217

Instance Number 4 of 5
Assigned Administrators Elliott, Marie
Assigned Tasks Manage all aspects of
workstation mgmt for all IT
business unit workstations in
Paris
Security Group Implementation
Permissions Assigned Implementation
Notes Creation and implementation

Table 77 shows the model creation template that the data owners fill out to
document the IT Rome Workstation Admins role.
Table 77 Model Creation Template for IT Rome Workstation
Admins Role
Field Assignment Information
Role Instance Name: IT Rome Workstation Admins
Instance of Workstation Admins
Instance Number 5 of 5
Assigned Administrators Paul, Eleonora
Assigned Tasks Manage all aspects of
workstation mgmt for all IT
business unit workstations in
Rome
Security Group Implementation
Permissions Assigned Implementation
Notes Creation and implementation

Table 78 shows the model creation template that the data owners fill out to
document the IT Application Admins role.
Table 78 Model Creation Template for IT Application Admins
Role
Field Assignment Information
Role Instance Name: IT Application Admins
Instance of Resource Admins
Instance Number 1 of 6
Assigned Administrators Karen, Luke
Assigned Tasks Manage all aspects of all IT
218

business unit applications

Security Group Implementation
Permissions Assigned Implementation
Notes Creation and implementation

Table 79 shows the model creation template that the data owners fill out to
document the IT Chicago Resource Admins role.
Table 79 Model Creation Template for IT Chicago Resource
Admins Role
Field Assignment Information
Role Instance Name IT Chicago Resource Admins
Instance of Resource Admins
Instance Number 2 of 6
Assigned Administrators Perry, Steve
Assigned Tasks Manage all aspects of other
IT business unit resources in
Chicago
Security Group Implementation
Permissions Assigned Implementation
Notes Creation and implementation

Table 80 shows the model creation template that the data owners fill out to
document the IT London Resource Admins role.
Table 80 Model Creation Template for IT London Resource
Admins Role
Field Assignment Information
Role Instance Name IT London Resource Admins
Instance of Resource Admins
Instance Number 3 of 6
Assigned Administrators Jerry, Carol
Assigned Tasks Manage all aspects of other
IT business unit resources in
London
Security Group Implementation
Permissions Assigned Implementation
Notes Creation and implementation
 219

Table 81 shows the model creation template that the data owners fill out to
document the IT New York Resource Admins role.
Table 81 Model Creation Template for IT New York Resource
Admins Role
Field Assignment Information
Role Instance Name IT New York Resource Admins
Instance of Resource Admins
Instance Number 4 of 6
Assigned Administrators Jack, Erica
Assigned Tasks Manage all aspects of other
IT business unit resources in
New York
Security Group Implementation
Permissions Assigned Implementation
Notes Creation and implementation

Table 82 shows the model creation template that the data owners fill out to
document the IT Paris Resource Admins role.
Table 82 Model Creation Template for IT Paris Resource Admins
Role
Field Assignment Information
Role Instance Name IT Paris Resource Admins
Instance of Resource Admins
Instance Number 5 of 6
Assigned Administrators Guy, Lise
Assigned Tasks Manage all aspects of other
IT business unit resources in
Paris
Security Group Implementation
Permissions Assigned Implementation
Notes Creation and implementation

Table 83 shows the model creation template that the data owners fill out to
document the IT Rome Resource Admins role.
Table 83 Model Creation Template for IT Rome Resource Admins
Role
Field Assignment Information
220

Role Instance Name IT Rome Resource Admins

Instance of Resource Admins
Instance Number 6 of 6
Assigned Administrators Enrico, Antonella
Assigned Tasks Manage all aspects of other
IT business unit resources in
Rome
Security Group Implementation
Permissions Assigned Implementation
Notes Creation and implementation

Step 5 – Implement the Contoso Data Management Administrative

Delegation Model
At this point, one OU exists for every business unit and the Business Unit
Admins role for each Business Unit has been delegated Full Control over its
respective business unit OU.
Each business unit administrator implements the model for the respective OU
according to the following criteria:
• Stakeholders: Business Unit Admins from all Business Units
• Objective: Implement each role instance according to the delegation model
design document
• Assumption: The three domains are installed and functioning
• Approach: Implement the roles defined in the data management delegation
model by performing the following steps:
1. Create the OU structure for the business unit
• Implement role instances
• Assign users to roles
Implementing the Data Delegation Model for the RandD
Business Unit
The RandD business unit administrator is responsible for creating the business
unit OU structure and implementing the data management delegation model for
this business unit.
Creating the OU Structure for the RandD Business Unit
To create the RandD OU structure, the RandD business unit administrator creates
the following OU objects:
• OU=User Accounts,OU=RandD,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
 221

• OU=Workstations,OU=RandD,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
• OU=Resources,OU=RandD,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
• OU=Research,OU=User Accounts,OU=RandD,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
• OU=Development,OU=User Accounts,OU=RandD,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
• OU=Desktops,OU=Workstations,OU=RandD,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
• OU=Laptops,OU=Workstations,OU=RandD,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
• OU=File Servers,OU=Resources,OU=RandD,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
• OU=Web Servers,OU=Resources,OU=RandD,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
• OU=Database Servers,OU=Resources,OU=RandD,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
• OU=Application Servers,OU=Resources,OU=RandD,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
Implementing RandD Role Instances
To implement the RandD business administrative roles, the RandD business unit
administrator creates security groups in the Delegation OU to represent the role
instances for the business unit.
In OU=Delegation,OU=RandD,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com, the following groups are
created:
• RandD Account Admins
• RandD Workstation Admins
• RandD Resource Admins
The RandD the business unit administrator grants permissions to security groups
as follows:
• RandD Account Admins: Full Control on the Accounts OU
• RandD Workstation Admins: Full Control on the Workstations OU
• RandD Resource Admins: Full Control on the Resources OU
Additionally, the Restricted Groups feature of Group Policy is used to add the
security groups representing the Workstation Admins and Resource Admins roles
to the local Administrators groups on member servers.
222

Assigning RandD Administrative Users to Roles

The RandD business unit administrator adds the accounts of the administrative
personnel listed for each role in the delegation model templates to the respective
security groups that represent the role instances.
Implementing the Data Delegation Model for the Production
Business Unit
The Production business unit administrator is responsible for creating the
business unit OU structure and implementing the data management delegation
model for this business unit.
Creating the OU Structure for the Production Business Unit:
To create the Production OU structure, the Production business unit administrator
creates the following OU objects:
OU=User Accounts,OU=Production,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
OU=Workstations,OU=Production,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
OU=Resources,OU=Production,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
OU=Desktops,OU=Workstations,OU=Production,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
OU=Laptops,OU=Workstations,OU=Production,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
OU=Production Application 1,OU=Resources,OU=Production,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
OU=Production Application 2,OU=Resources,OU=Production,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
OU=Production Application 3,OU=Resources,OU=Production,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
OU=Shared Resources,OU=Resources,OU=Production,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
OU=File Servers,OU=Production Application
1,OU=Resources,OU=Production,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
OU=Web Servers,OU=Production Application
1,OU=Resources,OU=Production,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
OU=Database Servers,OU=Production Application
1,OU=Resources,OU=Production,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
 223

OU=Application Servers,OU=Production Application

1,OU=Resources,OU=Production,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
OU=File Servers,OU=Production Application
2,OU=Resources,OU=Production,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
OU=Web Servers,OU=Production Application
2,OU=Resources,OU=Production,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
OU=Database Servers,OU=Production Application
2,OU=Resources,OU=Production,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
OU=Application Servers,OU=Production Application
2,OU=Resources,OU=Production,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
OU=File Servers,OU=Production Application
3,OU=Resources,OU=Production,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
OU=Web Servers,OU=Production Application
3,OU=Resources,OU=Production,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
OU=Database Servers,OU=Production Application
3,OU=Resources,OU=Production,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
OU=Application Servers,OU=Production Application
3,OU=Resources,OU=Production,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
OU=File Servers,OU=Shared
Resources,OU=Resources,OU=Production,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
OU=Web Servers,OU= Shared
Resources,OU=Resources,OU=Production,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
OU=Database Servers,OU= Shared
Resources,OU=Resources,OU=Production,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
OU=Application Servers,OU= Shared
Resources,OU=Resources,OU=Production,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com
224

Implementing Production Role Instances

To implement the Production business unit administrative roles, the Production
business unit administrator creates security groups in the Delegation OU to
represent role instances for the business unit.
In OU=Delegation,OU=Production,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com, the following groups are
created:
• Production Account Admins
• Production Location 1 Workstation Admins
• Production Location 2 Workstation Admins
• Production Application 1 Resource Admins
• Production Application 2 Resource Admins
• Production Application 3 Resource Admins
• Production Common Resources Resource Admins
The Production business unit administrator grants permissions to security groups
as follows:
• Production Account Admin: Full Control on the Accounts OU
• Production Location 1 Workstation Admins: Full Control on the Location 1
OU within the Workstations OU
• Production Location 2 Workstation Admins: Full Control on the Location 2
OU within the Workstations OU
• Production Application 1 Resource Admins: Full Control on the Application
1 OU within the Resources OU
• Production Application 2 Resource Admins: Full Control on the Application
2 OU within the Resources OU
• Production Application 3 Resource Admins: Full Control on the Application
3 OU within the Resources OU
• Production Common Resources Resource Admins: Full Control on the
Common Resources OU within the Resources OU
Additionally, the Restricted Groups feature of Group Policy is used to add the
security groups representing Workstation Admins and Resource Admins roles to
the local Administrators groups on member servers.
Assigning Production Administrative Users to Roles
The Production business unit administrator adds the accounts of the
administrative personnel listed for each role in the model documentation
(templates) to the respective security groups that represent the role instances.
 225

Implementing the Data Delegation Model for the Bus Mgmt

Business Unit
The Bus Mgmt business unit administrator is responsible for creating the
business unit OU structure and implementing the data management delegation
model for this business unit.
Creating the OU structure for the Bus Mgmt Business Unit
To create the Bus Mgmt OU structure, the Bus Mgmt business unit administrator
creates the OU objects shown in Figures 17 and 18 earlier in this document.
Implementing Bus Mgmt Role Instances
To implement the Bus Mgmt business unit administrative roles, the Bus Mgmt
business unit administrator creates security groups in the Delegation OU of the
respective domain to represent the required role instances.
In OU=Delegation,OU=Bus Mgmt,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com, the following groups are
created:
• BusMgmt NOAM Account Admins
• BusMgmt Chicago Workstation Admins
• BusMgmt New York Workstation Admins
• BusMgmt Application Admins
• BusMgmt Chicago Resource Admins
• BusMgmt New York Resource Admins
In OU=Delegation,OU=Bus Mgmt,OU=Business
Units,DC=europe,DC=concorp,DC=contoso,DC=com, the following groups are
created:
• BusMgmt Europe Account Admins
• BusMgmt London Workstation Admins
• BusMgmt Paris Workstation Admins
• BusMgmt Rome Workstation Admins
• BusMgmt London Resource Admins
• BusMgmt Paris Resource Admins
• BusMgmt Rome Resource Admins
The Bus Mgmt business unit administrator grants permissions to the
corresponding security groups as shown in Table 84:
Table 84 Permissions for Security Groups Representing Bus Mgt
Business Unit Role Instances
Security Permissions OU Domain
Group
BusMgmt Full Control Accounts OU noam.concorp
226

NOAM .contoso.com
Account
Admins
BusMgmt Full Control Accounts OU europe.conco
Europe rp.contoso.co
Account m
Admins
BusMgmt Full Control Chicago OU noam.concorp
Chicago within the .contoso.com
Workstation Workstations
Admins OU
BusMgmt Full Control London OU noam.concorp
London within the .contoso.com
Workstation Workstations
Admins OU
BusMgmt Full Control New York OU noam.concorp
New York within the .contoso.com
Workstation Workstations
Admins OU
BusMgmt Full Control Paris OU europe.conco
Paris within the rp.contoso.co
Workstation Workstations m
Admins OU
BusMgmt Full Control Rome OU europe.conco
Rome within the rp.contoso.co
Workstation Workstations m
Admins OU
BusMgmt Full Control Applications noam.concorp
Application OU within the .contoso.com
Admins Resources OU
BusMgmt Full Control Chicago OU noam.concorp
Chicago within the .contoso.com
Resource Resources OU
Admins
BusMgmt Full Control London OU europe.conco
London within the rp.contoso.co
Resource Resources OU m
Admins
BusMgmt Full Control New York OU noam.concorp
New York within the .contoso.com
Resource Resources
Admins
BusMgmt Full Control Paris OU europe.conco
Paris within the rp.contoso.co
Resource Resources OU m
 227

Admins
BusMgmt Full Control Rome OU europe.conco
Rome within the rp.contoso.co
Resource Resources OU m
Admins

Additionally, the Restricted Groups feature of Group Policy is used to add the
security groups representing Workstation Admins and Resource Admins roles to
the local Administrators groups on member servers.
Assigning Bus Mgmt Administrative Users to Roles
The Bus Mgmt business unit administrator adds the accounts of the
administrative personnel listed for each role in the delegation model templates to
the respective security groups that represent the role instances.
Implementing the Data Delegation Model for the IT Business Unit
The IT business unit administrator is responsible for creating the business unit
OU structure and implementing the data management delegation model for this
business unit.
Creating the OU structure for the IT Business Unit
To create the Bus Mgmt OU structure, the IT business unit administrator creates
the OU objects shown in Figures 17 and 18 earlier in this document.
Implementing IT Role Instances
To implement the IT business unit administrative roles, the IT business unit
administrator creates security groups in the Delegation OU of each domain to
represent the required role instances:
In OU=Delegation,OU=IT,OU=Business
Units,DC=noam,DC=concorp,DC=contoso,DC=com, the following groups are
created:
• IT NOAM Account Admins
• IT Chicago Workstation Admins
• IT New York Workstation Admins
• IT Application Admins
• IT Chicago Resource Admins
• IT New York Resource Admins
In OU=Delegation,OU=IT,OU=Business
Units,DC=europe,DC=concorp,DC=contoso,DC=com, the following groups are
created:
• IT Europe Account Admins
• IT London Workstation Admins
• IT Paris Workstation Admins
228

• IT Rome Workstation Admins

• IT London Resource Admins
• IT Paris Resource Admins
• IT Rome Resource Admins
The IT business unit administrator grants permissions to the corresponding
security groups as shown in Table 85:
Table 85 Permissions for Security Groups Representing IT
Business Unit Role Instances
Security Permissions OU Domain
Group
IT NOAM Full Control Accounts OU noam.concorp
Account .contoso.com
Admins
IT Europe Full Control Accounts OU europe.conco
Account rp.contoso.co
Admins m
IT Chicago Full Control Chicago OU noam.concorp
Workstation within the .contoso.com
Admins Workstations
OU
IT London Full Control London OU europe.conco
Workstation within the rp.contoso.co
Admins Workstations m
OU
IT New York Full Control New York OU noam.concorp
Workstation within the .contoso.com
Admins Workstations
OU
IT Paris Full Control Paris OU europe.conco
Workstation within the rp.contoso.co
Admins Workstations m
OU
IT Rome Full Control Rome OU europe.conco
Workstation within the rp.contoso.co
Admins Workstations m
OU
IT Application Full Control Applications noam.concorp
Admins OU within the .contoso.com
Resources OU
IT Chicago Full Control Chicago OU noam.concorp
Resource within the .contoso.com
Admins Resources OU
 229

IT London Full Control London OU europe.conco

Resource within the rp.contoso.co
Admins Resources OU m
IT New York Full Control New York OU noam.concorp
Resource within the .contoso.com
Admins Resources OU
IT Paris Full Control Paris OU europe.conco
Resource within the rp.contoso.co
Admins Resources OU m
IT Rome Full Control Rome OU europe.conco
Resource within the rp.contoso.co
Admins Resources OU m

Additionally, the Restricted Groups feature of Group Policy is used to add the
security groups representing the Workstation Admins and Resource Admins roles
to the local Administrators groups on member servers.
Assigning IT Administrative Users to Roles
The IT BU Admin adds the accounts of the administrative personnel listed for
each role in the delegation model templates to the respective security groups that
represent the role instances.
This completes Contoso’s implementation of the delegation model. From this
point, Contoso will follow the recommendations for maintaining the delegation
model.