Allow, deny, and inheritance: Understanding the effective access decision

1. Core mechanism

This lesson covers how the access decision is generated: requested access mask, sequential evaluation of ACEs, allow/deny interaction, and inheritance. 05.02 introduced access check's presence/absence decision (Is there a DACL, is there a right); 05.03 taught me how to read a descriptor. The focus here is on how the outcome is determined by order and inheritance when multiple ACEs occur together. The NULL and empty DACL edge cases also become clear here. The source of the access check algorithm is How AccessCheck Works; The ACE ranking is the Order of ACEs in a DACL document; Neither of them are interpreted, they are taught as they are.

Interfaces and specifications

• Requested access mask: the set of rights requested by the access request (e.g. FILE_READ_DATA + FILE_WRITE_DATA); access check is executed according to this mask.
• Remaining rights: those of the requested rights that have not yet been met with the allow ACE; It decreases as the evaluation progresses, access is granted when it reaches zero.
• Sequential assessment: ACEs in the DACL are examined in the order they appear; The decision becomes final in the first decisive match (sufficient allow is collected or a requested right is denied).
• Canonical order: preferred order — explicit ACEs before inherited ones; access-denied ACEs before access-allowed ones in each group.
• Inheritance: an ACE can be explicit (defined directly on the object) or inherited (coming from the parent object, ID flagged); Inherited ACEs come after explicit ones in canonical order.
• NULL DACL: No DACL (SDDL: NO_ACCESS_CONTROL); It means full access to everyone.
• Empty DACL: the DACL exists but has zero ACEs (SDDL: D:); it grants no requested rights through allow ACEs. In AD DS, the current owner may separately receive READ_CONTROL and WRITE_DAC; SE_TAKE_OWNERSHIP_PRIVILEGE may imply WRITE_OWNER.

Access decision is an accumulation

Access check treats the requested access mask as a list of requests, not as a single right. If the object does not have a DACL (NULL DACL), access is granted directly. If a DACL exists, the system examines ACEs in the order they appear and accumulates the requested rights: each access-allowed ACE marks some of the requested rights for the trustee it matches as 'met'.

The decision becomes final in one of two ways. If an access-denied ACE arrives for a trustee that matches a requested right that is still unremaining, access is denied at that point. If the assessment has collected enough permissions to cover all requested rights, access is granted. If the list ends without either, access is implicitly denied because no permissions are found for the remaining requested rights. Critical point: the decision stops on the first decisive match, so the order of the ACEs can determine the outcome.

Same ACEs, different order, different result

Consider two ACEs: one access-denied (write) and one access-allowed (full) to the same group. In canonical order, deny is written before allow: in a write request, the system sees deny first, matches the requested write right, and denies access. This is the mechanical equivalent of the 'explicit deny beats explicit allow' intuition — but this intuition only holds when the canonical order is preserved.

If the same two ACEs are stored in non-canonical order (allow before, deny after), the result changes: in the write request, the system sees the allow (full) ACE first, satisfies all rights, including the requested write, and grants access — the deny ACE is never reached. Windows' graphical interface always writes DACLs in canonical order, but descriptors can be made non-canonical via API or manually; This produces a silent and dangerous difference in behavior because access check operates in the stored order.

Explicit surpasses inherited

Inheritance is the second dimension of canonical order. In preferred order, explicit ACEs (defined directly on the object) always come before inherited ACEs (coming from the parent object, ID flagged). This has a very practical result: when an object has an explicit allow, an inherited deny from the parent folder is evaluated after this allow.

Therefore, explicit allow can satisfy the requested right and grant access before inherited deny is reached — that is, explicit allow exceeds inherited deny. This is the second exception to the 'deny always wins' simplification: the rule is that deny does not put allow, but the canonical order puts explicit before inherited. It is the explicit/inherited position and order of the ACE as well as its allow/deny type that determines the outcome.

No DACL and an empty DACL are opposites

The two extreme cases are often confused. NULL DACL means the object has no DACL; In this case, access check finds no record that would restrict access and gives full access to everyone. In SDDL this is indicated by D:NO_ACCESS_CONTROL and the parser marks this with a separate warning.

Empty DACL means that the object has a DACL but has zero ACEs in it. It provides no allow ACE for requested rights and its ACE-based check implicitly denies them. In AD DS, the current owner has separate implied rights such as READ_CONTROL and WRITE_DAC; SE_TAKE_OWNERSHIP_PRIVILEGE may imply WRITE_OWNER. Therefore, an empty DACL should not be generalized as “nobody can obtain any access” without context. In SDDL it is written as D: (without ACE), and its meaning is opposite to a NULL DACL.

State and data flow

1. The request arrives: the caller requests a handle with a requested access mask (e.g. a request containing write). Remaining rights = all requested rights.
2. NULL DACL fixture (D:NO_ACCESS_CONTROL): No DACL → full access is granted without evaluation; remaining is meaningless.
3. Canonical fixture ((D;;FW)(A;;FA), RID 2902): sequence deny→allow; In the write request, the first ACE matches deny FW remaining write → access is denied; allow cannot be reached.
4. Non-canonical fixture ((A;;FA)(D;;FW), RID 2902): sequence allow→deny; In the write request, the first ACE allow FA covers all remaining → access is granted; deny cannot be reached. Same set of ACEs, opposite result.
5. Inheritance fixture ((A;;FA)(D;ID;FW), RID 2902): explicit allow FA inherited deny before FW; write remaining is met with explicit allow → access is granted; inherited deny is passed.
6. Empty DACL fixture (D:): DACL exists, 0 ACE; no allow through the DACL → requested rights are implicitly denied by the ACE-based check. AD DS owner/privilege-implied rights may apply separately.

2. Exploitation

Broken trust assumption

Broken assumption: Putting an access-denied ACE for a user in a DACL definitely prevents that user from getting that right. In reality, the result depends on the order of the ACEs and their explicit/inherited position: If the DACL is written in non-canonical order (before allow, deny), access check first sees the allow ACE that meets the requested right and grants access, and never reaches the deny ACE; Similarly, explicit allow overrides inherited deny.

Technical prerequisites

• The DACL of the target object can be stored in non-canonical order (access-allowed ACE before the access-denied ACE of the same right); This is possible via non-GUI API or manual editing.
• Permission inspection does not look for the existence of ACEs and check their order ('deny exists, so it is blocked' assumption).
• A broad allow ACE (e.g. FullControl) also extends to narrow desired rights, so subsequent denials are ineffective.
• Relying on Inherited Denies and ignoring explicit Allows; Not knowing that explicit is evaluated before inherited.

Exploitation mechanism

Access check evaluates ACEs in the order stored and stops at the first decisive match (How AccessCheck Works). This is exactly why canonical order (Order of ACEs in a DACL) exists: It puts access-denied ACEs before access-allowed ones and explicit ACEs before inherited ones, ensuring that denials and explicit restrictions are seen first. If a DACL is queued non-canonically—for example, if a broad allow ACE for a user is written before the deny ACE that is supposed to restrict it—the write request is satisfied in the first ACE and the deny ACE is never reached; the result is that access is granted despite the current deny. The same logic works in inheritance: explicit allow wins because explicit allow comes before inherited deny. Scope is which objects' DACL is non-canonical or larger than expected; Blocking control is keeping DACLs in canonical order and least-privilege, narrowing large allow ACEs, and monitoring descriptor changes (4670).

Deny's presence is not enough

A permissions review may be mistaken if it results in 'there is a deny ACE for this user, so it is blocked'. The access check decision depends on which ACE matches first based on the requested right, not on the existence of the ACE. When a allow ACE precedes deny in a non-canonical sequence, it satisfies the requested right and deny is not evaluated at all.

So the review must check two things: Is the order of ACEs canonical (denies and explicits first) and whether allow ACEs grant wider permission than expected. The NewSd/OldSd difference (4670) can make it visible whether a descriptor has been made non-canonical, but sequence analysis is done outside the event on the SDDL.

3. Defense & Detection

Telemetry scope

• For a network share request, 5145 separates requested rights (AccessMask/AccessList) from the share access-check result (AccessReason and relevant ACE). These fields do not contain the complete DACL or prove an NTFS grant.
• According to the 5145 documentation, the Failure event is only generated when access is denied at the file-share level; Access denied at the NTFS level does not produce 5145 Failure. This indicates that share and NTFS layer are considered separately.
• When the content or order of a DACL is changed (e.g. a allow ACE is moved ahead of deny) this is recorded with the OldSd/NewSd offset as 4670 (Permissions on an object were changed); The transition to non-canonical order is brought to the surface by comparing these two SDDLs.
• The 4670 production depends on the Change Permissions audit ACEs in the SACL of the object and the relevant audit subcategory; If this scope is not present, the descriptor change will remain silent and the sequence corruption will not be visible from the event.

Events and relevant fields

• 5145: AccessMask and AccessList describe requested rights. AccessReason describes each requested right’s share-level grant/deny result and the relevant ACE. Requested rights alone do not prove a grant, anomaly or non-canonical DACL.
• 5145 Connects which session is accessing which resource on which share with SubjectLogonId, ShareName, and RelativeTargetName; The difference between requested vs granted is evaluated in this context.
• 4670: Comparing the OldSd and NewSd SDDLs determines whether a DACL has been queued non-canonically or a large allow ACE has been added; Sequence analysis is done off-event.
• An absent event means neither “no change” nor “access granted.” 5145 covers the share check. File/registry permission-change event 4670 requires the relevant audit policy and matching SACL audit ACE; it is not generated for a change to the SACL itself. Examine NTFS denials and the AD object audit path separately.

Compare what is requested with what is given

Separate the request from the result in 5145: AccessMask and AccessList describe requested rights; AccessReason describes the share-level grant/deny result and relevant ACE rationale. They are neither a complete DACL nor an NTFS access decision. Examine the actual descriptor for ACE ordering, and compare relevant 4670 OldSd/NewSd records for changes.

The second layer is to monitor the descriptor itself, which is the input to the decision. 4670's OldSd→NewSd difference may indicate when a DACL has been made non-canonical or a large ACE has been added; However, both of these events are scope limited (5145 share only, 4670 SACL scope only) and their absence does not mean 'no problem'.

Detection logic · KQL

// Inventory / triage: all collected 5145 events, not an anomaly detector
SecurityEvent
| where EventID == 5145
| project TimeGenerated, Computer, SubjectLogonId, ShareName, RelativeTargetName, AccessMask, EventData

Query assumptions

• This is broad 5145 inventory/triage. Ordinary access records are expected; it does not select suspicious grants or non-canonical descriptors.
• SecurityEvent documents the projected columns. AccessList and AccessReason are raw 5145 XML fields, not documented top-level columns of this table; inspect retained EventData or an explicitly validated ingestion mapping. Missing mapping is not a denial or an empty-rights result.
• AccessMask and AccessList represent the request; AccessReason describes share access-check results. An AccessMask being present does not distinguish normal access from an anomaly.
• 5145 Failure concerns share-level denial; NTFS-level denial does not produce a 5145 Failure. For descriptor order, inspect the actual descriptor and relevant change evidence separately.
• No SIEM execution, dataset, time window or measured detection quality is claimed. Narrowing requires a validated share/path, principal, expected-rights and result baseline.

False positives

• Legitimate broad authorizations (administrator access, application service accounts) routinely request broad AccessMasks; A single incident does not indicate malicious intent.
• Share-based backup/scan tools produce a large number of 5145s and should be reserved as benign baseline.
• AccessReason codes may vary depending on environment and language pack; Rules based on raw code mapping may produce false positives/negatives.
• The absence of the event is not security: NTFS-level rejection or out-of-SACL descriptor change do not appear in these events.

Hardening

• Keep DACLs in canonical order (denies and explicit ACEs first) and least-privilege; Periodically scan and fix descriptors that are non-canonical or contain larger than expected allow ACEs.
• Prevent subsequent deny and inherited constraints from being ineffective by collapsing broad allow ACEs (e.g. unnecessary FullControl); Set inheritance consciously, avoid unnecessary protected (P) DACLs.
• Configure the SACL of high value objects to capture descriptor changes and mark transitions to non-canonical order by following the 4670 OldSd/NewSd offset; Monitor share access decisions with 5145.
• Inventory NULL DACL (full access to everyone) and unwanted empty DACL states; Before implementing controls, measure audit volume and business impact in a pilot context and maintain a return plan.

Read the examples

O:BAG:BUD:(D;;FW;;;S-1-5-21-1002233445-2244556677-3366778899-2902)(A;;FA;;;S-1-5-21-1002233445-2244556677-3366778899-2902)

O:BAG:BUD:(A;;FA;;;S-1-5-21-1002233445-2244556677-3366778899-2902)(D;;FW;;;S-1-5-21-1002233445-2244556677-3366778899-2902)

O:BAG:BUD:AI(A;;FA;;;S-1-5-21-1002233445-2244556677-3366778899-2902)(D;ID;FW;;;S-1-5-21-1002233445-2244556677-3366778899-2902)

O:BAG:BUD:NO_ACCESS_CONTROL

O:BAG:BUD:

Two reality checks

Assumption: If a user has both allow and deny ACEs, deny always wins.

In fact: Access check evaluates ACEs in the order stored and stops at the first deterministic match; The result depends on the order. 'Deny wins' is only true when the canonical order is preserved (access-denied ACEs before access-allowed ones). If the DACL is placed in a non-canonical queue and the allow ACE is written before deny, the allow that meets the requested right is seen first and access is granted without reaching deny. Additionally, since explicit ACEs come before inherited ones in canonical order, explicit allow surpasses inherited deny.

Assumption: If an object's DACL is empty (no permissions defined), anyone can access it.

In fact: NULL DACL and empty DACL are opposites. NULL DACL (object has no DACL; SDDL: D:NO_ACCESS_CONTROL) gives full access to everyone. Empty DACL (there is a DACL but 0 ACE; SDDL: only D:) contains no allow ACE and its ACE-based check implicitly denies the requested rights. In AD DS, some owner- or privilege-implied rights may apply separately. The phrase 'empty DACL' confuses the two; The access result is diametrically opposed.

Sources

• Microsoft · How AccessCheck Works (How DACLs Control Access to an Object)
  NULL DACL -> full access; when a DACL exists, ACEs are evaluated in order; a matching access-denied ACE denies, sufficient access-allowed ACEs grant, otherwise implicit deny applies; the decision stops at the first decisive match
• Microsoft · Order of ACEs in a DACL
  Preferred (canonical) order: explicit ACEs before inherited ACEs; within each group, access-denied ACEs before access-allowed ACEs; inherited ACEs follow inheritance order
• Microsoft · Null DACLs and Empty DACLs
  A NULL DACL grants full access; an empty DACL (0 ACEs) provides no ACE-granted access. In AD DS, the owner/privilege-implied rights listed below may apply separately.
• Microsoft · ACE strings
  SDDL ACE syntax; A/D ACE types, FA/FW/FR rights abbreviations, ID (INHERITED_ACE) flag, and NO_ACCESS_CONTROL notation
• Microsoft · Access Rights and Access Masks
  Requested access mask; collecting generic and standard rights in the request mask, and running the access check against that mask
• Microsoft · 4670(S) Permissions on an object were changed
  OldSd/NewSd (SDDL) fields; comparing DACL/owner changes; not generated for SACL changes
• Microsoft · 5145(S, F) A network share object was checked
  Requested rights: AccessMask/AccessList; access-check results: AccessReason; share-only Failure scope
• Microsoft · [MS-ADTS] Null vs. Empty DACLs
  §5.1.3.3.1: empty DACL has no ACE-granted access; current owner implied READ_CONTROL/WRITE_DAC; SE_TAKE_OWNERSHIP_PRIVILEGE implies WRITE_OWNER; BlockOwnerImplicitRights caveat.
• Microsoft · SecurityEvent table columns
  AccessMask, EventData, EventID, Computer, SubjectLogonId, ShareName, RelativeTargetName; raw XML versus ingestion schema