Understanding Delegated Permissions in Active Directory

Active Directory Delegated Permissions Overview

The importance of Active Directory permissions cannot be understated, the capability for users to write and perform certain actions against your Active Directory can lead to unintended changes, unnecessary risk for attack vectors and lateral movement, or total domain compromise. In this blog, I’ll be going over, at a high level, how Active Directory permissions are applied, and how to view them natively. In the future, I’ll be covering how to discover risky permissions throughout your organization as well as how to identify access that can lead to unintended changes, such as compromising an account or the domain itself.

Applying Active Directory Permissions

The most common way to apply Active Directory permissions is through the tool Active Directory Users and Computers (ADUC). There are two ways in ADUC to apply permissions, the delegation wizard and navigating to an object, using the security tab, and applying permissions directly to the object or its descendants. More experienced administrators or those that are familiar with scripting may choose to apply and review permissions with PowerShell, but I won’t be covering that in this blog.

Active Directory Delegation Wizard

The ‘Delegate Control…’ wizard is an easy-to-use UI for an administrator to grant permissions to a user or group to perform a certain task. Let’s pretend that an administrator needed to provide the ‘Help Desk’ group the capability to reset passwords for all users in a specific OU that they’re responsible for assisting. This wizard can be launched by right-clicking an OU or container and selecting ‘Delegate Control…’.

This then launches the ‘Delegation of Control Wizard’, which is what allows the administrator to configure the permissions as required.

First, you’ll want to add the user(s) or group(s) you wish to grant the permissions to. These will be the accounts that are allowed to take the action you’re granting.

Then, you’ll want to choose the ‘common tasks’ you’d like these objects to be able to perform or you’ll want to create a custom task to delegate them access to perform. For this example, we’ll stick with the scenario I mentioned, resetting users’ passwords.

After pressing Next, you’ll just need to confirm your selection and finish the process, then under the covers, the permissions are applied to grant that group the capability to perform the task(s) you selected.

As you can see, we’ve granted the ‘Help Desk’ account the capability to ‘Reset user passwords and force password change at next logon’ to all descendant users of the ‘SB Test Area’ OU. We can confirm these permissions were applied as described in the next section, where we look directly at the Security tab of the ‘SB Test Area’ OU.

Security Tab

Reviewing Permissions

To view the security tab on an object, you’ll first want to enable ‘Advanced Features’ in ADUC. This can be done by choosing ‘Advanced Features’ from the View dropdown menu.

From there, let’s navigate to the SB Test Area OU and review the permissions that were applied from the delegation wizard.  To do this, we’ll right-click the SB Test Area OU and select ‘Properties’. Once that interface pops up, we can see information about the object, but most importantly, the security tab.

This interface may look very similar to NTFS permissions on a folder within Windows Explorer, and reviewing, applying, and removing permissions is done in a similar fashion. This interface shows us the Access Control List (ACL) for the SB Test Area object. The ACL of the object is comprised of Access Control Entries (ACEs). If we look through the groups and users that have been applied to the SB Test Area OU ACL, we can find the Help Desk group accounts ACE we added previously. We can see that this account was granted ‘Special Permissions’ since the permissions we applied were not basic and exposed in this UI. To view the permissions we applied, we’ll have to press Advanced.

Reviewing the information in the Advanced Security Settings for this object shows what was applied when walking through the wizard above. We can see in the screenshot below that the ACE for the ‘Help Desk’ principal is granting ‘Reset Password’ permissions on ‘Descendant User objects’ of the SB Test Area OU.

Clicking Edit here lets us review the ACE for the Help Desk principal on the SB Test Area OU.

We can see above that, under the covers, the permission we granted to the Help Desk account on the SB Test Area OU was just ‘Reset password’.

Applying Permissions

Now that I’ve shown you how to review permissions using the security tab, let’s quickly cover how you can apply permissions in this fashion, instead of using the delegation wizard.

Let’s say I wanted to grant my account the capability to modify members of groups within a certain OU. I can right-click the OU in question, in this case, KevinJSandbox, go to properties and then the security tab.

From here, I can press ‘Add…’ and select my account, KevinJ.

Once I added my account, I can see that it granted ‘Read’ access to the KevinJSandbox OU, but I don’t have a way from this interface to granularly allow group modifications. To do this, I’ll have to select Advanced. Once the Advanced UI opens, you’ll want to select ‘Edit’ on the ACE for the object we just granted access to.

We can see the default ACE that was created when I added my user account before was an entry to allow the listing of contents, reading of all properties, and reading of permissions on the KevinJSandbox object only. We’re going to modify this to allow us to also modify the membership of descendant groups in the KevinJSandbox OU. To do this, first, we’ll want to select ‘descendant group objects’ from the ‘Applies to’ dropdown.

The list of permissions allowed to be applied then changes, based on the object(s) selected in the Applies to field.

As you can see from the list above, there is no ‘Modify group membership’ permission under the Permissions entries. To grant the principal the capability to only modify group members of a group, you need to scroll down and select the ‘Write Members’ property.

As you can see from this blog, understanding, applying, and analyzing Active Directory permissions can be very complex. This only scratched the surface in terms of the granularity of permissions that can be applied, and the risk that comes with applying the permissions shown above.

What’s Next?

In a future blog, I’ll be covering the risk of certain Active Directory permissions and what they can lead to if left unchecked in your environment. In the meantime, if you’re interested in understanding and auditing the permissions that exist throughout your organization’s Active Directory, be sure to check out StealthAUDIT Active Directory Permissions Analyzer to be able to effectively report on access that can lead to unintended risk and attack vectors.