Active Directory Access Control List (ACL)

What Active Directory ACLs control

An Active Directory ACL is the object-level permission set that determines who can read, modify, delete, or take ownership of a directory object. Because ACLs sit on the object itself, they are the directory’s fine-grained authorization layer, not just a generic “can log in” setting.

In practice, an ACL is only meaningful when read alongside the object’s security descriptor, inheritance rules, and the Access Control Entries that grant or deny specific rights. That is why the same user, group, service account, or computer can have different effective access depending on the object, the parent container, and the exact rights assigned.

How ACEs and inheritance shape effective access

Each ACL is made up of Access Control Entries, or ACEs, that express the subject, the permission, and whether the permission is allowed or denied. In Active Directory, that structure is what turns abstract authorization into something the directory service can evaluate during an access check.

Inheritance matters because many directory objects receive permissions from their parent container unless an administrator blocks or overrides them. That design reduces manual work, but it also means a single broad ACE can spread across many objects and create access that is wider than intended.

Effective access is therefore not just the sum of visible entries. Deny rules, inherited entries, object-specific permissions, and ownership rights can all change the final decision. When ACLs are complex, operators need to think in terms of the resulting authorization decision, not just the raw list of entries.

Why Active Directory ACLs are security-sensitive

Active Directory ACLs are security-sensitive because they govern who can alter identities, groups, delegation paths, and other high-value directory objects. If an attacker or overprivileged account can change ACLs, they may be able to grant themselves lasting control, hide permissions, or redirect administration paths.

Misconfigured ACLs often become an escalation path rather than a simple administration mistake. A permissive write right on a group, OU, or privileged user object can be enough to change membership, delegate control, or shape downstream access in ways that are hard to notice in a large environment.

For that reason, ACL review belongs in the same defensive conversation as privileged access hardening and directory tiering. NHIMG’s Active Directory and Entra ID Hardening Guide and Access Control Policy Template both frame ACLs as part of broader least-privilege governance, while the CIS Controls v8 reinforce access control as an operational safeguard.

Common ACL failure modes and review priorities

ACL problems usually show up as excess privilege, inherited rights that were never revisited, ownership changes that were not intended, or delegation that quietly expanded over time. In environments with many administrators, service accounts, and nested groups, these failures are easy to accumulate and hard to spot without structured review.

Review should focus on objects that can change security posture across the directory, especially privileged users, privileged groups, organizational units, and objects tied to authentication or delegation. Effective review asks whether each permission is still needed, whether inheritance is safe, and whether an entry creates a path to broader control than the owner expects.

This is also where detection matters. Changes to ACLs, especially on sensitive objects, should be treated as high-value events because they often precede persistence or privilege escalation. Access review, configuration drift monitoring, and administrative change logging all help expose suspicious permission changes before they become durable access.

Risk and Threat Considerations

Active Directory ACLs are attractive to attackers because they can turn one weak permission into durable directory control. A single excessive ACE can enable privilege escalation, group manipulation, or persistent access even when passwords and sessions are otherwise protected.

Failure mechanism: Attackers or insiders abuse write, modify, or ownership rights on directory objects to add privileged members, change delegation, or preserve access through permission changes that look like normal administration.

Impact: The result can be broad identity compromise, lateral movement, and loss of trust in directory authorization decisions, especially when sensitive groups or administrative objects are affected.

Practitioner Guidance

What to watch for: Treat ACL changes on privileged objects as a governance event, not routine housekeeping. The most important question is whether the permission pattern still matches the object’s current business and administration model, especially after reorganisations, migrations, or third-party access changes.

Governance implication: Ownership of ACL review should be explicit, because “who can change permissions” is often separate from “who can use the object.” Keep review criteria focused on effective access, inheritance, and object ownership rather than on the visible ACL alone.

Practitioner takeaway: The safest ACLs are the ones that are both narrowly granted and periodically revalidated against the directory’s real administrative paths.

Related resources from NHI Mgmt Group

• Guide: NHI Lifecycle Management Guide
• Access Control List
• Which compliance frameworks require organisations to treat Active Directory security as part of broader access control and monitoring obligations?
• What breaks when MFA is the only control protecting Active Directory access?
• What breaks when role-based access control mistakes are not remediated quickly in Active Directory?