Appendix G: Active Directory Delegation Tools

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

Active Directory ships with all the tools required to delegate administrative tasks. This appendix provides details about the functionality of these tools.

The tools that can be used to delegate administrative authority are:

• Delegation of Control Wizard

• ACL Editor

• Ldp.exe

• Dsacls.exe

• Acldiag.exe

• Dsrevoke.exe

Note

The screens in this appendix are from Windows 2000, and might differ slightly from the screens in Windows Server 2003. The functionality of the tools, however, is essentially identical.

Delegation of Control Wizard

The Delegation of Control Wizard allows you to delegate administrative tasks to users (or groups) within a specific administrative scope and is primarily used to delegate data administration. This tool is driven by a customizable text file and ships with a base set of common administrative tasks. You can use the information provided earlier in this document in Appendix A: Active Directory Administrative Tasks, to customize this wizard and to increase the number of tasks that can be delegated by using the wizard.

Using the Delegation of Control Wizard

The Delegation of Control Wizard can be accessed through Microsoft Management Console (MMC) snap-ins. MMC is an extensible user interface that provides an environment for running management applications (called snap-ins) that are structured as components. Windows 2000 Server and Windows Server 2003 include a base set of MMC snap-ins for managing Active Directory data.

The following MMC snap-ins can be used to view and manage Active Directory objects for which you can delegate control:

• Active Directory Users and Computers. This snap-in is the main GUI-based delegation tool for delegating data management. It provides a hierarchical view of domain data. In Active Directory Users and Computers, the Delegation of Control Wizard can be accessed by right-clicking and choosing Delegate Control on containers, OUs, and the domain root.

• Active Directory Sites and Services. This snap-in provides access to information related to replication, and is used to perform replication management tasks. In Active Directory Sites and Services, the Delegation of Control Wizard can be accessed by right-clicking a container and choosing Delegate C.

To delegate administrative authority by using the Delegation Wizard, use the following procedure.

To delegate administrative authority by using the Delegation Wizard

1. Right-click a container or OU and select Delegate Control. The Delegation of Control Wizard Welcome page is displayed.

2. Click Next. The Users or Groupspage is displayed.

3. On the Users or Groups page, click Add. The Select Users, Computers, or Groups page is displayed.

4. On the Select Users, Computers, or Groups page, in the Enter the object names to selectbox, type the name of the user or security group to which you want to delegate tasks. You can add multiple users or security groups. When you are finished entering users or groups, click OK.

5. On the Users or Groups page, click Next. The Tasks to Delegate page is displayed:

   

6. On the Tasks to Delegate page, select the check boxes of the tasks that you want to delegate. You can also create a custom task to delegate, as described later in this appendix.

7. Once you have selected the tasks that you want to delegate, click Next. The Delegation of Control Wizard displays a summary of the tasks you just delegated.

8. Click Finish to complete the delegation.

When the Delegation of Control Wizard completes, the administrative authority you specified is delegated. You can modify the tasks available for delegation (presented on the Tasks to Delegate page of the Wizard) by editing Delegwiz.inf, a file stored on the domain controller. For more information about modifying Delegwiz.inf, see article 308404, “HOW TO: Customize the Task List in the Delegation Wizard,” in the Microsoft Knowledge Base on the Web at https://go.microsoft.com/fwlink/?LinkId=3202.

You can use the lists in Appendix A: Active Directory Administrative Tasks to obtain the precise set of permissions required to delegate a specific data administration task and customize the Delegwiz.inffile. You can then use the Delegation of Control Wizard to delegate a larger number of tasks. Note that each domain controller stores its own local copy of the file, so you need to copy the modified file to each domain controller where you want to use the Delegation of Control Wizard.

The Delegation of Control Wizard also allows you to delegate a custom task. To delegate a custom task, complete the following steps.

To create a custom task

1. On the Tasks to Delegate page of the Delegation of Control Wizard, select Create a custom task to delegate, and then click Next.

   

2. On the Active Directory Object Type page, if you want to delegate control over a specific class of object, select Only the following objects in the folder and then select the check boxes for the classes of objects for which you want to delegate control.Otherwise, select This folder, existing objects in this folder, and creation of new objects in this folderto delegate control over the folder and all objects in it, and to delegate the ability to create new objects in the folder. When you have finished making selections, click Next.

   

3. Click Next. On the Permissions page, under Show these permissions, select one of the check boxes to display the permissions to delegate:

   1. To delegate general permissions, select General and then select the check boxes for the permissions you want to delegate.

      

   2. To delegate access to one or more properties, click Property Specific and then select the check boxes for the permissions you want to delegate.

      

   3. To delegate the ability to create and/or delete objects, click Creation/deletion of specific child objects and then select the check boxes for the permissions you want to delegate.

      

4. Click Next. The Delegation of Control Wizard presents a summary of the tasks you selected to delegate.

5. Click Finish. Once the Delegation Wizard completes, the custom task you specified is delegated

ACL Editor

The ACL Editor allows you to view and modify the security descriptors of objects in Active Directory. You can inspect and change security permissions, security auditing, and object ownership information. Although the ACL Editor is primarily for managing access-control permissions, it can also be used to delegate administrative authority, because that involves granting the delegated user sufficient permissions to carry out the low-level operations that map to the delegated administrative task. More significantly, the ACL Editor is currently the only tool that can be used to un-delegate tasks or revoke delegated authority.

Using the ACL Editor

You can access theACL Editor from any of the MMC snap-ins listed earlier in this appendix, and from ADSI Edit (Adsiedit.mcs), a graphical Windows Support Tool that is available in the Support\Tools folder on the Windows CD. When Windows Support Tools are installed, you can add ADSI Edit to an MMC snap-in. ADSI Edit provides the ability to edit the attribute values of any object in any directory partition in the forest, and to examine RootDSE attributes.

To use the ACL Editor, start any of these tools:

• Active Directory Users and Computers

• Active Directory Sites and Services

• Adsiedit.mcs

To delegate permissions by using the ACL Editor

1. Right click the object on which you want to set permissions and select Properties. The Accounts Properties dialog box is displayed.

   

2. To view and change advanced security information and grant or revoke permissions, in the Accounts Properties dialog box, on the Securities tab, click Advanced to open the Access Control Settings for Accountsdialog box.

   

   In theAccess Control Settings for Accountsdialog box, you can view the permission entries in the DACL of the object, specify the operations that should be audited, and access and modify ownership information.

   By clearing the check box for Allow inheritable permissions from parent to propagate to this object, you can protect the DACL of the object from inheriting permissions from the parent object. When the DACL of an object is protected, the object no longer inherits any permissions from the parent object, and any permissions marked as inheritable on the parent object do not flow down to child objects of the protected object.

3. Click Add. The Select User, Computer, Or Group dialog box is displayed.

4. In the Select User, Computer, or Group dialog box, in the Name box, type the name of the user or security group for which to specify permissions ( delegate or undelegate administrative), and then click OK. The Permission Entry for Accounts dialog box is displayed.

   

   On the Object tab, you can allow or deny a user or group generic permissions and all extended rights. In the Apply-onto box, you can specify the objects affected by the permissions being applied.

   The Apply these permissions to objects and/or containers within this container onlyoption controls whether the permissions being applied should be propagated only down to (be inherited by) immediate child objects of this container, and not be inherited further down the hierarchy.

5. To allow or deny access to specific properties, click the Properties tab.

   

   The Properties tab displays all properties of objects of the class specified in the Apply onto box. To grant read or write access to a specific property, select the Allow check box for the read or write entry of that property.

   Note that the Permissions list box on the Properties tab might not display every property of the object. To make the list easier to manage, the user interface for access control does not display object and property types.

   The list of properties is filtered based on specific settings in a local text file. For more information about filtering of properties, see article 296490 “How to Modify the Filtered Properties of an Object” in the Microsoft Knowledge Base on the Web at https://go.microsoft.com/fwlink/?LinkId=3202.

   Also note that every property in Active Directory has three different names:

   • Common-Name. Every object in Active Directory has a naming attribute from which its relative distinguished name (also known as RDN) is formed. The Naming Attribute for Attribute-Schema objects is Common-Name. The value assigned to Common-Name is the value that the Attribute-Schema has as its Relative Distinguished Name.

   • LDAP-Display-Name. The name of this attribute is known to the LDAP agent for the Active Directory directory service. This is the name LDAP clients must use to read or write this attribute.

   • Admin-Display-Name. The Common-Name of a given object might not be descriptive enough for use in administration tools. Admin-Display-Name is available for tools to use as a display name for an attribute when the naming attribute is not appropriate.

   Active Directory MMC snap-in tools refer to classes and attributes by the Admin-Display-Nameif one is defined for that class or attribute. For those classes or attributes that do not have a defined Admin-Display-Name, these tools instead use the LDAP-Display Name.

   Consequently, if you cannot find a specific attribute in this tab, perform the following checks:

   • Check to see that the value in the Apply ontobox covers the class of objects on which this property exists. For example, if you want to grant Read access to the Organization-Nameproperty on User objects, check to make sure that the Apply onto box is set to User objects, This object and all child objects, or Child objects only.

     Additionally, if the object you are specifying permissions on is of class User, the Apply onto box can also be set to This object only.

     The point is that if the Apply onto box is set to an object class that does not include Organization-Nameas a property on the object, the property does not display.

   • If, after ensuring that the Apply onto box is set to an appropriate value, you still cannot see the property, check to see whether the property has an Admin-Display Name defined.

     For example, you cannot view Organization-Namein the list even if the Apply onto box is set to User objects. In this case, refer to Appendix H: “Active Directory Display Name Mappings”, later in this document. This appendix provides the corresponding Admin-Display-Name(if one exists)for every class and attribute in the Active Directory Schema. If the attribute has an Admin-Display-Namedefined, search for it instead. In this case, Appendix H shows that Organization-Namedoes not have an Admin-Display-Name defined. Consequently, you need to look for the LDAP-Display-Name, which is “o” for this attribute.

   • If you still cannot find the attribute, it might be filtered. In the case of Organization-Name, you will not be able to find “o” in the list because it is filtered. Turn off filtering for that specific attribute by modifying the Dsec.dat attribute as described earlier in this appendix.

     Note that the Dsec.dat file also uses the Admin-Display-Name if one exists, otherwise it uses the LDAP-Display-Name. This will help you look for the correct name in the file if you need to turn-off filtering.

     Alternatively, to avoid this filtering altogether, you can rename the Dssec.dat file so that it is no longer used by the administrative tools user interfaces. Doing so results in less complexity, because you no longer have to deal with filtered attributes. This makes the user interface somewhat more cumbersome to use because all potential attributes are displayed. However, because they are displayed in alphabetical order by default, this is usually not a problem.

   Once you turn-off filtering for an attribute, you should finally be able to view the attribute. In the example, you will finally be able to see “o” in the list. You can then allow or deny access to the attribute.

   Also be aware of the effect that making different selections in the Apply onto box has on the inheritance of permissions.

   

   The Apply onto box specifies the class of objects on which the selected permissions will be applied. For example, if you want to grant a delegated user the ability to modify the User-Account-Controlattribute but only on User objects but not on Computer objects, choose User objects from the list in the Apply onto box.

   The following table describes how different Apply onto settings affect the setting of inheritance flags for the specified permissions in the ACE of the selected object:

   Apply-Onto Value	Effect on inheritance of permissions
   This object only	No inheritance flags set. The resulting ACE will not be an inheritable ACE.
   This object and all child objects	Sets the Container Inheritflags and leaves the Inherited-Object-Typefield empty. The resulting ACE will be inheritable by all child objects and will be effective (enforced) on this object and all child objects.
   Child objects only	Sets the Container Inheritand Inherit Onlyflags and leaves the Inherited-Object-Typefield empty. The resulting ACE will be inheritable by all child objects but will be effective on child objects only; it will not be effective on the object on which it is being applied.
   <Specific object class> objects	Sets the Container Inheritand Inherit Onlyflags and sets the value of the Inherited-Object-Typefield to the GUID representing objects of class <Specific object class>. The resulting ACE will be inheritable by all child objects, but will only be effective on objects of class <Specific object class>. It will not be effective on this object or on child objects of other classes.

   Thus, to set an Inherit-Only ACE, in the Apply onto box, choose Childobjects only or <Specific object class> objects, as appropriate.

   Notethat the selection you make here also applies to the permissions being set on the Object tab of the Permission Entry for Accounts dialog box.

6. When you have finished making selections on the Object and Property tabs, click OK. Then, in the Access Control Settingsdialog box, click OK again to apply the settings you selected.

   Administrative authority is now delegated or revoked by having granted or revoked permissions for the selected user or group to perform one or more administrative tasks.

LDP

LDP (Ldp.exe) is a graphical tool that allows you to perform Lightweight Directory Access Protocol (LDAP) operations, such as connect, bind, search, modify, add, or delete, against any LDAP-compatible directory, including Active Directory. Many objects stored in Active Directory are not readily displayed using the graphical tools that are installed with Windows. Administrators can install the Ldp.exe tool to view these objects and their metadata, such as security descriptors and replication metadata, to aid in problem determination.

Using LDP

Ldp.exe is a support tool that is installed from the Windows CD. For information about how to install Windows support tools, see article 301423, “HOW TO: Install the Windows 2000 Support Tools to a Windows 2000 Server-Based Computer,” in the Microsoft Knowledge Base on the Web at https://go.microsoft.com/fwlink/?LinkId=3202. For delegation of administration, you can use LDP to view the security descriptors of Active Directory objects by performing the following tasks. To view the security descriptor of an object, use the following procedure.

To view the security descriptor of an object by using Ldp.exe

1. In LDP, on the Connection menu, click Connect to connect to a domain or a specific domain controller.

2. In theConnect dialog box, in theServer box, type a server name or leave the entry blank to connect to the local server, and then clickOK.

3. On the Connection menu, click Bind.

4. In the Bind dialog box, type a user name and password, and then click OK to bind to Active Directory.

5. On the View menu, click Tree. In the BaseDN box, either type a specific distinguished name (DN) or leave BaseDN blank to view the entire domain.

6. To display the object for which you want to view the security descriptor, double-click the domain object in the tree view and then double-click the appropriate container.

7. To view the security descriptor of an object, right click the object in the tree view, select Advanced,select Security Descriptor, and then in the Security Descriptor dialog box, click OK.

   The security descriptor of the object is displayed in the details pane. Note that you can scroll to view the Security Descriptor Definition Language (SDDL) version of the security descriptor and to view the security descriptor in text format.

   To analyze the security descriptor in detail, you can either view the information in the details pane, or, if you prefer, right click in the details pane, choose Select All, choose Copy, and then paste the contents into a text file.

Dsacls

Dsacls (Dscals.exe) is a powerful command-line utility that can be used to report and modify permissions on Active Directory objects. Dsacls is included in the Windows support tools that you can install from the Windows CD. For information about how to install Windows support tools, see article 301423, “HOW TO: Install the Windows 2000 Support Tools to a Windows 2000 Server-Based Computer,” in the Microsoft Knowledge Base on the Web at https://go.microsoft.com/fwlink/?LinkId=3202. For details about how Dsacls works, run Dsacls.exe to display the help file.

Acldiag

Acldiag (Acldiag.exe) is a command-line utility that can be used determine the effective access granted to a specific user or group based on the permissions in the DACL of a specific object. It can also be used to verify that the explicit permissions in the DACL of an object include the permissions specified in the default security settings for objects of that class as defined in the Active Directory Schema. Finally, Acldiag can also be used to determine whether the permissions specified in the object’s DACL map to any of the delegation templates in the Delegation of Control Wizard and can be used to repair any delegation templates that are not completely applied.

Acldiag is included in the Windows support tools that you can install from the Windows CD. For information about how to install Windows support tools, see article 301423, “HOW TO: Install the Windows 2000 Support Tools to a Windows 2000 Server-Based Computer,” in the Microsoft Knowledge Base on the Web at https://go.microsoft.com/fwlink/?LinkId=3202. For details about how Acldiag works, run Acldiag.exe to display the help file.

Dsrevoke

Dsrevoke is a new command-line tool that can be used on domain controllers that are running Windows Server 2003 or Windows 2000 Server to report the existence of all permissions for a specific user or group on a set of OUs in a domain and optionally remove from the DACLs of a set of OUs all permissions specified for a particular user or group. Dsrevoke complements the functionality provided by Delegation of Control Wizard, which is used to delegate administrative authority, by providing the ability to revoke delegated administrative authority.

Using Dsrevoke

You can download Dsrevoke from the Microsoft Web site at https://go.microsoft.com/fwlink/?linkid=12538 and searching by keyword for “dsrevoke.”

To maximize the benefits offered by Dsrevoke, follow these guidelines as much as possible when delegating administrative authority:

• Use roles to delegate administrative authority. When delegating roles, be sure to use a unique and specific security group to represent every unique and specific role instance.

• Use inheritance to grant permissions to the security group representing a role instance, and grant permissions on OUs.

Delegating administrative authority by using roles involves the following tasks:

1. Create a specific and unique security group to represent the role.

2. Identify the highest level OU that represents the root of the smallest subtree that contains the subset of all objects the delegated user needs to access and modify in order to perform the delegated tasks.

3. Run the Delegation of Control Wizard on that OU and delegate the required administrative tasks to the unique and specific security group representing the unique and specific role.

If you follow these delegation guidelines, you can use Dsrevoke to easily and reliably undelegate authority. Simply run Dsrevoke in the domain, providing as input the name of the specific security group used to represent the delegated role, and use the /report switch to verify the existence of all explicit permissions for that security group that have been set on all OU objects in the domain . Once you have reviewed the reported permissions, you can use the /remove switch to revoke all permissions granted to that security group, thereby revoking the delegated authority.

The following is the usage for Dsrevoke:

dsrevoke/report|/remove [/domain:<domainname>] [/username:<username>] [/password:<password>|*] [/root:<domain/OU>] <securityprincipal>

• /report

  Only reports the ACEs that have been set for the given principal on all domain and OU objects under root.

• /remove

  Reports and then removes (after confirmation) the aces for the given principal.

• /domain

  DNS or Netbios name of domain (must be specified when <securityprincipal> is in domain other than default or if alternate credentials are provided).

• /username

  Username if alternate credentials must be specified.

• /password

  Will prompt for password.

• /root

  Root OU to start search for ACEs. If not specified will default to the specified domain’s default naming context (the root domain or OU must be specified using x500 format; if the domain name must include spaces, enclose the option in quotes, e.g., “/root:..”).

• <securityprincipal>

  Domain\User or Domain\Group for the security principal being looked up.

  Note

  Dsrevoke removes only permissions; if a role has user rights applied, you must manually remove them by modifying the appropriate Group Policy. Also, because Dsrevoke works only on domain objects and OUs, you must manually remove ACEs if you set them on a container object or if you explicitly set permissions on an object within a container or OU. For this reason, it is recommended that you always apply permissions to OUs rather than to specific objects within OUs, and that you apply permissions to child OUs by using inheritance. Finally, because Dsrevoke works only on domain objects and OUs, you cannot use it to remove permissions from the Configuration and Schema directory partitions. Consequently, you typically cannot use Dsrevoke to revoke delegation of service management tasks.