To totally unlock this section you need to Log-in

Active Directory (AD) delegation is critical part of many organizations' IT infrastructure. By delegating administration, you can grant users or groups only the permissions they need without adding users to privileged groups (e.g., Domain Admins, Account Operators). The simplest way to accomplish delegation is by using the Delegation of Control Wizard in the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in.

Although the Delegation of Control Wizard provides an easy way to delegate permissions, there's no corresponding wizard for removing delegated permissions. Somebody at Microsoft must have noticed this shortcoming and created a command-line program named Dsrevoke.exe that can remove the permission entries added by the Delegation of Control Wizard.

However, the Dsrevoke.exe program has two important technical limitations, which are documented in the Microsoft article "When you use the Dsrevoke command-line tool to report permissions for all the organizational units in a Windows Server 2003-based domain, the tool may not return all the access control entries." These limitations are:

Dsrevoke.exe can find only up to 1,000 OUs in a single search. The suggested workaround for this limitation is to start the program's search in a more deeply nested organizational unit (OU) to reduce the number of results.
Dsrevoke.exe fails if any OUs contain a forward slash (/) character in their names. There's no workaround for this limitation other than to rename the offending OUs.

For organizational reasons, renaming the OUs to remove the slash character is not usually an option. Besides, the slash is a valid character in an OU name, and Dsrevoke.exe should work no matter whether an OU contains a slash in its name or not. Also, working around the 1,000 OU limit in my environment was time-consuming.

Starting in recent versions of Windows, the Dsacls.exe program provides a way of removing the permissions added by the Delegation of Control Wizard. Although it doesn't fail if an OU contains a slash in its name, Dsacls.exe can't search subcontainers for permissions like Dsrevoke.exe does.

Dsrevoke.exe and Dsacls.exe can produce a list of permissions, but the output is very long and technical.

We need to have some background information about what happens when we use the Delegation of Control Wizard as well as cover some basic Windows security concepts.

Why Delegate?

Imagine you are the head of a large company with several departments: finance, HR, sales, upper management.

If every user who forgot their password had to call the IT helpdesk, you would be swamped with calls.

Instead, you could delegate permissions to the head of each department so that he or she can reset his or her own team's passwords.

Another classic use case for delegation is the ability for staff to send emails as each other, either a shared mailbox, or a PA sending email on behalf of his or her boss.

Give everyone Domain Admin?

You might have thought, let’s give each department head Domain Admin permissions, then they can reset the passwords when required.

Whilst this is technically true, they would then be able to do anything you can do, including accessing user data.

So, be careful to give Domain Admin role to non-IT users to lower administration tasks: this approach can lead to several issues.

ACLs, ACEs, and Trustees

To understand the information being provided in the Advanced Security Settings dialog box, you need to know about the following Windows security concepts: access control list (ACL), access control entry (ACE), trustee, and inheritance. You also need to understand these concepts to use Remove-DSACE.ps1.

ACL: There are two kinds of ACLs: discretionary ACLs (DACLs) and system ACLs (SACLs). A DACL identifies the accounts that are allowed or denied access to an object. A SACL describes how an administrator wants to log attempts to access an object (i.e., auditing).

ACE: An ACL is composed of ACEs. Each ACE identifies a trustee and specifies the trustee's access (allow, deny, or audit) for the object. The Delegation of Control Wizard adds ACEs to an AD container's DACL. The previous figure shows the DACL for the All Users OU. In this figure, the term permission entry is synonymous with ACE.

Trustee: A trustee is the entity (a user, security group, or logon session) to which an ACE applies. Each ACE applies to a single trustee. In Figure 5, the term Principal is synonymous with trustee. Figure 5 shows that there are two ACEs assigned to the Password Reset group. In other words, the Password Reset group is the trustee (principal) for these two ACEs.

Inheritance: An ACE can be applied directly to an object, or it can be inherited from the resource's parent object. In the previous figure, the two ACEs for the All Users OU that contain the Password Reset group as a trustee aren't inherited from the parent container (i.e., the Inherited from column reads None) because the Delegation of Control Wizard added them directly to the DACL.

Adding Delegated Permissions with the Wizard

the Delegation of Control Wizard provides an easy way to delegate permissions. For example, suppose you want members of the Password Reset group to be able to reset passwords for users in the All Users OU in your AD domain. To do this, you need to perform these steps:

Open the Active Directory Users and Computers console and then right-click the All Users OU (or whatever OU) and choose Delegate Control, as shown in Figure 1. Click the Next button to advance past the wizard's welcome page.

On the wizard's Users or Groups page, click the Add button.

In the Select Users, Computers, or Groups dialog box, enter the group's name (Password Reset), click the Check Names button to make sure the group's name is correct, and click OK, as shown in following figure:

After making sure the group's name is listed on the Users or Groups page, click Next, as shown in the following figure:

On the Tasks to Delegate page, select Reset user passwords and force password change at next logon and click Next, as shown in following figure:

When you click the Finish button, the Delegation of Control Wizard adds the requested permissions to the All Users OU. You can view the effects of the delegation by right-clicking the All Users OU, choosing Properties, and selecting the Security tab. (If the Security tab isn't visible, enable the Advanced Features option on the View menu of the Active Directory Users and Computers console.)

For a detailed view, you can click the Advanced button. The following figure shows the Advanced Security Settings dialog box that appears.

Check Permission (Using PowerShell)

Now that we have discovered delegation, you might be wondering if there are any delegations that you don’t know about, either from past employees, or malicious administrators.

We have put together a short PowerShell script which will search each delegable object type and list the two common permission delegations, reset password and send-as (from Exchange).

Here’s a sample run from a domain:

And here the script code:

###### Search common delegation targets
$filter = "(|(objectClass=domain)(objectClass=organizationalUnit)(objectClass=group)(sAMAccountType=805306368)(objectCategory=Computer))" 

###### Search just OUs and Groups
#$filter = "(|(objectClass=organizationalUnit)(objectClass=group))"

###### More filters can be found here: http://www.ldapexplorer.com/en/manual/109050000-famous-filters.htm

###### Connect to DOMAINCONTROLLER using LDAP path, with USERNAME and PASSWORD
#$bSearch = New-Object System.DirectoryServices.DirectoryEntry("LDAP://DOMAINCONTROLLER/LDAP"), "USERNAME", "PASSWORD") 

###### Connect to DOMAINCONTROLLER using LDAP path
$bSearch = New-Object System.DirectoryServices.DirectoryEntry("LDAP://DOMAINCONTROLLER/LDAP") 

$dSearch = New-Object System.DirectoryServices.DirectorySearcher($bSearch)
$dSearch.SearchRoot = $bSearch
$dSearch.PageSize = 1000
$dSearch.Filter = $filter #comment out to look at all object types
$dSearch.SearchScope = "Subtree"

####### List of extended permissions available here: https://technet.microsoft.com/en-us/library/ff405676.aspx
$extPerms = '00299570-246d-11d0-a768-00aa006e0529', 'ab721a54-1e2f-11d0-9819-00aa0040529b', '0'
$results = @()

foreach ($objResult in $dSearch.FindAll())
{
    $obj = $objResult.GetDirectoryEntry()

    Write-Host "Searching... " $obj.distinguishedName

    $permissions = $obj.PsBase.ObjectSecurity.GetAccessRules($true,$false,[Security.Principal.NTAccount])
    
    $results += $permissions | Where-Object { $_.AccessControlType -eq 'Allow' -and ($_.ObjectType -in $extPerms) -and $_.IdentityReference -notin ('NT AUTHORITY\SELF', 'NT AUTHORITY\SYSTEM', 'S-1-5-32-548') } | Select-Object `
        @{n='Object'; e={$obj.distinguishedName}}, 
        @{n='Account'; e={$_.IdentityReference}},
        @{n='Permission'; e={$_.ActiveDirectoryRights}}
}
$results | Out-GridView

To use this script on your own domain:

Open Active Directory Users and Computers and navigate to the domain (or Organisational Unit) you are investigating.
Right click it and choose Properties.
In the Attribute Editor tab, look for the distinguishedName property.
Select it and press View, then copy the LDAP Path. You will need this later.
Edit line 6 ($bSearch = ...), replacing DOMAINCONTROLLER with the name of one of your domain's DCs.
Edit line 6, replacing LDAP with the path you copied previously.
Save the script and press run.
Let the script search through your Active Directory; progress is reported in the console and when it is completed you will receive a popup detailing objects that have permissions delegated to them.

Search by Keyword