Windows Advanced Audit Policy and SACL Design for Useful File Evidence

Windows advanced audit policy and a file or registry object’s System Access Control List (SACL) are separate controls that must be designed together. Enabling the Audit File System subcategory does not automatically produce events for every file. Windows generates file-system auditing events only when the requested access, account, and outcome match an applicable SACL on the object. Conversely, a broad SACL without an effective audit policy can create noise or fail to deliver the evidence an investigator expects.

The operational goal is not maximum event volume. It is a defined evidence question, a controlled set of audited objects and rights, collection and retention capacity, and a process to review and act on the records. This matters especially for sensitive shares, domain controllers, application data, and servers with high file churn. A poorly scoped audit configuration can fill Security logs, overwhelm a SIEM, create privacy concerns, or give responders false confidence because the desired object was never audited.

Separate policy, SACL, and collection

Advanced Audit Policy Configuration controls which categories and subcategories can generate audit events and whether successful or failed operations are recorded. A SACL on an individual securable object specifies which users or groups and which access rights are audited. The Security log stores generated events locally; Windows Event Forwarding or another collector can move them to a central repository. The SIEM or operational process then parses, correlates, alerts, and retains the events. These are distinct stages, each with its own configuration and failure modes.

For file-system access, policy alone is not enough. The SACL must include the relevant principal and rights on the target object or inherited from a parent. An event can be generated for success, failure, or both depending on the policy and SACL ACE. Object Access auditing can include access, deletion, permission change, and hard-link-related evidence, but event IDs differ by operation. Event 4663 is a success event: it records that a specific access right was used when it matches an applicable SACL; it is not a general “file was read” event for every path and it has no failure variant. For failed handle requests, evaluate event 4656(F) with the matching SACL and audit policy. Event 4660 is associated with object deletion, while event 4670 concerns permissions changes. Review Microsoft’s event reference before building detections.

The following snippet captures the current audit policy and selected file ACL details for a path. It is read-only, but retrieving audit ACLs may require privileges and should be run against a controlled sample:

$path = 'D:\SensitiveData'

auditpol.exe /get /category:*

$acl = Get-Acl -LiteralPath $path -Audit
$auditRules = $acl.GetAuditRules(
    $true,
    $true,
    [System.Security.Principal.NTAccount]
)
[pscustomobject]@{
    Path = $path
    Owner = $acl.Owner
    Sddl = $acl.Sddl
    AuditRules = @($auditRules | ForEach-Object {
        [pscustomobject]@{
            Identity = $_.IdentityReference.Value
            Rights = $_.FileSystemRights
            AuditFlags = $_.AuditFlags
            Inherited = $_.IsInherited
        }
    })
}

The SDDL output can contain security-sensitive identity data; protect it as configuration evidence. Get-Acl -Audit must be run with rights to read the SACL, and some remote or provider contexts may return less detail. The query shows the effective ACL on one path, not every child object’s inheritance state. Enumerate the actual target set and review inheritance boundaries before assuming the parent SACL covers all relevant files.

Define the investigative use case first

Write down the question the audit is intended to answer. Examples include: Which principals attempted to modify a protected configuration directory? Did a specific service account read a credential file? Who changed permissions on a critical folder? Was a failed access attempt observed before an application error? Define the object scope, identities, operations, success/failure requirements, evidence owner, expected event rate, retention period, and escalation path.

Map that question to the smallest relevant set of subcategories and SACL entries. For a protected folder, audit only the rights and principals needed to answer the question. Avoid auditing every read and write by Everyone across an entire volume. Use groups and inheritance intentionally, but watch for explicit child SACLs that block or alter inheritance. Exclude routine high-volume principals only after validating the security implications and documenting the rationale.

Estimate event volume with a representative pilot. Success auditing for broad read rights on a busy file server can generate very large volumes. Failure auditing can also be noisy when applications repeatedly probe denied paths. Measure records per second and average event size, then plan local log size, overwrite behavior, forwarding throughput, SIEM ingestion, retention, and query cost. Increasing the Security log capacity may be necessary, but it does not replace central collection or alerting on log clearing and forwarding gaps.

Inspect effective policy and precedence

Use auditpol /get /category:* to query current effective audit settings and gpresult or Resultant Set of Policy to determine which Group Policy object supplies them. Advanced audit policy can interact with legacy audit policy configuration; enable the policy option that forces subcategory settings to override category settings where Microsoft’s current guidance and the organization’s baseline require it. Test policy refresh and reboot behavior on representative systems before broad rollout.

The following commands preserve an audit policy backup for change recovery and query the relevant result. The backup file contains security configuration and should be protected with the same care as other host baselines:

$backup = 'C:\SecureChange\audit-policy-before.csv'
New-Item -ItemType Directory -Path (Split-Path $backup) `
    -ErrorAction Stop | Out-Null

auditpol.exe /backup /file:$backup
auditpol.exe /get /subcategory:'File System'
gpresult.exe /scope computer /h C:\SecureChange\computer-policy.html

Validate the exact localized name of the subcategory on non-English systems or use the supported GUID syntax where appropriate. Review the return codes and verify that the files exist and contain the expected settings. The snippet writes a backup and report but does not change policy. Do not restore an old local audit policy blindly on a domain-managed system; Group Policy may overwrite it or reintroduce settings that conflict with the current baseline.

For centrally managed servers, define audit settings in a controlled GPO linked to the intended OU and confirm security filtering and inheritance. Avoid editing Default Domain Controllers Policy for a one-server experiment. Record which GPO controls the subcategory, which team owns the SACL, and how the configuration is deployed to newly provisioned servers. If local policy is deliberately used, document why it does not conflict with domain policy and monitor drift.

Configure SACLs narrowly and verify inheritance

Select the exact directory or file, principals, and access mask required by the use case. A SACL ACE includes an identity, audited rights, success/failure flags, and inheritance behavior. A folder-level ACE can propagate to child files and subfolders, but inheritance may be blocked, overridden, or modified. Test a sample folder and a representative child before applying the rule to a production tree. If the object contains millions of files, changing inherited SACLs can be expensive and should be planned and monitored.

Do not paste a generic audit ACL without understanding its rights. For example, “Write” can map to several specific file-system rights, and a detection for permission changes may need different rights than one for data modification. Include the minimum necessary audit flags. Document whether inherited rules should apply to child files, subfolders, or both. Review existing SACLs first to avoid duplicate entries and unexpected coverage.

After applying a change through the approved security descriptor tool or script, inspect the ACL and trigger a controlled test operation with a dedicated account. Test a successful access and, if failure auditing is intended, a denied operation that does not risk production data. Confirm that the event appears on the source host, has the expected subject, object name, process, access mask, and outcome, and reaches the central collector. Avoid using a privileged administrator account for the test if the production question concerns standard user or service access.

Interpret events and build useful alerts

Event 4663’s access mask and process information need context. A process may access a file as part of normal scanning, indexing, backup, or antivirus activity. Correlate the event with logon events, process creation telemetry, file server auditing, application transactions, and the object’s expected owner. Do not infer data exfiltration from one successful read. Preserve original XML when parsers omit fields and record the source computer and collection timestamp.

Failure events may reveal probing, a broken application permission, or a stale service identity. Use a threshold and context appropriate to the server role. A single access denied on a protected path can be normal; a burst across many sensitive objects from an unexpected identity may warrant escalation. Ensure the alert explains the audited object, principal, rights, outcome, and owner so responders can triage without repeating data collection.

Monitor Security log clear events, log wrap/overwrite, forwarding subscription health, collector backlog, and retention. A quiet SIEM dashboard can mean no suspicious activity, no applicable SACL, a stopped collector, a policy override, or a log that wrapped before forwarding. Validate collection with synthetic events on a regular schedule and alert when the expected canary record is missing.

Deployment and retirement workflow

Pilot the policy and SACL on a representative server with a documented rollback. Record baseline event volume, test expected events, confirm forwarding and alert behavior, and obtain owner approval. Roll out by workload cohort rather than linking one broad policy everywhere. Watch for application latency, log growth, collector load, and support issues. Use a change freeze or a narrow rollback if the logging volume exceeds the tested threshold.

When a use case ends, remove its SACL entries and policy settings through the same managed source. Leaving obsolete auditing in place creates noise and can expose sensitive operational metadata. Before removing, verify whether another use case depends on the same ACE. Keep the final policy backup, ACL evidence, test records, approved exclusions, and retention plan with the system’s security documentation.

Acceptance requires a defined detection question, effective advanced audit policy, intended SACL coverage, proven event generation, functioning forwarding, sufficient log capacity and retention, a named review owner, and a tested rollback. Re-evaluate after application changes, file-server migrations, Group Policy redesign, identity changes, or SIEM pipeline updates.

Related:

Sources: