Overview of Active Directory Delegation
Updated: December 5, 2005
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
Through delegation of administration, responsibility for administrative tasks is transferred to the administrators who must perform the respective tasks, and to no one else. From a technical perspective, delegation of administration involves a higher-level administrator granting a controlled set of permissions to a relatively lower-level administrator to give the lower-level administrator the ability to perform a specific administrative task. In other words, a higher-level administrator authorizes the delegated lower-level administrator to carry out a specific administrative task.
Every administrative task involves effecting a change to the state of some data, and changing the state of data involves performing a low-level operation on the object that stores that data. As mentioned earlier in this document, there are two major categories of administrative tasks in Active Directory – data management asks and service management tasks:
Data management tasks typically include such tasks as creating and managing user and computer accounts, security groups, and application-specific data, all of which are stored in Active Directory. In certain cases, a small subset of tasks might involve the modification of Group Policy settings to affect the configuration state of member computers. Creation of user accounts and modification of group memberships are both examples of data management tasks.
Service management tasks include tasks that are related to the creation and maintenance of Active Directory configuration data. For example, adding a domain controller to a child domain, associating a new subnet to a site, and extending the Active Directory schema are all Active Directory service management administrative tasks that effect changes to configuration data. A majority of Active Directory configuration data is stored in Active Directory itself. However, certain aspects of Active Directory behavior can or must be configured on a domain controller. The configuration data that is associated with these tasks might be stored in the registry or file system of domain controllers.
Thus, data and service management administration tasks primarily involve effecting the change of data that is stored either in Active Directory, or in some cases on the file system or registry of Domain Controllers and other computers joined to Active Directory.
Every administrative task effects a change to the state of some data, and changing the state of data involves performing a low-level operation on some data represented by an object in the directory (or in some cases by an object on the file system or registry of a computer or Domain Controller). For example, the administrative task of resetting a user’s password involves a low-level write operation on an attribute of the user object. Similarly, creating a new site involves creating a corresponding site object. Similarly, modifying the level of detail logged for security events involves modifying a registry key (data) on Domain Controllers. These low-level operations that constitute an administrative task typically involve creation, deletion, access to, modification of, or verification of data.
All data stored in Active Directory is represented by directory objects, each of which can be individually secured. Similarly, all data stored on the file system on computers and in their registries is also represented by individually securable objects. Individually securable refers to the fact that all low-level operations on data (represented by objects) can be individually authorized. In other words, an administrator can specify who can do what on every specific unit of data.
Since every Active Directory administrative task involves affecting the state of some data by means of a low-level operation, and since all data can be individually secured to allow or deny someone the ability to perform a low-level operation on that data, it follows that the ability to carry out every administrative task can be controlled by controlling the appropriate permissions that authorize the execution of the corresponding low-level operation on the target data that is involved in the administrative task.
Thus, by being able to individually authorize every low-level operation on data, administrators can in effect authorize all administrative tasks that involve low-level operations. Since all administrative tasks involve at least one low-level operation, it follows that all administrative tasks can be individually authorized. Since delegation involves a higher-level administrator authorizing the delegated lower-level administrator to carry out a specific administrative task, every administrative task in Active Directory can be delegated by controlling the permissions required to perform the low-level operation involved in the administrative task.
Delegation involves granting a controlled set of permissions to someone so that can carry out an administrative task.
Every administrative task involves performing some low-level operation on data.
Low-level operations on data can be (individually) authorized.
By being able to authorize the corresponding low-level task, you can delegate a task.
The following example illustrates the crux of how delegation works in Active Directory. Let us consider a day in the life of David Hamilton, a marketing associate with Contoso Pharmaceuticals.
David Hamilton recently joined the company. When he joined the company, a user account was created for him under the Business Division OU by the Account Admins for the Business Division of the company. The creation of the user account involved a create operation for an object of class User under the parent object, which in this case happened to be the OU object for the Business Division. Since the Account Admins had Create Child permissions on this OU, they were able to create the account.
Once the account was created, David could log on to the Active Directory domain and go about performing his assigned responsibilities. One day, David forgot his password and thus could not log on. He then called the Help Desk for help. Jeff Price, a member of the Help Desk operators group, received the call and reset David’s password after verifying David’s identity. The reset password operation involved modifying password related attributes on David’s user account object and required that the Reset Password extended right on David’s user account object be granted to the individual who should be able to reset David’s password. During the implementation of the delegation model, the Help Desk operators group, of which Jeff was a member, was granted this extended right on all users in the domain. Thus, Jeff was authorized to reset David’s password.
Within six months of employment, David was promoted to the position of senior marketing associate and now reported to a new manager. Michelle Alexander, a Contoso employee in the Human Resources department, needed to appropriately update David’s manager information as stored on David’s user account in Active Directory. Modifying a user’s manager information requires a low-level operation involving the modification of the Manager attribute on user account objects, and requires write-property permissions to the Manager attribute to succeed. Account Admins had granted a group called Human Resources Personnel, of which Michelle was a member, write-property permissions to modify the manager attribute on all user objects. Michelle was thus able to update David’s account by appropriately changing David’s manager information.
After one year with the company, David was offered a promotion and a new job in the Research and Development (RandD) Division of the company. His user account now needs to be moved to the OU for the RandD Division. Moving an object involves multiple low-level operations, including the deletion of the object from under its current parent object, the creation of a new object under the new parent object, and the modification of the Common-Name and relative distinguished name attributes on the object. (Note that technically the object is not deleted – it only seems that it is deleted and re-created.) Michael Allen, a member of the overall account management team for Contoso (which has membership in the Contoso Account Admins group) was asked to move the object between the two OUs. The Contoso Account Admins group is granted sufficient permissions on both the source and target OUs to enable its members to carry out object moves. Michael thus has the required Delete Child permissions to carry out the low-level delete operation on the Business OU and Create Child permissions to carry out the low-level create operation on the RandD OU, and additionally has write-all-properties permissions on the user object and was thus able to carry out the move operation for David’s user account.