Rachit Arora

Active Directory: ACLs

Apr 11, 2024

Access Control List Model ( ACL )

Enables control on the ability of a process to access objects and other resources in active directory based on:

  1. Access Token a. Security Context of a process b. Identitiy and privs of user
  2. Security Descriptors
    • SID of principal that is the object owner
    • SID of the owner primary group
    • (Optional) DACL (Discretionary Access Control List)
    • (Optional) SACL (System Access Control List)
PS C:\> $(Get-ADUser anakin -Properties nTSecurityDescriptor).nTSecurityDescriptor | select Owner,Gro
up,Access,Audit | Format-List

Owner  : CONTOSO\Domain Admins
Group  : CONTOSO\Domain Admins
Access : {System.DirectoryServices.ActiveDirectoryAccessRule, System.DirectoryServices.ActiveDirectoryAccessRule,
         System.DirectoryServices.ActiveDirectoryAccessRule, System.DirectoryServices.ActiveDirectoryAccessRule...}
Audit  :

An ACL is a list of ACEs (Access Control Entry). The ACEs of the SACL defines the access attempts that are going to generate logs, and they can be useful from a defensive perspective.

However, the most important part is the DACL, that is usually present in all the objects, whose ACEs determines the users/groups that can access to the object, and the type of access that is allowed. Usually when someone refers to the object ACL, it means the DACL


Defines the permissions trustees (a user or group) have on an object.


DACL Structure

The access control list consists of multiple individual permissions known as ACEs Access Control Entries.

Each entry has a permission type (allow or deny), a principal account (who is this permission for — user, group, computer), what objects the principal account can access, and the access rights [read, write, Full Control].



SACL - Logs success and failure audit messages when an object is accessed.


Every object have Security Descriptors



Each ACE has several parts:

PS C:\Users\Administrator> $(Get-ADUser anakin -Properties nTSecurityDescriptor).nTSecurityDescriptor.Access[0]

ActiveDirectoryRights : GenericRead
InheritanceType       : None
ObjectType            : 00000000-0000-0000-0000-000000000000
InheritedObjectType   : 00000000-0000-0000-0000-000000000000
ObjectFlags           : None
AccessControlType     : Allow
IdentityReference     : NT AUTHORITY\SELF
IsInherited           : False
InheritanceFlags      : None
PropagationFlags      : None

On the other hand, ACEs can be inherit from parent objects of the database (OUs and containers), and actually, most of the ACEs that apply to objects are inherited. In case of a inherited access contradicts an explicit ACE (not inherited), then the explicit ACE determines the access rule. Thus, the precedence is the following for ACEs:

  1. Explicit deny ACE
  2. Explicit allow ACE
  3. Inherited deny ACE
  4. Inherited allow ACE

Active Directory object permissions

Some of the Active Directory object permissions and types that we as attackers are interested in:

GenericAll - full rights to the object (add users to a group or reset user’s password)

GenericWrite - update object’s attributes (i.e logon script)

WriteOwner - change object owner to attacker controlled user take over the object

WriteOwner - change object owner to attacker controlled user take over the object

AllExtendedRights - ability to add user to a group or reset password

ForceChangePassword - ability to change user’s password

Self (Self-Membership) - ability to add yourself to a group

There are many extended rights, but here are ones of the most :

ACL attacks

  1. Change the user password

  2. Make user Kerberoasteable

  3. Execute malicious script

  4. Add users to group

  5. DCSync attack:

  6. LAPS password

  7. Modify ACLs

  8. GPO abuse

There are more, would be writing a different blog for that

Enumerating ACLs

# The GUID resolver parameter gets the group ID of the requested object.
Get-DomainObjectAcl -SamAccountName studentl -ResolveGUIDs

# Get the ACLs associated with the specified prefix to be used for search
Get-DomainObjectAcl -SearchBase "LDAP://CN=Domain Admins,CN=Users,DC=dollarcorp,DC=moneycorp,DC=local" -ResolveGUIDs -Verbose

# Check the Domain Admins permission - PowerView as normal use
Get-DomainObjectAcl -Identity 'Domain Admins' - ResolveGUIDs | ForEach-Object {$_ | Add-Member NoteProperty 'IdentityName' $(Convert-SidToName $_.SecurityIdentifier);$_} |  {$_.IdentityName -match "student1"}
# ActiveDirectory Module
(Get-Acl -Path 'AD:\CN=Domain Admins,CN=Users,DC=dollarcorp,DC=moneycorp,DC=local').Access | ?{$_.IdentityReference -match 'student1'}

# We can also enumerate ACLs using ActiveDirectory module but without resolving GUIDs (ADModule)
(Get-Acl 'AD:\CN=Administrator,CN=Users,DC=dollarcorp,DC=moneycorp,DC=local').Access

#To filter through a specific type of permission, use the equal (-eq) operator and pass it the permission type such as “GenericAll.
Get-ObjectAcl student181 | Where-Object ActiveDirectoryRights -eq "GenericAll"
Get-ObjectAcl student181 | select IdentityReference, ActiveDirectoryRights | Where-Object ActiveDirectoryRights -eq "GenericAll"

# Search for interesting ACEs
Find-InterestingDomainAcl -ResolveGUIDs

Get-PathAcl -Path "\\dcorp-dc.dollarcorp.moneycorp.local\sysvol"

# Get The ACLs associated with specified LDAP path
Get-ObjectAcl -ADSpath "LDAP://CN=Domain Admins, CN=Users, DC=dollarcorp, DC=monycorp, DC=local" -ResolveGUIDS -Verbose

#Search For Interesting ACEs
Invoke-ACLScanner -ResolveGUIDS 
Invoke-ACLScanner -ResolveGUIDS | ?{$_.IdentityReferenceName -match "RDPUsers"}

Find-InterestingDomainAcl -ResolveGUIDs | ?{$_.IdentityReferenceName -match "RDPUsers"}
Find-InterestingDomainAcl -ResolveGUIDs | ?{$_.IdentityReferenceName -match "studentx"}


AdminSDHolder is an special object in the database whose DACL is used as template for the security descriptor of privileged principals.

Every 60 minutes, the SDProp (Security Descriptor Propagator) examines the security descriptor of these privileged principals, and replace their DACL with a copy of AdminSDHolder DACL (if they differ). This is done in order to prevent modifications on the DACLs of these principals, but if you are able to add custom ACEs to the AdminSDHolder DACL, then these new ACEs will also being applied to the protected principal

By default the following principals are “protected” by AdminSDHolder:


In Active Directory, some privileges can be also abused (mainly in the Domain Controllers):

  1. SeEnableDelegationPrivilege

  2. SeBackupPrivilege

  3. SeRestorePrivilege

  4. SeTakeOwnershipPrivilege

  5. SeDebugPrivilege

  6. SeImpersonatePrivilege

check the token-priv repository of FoxGlove that includes a paper describing them and PoCs to exploit them, highly recommended resource.

Additional resources