Establishing Secure Service Administration Practices

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

Service administrators have the most widespread power in your network environment. They are responsible for the delivery of the directory service, directory-wide settings, installation and maintenance of software, and application of operating system service packs and hotfixes on domain controllers. They also manage the overall configuration of the directory service, including replication behavior, schema management, and domain creation and deletion. To perform most of these functions, service administrators must have physical access to domain controllers.

Because service administrators have elevated privileges, take appropriate steps to keep their accounts secure:

• Secure service administrator accounts to control how the accounts are used.

• Secure service administrator workstations to control where the accounts can be used.

• Avoid delegating security-sensitive operations.

Securing Service Administrator Accounts

As with regular user access, administrative access to resources is controlled by the permissions that are set on the various resources being managed and by the privileges that are granted to the administrative accounts. Active Directory has a number of default service administrator accounts. By default, these accounts are granted access to directory and server resources when Active Directory is installed. Table 35 lists the default service administrator accounts and provides a brief description of each account.

Table 35 Default Service Administrator Accounts

Account Name	Scope	Description
Enterprise Admins (EA)	Forest	This group is automatically added to the Administrators group in every domain in the forest, providing complete access to the configuration of all domain controllers. This group can modify the membership of all administrative groups. Its own membership can be modified only by the default service administrator groups in the forest root domain. This account is considered to be a service administrator.
Schema Admins (SA)	Forest	This group has full administrative access to the schema. The membership of this group can be modified by any of the service administrator groups in the forest root domain. This account is considered to be a service administrator because its members can modify the schema, which governs the structure and content of the entire directory.
Administrators (BA)	Domain	This built-in group controls access to all domain controllers in its domain, and it can change the membership of all administrative groups in the domain. Its own membership can be modified by the default service administrator groups BA and DA in the domain, as well as by the EA group. This group has the special privilege of taking ownership of any object in the directory or of any resource on a domain controller. This account is considered to be a service administrator because its members have full access to the domain controllers in the domain.
Domain Admins (DA)	Domain	This group controls access to all domain controllers in a domain, and it can modify the membership of all administrative accounts in the domain. Its own membership can be modified by the service administrator groups BA and DA in its domain, as well as by the EA group. This account is a service administrator account because its members have full access to a domain’s domain controllers.
Server Operators (SO)	Domain	By default, this built-in group has no members, and it has access to server configuration options on domain controllers. Its membership is controlled by the service administrator groups BA and DA in the domain, as well as by the EA group. It cannot change any administrative group memberships. This account is a service administrator account because its members have physical access to domain controllers and they can perform maintenance tasks, such as backup and restore, and they have the ability to change binaries that are installed on the domain controllers.
Account Operators (AO)	Domain	By default, this built-in group has no members, and it can create and manage users and groups in the domain, but it cannot manage service administrator accounts. This account can modify computer accounts, including those accounts that belong to domain controllers. As a best practice, leave the membership of this group empty, and do not use it for any delegated administration.
Backup Operators (BO)	Domain	By default, this built-in group has no members, and it can perform backup and restore operations on domain controllers. Its membership can be modified by the default service administrator groups BA and DA in the domain, as well as by the EA group. It cannot modify the membership of any administrative groups. While members of this group cannot change server settings or modify the configuration of the directory, they do have the permissions needed to replace files (including operating system binaries) on domain controllers. For this reason, members of this group are considered service administrators.
Administrator	DS Restore Mode	This special account is created during the Active Directory installation process, and it is not the same as the Administrator account in the Active Directory database. This account is only used to start the domain controller in Directory Services Restore Mode. When it is in Directory Services Restore Mode, this account has full access to the directory database, as well as to files (including operating system binaries) on the domain controller. For this reason, this account is considered a service administrator.

Limiting the Exposure of Service Administrator Accounts

Service administrator accounts are highly privileged, making them desirable targets for attack. Therefore, it is especially important to protect the integrity of these accounts. The recommendations in this section are designed to enhance the security of your service administrator accounts. Limiting the exposure of the service administrator accounts gives attackers fewer targets of opportunity. Observe the practices in the following sections to limit the exposure of service administrator accounts.

Limit the Number of Service Administrator Accounts

Keep the membership of service administrator accounts to the absolute minimum that is necessary to support your organization. Tasks that are performed by service administrators should be limited to changing the Active Directory service configuration and reconfiguring domain controllers. Do not use service administrator accounts for day-to-day administrative tasks, such as account and member server management; instead, delegate these tasks to data administrators.

Separate Administrative and User Accounts for Administrative Users

For users who fill administrative roles, create two accounts: one regular user account to be used for normal, day-to-day tasks and one administrative account to be used only for performing administrative tasks. The administrative account should not be mail enabled or used for running applications that are used every day, such as Microsoft Office, or for browsing the Internet. These precautions reduce the exposure of the accounts to the outside world, and they reduce the amount of time that administrative accounts are logged on to the system.

Hide the Domain Administrator Account

Every installation of Active Directory has an account named Administrator in each domain. This is the default administrative account, which is created during domain setup, that you use to access and administer the directory service. This is a special account that the system protects to help ensure that it is available when needed. This account cannot be disabled or locked out.

The fact that this account is always created during domain setup, cannot be deleted, and cannot be disabled means that every malicious user who attempts to break into your system assumes that the account exists and that can it can be used as a target. For this reason, you should rename it to something other than Administrator. When you rename the account, make sure that you also change the text in the Description for the account. In addition, you should create a decoy user account called Administrator that has no special permissions or user rights.

To hide the default Administrator account, perform the following tasks:

1. Rename the default Administrator account. For more information about performing this task, see “Renaming the Default Administrator Account” in the Appendix: Procedures section.

2. Create a decoy Administrator account with no special permissions or privileges. For more information about performing this task, see “Creating a Decoy Administrator Account” in the Appendix: Procedures section.

Managing Service Administrators in a Controlled Subtree

To help protect highly privileged service administrator accounts, allow only service administrators to manage service administrator accounts. Because these accounts have elevated privileges, data administrators should not be given the authority to modify these accounts. Doing so allows data administrators to elevate their privileges. Service administrator accounts should be accessed and managed in a highly controlled subtree in each domain.

To provide a more controlled environment that facilitates the management of service administrator accounts and workstations, create a controlled OU subtree to manage service administrator accounts in Active Directory. The controlled subtree structure should be created for each domain by a member of the Domain Admins group for that domain, and it should be configured with its recommended security settings.

To create the controlled subtree, perform the following tasks:

1. Create the OU structure for the controlled subtree.

2. Set the permissions on the controlled subtree OUs.

3. Move service administrator groups to the controlled subtree.

4. Add service administrator user accounts to the controlled subtree.

5. Add service administrator workstation accounts to the controlled subtree.

6. Enable auditing on the controlled subtree OU.

By creating your own subtree containing all service administrator accounts and the administrative workstations that they use, you can apply controlled security and policy settings to them to maximize their protection.

Task 1: Create the OU structure for the controlled subtree.

Create a high-level OU to hold the groups and user accounts that constitute your service administrators and their workstations. Within that OU, create one OU to hold administrative user and group accounts and another OU for administrative workstations. Figure 10 depicts the recommended OU hierarchy for a controlled subtree to manage service administrator accounts and workstations. It consists of a controlled subtree, rooted at the Service Admins OU, that contains two additional OUs: the Users and Groups OU, to hold the administrative user and group accounts, and the Admin Workstations OU, to hold the computer accounts of the workstations that are used by the service administrators.

Task 2: Set the permissions on the controlled subtree OUs.

To limit access to the controlled subtree so that only service administrators can administer the membership of service administrator groups and workstations, do the following:

• Block inheritance of permissions on the Service Admins OU so that changes that are made higher up in the domain tree are not inherited down, altering the locked-down settings

• Set the permissions (ACLs) on the Service Admins OU, Users and Groups OU, and Admin Workstations OU, as indicated in Table 36.

Table 36 Permission Settings for the Controlled Subtree OUs

Type	Name	Access	Applies To
Allow	Enterprise Admins	Full Control	This object and all child objects
Allow	Domain Admins	Full Control	This object and all child objects
Allow	Administrators	Full Control	This object and all child objects
Allow	Pre–Windows 2000 Compatible Access	List Contents Read All Properties Read Permissions	User and InetOrgPerson objects
Allow	Enterprise Domain Controllers	List Contents Read All Properties Read Permissions	This object only
Allow	Enterprise Domain Controllers	Read All Properties	User, group, and computer objects

The following figure shows the Service Admins OU with permissions that control access to the contents of the OU.

Task 3: Move service administrator groups to the controlled subtree.

Move the following service administrator groups from their current location in the directory into the Users and Groups OU in your controlled subtree:

• Domain Admins and any nested subgroups

• Enterprise Admins (if this is the root domain of the forest) and any nested subgroups

• Schema Admins (if this is the root domain of the forest) and any nested subgroups

• Any groups that are nested in the domain’s Administrators, Server Operators, Backup Operators, or Account Operators groups

• Any group that has delegated rights that effectively grant its users service administrator rights

The built-in groups from Table 35 (Administrators, Server Operators, Account Operators, and Backup Operators) cannot be moved from their default container to the controlled subtree. However, built-in groups are protected by default in Windows Server 2003, as described in Table 38 later in this guide, and they need no additional protection.

Task 4: Add service administrator user accounts to the controlled subtree.

Move all administrative user accounts that are members of any of the service administrator groups listed in Table 35 from their current locations in the directory into the Users and Groups OU in your controlled subtree. This set of accounts includes the domain Administrator account.

As recommended, each service administrator should have two accounts: one for administrative duties and one for their normal user access. Place the administrative user accounts in the Users and Groups OU in your controlled subtree. If these accounts already exist elsewhere in the directory, move them into the subtree now. The regular user accounts for those administrators should not be placed in this controlled subtree.

Task 5: Add administrative workstation accounts to the controlled subtree.

Designate administrators’ computers as administrative workstations. Move the computer accounts for those workstations into the Admin Workstations OU in your controlled subtree.

Task 6: Enable auditing on the controlled subtree.

It is important to audit and track any additions, deletions, and changes to the service administrator accounts and workstations — and changes in policies that are applied to them — so that improper or unauthorized changes can be detected. Assuming that you have enabled auditing on your domain controllers in accordance with the recommendations in Chapter 4: Strengthening Domain and Domain Controller Policy Settings, set the SACL on the Service Admins OU by setting auditing, as specified in Table 37. Monitor the security audit log for changes to the controlled subtree, so that you can ascertain that the changes are legitimate.

Table 37 Auditing Settings on OU=Service Admins,DC=domain name

Type	Name	Access	Applies To
All	Everyone	Write All Properties	This object and all child objects
All	Everyone	Delete	This object and all child objects
All	Everyone	Delete Subtree	This object and all child objects
All	Everyone	Modify Permissions	This object and all child objects
All	Everyone	Modify Owner	This object and all child objects
All	Everyone	All Validated Writes	This object and all child objects
All	Everyone	All Extended Rights	This object and all child objects
All	Everyone	Create All Child Objects	This object and all child objects
All	Everyone	Delete All Child Objects	This object and all child objects

At this point, the controlled subtree for service administrators is set up and ready for use.

Protecting the 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 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 it runs once every half hour after that. This refresh interval is not configurable. In Active Directory in Windows Server 2003, all the service administrative groups that are listed in Table 35 and all their nested member groups and users are protected by this process.

The master security descriptor for service administrator accounts is stored as the security descriptor attribute of the AdminSDHolder object, which is located in the system container (CN=AdminSDHolder,CN=System,DC=DomainName) of the domain directory partition.

The security descriptor on this object serves two purposes:

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

The default settings in the master security descriptor of the AdminSDHolder object are listed in Table 38.

Table 38 Default Security Descriptor on the AdminSDHolder Object Used to Protect Service Administrator Accounts

Type	Name	Permission	Apply To
Allow	Administrators	List Contents Read All Properties Write All Properties Delete Read Permissions Modify Permissions Modify Owner All Validated Writes All Extended Rights Create All Child Objects Delete All Child Objects	This object only
Allow	Authenticated Users	List Contents Read All Properties Read Permissions	This object only
Allow	Domain Admins	List Contents Read All Properties Write All Properties Read Permissions Modify Permissions Modify Owner All Validated Writes All Extended Rights Create All Child Objects Delete All Child Objects	This object only
Allow	Enterprise Admins	List Contents Read All Properties Write All Properties Read Permissions Modify Permissions Modify Owner All Validated Writes All Extended Rights Create All Child Objects Delete All Child Objects	This object only
Allow	Everyone	Change Password	This object only
Allow	Pre–Windows 2000 Compatible Access	List Contents Read All Properties Read Permissions	User and InetOrgPerson objects
Allow	SYSTEM	Full Control	This object only
Allow	SELF	Change Password	This object only
Allow	Cert Publishers	Read userCert Write userCert	This object only
Allow	Windows Authorization Access Group	Read tokenGroupsGlobalAndUniversal	This object only
Allow	Terminal Server License Servers	Read terminalServer Write terminalServer	This object only

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. Be careful 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 the Appendix: Procedures section.

Hiding the Membership of the Service Administrator Groups

Because members of the service administrator groups are highly privileged, they constitute an attractive target for attackers. Therefore, the membership information of these groups should be guarded as much as possible. For maximum security, it is best to hide the membership information for all service administrator groups from regular users. However, the default security descriptor on AdminSDHolder that is used to protect service administrator groups allows their membership information to be visible to regular users.

The entry in Table 38 that grants Read access to Authenticated Users allows those users to list the membership information for all service administrator groups. Some applications and services rely on the presence of this permission to enumerate the members of an administrative group. For example, applications such as Microsoft SQL Server, which run under service accounts, might read the list of administrative group members to make its own application-specific access control decisions. Other non-Microsoft applications and line-of-business applications might also rely on this capability. Because there is no way to anticipate every service account that will need this type of Read access, the Authenticated Users entry exists to support all such cases.

It is possible to tighten security further by removing Read access for Authenticated Users from the security descriptor on AdminSDHolder, although doing so can cause some of your server-based applications to stop functioning. To ensure the proper functioning of these applications, systematically remove Read access for Authenticated Users by performing the following tasks:

1. If you have not already done so, disable pre–Windows 2000 compatible access for your domain. For more information, see "Disabling Anonymous Active Directory Access" in the Establishing Secure Domain Controller Build Practices earlier in this guide.

2. Create a group called Server Applications, and grant it Read access to AdminSDHolder by adding the permissions shown in Table 39.

3. Add the individual service accounts that are used by your applications that require the ability to enumerate group membership of the service administrator groups to the Server Applications group.

4. Remove the Authenticated User and the Pre–Windows 2000 Compatible Access entries from the security descriptor.

Table 39 Permission Changes on AdminSDHolder for the Server Applications Group

Type	Name	Permission	Apply To
Allow	Server Applications	List Contents	This Object Only
Allow	Server Applications	Read All Properties	This Object Only
Allow	Server Applications	Read Permissions	This Object Only

At this point, your service administrator accounts should not be visible to regular users on your network. Because it is impossible to predict the impact on every application, closely monitor applications running in your environment and make sure that they still function properly. If you observe application problems, simply add Authenticated Users as a member of the newly created Server Applications group to restore functionality, while you diagnose how to remove the application dependency.

Managing Group Memberships for Service Administrator Accounts

To enhance security, limit the membership in each of the service administrator groups to the absolute minimum that your organizational logistics allow, while still enabling you to manage your Active Directory service functions. Limiting these memberships reduces the number of possible administrative accounts that can be compromised by malicious users. The practices in the following sections are recommended for managing the membership of the service administrator groups.

Assign Trustworthy Personnel

Service administrators control the configuration and functioning of the directory service. Therefore, this responsibility should be given only to reliable, trusted users who have demonstrated responsible ownership and who fully understand the operation of the directory. They should be completely familiar with your organization’s policies regarding security and operations, and they should have demonstrated their willingness to enforce those policies

Restrict Service Group Membership to Users Within the Forest

Do not include users or groups from another forest as members of service administrator groups, unless you completely trust the service administrators of the other forest. Because service administrators in the other forest have full control on the user accounts in that forest, they can easily impersonate or authenticate to your forest using the credentials of one of those users. Further, by trusting the remote domain (or forest) in this way, you also trust their security measures, which is something you have no control over.

If it is necessary to have a user from another forest act as a service administrator in your domain, create an account in your domain that he or she can use when performing the administrative role. By using a local account, you eliminate dependence on the security measures of the other forest.

Limit the Schema Admins Group to Temporary Members

The Schema Admins group is a special group in the forest root domain that provides administrative access to the Active Directory schema. Members of this group have the necessary user rights to make changes to the schema. In general, because schema changes are rare, it is not necessary for a schema administrator to be available at all times. This account is needed only when a schema update must be processed or if a change must be made to the configuration of the schema master role holder.

To minimize the possibility of an Active Directory attack through a schema administrator account, keep the membership of the Schema Admins group empty. Add a trusted user to the group only when an administrative task must to be performed on the schema. Remove that user after the task is completed.

Limit Administrator Rights to Those Rights That Are Actually Required

Active Directory contains a Backup Operators built-in group. Members of this group are considered to be service administrators because members of the group have the privilege to log on locally and restore files, including the system files, on domain controllers. Membership in the Backup Operators group in Active Directory should be limited to those individuals who back up and restore domain controllers.

All member servers also contain a Backup Operators built-in group that is local to each server. Individuals who are responsible for backing up applications on a member server (for example, Microsoft SQL Server) should be made members of the local Backup Operators group on that server. These users should not be members of the Backup Operators group in Active Directory.

On a dedicated domain controller, you can reduce the number of members in the Backup Operators group. When a domain controller is used to run other applications, as might be the case in a branch office, users who are responsible for backing up applications on the domain controller must also be trusted as service administrators because they have the privileges that enable them to restore files, including the system files, on domain controllers.

Avoid using the Account Operators group for strictly delegating a “data administration” task, such as account management. The default directory permissions give this group the ability to modify the computer accounts of domain controllers, including deleting them. By default, there are no members of the Account Operators group, and its membership should be left empty.

Controlling the Administrative Logon Process

The members of the Administrators, Enterprise Admins, and Domain Admins groups represent the most powerful accounts in your forest and in each individual domain. To minimize security risks, take the steps in the following sections to enforce strong administrative credentials.

Require Smart Cards for Administrative Logon

Require your service administrators to use smart cards for their interactive logons. In addition to forcing the administrative users to have physical possession of the cards to log on, smart cards also ensure the use of randomly generated, cryptographically strong passwords on the user accounts. These strong passwords help to protect against the theft of weak passwords to gain administrative access. To implement this strategy, you must have a PKI available to authenticate the smart cards.

You can enforce the use of smart cards by enabling the Interactive logon: Require smart card security option for each administrative account. If you create a subtree, as described in Managing Service Administrators in a Controlled Subtree, set this option on the Users and Groups OU.

For more information about using smart cards authentication, see The Smart Card Deployment Cookbook on the Microsoft TechNet Web site at https://go.microsoft.com/fwlink/?LinkId=18552, and see “Designing a Public Key Infrastructure” and “Planning a Smart Card Deployment” in Designing and Deploying Directory and Security Services of the Windows Server 2003 Deployment Kit (or see “Designing a Public Key Infrastructure” on the Web at https://go.microsoft.com/fwlink/?LinkId=4735 and “Planning a Smart Card Deployment” on the Web at https://go.microsoft.com/fwlink/?LinkId=4736).

Share Logon Credentials for Sensitive Administrative Accounts

For each account that is a member of the Enterprise Admins and Domain Admins groups in the forest root domain, assign two users to share that account so that both users must be present to log on successfully with that account. Sharing these accounts provides inherent visual auditing of the use of the accounts, in which one user observes the actions that are performed by the other. It also means that a single user cannot log on privately to access the system as an administrator and compromise its security, either as a rogue administrator or under coerced circumstances.

Shared administrative accounts can be implemented by using either split passwords or split smart cards plus personal identification numbers (PINs). If you are using:

• Password-based credentials for administrative accounts:

  Split the password for the administrative account between the two users who share that account so that each user knows only half of the password. Each user is responsible for maintaining their half of the password. For example, you can create an administrative account called Admin1 and assign two trusted users, Jane and Bob, to share this account. Each of them maintains half of the password. For one of them to log on and use the account, the other must be present to enter the other half of the password.

• Smart-card-based credentials for administrative accounts:

  Split the ownership of the smart card and its PIN between the two users sharing that account so that one user retains physical ownership of the smart card and the other user maintains the PIN for the card. This way, both users must be present to log on to the account.

Securing Service Administrator Workstations

In addition to limiting access to resources that are stored on the domain controllers and access to information that is stored in the directory, you can also enhance security by strictly controlling the workstations that are used by service administrators for administrative functions.

Restricting Service Administrators Logon to Administrative Workstations

Each administrative account can be restricted so that it is allowed to log on only to specific workstations. If one of your administrative accounts is compromised, limiting the possible workstations limits the number of locations where that account can be used.

As described in described in the Managing Service Administrators in a Controlled Subtree section, the process of creating a controlled subtree of OUs for the management of service administrator accounts can be used for managing administrative workstations as well. Move the administrative workstations into this subtree so that you can apply Group Policy settings that control who can log on at which location.

To limit the locations where the service administrator accounts can log on, perform the following tasks:

1. Modify the User Rights Assignment policy in the Default Domain Policy GPO (Default Domain Security Settings) to Deny log on locally to the following groups: Schema Admins, Enterprise Admins, Domain Admins, Server Operators, Backup Operators, and Account Operators.

   For more information about performing this task, see “Denying Logon Access to the Domain” in Appendix: Procedures later in this guide.

2. Define the User Rights Assignment policy setting Deny log on locally, but do not assign the right to any group. By default, the Deny log on locally right on the Admin Workstations OU is not defined. If you leave it that way, the Deny log on locally right in the Default Domain Policy GPO applies.

   For more information about performing this task, see “Allowing Logon Access to Administrative Workstations” in Appendix: Procedures later in this guide.

   The figure below shows the application of the Deny log on locally right for the various service administrative accounts to the Default Domain Policy and the same Deny log on locally right defined on the Admin Workstations OU but unassigned (not applied to any accounts). The policy that is applied at the OU level overrides the domain-level policy.

   

Prohibiting the Use of Cached Credentials in Unlocking an Administrative Console

When the console on an administrative workstation is locked, either by the action of a user or automatically by a screensaver time-out, the console must be unlocked to regain access to the workstation. The workstation maintains cached credentials for any users that have been authenticated locally. When the console is unlocked, by default the workstation uses these cached credentials, if they exist, for the user who attempts to unlock the console.

When cached credentials are used to unlock the console, any changes to the account, such as user rights assignment, group membership changes, or disabling of the account, are not enforced. For example, if an administrator who is logged on to a workstation console is terminated, he can still unlock the console, even if his account is disabled. To ensure that any changes to the account are enforced immediately, require domain controller authentication of the account to unlock the console, instead of cached credentials.

To ensure that cached credentials cannot be used to unlock an administrative workstation, set the security option Interactive logon: Require Domain Controller authentication to unlock workstation to Enabled in Group Policy for the Admin Workstations OU.

Avoiding Running Applications in Administrative Contexts

When a computer becomes a member of a domain, the Domain Admins group is automatically added to the local Administrators group on that computer. This membership gives Domain Admins full access to the member computer. However, if the computer contracts a virus while a domain administrator is logged on, the virus runs in the context of that domain administrator, who is also a local administrator. In this way, the virus is able to use the administrator’s privileges to infect the workstation.

To avoid running applications in the context of a service administrator account, remove the Domain Admins group from the local Administrators group on the workstations in the Admin Workstations OU in your controlled subtree. If a service administrator contracts a virus while logged on, the virus will not have administrative access to the computer.

Also, avoid running application or service agents on administrative workstations in the context of a service administrator account. For example, a monitoring agent running in the context of a Domain Admins member might make it possible for a compromised agent to breach the security of the domain and the domain controllers. The local administrator account on the workstation has the necessary privileges to take control of the agent and act as the service administrator. If a user manages to gain access to the system as a local administrator, that user can then assume control of the agent and any information that it is collecting.

Running Antivirus Software

Running antivirus software regularly on administrative workstations helps protect the workstations from contracting a virus that can exploit the privileges of a logged-on service administrator to spread itself through the computer and into the domain.

Securing Traffic Between Administrative Workstations and Domain Controllers

Table 40 lists the features in Windows Server 2003 that can be used to secure traffic between administrative workstations and domain controllers, along with the threats that are mitigated by each feature.

Table 40 Features in Windows Server 2003 That Secure Administrative Traffic

Feature	Requirements	Information Disclosure Threat	Data Tampering Threat
LDAP packet encryption and signing	Windows Server 2003 or Windows XP with Adminpak.msi	Mitigated	Mitigated
LDAP packet signing	Windows 2000 SP3 and later	N/A	Mitigated
Terminal Services (Remote Desktop for Administration)	Windows Server 2003	Obfuscated	Obfuscated

Securing LDAP Traffic Between Administrative Workstations and Domain Controllers

On administrative workstations that are running Windows XP Professional, you can install the Windows Server 2003 Administration Tools Pack (Adminpak.msi), which can be installed from the i386 directory on the Windows Server 2003 CD. This version of the Administration Tools Pack encrypts and signs LDAP traffic between the administrative tool clients and domain controllers. If your administrative workstations are running Windows Server 2003, the administration tools are installed by default; you do not have to install the Administration Tools Pack.

When LDAP traffic is not encrypted and signed, it is possible for attackers to gain access to sensitive information by intercepting network traffic between administrative workstations and domain controllers. Encrypting and signing LDAP traffic protects against two types of vulnerabilities to the data:

• Information disclosure: A user can gain access to data, intentionally or otherwise, that the user is not authorized to see.

• Data tampering: A user can modify system or user data, with or without detection.

If administrative workstations are running Windows 2000, they cannot run the Administration Tools Pack. However, you can set Group Policy to force signing of all LDAP traffic from the administrative workstation.

LDAP packet signing does not encrypt the data in the packet, and the data can still be read by someone who captures the packet. LDAP packet signing does, however, use a digital signature to help prevent the attacker from altering the packet and putting it back on the network. Digital signatures in the packet guarantee the integrity of the data.

To use LDAP packet signing, administrative workstations must be running at least Windows 2000 SP3, and they must have the Network Security: LDAP client signing requirements security option set to Require Signing in the Admin Workstations OU GPO.

LDAP packet signing and encryption applies only to LDAP traffic between the workstations and domain controllers.

Using Terminal Services to Perform Procedures Remotely on Domain Controllers

On domain controllers that are running Windows Server 2003, Remote Desktop for Administration, formerly known as Terminal Services in Remote Administration mode, provides remote access to the desktops of computers that are running any operating system in the Windows Server 2003 family. Remote Desktop for Administration is disabled by default. You must enable Remote Desktop for Administration on all domain controllers that you want to manage over a remote connection.

Terminal Services in Remote Administration mode is the graphical remote administration component in the Windows 2000 Server family. The Terminal Services feature is built into each version of Windows 2000 Server, and Terminal Services in Remote Administration mode is the recommended method for all graphical remote administration tasks that are performed on computers that are running Windows 2000 Server.

Because LDAP signing and encryption are built into Windows Server 2003 Administration Tools Pack (Adminpak.msi), remote administration by using these tools is the recommended practice for administering Active Directory remotely on domain controllers that are running Windows Server 2003. However, for all other computer management tasks that you need to perform locally on a domain controller, use Remote Desktop for Administration. For example, you can run Ntbackup remotely only by using Remote Desktop for Administration.

The client component that uses Remote Desktop for Administration is Remote Desktop Connection, formerly known as the Terminal Services client. Remote Desktop Connection is available by default on computers that are running Windows XP or Windows Server 2003 operating systems.

For more information about using Remote Desktop for Administration, see Help and Support Center for Windows Server 2003. For more information about using Terminal Services for remote administration of domain controllers that are running Windows 2000 Server, see “Best Practice Guide for Securing Active Directory Installations and Day-to-Day Operations: Part I.” To download this document, click the link under “Planning & Deployment Guides” on the Microsoft Web site at https://go.microsoft.com/fwlink/?LinkId=18591.

Avoiding the Delegation of Security-Sensitive Operations

There are some forest-level and domain-level operations that should not be delegated away from the trusted service administrator accounts that they are assigned to by default. Delegation of these operations can lead to an elevation-of-privilege or denial-of-service attack by the user to whom the task is delegated, which could jeopardize the entire forest or domain. Control of such operations should be retained solely within the service administrator groups. The following sections list security-sensitive operations that should not be delegated.

Restricting the Delegation of Sensitive Forest-Level Operations

The operations in Table 41 should be performed only by a member of the forest-level service administrator groups (Enterprise Admins or Schema Admins), and they should not be delegated to anyone else. Delegating these operations can lead to an elevation-of-privilege attack by a malicious user.

Table 41 Forest-Level Operations That Should Not Be Delegated

Operation	Reason Why the Operation Should Not Be Delegated
Installing the enterprise CA	Any user with the authority to set up the CA has the authority needed to issue certificates to individuals that can result in elevated privileges. The authority to perform this action must remain with the most trusted service administrator account in your organization.
Modifying forest LDAP policy settings	Some LDAP policies control the performance of domain controllers. These policies are applied across the forest. Therefore, they can affect every domain controller. If improper settings are distributed, they can result in denial of service.
Modifying the schema	Modifications to the schema have a forest-wide impact. Improper modifications can result in the failure of existing applications or possible directory corruption. The ability to modify the schema also makes it possible to modify the default security descriptors of the classes used to protect new objects that are created in the directory. By making changes to default security descriptors, a user can gain the ability to create security principals with elevated privileges.
Managing forest-level operations master roles	A user with this ability has the authority to seize operations master roles. If it is performed improperly, this operation can result in a directory that is unusable. Improperly seizing the domain naming master can result in a situation in which domains with duplicate names might be created in the forest. After they are discovered, the process of repairing them might render trusts with other domains in the forest invalid, requiring portions of the forest to be rebuilt. Improperly seizing the schema master role can result in the existence of multiple schemas, which in turn can lead to islands of domain controllers that are associated with each copy of the schema.
Managing site topology	A user who has been delegated control over the site topology can launch a denial-of-service attack against every domain in the forest. This attack can be accomplished by breaking all inbound replication connections (that is, allowing no inbound replication).
Managing crossRef objects	Modifying crossRef objects can result in elevation of privilege. A user with this ability can create a private domain that he or she can specify as trusted. The user can then modify the SID history of an account in the private domain to introduce SIDs that represent the account as a domain administrator in the main domain, giving that account elevated privileges.

Restricting the Delegation of Sensitive Domain-Level Operations

To enhance security, the operations in Table 42 should be performed only by members of the domain-level service administrator groups (Administrators, Domain Admins, Server Operators, or Backup Operators). These operations should not be delegated to anyone else.

Table 42 Domain-Level Operations That Should Not Be Delegated

Operation	Reason Why the Operation Should Not Be Delegated
Installation and removal of Active Directory	The account with this authority has the ability to add and remove domains within the forest, including the ability to add and remove domain controllers. Therefore, this account can add and remove nodes of the distributed directory service and the associated security infrastructure. Access to password and account information in those domains can be used for offline password-cracking attacks. This account can also delete entire domains, which is an extreme example of a denial-of-service attack.
Software installation on domain controllers	The installer has local administrator access to the domain controller. With this type of access, a user can gain direct access to the directory database file, with the ability to copy it for an offline attack. The user also has the necessary permissions to install software updates and add services to the operating system. Services might include rogue agents that filter passwords or debuggers to monitor the LSA process for sensitive information.
Outbound trust management	Users who have the authority to create outbound trusts to external domains or to manipulate trusts with non-Windows Kerberos realms have the authority to establish trust with a dummy target forest of their creation in which they are administrators of the forest root domain, such as domain administrator or enterprise administrator. In the dummy target forest, they can manipulate their group membership in the directory to introduce group SIDs that represent a privileged entity in the source forest. Unless proper SID filtering has been enabled (which is the default setting in Windows Server 2003), creating an external trust can result in elevation of privileges in the source forest.
Replication management	Anyone with replication management rights has the ability to direct replication to an outside source, where data from the directory can be collected and then taken offline for a password-cracking attack. In a given domain, if the users who are delegated this right have full control over any computer object in the domain, they can inject arbitrary changes into the domain by creating a fake replication source. They also have the ability to launch denial-of-service attacks by removing replication links and preventing replication from taking place.
Domain-level operations master role management	The domain controller with the RID master role controls the domain RID pool as well as the allocation of RIDs to the domain controllers. Improper seizure of this role can result in duplicate RIDs being allocated. As a result, new objects will be given invalid SIDs.
Domain controller security policy changes	The user with this ability can control all access to the domain controller. Policy configuration is generally fairly static, and after it is initially set, changing it is an infrequent operation. There is no real need to delegate this operation.
Domain security policy changes	Domain security policies affect all domain users, member servers, and workstations that are members of the domain. A user with this ability can apply security policies to the entire domain. Security policies can be used to spread a weak password policy, which in turn can lead to broken passwords. Domain security policy change is an infrequent operation, and there is no real need to delegate it.
Backup and restore operations	Users with these rights have the ability to overwrite files on the system and use tools that copy files off the system. Having this ability allows the installation of rogue agents or the removal of files for offline password cracking.