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:
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 infrastructurerelated administrative tasks:
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:
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 managementrelated 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.
