Active Directory (AD) administrative delegation is the ability to delegate Windows AD infrastructure-­related administrative tasks to a particular administrative account or group. AD delegation is a must when you want to easily divide up and assign administrative control over a large number of AD objects (users, computers, printers, sites, domains, and so on) among multiple administrators. A good example of a scenario in which AD delegation is useful is giving Help desk administrators just enough rights to let them reset the passwords of AD user accounts. By facilitating the decentralization of administration, AD administrative delegation can increase administrative efficiency, reduce administrative costs, and improve the overall manageability of large IT infrastructures.

The Importance of OUs
AD delegation is possible thanks to the AD authorization model, which supports fine-grained AD object permissions and inheritance of permissions from AD parent objects to child objects. Organizational units (OUs), AD's container objects, are an important enabler for the administrative delegation of AD objects. You can delegate the administrative control over the objects that are contained in an OU. When dealing with OUs, you must always keep the following in mind:

  • An OU is an AD container object used primarily to organize AD objects in a hierarchical way and to delegate control over these objects to different administrators.
  • OUs aren't security principals. They don't have a SID. Thus, they can't be used in ACLs. Also, you can't delegate administrative tasks to an OU, which makes an OU different from a group. You can use ACLs to set authorization settings on OU objects.
  • An object can be contained in only one OU, although from a hierarchical point of view, an object can have multiple parent OUs.
  • An OU is bound to a single domain. It can't span multiple domains.
  • Figure 1 shows the OU structure of an AD infrastructure spanning several geographical locations. The top-level OUs reflect the continents and cities of the infrastructure: Europe is the top OU, and under it are OUs for Brussels (BRO), Dublin (DBO), Amsterdam (AMS), and London (LON). Each city OU is split into sub-OUs that are based on the object types that must be administered: administrators, users, machines, and printers. An AD object's distinguished name (DN) reflects the nesting of OUs. For example, a file- server object that's part of the OU structure in Figure 1 might have the following DN: CN=FileServer1, OU= Member Servers, OU=Machines, OU=BRO, OU=EU, DC=hp, DC=com.

    Setting Up Administrative Delegation
    To easily set up administrative delegation, Microsoft provides the Delegation of Control wizard. Figure 2 shows the final screen of this wizard, which summarizes the control delegated. The wizard is accessible at the site, domain, and OU levels from the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in and MMC Active Directory Sites and Services snap-in. The Delegation of Control wizard lets an administrator choose among a set of predefined delegation tasks, which Table 1 lists. You can also create custom tasks to better reflect your organization's needs by defining a task in the Delegation of Control wizard or predefining it and then adding the predefined task to the wizard.

    To add a predefined task to the Delegation of Control wizard, you must modify the delegwiz.inf configuration file. Figure 3, shows a bit of this file, which is located in the %windir%/inf directory. The syntax you must use when customizing the task list is explained in the Microsoft article "How to customize the task list in the Delegation Wizard," http://support.microsoft.com/?kbid=308404.

    If you have a good understanding of the AD object ACL editor and the AD authorization model, you can do without the Delegation of Control wizard and set delegation directly through the ACL editor of a site, an OU, or any other object. Otherwise, I strongly recommend you use the Delegation of Control wizard.

    The Group Policy Management Console (GPMC), an AD management tool that was introduced in Windows Server 2003, is convenient for delegating administrative control over Group Policy Objects (GPOs). The GPMC GUI has a special Delegation tab, which Figure 4, shows, for each GPO. You can download GPMC for free from the Microsoft Web site at http://www.microsoft.com/downloads/details.aspx?familyid=0a6d4c24-8cbd-4b35-9272-dd3cbfc81887&displaylang=en.

    The Delegation of Control wizard can be used only to add permissions, not to remove them. You can easily remove individual AD administrative permissions from the ACL editor or by using the dsacls.exe command-line tool. If you need to undelegate AD administrative permissions that have been set for an account on child objects when administration was delegated on the level of a parent OU, you can use a command-line tool called dsrevoke.exe, which eases and automates the removal of permissions on hierarchical object structures. You can download the tool at http://www.microsoft.com/downloads/details.aspx?familyid=77744807-c403-4bda-b0e4-c2093b8d6383&displaylang=en.

    To better reflect the AD administrative delegation you set up, you can develop a customized administration interface, called a taskpad, on the level of the administrative interface of the administrator to whom you delegated permission. To create a taskpad, open a new MMC console and add a snap-in. Right-click the snap-in container and select New Taskpad View. The Taskpad View Wizard will take you through the process of creating a taskpad. You can save customized MMC consoles and taskpads as regular files and email them to the administrators who need them.

    AD Delegation Guidelines
    Microsoft recommends delegating only at the OU level, not at the AD domain or site level. Delegation on the domain level can't fully isolate the administrative authority of a particular administrator. A Windows domain is only a boundary for AD replication. In Windows 2000 and later, the true security boundary is the forest. If you want to provide complete isolation between administrative entities, you must set up multiple AD forests.

    You shouldn't delegate administration tasks at the site level because sites are bound to the physical layout of the network used for your AD infrastructure. Sites are based on IP addresses and subnets. The fact that a single site can span different forests, domains, and OUs might make the ACL evaluation process too complex.

    Microsoft also recommends against delegating the following AD infrastructure­related administrative tasks:

  • Management of AD security settings, including the management of the Default Domain and Domain Controller GPOs
  • AD backup and restoration
  • For more AD delegation guidelines from Microsoft, have a look at the "Best practices for Active Directory Delegation" white paper that you can download at http://www.microsoft.com/downloads/details.aspx?familyid=631747a3-79e1-48fa-9730-dae7c0a1d6d3&displaylang=en.

    Administrative Delegation Examples
    The following examples illustrate how you could use administrative delegation in a Windows 2003 domain. I show you how to set up delegation to let Help desk staff reset user passwords, let users change some of their account information, and let certain administrators perform key network management tasks.

    Help desk example. As I mentioned at the beginning of this article, AD administrative delegation is useful in a Help desk scenario. Organizations typically want to delegate the following AD permissions to their Help desk staff: the ability to reset account passwords, set the User must change password at next logon account property, and unlock accounts by clearing the Account is locked out account property.

    To delegate the above administrative tasks to your Help desk personnel, you must give them the following permissions on the OU that contains the user accounts:

  • Set the Reset Password for user objects right to Allow to grant permission to reset account passwords.
  • Set the Write lockoutTime for user objects right to Allow to grant permission to unlock accounts.
  • Set the Write pwdLastSet for user objects right to Allow to grant permission to set the User must change password at next logon account property.
  • Set the Read AccountRestrictions for user objects right to Allow to grant permission to read all account options. This permission lets a Help desk staffer determine whether an account is enabled.
  • To display the pwdLastSet and lockoutTime user account attributes in the advanced view of the ACL editor of Win2K machines, you must edit the dssec.dat configuration file. You must set the lockoutTime and pwdLastSet attributes to the value 0 (the default value is 7). Figure 5 shows how setting pwdLastSet to 0 in the dssec.dat file makes the Read pwdLastSet and Write pwdLastSet permissions visible in the ACL editor.

    User account self-management example. By default, AD allows users to edit specific user account attributes such as their phone number and office location. You can leverage this feature to reduce the workload of Help desk administrators for simple and recurring user account property changes. And you can control which attributes a user can manage on his or her account object.

    To enable user account self-management, Microsoft provides a special security principal called Self. By default, various permissions are set for the Self security principal that enable each user to edit attributes on his or her own user account in AD. To change the attributes that can be self-managed, you must change the default security descriptor (i.e., the default authorization settings) for the User object class in AD.

    You can set the default security descriptor of an AD object class in the properties dialog box of the AD object class. The easiest way to do this is by using the MMC Active Directory Schema snap-in. Before you can use this snap-in, you must register the schmmgmt.dll. To do so, type the following at a command line:

    Regsvr32 schmmgmt.dll

    Then, open the Active Directory Schema snap-in, locate the User object in the Classes container, and open the class's Properties dialog box. Go to the Default Security tab, which Figure 6 shows, to change the default security descriptor. In Win2K, this tab is simply named Security--which is a bit confusing.

    Figure 7 shows the permissions that are given by default to the Self security principal for the User object class. When you change an object class's default security descriptor, only objects created after the change will have the updated permissions.

    Network management examples. Table 2, gives some examples of network management­related tasks that you might want to delegate to particular administrators in your organization and how you can configure these administrative delegations.

    Third-Party AD Delegation Tools
    Table 3, lists third-party software products that can help facilitate AD administrative delegation. All of them provide a role-based administrative abstraction layer that's implemented on top of the AD authorization model. They all include logic that translates organizational roles and their associated AD administration tasks into native AD access permissions. Third-party AD delegation tools can get you started with AD administrative delegation more rapidly: You don't need to be an AD authorization guru to use them. Also, third-party tools include features to easily backup and restore your AD delegation settings.

    AD administrative delegation is a powerful AD feature--letting you delegate regular day-to-day AD administrative tasks. If you want to use AD delegation properly and get the most out of it, you must have a detailed understanding of the AD authorization model. Even then, it's better not to touch the AD objects' permissions directly but rather use the AD Delegation of Control wizard or a third-party AD delegation tool.