Delegating Privileges in Active Directory

One of the key benefits of Active Directory (AD) is the ability to delegate privileges on an extremely granular level to other users in the directory. With AD’s security delegation model, you can delegate common tasks—like password resets, account unlocks, or even creation and management of objects—to someone without making him or her an administrator of the directory. The Active Directory Users and Computers (ADUC) Microsoft Management Console (MMC) includes a wizard that can help with some common tasks, but it doesn’t handle every scenario. In this article, we’ll take a practical look at the more advanced AD security editor with some common examples. We’ll also look at the different fundamental constructs that you will need to know in order to master AD delegation.

All About ACLs

An ACL is applied to every object in the directory, and it controls the security of that object. Also known as the security descriptor, the ACL is stored as binary data in the nTSecurityDescriptor attribute of the object. Starting with Windows Server 2003, AD internally uses a single-instance storage mechanism for storing ACLs in the AD database, since the majority of objects in the directory share a common set of ACLs. The actual ACL data is relatively large, so there is a substantial space savings in storing them only once.

ACLs are comprised of two major components: the Discretionary ACL (DACL) and the System ACL (SACL). The SACL is used to control when security audits are generated for that object (e.g. when it is modified). Both the DACL and SACL are comprised of a series of access control entries (ACEs) which represent the actual security permissions in the ACL. For the remainder of this article, we’ll be referring to the DACL component when we use the term ACL.

In order to view the ACL of an object using ADUC, you’ll first need to enable Advanced Features in the console by selecting View, then Advanced Features. Then right-click an object, open the Properties tab, then switch to the Security tab, which Figure 1 shows. You’ll find that the UI is fundamentally identical to managing NTFS file system permissions and that there are just different security permissions to assign. If you’re interested in digging deeper into the structure of the ACL, see the sidebar “Using the Security Descriptor Editor in LDP to Remove the Abstraction from the ACL.”

Much like the permissions on the file system, permissions inside of AD will be inherited by child objects unless you tell the directory not to. This makes it very easy to give an administrator the ability to perform an operation (such as password reset) on all the objects in a specific organizational unit (OU) or OU hierarchy. If this functionality didn’t exist, you would need to delegate the permissions on each user individually.

AD uses an internal background process called the Security Descriptor Propagator (usually abbreviated SDProp) to apply inherited permissions to child objects. In a very large environment, you might not see inherited permissions applied immediately. If you’ve ever noticed an attribute called dSCorePropagationData in AD and wondered what it does, this is the attribute that stores state information for SDProp.

What You Can Delegate

At a high level, there are a limited set of operations that you can delegate, and they can be applied across all classes of objects or just to a specific class, such as users. If you’re not familiar with the basics of the AD schema, take a look at “Extending the Active Directory Schema,” November 2010, InstantDoc ID126022, because we’ll be using some of the terms from that article later in this discussion. Security delegations can be applied to grant permissions to users or groups. While it’s functionally OK to delegate permissions to users, it’s always best practice to delegate permissions to a group and then place the appropriate users in the group. With this method, you control users’ rights by managing their group membership. This is a much simpler operational task than managing permissions.

The most common delegation you’ll probably apply is the ability to write to a specific attribute or set of attributes. If, for example, you want to delegate the ability to unlock user accounts, you’ll grant Write Property permissions on the lockoutTime attribute.

Certain operations that might seem like simply delegating Write Property to an attribute or two actually will involve delegating one or more extended rights. Reset Password and Change Password are two of the most common extended rights you’ll run into. AD and other applications can check for permissions to an extended right when an operation is requested via standard APIs, and applications can even define custom extended rights in the directory. If you have Exchange deployed, you’ll find a number of extended rights, such as Send-As and Receive-As.

If you take a look at the ACL on a user account (such as in Figure 2), you’ll find that the SELF security principal is delegated the Change Password Extended Right. You’ll also find that SELF is delegated the ability to write to a number of additional entries, such as Personal Information. Personal Information is an example of a Property Set, a collection of attributes, grouped together, that allows you to set permissions on the set instead of on all the individual attributes. AD allows attributes to be members of up to one Property Set. The advantage of Property Sets is that rather than creating individual ACEs that grant the ability to read or write to a large number of attributes, you can create a single delegation for the Property Set, and it will apply to all of the attributes in the set.

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:WindowsADAM 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.

Delegating Adding Computers to a Domain

Another common task is delegating the ability for a group of users to join machines to the domain. Out of the box, AD actually allows any authenticated user to join and join up to ten machines in the domain at any given time. AD implements this restriction using a function known as object quotas, which allows an administrator to specify the number of objects of a certain type that a user can have in the directory at any given time. AD determines how many objects count towards a user’s quota based on the object ownership information, which is stored in the ACL alongside the DACL and SACL.

There are two ways that you can delegate the right for someone (perhaps a junior administrator) to add an unlimited number of computers to the domain. The first way is to use the legacy NT Security Privilege (SeMachineAccountPrivilege), which allows a user to add machines to the domain. This privilege is granted on DCs via Group Policy and added to a user’s security token when he or she logs on. If you simply want to allow users to join machines to the Computers container, granting the privilege via Group Policy might be the simplest way to go about this task. To delegate this right to the Service Desk Users group using Group Policy, follow these steps:

1.   Launch the Group Policy Management Console by clicking Start, Run, then type gpmc.msc.

2.   Right-click Default Domain Controller Policy, and click Edit.

3.   Browse to PoliciesWindows SettingsSecurity SettingsLocal PoliciesUser Rights Assignment.

4.   Open the Add Workstations to Domain entry.

5.   Add Service Desk Users as shown in Figure 5.

6.   If you want to remove the ability for any user to join workstations to the domain, remove Authenticated Users.

If you’d instead like to control what OUs a computer can be joined to, you’ll want to use native Active Directory ACLs similar to the previous walk-through. In this example, we’ll grant the Service Desk Users group rights to join machines to the Desktops OU, and we’ll also give them the ability to reset machine account passwords in case they need to rejoin a machine to the domain. To do this, we’ll grant the Service Desk Users group the ability to create computer objects in the Desktops OU, then grant them the Reset Password permission and Write to pwdLastSet permission on computer objects.

The attributes and permissions that are available in the ADUC ACL Editor are loaded from the dssec.dat file on the local machine, instead of directly from the directory. One of the attributes that you will need to modify to complete this task isn’t listed by default in the dssec.dat file. To edit the dssec.dat file, follow these steps on the machine you are running ADUC from:

1.   Open an elevated command prompt and switch to %windir%system32.

2.   Launch notepad dssec.dat from the elevated command prompt.

3.   Find the \[computer\] section in the file.

4.   Find the line pwdLastSet=7 under \[computer\] and change it to pwdLastSet=0.

5.   Restart ADUC.

To create this delegation, follow these steps:

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

2.   Click Add, then click Find Service Desk Users.

3.   On the Object tab, specify Apply to This object only. Note that if you have OUs under Desktops, you want to allow computers to be joined to specify OU objects instead.

4.   Select the Allow check box for Create Computer objects.

5.   Click OK.

6.   Click Add, then click Find Service Desk Users again.

7.   Select Apply to Descendant Computer objects.

8.   Select Allow for the Reset Password permission.

9.   On the Properties tab, specify Apply to Computer objects.

10.  Select Allow for Write pwdLastSet.

11.  Click OK.

To test this delegation, you’ll need to try joining a test computer to the domain using a user account that’s a member of the Service Desk Users group. There are two ways to join a computer to the domain and specify the OU the computer will be in. The first method is to pre-create the computer account using ADUC. Launch ADUC and right-click inside the Desktops OU, click New, then click Computer. Specify the name of the computer, and grant the Service Desk Users group rights to join the machine, as Figure 6 shows.

The second method is to use the netdom command line tool to join the machine and specify the OU as part of the command. To join a machine called TEST-PC02 to the Desktops OU at the root of a domain called contoso.com, run this command:

netdom add test-pc02 /domain:contoso.com /userd:"contosojohn.doe" /passwordd:* /OU:"ou=desktops,dc=contoso,dc=com"

You will be prompted for the password to John.Doe’s account. If you want to use a smart card, you should add the /SecurePasswordPrompt switch.

Practice, Then Delegate

AD provides an incredibly flexible model that you can use to delegate very granular sets of permissions inside the directory to various sets of users. Delegations are stored inside ACLs, which are comprised of a series of ACEs. The Security Editor in ADUC Advanced mode simplifies complex delegations of permissions to objects, attributes, and extended rights. With a little bit of practice, you can easily start delegating granular rights to various groups, such as the Help desk or a junior administrator in your organization, without giving away the keys to the kingdom.