Delegating Privileges in Active Directory

The specific delegation for SELF here allows that user to write to a number of attributes on his or her account. Many organizations will remove these rights because they don’t want to risk letting users update information that is managed by a central system. The good news is that users will rarely discover how to edit these attributes. To do so, they would need to use an LDAP editor or something similar.

If you’re wondering what attributes are included inside a Property Set, you can use a tool bundled with Active Directory Lightweight Directory Service (AD LDS) to find out. On a machine that has the Windows Server 2008 (or newer) Remote Server Administration Tools (RSAT) tools installed and the AD DS and AD LDS tools enabled, browse to C:\Windows\ADAM and run ADSchemaAnalyzer.exe. Then, go to File, click Load Target Schema, specify a domain controller (DC) in your forest, then enter valid user credentials. The AD Schema Analyzer loads the AD schema and gives you a view that lets you browse relationships between classes, attributes, and property sets, which you can see in Figure 3. The attributes of each property set are listed under the Dependents container.

Another common task you might want to delegate is the ability to create a specific set of objects, perhaps allowing the helpdesk to create user objects. This is an extremely easy task to delegate; however, it’s important to consider some of the hidden security implications of delegating the ability to create objects. When an object is created, the user who created the object is assigned as the object’s owner in one of the fields in the ACL. Owners of an object have full control of that object, so they can bypass the granular permissions they are delegated on that object. Here’s a good example of how delegating the right to create objects might come back to bite you. Say you delegate to a user the ability to create OUs, and you also delegate to that same user the ability to create users inside those OUs. Since the user has full control of those OUs, the user can actually create any type of object, such as computers or groups, inside those OUs. After your domain is in the Windows Server 2008 Domain Functional Level (DFL) 3 or better, you can take advantage of Owner Access Rights to control this issue.

Now that we’ve taken a look at the various terms and components you’ll run into when delegating security permissions, let’s apply them to perform a few common tasks.

Delegating Password Reset and Account Unlock

One of the most common tasks to delegate, usually to a service desk or Help desk, is the capacity to reset users’ passwords when they forget them and unlock their accounts. To accomplish this, you’ll need to perform a few delegations: You’ll need to delegate the Reset Password Extended Right permission and the Write Property permission for the pwdLastSet and lockoutTime attributes.

The pwdLastSet attribute stores the timestamp for when the user’s password was last set so that AD can enforce password expiration. The lockoutTime attribute stores the timestamp for when the user’s account was locked out. When you select the check box to require the user to change the password at next logon, you’re actually setting pwdLastSet to 0. Likewise, when you select the check box to unlock an account in ADUC, you’re actually setting lockoutTime to 0.

Through the rest of this article, we’re going to use the ACL editor in ADUC to create the delegations discussed. Some of the tasks we complete with this editor are also possible using the Delegate Control Wizard in ADUC. However, using the raw ACL editor provides a much more complete view of the changes being made. If you are following these steps with a version of ADUC that was released before Windows Server 2008 R2, some of the text in the screenshots and some of the steps might not match exactly. You can safely use newer versions of ADUC and the other RSAT tools with older versions of AD.

For this discussion, we’ll assume that you’re going to delegate the ability to reset a user’s password to the Service Desk Users group for all users inside the People OU. To complete this task, follow these steps:

1.   In ADUC, open the Properties tab of the People OU, switch to the Security tab, and click Advanced.

2.   Click Add and Find Service Desk Users.

3.   On the Object tab, specify Apply onto Descendant User objects.

4.   On the Object tab, check Allow for the Reset Password permission.

5.   On the Properties tab, specify Apply onto Descendant User objects.

6.   On the Properties tab, select Allow for Write lockoutTime and for Write pwdLastSet.

7.   Click OK.

8.   Log on as a member of the Service Desk Users group, and verify that you can reset the password of a user in the People OU.

You should see three additional ACEs, which Figure 4 shows. ADUC’s ACL editor makes it easy to grant multiple permissions at once, even when those permissions require multiple ACEs. If you were to follow the above steps using a raw editing tool such as LDP, you’d need to create three individual ACEs: one for Reset Password, one for Write Property pwdLastSet, and one for Write Property lockoutTime.