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.