Implementing Your Data Management Delegation Model

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

After the data owners of each business unit have created their administrative delegation models, Business Unit Administrators should implement their respective delegation models. However, before Business Unit Administrators can delegate their models, service owners need to hand off data management to data owners and provision the Business Unit Admin roles.

Implementing the delegation model involves setting permissions on Active Directory objects. Active Directory ships with a set of delegation tools that can be used to apply and manage permissions in Active Directory. For a list of these administration tools and for details about how to use them, see Appendix G: Active Directory Delegation Tools in Best Practices for Delegating Active Directory Administration: Appendices, which accompanies this document. It is recommended that you invest the time to gain familiarity with these tools, as these tools are required to manage permissions. One alternative to using these tools is to use scripting to manage permissions.

Handing Off Data Management to Data Owners

Typically, organizations will choose to create and implement their service management delegation model, following which the data management model will be implemented. As a part of this process, the service owners should hand over responsibility for Active Directory data management to data owners by handing off data management to the respective business unit administrators, who represent the data owners. These high-level data administrators have overall responsibility for managing business unit content in Active Directory. They represent the data owners in implementing the respective business unit delegation models.

High-level service administrators represent the service owners in performing the tasks that are required to hand off data management to data owners. To hand off data management to business unit data owners, a member of the Domain Configuration Operators role or the Domain Admins group performs the following tasks in each domain:

1. Create a new OU as an immediate child of the domain object. A suggested name for this OU is Business Units. It serves as a high-level container for all domain content.

2. Within the Business Units OU, create one OU for each participating business unit, and name them appropriately following a standard convention.

3. Within the Business Units OU, create an additional OU for storing the security groups that will be used for representing the Business Unit Admins administrative role instances and instances of any other role that will require access to all business unit OUs. A suggested name for this OU is Delegation.

4. Within the Delegation OU, create one security group for every instance of the Business Unit Admins role; that is, create one domain local group for each business unit. Name each security group appropriately: a recommended name format is BusinessUnitName Admins.

5. On each of the security group objects that you create in step 4, grant the following permissions to the security group account itself:

   1. Property permission Read All Properties

   2. Property permission Write Members

6. On each business unit OU object, to the security group that represents the Business Unit Admins role for that business unit, grant Full Control.

7. Create one user account for each Business Unit Admins administrator in his or her respective business unit OU (these accounts will be moved to an appropriate OU within the respective Accounts OU by the business unit administrator after delegation of the business unit OU is implemented).

8. Add each user account to the respective security group that represents the Business Unit Admins role instance for the business unit.

Figure 8 shows a prototype domain-level OU structure that is created by a service administrator for handing off data administration to data owners in a domain that has two business units.

This completes the handoff process of transferring responsibility for data management to data owners, who are represented by respective Business Unit Admins, the operational arm of the data owners for the various business units sharing the domain.

Depending on the size of the organization, it might very well be that there is only one business unit in the entire domain. The handoff described in this section is beneficial in that situation too, as it creates an extensible OU structure which can easily accommodate the addition of new business units to the domain should the need arise.

Implementing Business Unit Delegation Models

Handing off the responsibility for data management results in the creation of one high-level OU for every business unit. It also involves enabling the Business Unit Admins roles and leaves Business Unit OUs ready to be managed by their Business Unit Admins. Business Unit Admins now have complete control over their Business Unit OUs and can proceed to implement their delegation models. This section provides recommendations for implementing an efficient and security-conscious delegation model.

The following are the recommended tasks involved in implementing the business unit delegation model:

1. Implement the OU hierarchy structure.

2. Create security groups to represent the various administrative role instances.

3. Enable Administrative Roles.

4. Delegate Administrative Roles.

Implementing the OU Structure

The first step in implementing the delegation model is to create the OU structure in the directory. This step is usually simple and straightforward: The Business Unit Admins create all OUs according to the documented OU structure for the business unit.

Creating Security Groups to Represent Role Instances

The next step in implementing the OU structure is to create security groups to represent all required administrative role instances as documented during the creation of the model. This step is also very straightforward and involves the following tasks:

1. For every required administrative role instance, the Business Unit Admins create one security group in the Delegation OU, a child of the Business Unit OU. These groups are typically Domain Local groups, as their scope of application is the Domain.

   Note

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

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

Enabling Administrative Roles

The next step in implementing the delegation model involves enabling all the required instances of the various administrative roles. Enabling a role involves granting the security group representing each role instance the minimal set of permissions required to allow members of this administrative group the ability to perform all administrative tasks assigned to this administrative role instance.

Enabling account management roles

Every business unit will typically have at least one instance of the Account Admins role that is granted overall responsibility for managing all aspects of all user accounts. Additionally, other role instances can be delegated account management responsibilities for specific sets of users.

To delegate an instance of the Account Admins role, perform the following tasks:

1. Refer to the documented role instance descriptions and identify the scope of administrative authority. Then map this scope to an OU subtree in the Accounts OU. Based on this information, determine the point of delegation for delegating this role instance. The point of delegation is the usually the object whose DACL will have to be modified to grant the set of permissions required to delegate this role instance. Note that in some cases, the point of delegation might actually map to more than one object depending the nature of the responsibilities being delegated and whether the objects representing the target of delegation are stored in more than one location in the OU hierarchy.

   For example, assume that the Account Admins role that has been granted has overall responsibility for all user accounts in the Business Unit. The point of delegation in this case will be the Accounts OU itself because the subtree of objects rooted at this OU contains the entire scope of authority for this role, which in this case refers to all the user accounts in the business unit.

   As a second example, assume that the Account Admins role that has been granted has account management responsibilities for all accounts in Division A. The scope of administrative authority is thus all accounts in Division A. Mapping this to the OU subtree in the Accounts OU reveals that there is an OU for Division A. This OU contains (or will contain) all user accounts for Division A. Thus, the point of delegation for this role is the Division A OU under the Accounts OU.

2. Based on the documented role instance descriptions, determine the minimal set of permissions required to delegate all assigned administrative tasks by referring to Appendix A: Active Directory Administrative Tasks in Best Practices for Delegating Active Directory Administration: Appendices, which accompanies this document. This appendix documents the minimal and precise set of permissions required to delegate every Active Directory administrative task.

   For example, assume that the business unit data owners decided to delegate only the following tasks to the Account Admins for the Division A:

   • Create user accounts

   • Modify all attributes that belong to the Personal Information property-set

   According to Appendix A: Active Directory Administrative Tasks, the following are the permissions required to perform these administrative tasks:

   • Create user accounts

   • Create Child on parent object

   • Modify all attributes that belong to the Personal Information property-set

   • Write-Property to the Personal-Information property-set

   Thus, in order to delegate this role, the security group representing the Division A Account Admins role will need to be granted the following permissions:

   • Create Child on parent object

   • Write-Property to the Personal-Information property-set

   Also, note the specifics of where these permissions are required. Since the Create Child permission is required on the parent object, which in this case happens to the be the Division A OU, there is no need to mark that permission as inheritable. On the other hand, since the Write-Property permission will actually be required on the user objects, this permission will need to be marked as inheritable.

3. Once you have determined the point of delegation and the minimal set of permissions required to delegate the various roles, modify the DACL on the object that corresponds to the point of delegation and grant the security group representing each administrative role the identified set of permissions.

Once these steps have been completed, all administrative roles for account management will have been delegated.

Enabling security group management roles

Your business unit should have only one instance of the Security Group Admins role that is responsible for security group management for the entire business unit.

To delegate an instance of the Security Group Admins role, perform the following tasks:

1. Refer to the documented role instance descriptions and identify the scope of administrative authority. Then map this scope to an OU subtree in the Security OU. Based on this information, determine the point of delegation for delegating this role instance.

2. Based on the documented role instance descriptions, determine the minimal set of permissions required to delegate all assigned administrative tasks by referring to Appendix A: Active Directory Administrative Tasks in Best Practices for Delegating Active Directory Administration: Appendices, which accompanies this document. This appendix documents the minimal and precise set of permissions required to delegate every Active Directory administrative task.

3. Once you have determined the point of delegation and the minimal set of permissions required to delegate the various roles, modify the DACL on the object that corresponds to the point of delegation and grant the security group representing each administrative role the identified set of permissions.

   In the case of the single administrative role that has been assigned overall responsibility for security group management, this point of delegation will correspond to the Security Groups OU. Since this group will typically be assigned responsibility to manage all aspects of security group management, although individual permissions for every administrative task can be granted, this security group could be granted Full Control on all objects of the class Group.

   In some cases, the business unit might decide to delegate security group management to more than one group. In this case, for each role instance, determine the point of delegation and the cumulative set of permissions required to delegate these roles. Then grant the security groups representing these roles the identified set of permissions by modifying DACL on the object that corresponds to the point of delegation.

Once these steps have been completed, all administrative roles for account management will have been delegated.

Enabling resource management roles

Your organization will have typically multiple instances of each resource management role.

The implementation aspects of delegating resource management are a little different than those for account or security group management. This is primarily because delegating resource management usually involves using the delegation capabilities of Active Directory to make delegated administrators local administrators on member computers, in addition to granting these administrators the full-control over the computer account representing the computer. In cases where these administrative groups only require the ability to manage the service aspects of a service that they are responsible for, these administrative groups need not be made local administrators on these computers; it is sufficient to make them members of local groups that are authorized to manage these services.

Making administrative groups in Active Directory members of local administrative groups involves the application of a specific feature of Group Policy – restricted groups. The Restricted Groups feature allows an administrator to control membership by creating a list that restricts the members of a group and the groups to which a group can belong. The policy restricts membership by enforcing the list: any members who are not on the list are removed from the group; any security principals in the list that are not members of the group are added to the group.

For more information about restricted groups, see “Restricted Groups” in Help and Support Center for Windows Server 2003. For more information about restricted groups, see article 810076, "Updates to Restricted Groups ("Member of") Behavior of User-Defined Local Groups" in the Microsoft Knowledge base.

The following example illustrates the application of this feature to delegation of the workstation management role.

The Production business unit of Contoso Pharmaceuticals has operations in two physical locations – Chicago and Atlanta. 60 percent of the users of this business unit are based in Chicago and 40 percent in Atlanta. Every user is typically assigned one end-user workstation.

Contoso’s OU hierarchy thus has two OUs within the Workstations OU, one representing Chicago and the other Atlanta. Computer accounts for all workstations located in Chicago are stored in the Chicago OU. Accordingly, computer accounts for all workstations located in Atlanta are stored in the Atlanta OU. Contoso’s data owners have assigned the responsibility of managing all workstations in the Chicago location to a locally based administrative group called Chicago Workstation Admins. Members of this administrative group require the ability to manage all aspects of computer management for these workstations. They might be called upon to perform a variety of administrative tasks including, but not limited to, troubleshooting operating system issues, adding hardware, configuring drivers, and installing patches. Most of these tasks require administrative access to these workstations.

Contoso’s administrators easily facilitated making this administrative group local administrators on all workstations by performing the following steps:

1. Creating a security group called Chicago Workstation Admins to represent this role.

2. Granting this security group inheritable full-control on all computer objects by modifying the DACL of the Chicago OU within the Workstations OU.

3. Using the restricted groups feature of Group Policy to make this group a member of the Local Administrators group on all workstations in Chicago by applying Group Policy on the Chicago OU and specifying that the Chicago Workstation Admins be made a member of the Local Administrators group on all workstations whose computer accounts are present in the Chicago OU.

Enabling resource management administrative roles essentially involves repeating the steps involved in this example for all administrative roles. The following recommendations can be used to enable resource management roles.

Perform the following steps to enable the various instances of the Workstation Admins role:

1. Refer to the documented role description for this instance and identify the scope of administrative authority. Map this scope to an OU subtree in the Workstations OU. Based on this information, determine the point of delegation for delegating this role instance.

2. Grant the security group representing this role instance the following inheritable permission on the point of delegation:

   • Full-Control on Computer objects

3. Use the Restricted Groups feature of Group Policy by applying a GPO to the OU that represents the point of delegation,to make this make the security group representing the specific role instance a member of the local Administrators group on all member workstations that are stored in the OU.

Once these steps have been completed, all administrative roles for workstation management will have been delegated.

For each instance of the Server Operators role, perform the following steps to enable the instance:

1. Refer to the documented role description for this instance and identify the scope of administrative authority. Then map this scope to an OU subtree in the Resources OU. Based on this information, determine the point of delegation for delegating this role instance. Refer to your OU model to determine the specific OU created with the purpose of storing non resource specific servers. You might have more than OU if you created a high-level OU under the Resources OU to store non resource specific servers and possibly created an additional level of OUs within this OU, one for each physical location that has servers located and depends on local administrative groups for management of these servers.

2. Grant the security group representing this role instance the following inheritable permissions on the point of delegation:

   • Full-Control on Computer objects

3. Use the Restricted Groups feature of Group Policy by applying a GPO to the OU that represents the point of delegation, to make this make the security group representing the specific role instance a member of the local Administrators group on all member workstations that are stored in the OU.

Once these steps have been completed for all instances of the Server Operators role, all administrative roles for server management will have been delegated.

For each instance of the Resource Admins role, perform the following steps to enable the instance:

1. Refer to the documented role description for this instance and identify the scope of administrative authority. Map this scope to an OU subtree in the Resources OU. Based on this information, determine the point of delegation for delegating this role instance. Refer to your OU model to determine the specific OU created with the purpose of storing the set of servers that hosts this specific resource. In an OU hierarchy that was based on the recommendations in this document, the specific OU for this resource should be under the corresponding resource-specific OU.

   For example, when delegating resource management for the Human Resources Web portal that is hosted on a set of high-performance Web servers, there should be one OU under the Web-Servers OU (which is under the Resources OU) for the Human Resources Web portal. This OU should contain the set of servers that collectively hosts this Web portal. This OU is the point of delegation for delegating this role.

2. Grant the security group representing this role instance the following inheritable permission on the point of delegation:

   • Full-Control on Computer objects

3. If the administrative requirements for this role instance require that administrators in this role be able to manage all aspects of server management on the servers hosting this resources, use the Restricted Groups feature of Group Policy (by applying a GPO to the OU that represents the point of delegation) to make the security group representing the specific role instance a member of the local Administrators group on all member servers that are stored in the OU.

4. Use the Restricted Groups feature of Group Policy by applying a GPO to the OU that represents the point of delegation. The GPO should make the security group representing the specific role instance a member of the local group on all member servers stored in the OU that is sufficiently authorized to manage all service aspects of the service that administrators in this group will be responsible for managing.

Once these steps have been completed for all instances of the Resource Admins role, all administrative roles for resource management will have been delegated.

Authorizing access to resources

Administrators who are responsible for managing specific resources might also require the ability to authorize access to their resources. For this purpose, Resource Admins can request security groups for each resource.

For example, the Portal A Admin requires the ability to specify who can access the portal. To authorize access to resources, the Resource Admin can perform the following tasks:

1. Contact the Security Group Admin and request creation of account and resource groups as follows:

   • A resource group for access to the service

   • Account groups to specify collections of users who can access this service; these groups are added to the resource group

2. Request that the Security Admins group grant to the Resource Admins group the ability to modify the membership of these groups. On each security group object, grant the following permissions to the security group account itself:

   • Property permission Read All Properties

   • Property permission Write Members

The Security Group Admins can evaluate the request and if approved, create the specific security groups in an appropriate location, thereby enabling Resource Admins to authorize access to their resources.

Enabling help-desk roles

Every business unit will typically also have at least one instance of the Help Desk Operators role. Administrators in this role are responsible for providing account support for user accounts, and typical helpdesk operations include resetting user passwords and unlocking user accounts. Since most of the administrative tasks assigned to this role involve providing account support, most of these administrative tasks involve low-level operations on user account objects.

To delegate an instance of the Help Desk Operators role, perform the following tasks:

1. Refer to the documented role instance descriptions and identify the scope of administrative authority. Map this scope to an OU subtree in the Accounts OU. Based on this information, determine the point of delegation for delegating this role instance. For most business units, the scope of delegation will typically map to the Accounts OU, since in most organizations a single administrative group is responsible for providing account support.

2. Based on the documented role instance description, determine the minimal set of permissions required to delegate all assigned administrative tasks by referring to Appendix A: Active Directory Administrative Tasks in Best Practices for Delegating Active Directory Administration: Appendices, which accompanies this document. This appendix documents the minimal and precise set of permissions required to delegate every Active Directory administrative task.

   As mentioned earlier in this section, typical account support tasks include the following:

   • Resetting user passwords

   • Unlocking locked out accounts

   According to Appendix A: Active Directory Administrative Tasks, the following are the permissions required to perform these administrative tasks:

   • Resetting user passwords

   • Reset User Password Extended right on the user account

   • Unlocking locked out accounts

   • Write-Property permission to the user object

   Thus, in order to delegate this role, the security group representing the Help Desk Operators role for this business unit will need to be granted the following permissions:

   • Reset User Password Extended right on the user account

   • Write-Property to the user object

   Also, note the specifics of where these permissions are required. Since all user accounts are stored in the Accounts OU, the application of inheritable permissions on the Accounts OU should be sufficient to delegate the two administrative tasks that this group is responsible for.

3. Once you have determined the point of delegation and the minimal set of permissions required to delegate this role, modify the DACL on the object that corresponds to the point of delegation and grant the security group representing this administrative role the identified set of permissions.

Once the earlier steps have been completed, the Help Desk Operators administrative role will have been delegated.

Note that in some organizations, a single administrative group might be responsible for providing account support for all Business Units. In this case, the following recommended approach should be used:

1. Domain Administrators should create a security group within the Delegation OU that was used to store the security groups representing the Business Unit Admin role instances.

2. Business Unit Admins of all business units should delegate the Help Desk Operators role as described earlier in this section.

3. Business Unit Admins of all business units should then add the security group created by the Domain Administrators to the security group representing the specific instances of the Help Desk Operators role created in their business units.

Enabling application-specific data management roles

It is not uncommon for organizations to have Active Directory–enabled or Active Directory–integrated applications deployed. These applications typically store application specific data in Active Directory. These applications also have administrators that might need to manage this data. Business Unit Admins can create instances of the Application Specific Data Admins roles for the purpose of delegating all administrative tasks that these administrators might need to perform to manage their application data.

Active Directory–enabled or –integrated applications might store application specific data in different places in Active Directory. For example, certain applications might extend the class definition of user objects and store their application specific user information on user objects, while other applications might create their own OUs and store application specific data in these application specific OUs.

Thus, before delegating instances of the Application Specific Data Admins roles, it is important to identify precisely where the application data is being stored. This information will be required to determine the point of delegation and the manner in which application is delegated. For example, if the application stores data in a separate OU that it creates and this OU happens to be outside of any Business Unit OU (for example, if it is a child of the Domain object), then the Domain Admins will be responsible for delegating these roles and the scope of delegation will typically be the specific OU. On the other hand, if this application stores application specific data on user attributes (for example, the application could extend the schema and store user specific information on user objects), then this falls within the scope of administrative authority of the Business Unit Admin and the scope of delegation then becomes the Accounts OU.

To delegate an instance of the Application Specific Data Admins role, perform the following tasks:

1. Refer to the documented role instance descriptions and identify the scope of administrative authority. Map this scope to an OU subtree if it maps to an OU within the business unit. If it maps to an OU outside of the Business Unit, transfer responsibility for delegating this role to Domain Admins. Based on this information, determine the point of delegation for delegating this role instance.

   Based on the documented role instance description, determine the minimal set of permissions required to delegate all assigned administrative tasks by consulting the application’s administrators.

2. Once you have determined the point of delegation and the minimal set of permissions required to delegate this role, modify the DACL on the object that corresponds to the point of delegation and grant the security group representing this administrative role the identified set of permissions.

Once these steps have been completed, the Application Specific Data Admins administrative role will have been delegated.

Delegating self-service on user accounts

User accounts store information about users in the form of properties, or attributes, of the user object. For example, some of these properties include such information as the user’s home phone number, mailing address, manager, cell phone number, and so on. Active Directory defines certain property sets that are collections of such properties. Specifically, a user object has the following property sets:

• Personal-Information

• Email-Information

• Web-Information

• RAS-Information

• User-Account-Restrictions

• Membership

• General Information

• User Logon

• Domain Password

For more information about the membership of these property sets, refer to Appendix E: Active Directory Property Sets in Best Practices for Delegating Active Directory Administration: Appendices, which accompanies this document.

The default security descriptor for user objects, as defined in the Active Directory schema, grants users the ability to modify the following property sets:

• Personal-Information

• Email-Information

• Web-Information

User in your business unit might require the ability to modify other properties on user objects in addition to the properties that are covered by these three property sets. In this case, additional administrative steps are required to grant users the required permissions. To grant additional access to users, perform the following tasks:

1. Identify the specific properties that users are to be able to modify.

2. To all users, grant Write-Property permissions (inheritable) to SELF.

For the exact set of permissions that are required to modify a specific property or a collection of properties, see Appendix A: Active Directory Administrative Tasks in Best Practices for Delegating Active Directory Administration: Appendices, which accompanies this document.

Delegating Administrative Roles

The next step in implementing the delegation model involves delegating all the required instances of the various administrative roles. Delegating a role simply involves modifying the group memberships of the security groups of all administrative roles that have been enabled. The act of making an administrator a member of a security group that represents an administrative role results in the role having been delegated to an administrator.

To delegate the various administrative roles that have been enabled, do the following for each role instance:

• Modify the group membership of the security group representing this instance of the administrative role by adding to the membership the user account of every administrator that has been assigned to this role. Refer to the documented description for the role instance to obtain the list of all administrators that have been assigned to this role.

The delegation model for your business unit is now completely implemented and ready to use. All administrators should now be able to perform all administrative tasks assigned to them.

Best Practices for Implementing Delegation

The following list summarizes the set of recommended best practices for implementing delegation:

• Use security groups that represent roles for the sole purpose of delegating the roles. Do not use these security groups for other purposes. For example, do not use the security group to authorize access to other resources in the domain that are not associated with the ability to perform the administrative role.

• When delegating data management, as far as possible, delegate permissions only on OUs, which are provided specifically to facilitate delegation of administration. Delegating permissions on OUs enables them to be easily and reliably revoked.

• Unless absolutely required, do not specify permissions on individual objects within an OU.

• To delegate a role, grant permissions sufficient only to perform the set of administrative tasks assigned to an administrative role.

Using Inheritance

You can use inheritance of permissions to more easily implement delegation. The use of inheritance of permissions allows administrators to easily apply permissions on a collection of objects without having to explicitly modify the DACL of every object. This capability allows administrators to easily manage and control permissions on large sets of objects by applying and managing permissions on a relatively small set of objects, from which other objects inherit permissions.

When using inheritance to specify permissions, administrators can control the various ways in which an inheritable permission is propagated. The following guidelines can help you use inheritance effectively:

• When specifying inheritable permissions on an object, if these permissions need to apply only to a specific object class, specify the object class instead of letting the permission apply onto all child objects. This will ensure that these permissions, when inherited, are effective only on objects of the specific class on which they are intended to be effective.

• When specifying inheritable permissions on an object, if the permissions being specified are meant for child objects only, specify that these permissions apply to child objects only. This will ensure that the applied permissions are not effective on the object on which these permissions are being specified.

• When specifying inheritable permissions on an object, if these permissions need to be applicable only on immediate child objects, and do not need to be inherited further down, specify that these permissions should be inherited only one level below.

• When using inheritance, it is useful to take into consideration the precedence order of ACEs:

  • Any inheritable DENY permissions applied on the parent object will precede any inheritable DENY permissions applied on the grandparent object. Thus, when using DENY permissions, apply inheritable ACEs as close to the target objects as possible and ensure that all target objects of the permission are contained in the subtree rooted at the OU on which the permissions are being applied. In general, as far as possible, avoid the use of DENY permissions.

  • Remember that an inheritable permission cannot override an explicit ACE on an object. Thus, before using inheritance, it is recommended that you check to see that there are no explicit ACEs on target objects that will override the inheritable ACE.

    Note

    Any user who has the ability to modify the DACL of any OU in the OU hierarchy can use inheritance to grant him or herself or any other user any permission on any object in the subtree rooted at that OU. Therefore, carefully grant permissions to modify the DACL of an OU object.

Taking Ownership of Objects

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

This aspect of object ownership affects how Active Directory data can be managed. Consider the scenario in which administrative authority has been delegated to a group of administrators by implementing an administrative role. As part of carrying out delegated responsibilities, one of the members of the administrative role creates an object. As the creator of the object, this specific administrator also becomes the owner of the object. At a later date, this administrator might no longer be a member of this administrative role. If this administrator is no longer a member of this administrative role, he or she should ordinarily no longer be able to manage this object. Since this administrator is no longer a member of the administrative group representing the administrative role that he or she was a member of, and since inheritable permissions were used to delegate control of these objects to members of this administrative role, it seems reasonable to conclude that this administrator will no longer have access to this object. However, the administrator will still have access to this object by virtue of the fact that as the creator of the object, he or she still owns the object. This can obviously complicate delegation of administrative authority.

While this issue can be addressed by putting in place business policies to add certain checks when an administrator is removed from an administrative role, such administrative checks will not be fool-proof. A business unit can enforce policy that requires that when an administrator is removed from an administrative role, a check is made to see what objects the administrator owns and that ownership of all objects be appropriately transferred. However, this check is not fool-proof because the administrator might have used his authority as owner to grant himself or herself (or another user) sufficient permissions to modify the DACL of this object, or permissions to perform other operations.

The following precaution is recommended to adequately address this issue with respect to managing user and group objects: Create a script that runs in the security context of a Domain Admin account on a periodic basis (like daily or weekly). This script should perform the following actions:

• Walk through a specifiable subtree of objects, rooted at some OU, and for every object do the following:

  • Check the owner field of the object; if the owner field is not set to Domain Admins, change the owner field to Domain Admins.

  • Additionally, check the DACL of the object to ensure that the only explicit ACEs in the DACL are the ones that are found in the default security descriptor for that object class in the Schema. This check ensures that creator of the object did not modify the DACL explicitly to grant anyone (including himself or herself) any additional permissions. If any explicit ACEs are found that do not exist in the default security descriptor for that object class, report their existence and remove these ACEs.

    Note

    This check will limit an organization’s ability to apply explicit ACEs on objects. This limitation can be overcome by having the script report the existence of such ACEs and prompt for manual deletion. This approach, while continuing to allow the use of explicit ACEs, will require manual intervention and might require significant manual intervention if many explicit ACEs are used. However, if explicit ACEs have been used sparingly and minimally, this approach can be very useful.

The reason this approach will work only for user and group objects is that the default security descriptors of these object classes do not contain any ACEs for the Creator Owner Trustee. The general problem with Creator Owner ACEs on other object classes, however, is that some default security descriptors can contain ACEs for the Creator Owner Trustee, because during object creation, the user field in any ACE for this trustee is replaced with the SID of the user creating the object. Thus, when checking to see that only ACEs that were in the default security descriptor are present, any ACE that was mapped to the SID of the creator will show up as an explicit ACE that was not in the default security descriptor and, if removed, could impact functionality.