Common Active Directory ACL Entries

Summary

A significant portion of being a good systems administrator is knowing how to accomplish tasks without doing more than is required. Maybe the best example of this is granting access to resources in Active Directory. When a user or team needs access to something in the directory, the beginner/bad sysadmin will take the easy way out, probably by using a default role like Account Operators or granting full control over the OU where the resources reside. After a while, you'll start seeing users in places where only groups should be or realize you've given someone the ability to reset the passwords on your elevated or production service accounts when you only wanted them to be able to unlock standard users.

I'm not overstating things when I say the ACLs below are the basis for my entire directory design. AD's ability to grant permissions on a per-attribute level is what makes things like the separation of resources, the deployment of a proper role-based security model, and adherence to the least-permissions principle possible. Before someone asks: yes, you can set a lot (if not all) of these using the delegation wizard. However, if you don't know what is being set by that wizard, how will you effectively troubleshoot access when users claim it's not there or build your own custom ACL lists for one-offs in your environments?

An aside: as a general rule, you should grant these permissions to access groups, not individual users or role groups. I'll be working on a set of posts to explain that concept further. Keep in mind these are just the most common ACL sets I've encountered; there are obviously many more.

Notes

• The terminology/UI descriptions are for Windows Server 2012, but you can pretty easily translate for previous versions.
• After you specify a security principal and the Applies to section of the dialog box, it will automatically fill in several checkboxes under Permissions, Properties, or both. Scroll all the way down to the end of the list and clear them all with the button in the bottom right, then check the boxes noted in this article.
• Unless otherwise noted, these entries should be placed on the parent OU that contains the target objects. The assumption is you've designed your directory structure in a way that separates resources by type/security need.
• These ACLs must be added in the Advanced Permissions section in ADUC or ADSIEdit. You cannot add them in the basic Security tab.
• In the case where an entry has multiple Applies to entries, you will have to add multiple ACLs for the same access group.
• Sometimes checking a box in the Permissions area causes boxes in the Properties section to also be checked. If this happens, do not uncheck the resulting Properties boxes, even if nothing is specified in that section below.
• DO NOT TRUST VENDORS WHO CLAIM TO NEED DOMAIN ADMIN RIGHTS. In my career, I can't count the number of vendors who claimed (even in install documentation) their service account needed membership in Domain Admins for full functionality. Unless they are promoting/demoting DCs, extending the schema, or doing other high-level domain administration tasks, they don't need it. Force them to tell you exactly what they need, and grant it granularly. I actually forced a vendor to go through this process, and at the end, they asked for the documentation I had developed so they could use it in future installs. I should have billed them.

Unlock Users

This is one of the more common requests I see, regardless of the purpose of the domain. Any environment that has users and a lockout threshold will have lockouts, and support personnel need to be able to unlock them.

Applies to: Descendant User objects

Permissions: None

Properties: Write lockoutTime

It's normal for me to grant this access pretty easily. You can't directly use it to take over an account, so it's fairly low-impact from a security perspective.

Reset Passwords for Users

This goes hand in hand with the Unlock Users entry, but I recommend you assign these to separate access groups. When designing access, maintaining granularity is very important because of changing requirements. As your domain grows and evolves, you may have a need for different users/teams to do those tasks, so separating them now costs you very little and can pay off big in the long run.

Applies to: Descendant User objects

Permissions: Reset password

Properties: Write pwdLastSet

The reason you should add the pwdLastSet attribute modification in addition to the reset password permission is it is required to check the box to force users to change their password at next logon. Without this, you can run into issues the minimum password age and audits.

Keep in mind: whoever can reset the password for an account can take it over. Don't grant lower-level users the ability to reset passwords for other users with higher access in the environment.

Create/Manage/Delete Users

To be clear: you should only assign this set of ACLs if you want the specified users/teams to be able to fully manage users under that directory. They will be able to do everything but change permissions and manage child objects under the users. However, it is far better to grant this (admittedly expanded) access to a specific OU than add them to something like Account Operators that gives them highly elevated rights to all users in the entire domain.

Applies to (1): This object and all descendant objects

Permissions: Create User objects, Delete User objects

Properties: None

Applies to (2): Descendant User objects

Permissions: Write all properties, Delete, Delete subtree

Properties: None

Is is relatively common to see child objects created under user objects, so the Delete subtree is required to allow their deletion.

Disable Users

Unfortunately, changing the enabled/disabled status of an account uses the attribute userAccountControl, which can define many aspects of the account (see details here). So just know that when you grant this, you also grant the ability to set the password to non-expiring and set up other potentially problematic configurations.

Applies to: Descendant User objects
Permissions: None
Properties: Write userAccountControl

Write SPNs of Users

It is common for users or service accounts to need the ability to write service principal names to other resources (or themselves), especially Microsoft products like SQL Server and SharePoint. Admins can choose to request a list and apply them using the setspn command, but it's usually better to let the installer do it to lessen the chance of typos or other issues.

Writing SPNs to Other Users

Applies to: Descendant User objects

Permissions: None

Properties: Write servicePrincipalName

Writing SPNs to Self

Instead of specifying the access group as the security principal, use SELF

Applies to: This object only

Permissions: None

Properties: Write servicePrincipalName

Some versions of ADUC and ADSIEdit don't show this attribute in the Properties list. You can choose to try another version, modify the configuration of the tool to show it, or grant the access using a command line tool like PowerShell.

Modify the Membership of Groups

Another very common need: you have multiple similar groups in an OU, and you want a user/team to be able to modify the membership of the groups without changing the names or other attributes.

Applies to: Descendant Group objects

Permissions: None

Properties: Write members

Fun side note: when you make someone the manager of a group and check the box to give them the ability to manage the membership, AD simply adds this ACL. There's nothing magic about that checkbox; you can just as easily add the access yourself (unless you want them to be able to modify the membership in Outlook, but that's another post).

Create/Modify/Delete Groups

I recommend giving this access out more sparingly than most people probably expect. "They're just groups; it's not like they're user identities or other more audited objects." That's true, but groups will make or break the health of your domain. They are the links in the access chain, and if you have a cohesive security model in place, it will rely on groups. Allowing users who are unfamiliar with your model/naming scheme/directory structure guarantees those groups will not be created to your standards, creating one-offs and influencing other users. You should only grant this access in specific cases where there is a business need to create/modify the groups autonomously, and even then, only to users who have been taught the naming scheme and other details. A good compromise here is keeping the creation rights to yourself, but allowing the users to manage the membership of the groups you created (see the ACL above).

Applies to (1): This object and all descendant objects

Permissions: Create Group objects, Delete Group objects

Properties: None

Applies to (2): Descendant Group objects

Permissions: Write all properties, Delete

Properties: None

Create Computers

This ACL is only to create computers. At some point, you will probably be asked to grant access for an operating system deployment system that automates the server/workstation build process. It is very common for vendors to request full control rights over OUs/containers, but unless they can give you an task-specific reason for it, they probably only need the ability to create computers.

Applies to: This object and all descendant objects

Permissions: Create Computer objects

Properties: None

If they want the ability to write simple text attributes like Description, just add that to the Properties section.

Create/Modify/Delete Computers

This ACL set is for those who truly need to manage computer objects under the specified container: it allows them to do all the basic tasks of resource management in AD as well as some tasks that are special to computer objects like creating child objects for a cluster install. Grant it with the appropriate caution.

Applies to (1): This object and all descendant objects

Permissions: Create Computer objects, Delete Computer objects

Properties: None

Applies to (2): Descendant Computer objects

Permissions: Write all properties, Delete, Delete subtree, Create all child objects, Delete all child objects

Properties: None

Create/Modify/Delete OUs

This is another entry that is similar to managing groups: it seems innocent enough, but it has the ability to completely wreck your directory. If users who don't know the security model start branching out your tree, it will quickly cause confusion for everyone. Again, I recommend only granting this right if there is a very standardized process than can be done by a team you trained. Even then, I regularly check in to make sure the policies are being followed.

Applies to (1): This object and all descendant objects

Permissions: Create Organizational Unit objects, Delete Organizational Unit objects

Properties: None

Applies to (2): Descendant Organizational Unit objects

Permissions: Delete

Properties: Write name, Write Name

Yes, there are two properties for the OU name. Notice we did not grant Delete subtree permissions on this one; you don't want users outside of the domain administration team having the ability to delete OUs that still contain resources. That's just asking for trouble.