Establishing Secure Data 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

Data administrators are responsible for managing data that is stored in the directory and on computers that are members of the forest. Data administrators have no control over the configuration and delivery of the directory service itself; they control subsets of objects in the directory. Using permissions on objects that are stored in the directory, it is possible to limit the control of a given administrator account to very specific areas of the directory. Data administrators also manage computers (other than domain controllers) that are members of their domain. They manage local resources, such as print and file shares on local servers, and they also manage the group and user accounts for their own part of the organization. Data administrators can perform all of their responsibilities from management workstations, and they do not need physical access to domain controllers.

Delegation of data administration is accomplished by creating groups, granting the appropriate user rights to those groups, and applying Group Policy settings to the members of those groups. After these steps are complete, delegation is a matter of adding user accounts to the groups that are created. The critical part of this operation is granting proper access and applying the proper policies to maximize security, while still allowing administrators to perform their delegated functions.

Delegating Data Management

Because the creation of data administrator accounts and the specific functions that are delegated to them is driven by the needs of individual organizations, it is difficult to list specific recommendations for creating and managing individual accounts. However, this section provides a list of considerations to keep in mind when delegating control to data administrator accounts.

Restricting Group Policy Application to Trusted Individuals

Group Policy should be created and applied only by completely trusted individuals. These individuals should be familiar with the organization’s security policies, and they should have demonstrated their willingness to enforce those policies.

Users with accounts that have the ability to create or modify Group Policy settings can elevate the privileges of another user account through those policies. For example, if these users modify a GPO that has been applied to a group of administrative accounts, they might be able to configure a logon script that runs the next time that one of the administrators logs on. The logon script might contain a script that adds their user accounts to the Administrators group. Because the script is launched during the administrator's logon process, it runs in the security context of the administrator. In this case, it acts as if the administrator were adding the users to the group. After this process is complete, the users have administrative access.

Taking Ownership of a Data Object

If data administrators have the ability to create objects, make sure that you understand the scope of that ability. When a user creates an object, he or she might also become the owner of that object by virtue of being its creator, and this person is called the Creator Owner. In the discretionary access control model that is used by Windows Server 2003, the owner of an object has Full Control of that object, including the ability to change the permissions on that object. By implication, the owner of an object also has Full Control permissions on any child objects that might be added under that object. The owner has the ability to block permission inheritance from parent objects and to block service administrators’ access to that object.

If a situation arises in which access to an object has been blocked so that even service administrators cannot access it, a member of the Administrators group must take ownership of the object to regain control. Members of the Administrators group always have the right to take ownership of an object, and as the owner they can modify the security descriptor of the object.

Reserving Ownership of Directory Partition Root Objects for Service Administrators

Ensure that the appropriate service administrator groups in each domain own the root object for the domain directory partition. Because the owners of these directory partition root objects have the ability to change the security settings of all other objects in the partition through inheritable ACEs, it is vitally important to ensure that the directory partition root object is owned by a highly trusted administrative group. By default, Active Directory partitions are set up so that the directory partition root objects are owned by the administrative groups that are recommended in this guide. The schema directory partition is owned by the Schema Admins group, the configuration directory partition is owned by the Enterprise Admins group, and the domain directory partition is owned by the Builtin\Administrators group.

Preventing Concurrent Group Membership Changes

When you plan your account management operations, institute operational practices ensuring that changes to group memberships within a delegated scope — for example, within an OU — are performed by a single data administrator within that OU, or that they are tightly coordinated between a few data administrators for that OU. By limiting group administration to a single account or to as few accounts as possible in each administrative entity (domain or OU), you greatly reduce the potential for conflicting changes to group membership. Concern about conflicting membership changes is significant in Windows 2000 as a result of the way that Active Directory in Windows 2000 replicates and handles conflicts in group membership changes between domain controllers. This concern is removed in Windows Server 2003 because group membership changes replicate differently.

Windows 2000 Replication of Entire Group Membership

In Windows 2000, when the membership of a group changes, the entire list of members, which is stored as a single multivalued attribute in the group object, replicates as a whole. If a conflict is detected between two concurrent changes to the group membership that originate at two separate domain controllers, one change wins (the change that occurs last) and the other change is lost.

An organization can lose changes if more than one administrator is capable of making changes to group membership. For example, imagine an organization in which a group of administrators can modify group membership. Admin1 is terminated from the organization. Admin2, in an effort to protect organization resources, immediately removes Admin1 from the Administrators group and then clicks OK to complete the operation. At the same time, elsewhere on the network, Admin3 modifies the membership of the Administrators group to add a new member and completes that operation at a time later than the completion of Admin2’s changes, but before replication of domain changes. Replication of the group membership contains the newly added member, but it still contains Admin1 as a member. The result is that Admin1 is still a member of the Administrators group, with access to the organization’s resources.

Windows Server 2003 Replication of Separate Member Values

When a Windows Server 2003 forest has a forest functional level of Windows Server 2003 or Windows Server 2003 interim, replication of group membership occurs at the value level, not at the attribute level. The member attribute of a group object is multivalued. Instead of the entire attribute being replicated when group membership changes, only the value that changes is replicated. For a concurrent change to the same membership to occur, two administrators have to change the membership of the same user in the same group at precisely the same time. Although the likelihood of such a concurrent change is small, limiting the number of administrators who can change group membership is still a best practice for secure data administration.

Setting Object Ownership Quotas

On domain controllers that are running Windows Server 2003, you can set quotas that limit the number of objects that a security principal (user, group, computer, or service) can own in a domain, configuration, or application directory partition. By default, the security principal that creates an object is the object owner, although ownership can be transferred. Active Directory quotas eliminate the ability to create unlimited numbers of objects in a directory partition, which can be used for denial-of-service attacks.

By default, quotas are not set; therefore, there are no limits to the number of objects that any security principal can own. For each target directory partition, you can set different limits for different security principals, you can set limits that apply to all security principals, or you can do both.

You can set quotas per directory partition, except for the schema directory partition, which does not support quotas. You can set quotas to apply to security principals for a directory partition by using the command line. The commands that you can use to manage quotas are as follows:

• dsadd quota: Sets quotas for a directory partition.

• dsmod quota: Modifies existing quotas.

• dsmod partition: Modifies default quota settings for a partition.

• dsquery quota: Searches for quota assignments and quota consumption.

For more information about directory quotas and how to use the dsadd, dsmod, and dsquery commands to manage them, see “Directory data store” and the respective topics for each command in Help and Support Center for Windows Server 2003.

Establishing Other Secure Practices for Delegating Administration

When you manipulate permissions on objects in the directory, you should be mindful of certain considerations so that you can avoid problems with unpredictable or confusing access control behavior. The following sections describe these considerations.

Avoiding Use of the Dnprotect Tool

"Building Enterprise Active Directory Services — Notes from the Field" (Microsoft Press) suggests a utility (Dnprotect.exe) to use for securing objects in the directory. When this tool sets a bit on a directory object, the object can be changed only on a domain controller that is a member of the same domain as the object's owner. Normally, when a user attempts to access an object, the user’s access token is evaluated against the access control list (ACL) on the object to determine if the requested access is allowed. If the bit has been set by Dnprotect.exe, the operating system verifies that the user requesting access is a member of the same domain as the object's owner before evaluating the permissions on the object. If the user making the change is not a member of the same domain, access is denied.

Although this tool might provide some security for directory partitions that are widely replicated in the forest across multiple domains, it also introduces an element of confusion into the security model in your environment. It is possible to create a situation in which a user is listed in an object's ACL as having access, but access is denied when the user attempts to access the object.

Avoiding Use of Domain Local Groups for Controlling Read Access to Global Catalog Data

Do not use domain local groups to control Read permissions on object attributes that are replicated to the global catalog. Doing so can result in unpredictable access control behavior for searches, depending on which global catalog services the search request, as illustrated by the following example. Suppose that a local group called LocGrp1, which is defined in domain Dom1, is granted Read access to an object that replicates to the global catalog. A user who is a member of LocGrp1 initiates a search for that object. When a user initiates a search for an object in the global catalog, the domain controller locator requests and obtains the address of a global catalog server from DNS. The address of the global catalog server that is returned can be one of many global catalog servers in the forest, not necessarily a global catalog server in domain Dom1. If the user binds to a global catalog server in domain Dom1, Read access is granted to the user because the user’s authorization data (that is, the list of groups of which the user is a member) that is evaluated on that global catalog server includes the local group LocGrp1. However, if the user binds to a global catalog server in a different domain (Dom2), the user’s authorization data that is evaluated on that global catalog server does not include the group LocGrp1. In this case, the user is not granted access to the object. Because the user has no control over which global catalog server is selected, the results of the search are unpredictable.