Maintaining Your Data Management Delegation Model

  • Article

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

Over time, your data management administrative delegation model might need to be modified to address changing needs and requirements. The data management tasks required to maintain a changing data management delegation model are the same as those required to maintain a service management delegation model.

Tasks that are required to maintain the service delegation model can include:

  • Adding (delegating) or removing (undelegating) members to or from data administration role instances.

  • Adding new instances of roles in the event of changes in administrative needs.

  • Modifying a role by assigning or revoking a new or existing task from the role definition.

  • Creating new custom roles if the need arises.

  • Undelegating a role completely by revoking all permissions that are granted to the group that represents the role.

Modifying the Administrators Assigned to a Data Administration Role

To address personnel changes that affect the set of administrators who are assigned to a data administration role, you typically need to perform one of the following tasks:

  • Add new administrators to an existing role.

  • Remove one or more assigned administrators from a role.

  • To add one or more data administrators to a role, simply add the user accounts of these administrators to the security group that represents the role. To remove one or more assigned data administrators from a role, simply remove the user accounts of these data administrators from the related security group.

Adding New Instances of Existing Roles

Organizational or operational changes might necessitate the introduction of new role instances. For example, the introduction of a new business unit might require creating an entire set of data management role instances to provide administrative coverage. Similarly, the introduction of a new location might require new instances of the Workstation Admins or Resource Admins roles, or both, to facilitate administration of the IT resources at the new location.

To introduce a new role instance, understand the new administrative requirement and decide whether or not this requirement can be addressed by an existing role definition. If this requirement cannot be addressed by an existing role definition, create a custom role to meet this requirement (see Creating New Custom Data Administration Roles).

If the requirement can be addressed by an existing role definition, take the following steps:

  1. Document the requirements that call for the creation of a new role instance.

  2. Determine the scope of influence of the new instance, which affects how and where this role is granted the required permissions in Active Directory. If needed, create a new OU or move an existing OU to ensure that the target of administration is appropriately located in the OU structure.

    For example, if a new location is being added and the new location will have on-site workstations, you should add a new OU under the Workstations OU in the Business Unit’s OU structure. This new OU should contain all of the computer accounts for the workstations that will be physically located at this location. If you have one OU for every unique location, you will have to add a new OU for this location. If you are moving an entire OU from one business unit to another, you could simply move the OU to this new location under the Workstations OU.

  3. Create a new security group to represent the new role instance. Depending on your administration model, the Business Unit administrator might or might not have delegated the authority to sub-delegate administrative authority.

    • If this new requirement is being addressed by sub-delegated administrators, this new security group should be created by the sub-delegated administrators in the OU where they have stored existing security groups representing delegated roles.

    • If a new role instance is required, the Business Unit administrator can create a security group in the OU that is used by the Business Unit administrator to delegate other roles instances.

  4. After the security group has been created, appropriate permissions must be assigned to it so that the administrators in that role can perform the responsibilities of the role. Refer to the documentation that you created during your role definition process and assign this new security group all required permissions in the appropriate administrative scope. For more information about how to implement recommended roles, see Implementing Your Data Management Delegation Model.

  5. Add the user accounts that represent the administrators who will be assigned to this role to the corresponding security group.

  6. Document the new role instance by using the role instance template to specify the scope of influence, the security group that represents the role instances, the detailed set of permissions that are granted, and the administrators who are assigned to the role.

Modifying Administrative Tasks Associated With a Data Administration Role

If the set of administrative tasks that is associated with a role must be modified, you might need to add one or more new tasks to a role or remove one or more assigned tasks from the role.

For example, suppose that there are three existing instances of the Help Desk role, one for each business unit, and that this role is initially assigned the following two tasks:

  • Reset Passwords

  • Unlock User Accounts

Six months later, it is decided that responsibility for the administrative task of unlocking user accounts will be given solely to the Corporate Security role. Addressing this new requirement involves revoking this ability from all instances of the Help Desk role.

There are two ways to revoke these permissions:

  1. Modify the DACLs of the three OUs where the required permissions were granted and remove the permissions that allow the security group representing each role the ability to unlock user accounts.

  2. Remove and reassign the role, as follows:

    • Revoke all the permissions granted to the security group that represents the Help Desk role

    • Re-grant the set of permissions that are required to perform the new and updated set of administrative tasks.

Although in this example the approach of modifying the DACLs might appear easy to grasp and implement, it is complicated to use in the following cases:

  • The precise set of permissions required for every administrative task cannot be mapped to one specific permission.

  • Full Control has been granted.

  • A number of permissions were specified for a given role.

In such cases, it is preferable to remove and re-assign the role. The Dsrevoke command-line tool can be used to easily and reliably remove all permissions that are granted to a security principal. For more information about using this tool, see Undelegating a Data Administration Role.

To add a new task to a role for each role instance that needs to be modified, perform the following tasks:

  1. Identify the set of permissions that are required to perform the task.

  2. Identify the location (specific OU or OU tree) in the OU hierarchy where permissions have been granted to the security group that represents the role instances.

  3. Either revoke all permissions and then re-apply the updated set of permissions, or grant this security group the additional minimal set of permissions that are required to perform the new administrative task.

Depending on the requirement, you might need to update the set of administrative tasks that are assigned to a specific instance of the role or to all instances of the role.

Creating New Custom Data Administration Roles

Although the set of recommended roles should meet most of your data administration needs, unique requirements or special needs might call for the creation of new custom role definitions. Because the specific requirements can vary, the actual definition of a custom role is necessarily variable.

You can, however, use the following steps to aid in creating and implementing new custom roles:

  1. Analyze and obtain a good understanding of the requirements of the role.

  2. Create a new role to address these requirements.

  3. Define the scope of administrative authority for this role.

  4. Define the precise set of administrative tasks for which administrators in this role will be responsible.

  5. Identify the minimal and precise set of permissions that are required to delegate the set of administrative tasks.

  6. Create a naming convention for the security groups that represent instances of this role.

  7. Understand how the administrative scope of the role maps to the OU structure in your organization.

After the data owner creates this model, the Business Unit Admin or a data administrator who has been delegated the ability to sub-delegate should implement the required number of instances of the role.

Undelegating a Data Administration Role

If a business unit no longer has a need for a specific instance of some role, the Business Unit Admin needs to discontinue it. For example, an organizational change might result in the discontinuation of business at a physical location, either by moving assets and operations from that location to another location, or by completely stopping operations in that location. In this circumstance, you might no longer need the administrative roles that were initially implemented to manage workstations, resources, and perhaps users in that location.

To completely discontinue the role instance:

  1. Revoke all the permissions that are granted to the security group that represents the role.

  2. Empty the membership of this security group.

  3. Delete the security group.

In another case, your organization might decide to temporarily halt operations at a location for four months due to construction. During this time, none of the IT resources or users in that location will require administrative coverage, so you might want to disable these roles during that period. In this situation, you will want to only temporarily disable the role of the security group representing the role instance.

Revoking All Permissions for a Security Principal

For the first scenario, you can use the Dsrevoke command-line tool to revoke all permissions granted to the security group representing the role instance.

The Dsrevoke command-line tool provides the ability to remove ACEs that have been applied for a security principal on the domain object or on OU objects. By specifying the security group that represents the instantiated role and the OU or domain on which the security group that represents the role has been granted permissions, you can undelegate the role. However, Dsrevoke removes only permissions. If a role has user rights applied, you must manually remove these from the group.

For a specified user or security group, Dsrevoke removes ACEs on the specified root object and on all OU objects below that root in the hierarchy. If a domain root is specified, the tool searches the domain root and all OUs below that root. If an OU root is specified, the tool searches the OU tree, beginning at the specified root. Dsrevoke reports the explicit ACEs that exist for the specified security principal. When you remove the ACEs, for each explicit ACE that Dsrevoke removes, all inheritable ACEs that apply onto child OUs are also removed.

Dsrevoke works only on domain objects and OUs. If you delegate permissions on a container object or if you explicitly set permissions on an object within a container or OU, you must manually remove these ACEs. For this reason, as a best practice, it is recommended that permissions always be applied to OUs rather than to specific objects within OUs, and that permissions be applied to child OUs by using inheritance. For ease of management, always use security groups to apply permissions.

Using Dsrevoke

Dsrevoke.exe has the following syntax:

**dsrevoke/report|/remove[/domain:**domainname] **[/username:**username]

[**/password:**password|*] **[/root:**domain/OU] securityprincipal

Descriptions for each option are as follows:

  • /report: Reports the explicit ACEs that are currently set for the specified security principal on OU objects in the specified domain or an OU subtree. By default, the command dsrevoke /report starts at the domain root and searches every OU below that root for explicit ACEs that are granted to the specified security principal. If you are sure that the permissions for a security group are set only on or below a specific OU, you can specify the scope of the search by using the /OU switch to make the search more efficient.

  • /remove: Reports all explicit ACEs and then, after prompting for confirmation, removes the ACEs that are currently set for the security principal, including all inherited ACEs.

  • /domain: The DNS or NetBIOS name of the domain in which the permissions are to be removed. This value must be specified only when the ACEs that you want to remove are set on OUs in a domain other than the domain of the logged-on user.

  • /username: The user name of the user who is using the tool. This value is required when:

    • The user is not logged on as an administrator.

    • ACEs are being removed in a domain other than the domain of the logged-on user.

  • /password: The password of the tool user. If the command is entered with an asterisk (*) in place of a password, the tool prompts the user for a password.

  • /root: The OU or domain root at which to start the search for ACEs. If no value is specified, the search begins at the root of the specified domain. If no domain is specified, the search begins at the root of the domain of the logged-on user. When specifying a root domain or OU, you must use the distinguished name (for example, /root:OU=BusUnits=DC=DomainA,DC=com). If spaces occur in any part of the distinguished name, enclose the entire option in quotation marks (for example, “/root:OU=Product Development,OU=Delegation,OU=Business Units,DC=DomainA,DC=com”).

  • /securityprincipal: The identity of the user or group in the form DomainName\UserName or DomainName\GroupName. Use the DNS name or NetBIOS name of the domain.

For more information about using Dsrevoke.exe and to obtain the tool, see Appendix G: Active Directory Delegation Tools in Best Practices for Delegating Active Directory Administration: Appendices, which accompanies this document.