FFoundationalActiveDirectory
Access control lists define who can do what to every object in Active Directory. This lesson explains what ACLs are, how they control permissions on AD objects, why they matter for delegated administration and attack surface, and how to explain them clearly in interviews.
An access control list in Active Directory is a set of rules attached to an object that defines which security principals (users, groups, computers) are allowed or denied specific actions on that object. Every AD object — every user account, computer account, group, organizational unit, and GPO — has a security descriptor that contains two ACLs: a DACL that controls access permissions and a SACL that controls auditing. The DACL is the one that determines who can do what.
It is made up of individual Access Control Entries (ACEs), each of which grants or denies a specific permission to a specific principal. When a user attempts an operation on an object, the system evaluates the DACL to determine whether the operation is permitted.
Think of every AD object as a room with a door that has a detailed access list posted on it. The list says who can enter, who can rearrange the furniture, who can change the lock, and who can modify the list itself. The DACL is that posted list. Each line on the list is an ACE — one rule that says 'this person can do this specific thing.'
Some permissions are straightforward: read the object, write to a specific attribute. Others are powerful and subtle: GenericAll grants full control, WriteDACL allows rewriting the access list itself, and WriteOwner allows taking ownership, which effectively grants full control through an extra step.
The critical insight is that these permissions are not just administrative conveniences — they are the mechanism by which delegated control works in AD, and every delegation creates a potential path that an attacker can follow.
Microsoft · Official Microsoft reference for access control lists, DACLs, SACLs, and ACE types in Active Directory
Microsoft · Microsoft Win32 reference for ACL structure and ACE ordering — complements the AD-specific view with the underlying Windows security model
Microsoft · Microsoft reference for security principals — the identities that ACEs grant or deny permissions to
Every object in Active Directory has an ACL that determines who can read it, modify it, reset its password, change its group memberships, or take ownership of it.
If you cannot explain how AD permissions work, you cannot explain why ACL misconfigurations are among the most common and impactful findings in AD assessments. ACL-based attack paths are frequently discovered by tools like BloodHound, and interviewers expect candidates to understand the permission model that makes those paths possible, not just the tool output.
In real assessments, ACL misconfigurations are among the most frequently discovered privilege escalation paths. BloodHound identifies these by mapping ACEs across the entire directory: it finds the helpdesk group that has GenericAll on a service account that is a member of Domain Admins, or the IT-Ops group that has WriteDACL on the domain object. These paths exist because administrators delegate control for legitimate operational reasons, but rarely audit the cumulative effect of those delegations.
When you report an ACL-based finding, you need to explain not just that the permission exists, but why it creates a path — connecting the delegated permission to the specific escalation it enables. Clients understand 'this group can reset this admin's password' much better than 'GenericAll on CN=svc_admin.'
Access control lists in Active Directory define who can perform which operations on every object in the directory — users, groups, computers, OUs, GPOs, and the domain itself. Each object has a DACL made up of individual ACEs, where each ACE grants or denies a specific permission to a specific principal. The permissions that matter most for security are the ones that grant control over objects: GenericAll gives full control, WriteDACL allows rewriting the permission list, WriteOwner allows taking ownership (which leads to DACL control), and ForceChangePassword allows resetting a user's password.
These permissions exist because AD uses them for delegated administration — helpdesk teams resetting passwords, application teams managing service accounts. But those delegations create paths that an attacker can follow.If a compromised account has WriteDACL on a privileged group, the attacker can grant themselves membership. Understanding the permission model is what makes BloodHound output meaningful rather than just a graph of colored lines.