Service Management Overview

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

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.

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 Administrator Groups in Best Practices for Delegating Active Directory Administration: Appendices, which accompanies this document.

Active Directory service management can be separated into the following categories:

  • 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 https://go.microsoft.com/fwlink/?LinkID=21268.

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 https://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 trust relationship across forests 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 https://go.microsoft.com/fwlink/?LinkID=21268.

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.

  • 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 https://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 https://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.

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 https://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.

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 https://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

    • 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.

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 https://go.microsoft.com/fwlink/?LinkID=4723 and "Deploying DNS" on the Web at https://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 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 https://go.microsoft.com/fwlink/?LinkID=21268.

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:

  • 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 additional 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.

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 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.

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

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.

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 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 home page on the Microsoft Web site.

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 https://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.

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.

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

  • 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.

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 https://go.microsoft.com/fwlink/?LinkId=4709.

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.

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 management

Forest Configuration Operators

Operations Master Roles management

Forest Configuration Operators

Domain Configuration Operators

Backup and Restore management

Backup Operators

Domain Configuration Operators

LDAP Policy management

Forest Configuration Operators

Directory Service Configuration management

Domain Controller Administrators

Replication management

Replication Management Administrators

Replication Monitoring Operators

Functional Levels management

Forest Configuration Operators

Directory Database management

Domain Controller Administrators

Security Policy management

Security Policy Administrators

Service Admin Groups and Accounts management

Service Admin Managers

DNS management

DNS Administrators

Domain Controller management

Domain Controller 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 Category Covered

Forest Configuration Operators

Installation management

Trust management

Knowledge Reference management

Operations Master Roles management

LDAP Policy management

Functional Levels management

Domain Configuration Operators

Installation management

Operations Master Roles management

Backup and Restore management

Security Policy Administrators

Security Policy management

Service Admin Managers

Service Admin Groups and Accounts management

Domain Controller Administrators

Directory Service Configuration management

Directory Database management

Domain Controller management

Backup Operators

Backup and Restore management

Schema Administrators

Schema management

Replication Management Administrators

Replication management (topology and operational aspects)

Replication Monitoring Operators

Replication management (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 Administrator 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 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.