An Access Control Entry (ACE) is a single rule within an access control list that allows, denies, or audits a specific type of access for a specific user, group, or security principal.
What Is an Access Control Entry?
An Access Control Entry is the smallest unit of permission in many operating systems and directory services. Each ACE says one thing: this principal is allowed, denied, or audited for these actions on this object.
ACEs are grouped into an access control list (ACL) attached to a file, folder, registry key, service, or directory object. Together, the entries define who can read, change, delete, or take ownership of that object.
The term is most closely tied to Microsoft Windows and Active Directory, but similar entries exist in NFSv4, macOS, and many storage platforms. Cloud IAM systems use different policy formats, though they follow the same idea of pairing an identity with permitted actions.
What Does an ACE Contain?
According to Microsoft’s access control entries documentation, a Windows ACE typically includes:
- Security identifier (SID): The user, group, or computer the entry applies to
- ACE type: Whether the entry allows, denies, or audits access
- Access mask: The specific rights covered, such as read, write, delete, or change permissions
- Inheritance flags: Whether child objects, such as files in a folder, receive the entry
- Object type: For directory objects, the specific attribute, property set, or extended right the entry controls
What Are the Types of ACEs?
- Access allowed: Grants the listed rights to the principal
- Access denied: Explicitly blocks the listed rights
- System audit: Generates a log event when the principal attempts the listed access
- Object specific ACEs: Used in Active Directory to control access to particular attributes or extended rights rather than the whole object
Allow and deny ACEs live in the discretionary access control list (DACL). Audit ACEs live in the system access control list (SACL), which security teams use to record sensitive access.
How Are ACEs Evaluated?
When a process requests access to an object, the system compares the requester’s access token, including its user and group SIDs, with the ACEs in the object’s DACL.
- The system reads the ACEs in order.
- If an ACE denies any requested right to a SID in the token, access is denied.
- If the allow ACEs together grant every requested right, access is granted.
- If the system reaches the end of the list without granting every right, access is denied.
Order matters. Windows places explicit deny entries before explicit allow entries, followed by inherited entries, as described in Microsoft’s guidance on the order of ACEs in a DACL.
Two edge cases surprise many teams. An object with no DACL grants everyone full access, while an object with an empty DACL grants no access to anyone.
Why Do ACEs Matter for Security?
Every permission problem on a file share or directory object comes down to individual ACEs. Small entries can carry large consequences.
- Privilege escalation: An ACE granting GenericAll, WriteDacl, or WriteOwner on a privileged group or account can let an attacker take control of it.
- DCSync abuse: ACEs granting directory replication rights on the domain object let attackers request password hashes for any account. MITRE ATT&CK tracks this as OS Credential Dumping: DCSync.
- Attack path mapping: Tools such as BloodHound chain ACEs together to find indirect routes from an ordinary user to domain administrator.
- Persistence: Attackers sometimes add a quiet ACE to a privileged object so they can regain access after a cleanup.
- Data exposure: Broad entries such as Everyone or Authenticated Users with read access expose sensitive file shares.
- Permission sprawl: ACEs granted to individual users rather than groups become hard to review and rarely get removed.
How Can Organizations Manage ACEs Safely?
Begin with visibility into who holds rights over your most sensitive objects: privileged groups, the domain root, and critical file shares.
Organizations should then:
- Grant access to groups, not individual users, so access can be reviewed by role.
- Apply least privilege and remove broad entries for Everyone, Domain Users, and Authenticated Users on sensitive data.
- Use deny ACEs sparingly, since they complicate troubleshooting and often signal a design problem.
- Audit ACEs on privileged Active Directory objects, including AdminSDHolder and the domain root.
- Enable SACL auditing for sensitive files and directory changes, and forward events to your SIEM.
- Alert on changes to the DACLs of privileged groups and on any new replication rights.
- Run regular attack path analysis to find dangerous ACE chains before attackers do.
- Include file share and directory permissions in access certification campaigns.
Sennovate’s Identity and Access Management services help organizations review and clean up Active Directory permissions, connect entitlements to identity governance, and monitor changes to privileged objects.
ACE vs. ACL
| Aspect | ACE | ACL |
| What it is | A single permission rule | An ordered list of ACEs |
| Scope | One principal and one set of rights | Every principal with access to an object |
| Where it lives | Inside an ACL | In the object’s security descriptor |
| Example | Finance group can modify the Budget folder | All the rules that control access to the Budget folder |
An ACL without its entries is empty, and an ACE outside an ACL does nothing. Reviewing access means reading both: the list tells you where to look, and each entry tells you what it actually grants.
Frequently Asked Questions About ACEs
What Is the Difference Between an ACE and a Permission?
A permission is the right itself, such as read or write. An ACE is the record that assigns that right to a specific principal on a specific object.
Does a Deny ACE Always Win?
Not always. In a correctly ordered DACL, explicit deny entries override explicit allow entries for the same rights. However, an explicit allow can override an inherited deny, because explicit entries are evaluated first.
Are ACEs Used in Cloud Environments?
Cloud file services that support Windows or NFSv4 permissions use ACEs. Most cloud IAM platforms use JSON policies or role bindings instead, but the idea of pairing an identity with permitted actions is the same.
How Do Attackers Find Weak ACEs?
They enumerate directory permissions with standard LDAP queries or tools such as BloodHound. Then they look for entries that let a compromised account modify a more privileged one.
Treat Permissions as Part of Identity Security
Access control entries decide what every identity can actually do once it is inside the network. A single misplaced entry can turn an ordinary account into a path to domain control.
A mature program grants access through groups, keeps entries minimal, audits changes to privileged objects, and reviews permissions as part of identity governance.
Learn how Sennovate approaches identity first security and Zero Trust across users, workloads, and privileged accounts.
