What Is Windows File Access Audit Proof?
Windows file access audit proof connects a server's effective audit policy, a file's auditing rules, and a controlled access attempt to the resulting Security events. A Group Policy setting alone cannot establish that connection. Before changing production policy, use dummy files to determine which identities and file rights actually produce evidence on a server within the agreed scope.
This guide separates three questions: is Audit File System enabled on that server, does the file have a matching system access control list (SACL), and does the recorded event describe the operation you tested? Keep the answers together in a review record. A reassuring policy value with no corresponding event leaves the proof incomplete.
The procedure below has not been executed against a live domain. Commands use documented Microsoft syntax; paths and identities are examples to replace with approved test values. Expected observations are acceptance criteria, not reported laboratory results.
How File Auditing Works: Policy, SACL, and Access
Microsoft's Audit File System documentation makes auditing conditional on a matching SACL: the requesting account and requested access must match its entries. Success and failure auditing serve different outcomes. Enabling the subcategory without suitable object auditing rules does not establish file-level coverage. Microsoft also advises planning how the collected events will be analyzed and removing excessive auditing rules.
The file's permissions and auditing rules have separate jobs. Review the discretionary access control list (DACL) to establish the intended allowed or refused access, then review the SACL to establish which attempts should be recorded. Adding an auditing rule is not a reason to grant an otherwise unauthorized file right.
Choose the proof scope before testing. Which servers and file rights must be demonstrated? Identify the host, synthetic path, test identity, application and operation. A local read on one member server supports that specific case; it does not establish coverage for every server or application. Keep directory-object monitoring distinct: our AD monitoring guide to event collection, field mapping and validation explains the broader identity monitoring pipeline, including directory events. Here the object under test is a dummy file.
A handle request is not a used file right
| Event | What it establishes | Limit when reviewing a test |
|---|---|---|
| 4656 | A handle was requested, with success or failure information | A successful request does not prove the requested operation occurred |
| 4663 | An access right was used on the object | It has no Failure variant; do not use it as proof of a refused request |
These distinctions come from Microsoft's 4656 reference and 4663 reference. Each also requires the relevant SACL entry. For this protocol, an allowed file read should be assessed against a matching 4663; a refused handle request should be assessed against a matching Failure 4656.
Verification: Build the Evidence Before Remediation
Step 1: Record the effective policy on the chosen server
Run the following on the server hosting the dummy files, using an account permitted to inspect audit policy. Microsoft documents the category/subcategory selection and CSV report option in auditpol get:
auditpol /get /subcategory:* /r
Retain the complete output with the server name, collection time and operator. Locate File System and record its success and failure settings. For a protocol covering both allowed and refused access, establish both settings before expecting both kinds of evidence. If a mode is disabled, record that observation and its consequence rather than marking the entire server as verified.
Keep the GPO view as a separate artifact. It records declared configuration; the local query records the system audit policy returned by that host. If per-user policy may affect the test identity, inspect that policy too using the documented /user selector. Record any permission error as an incomplete measurement rather than an empty or disabled policy.
Step 2: Inspect the actual dummy files' SACLs
Prepare two synthetic files through the approved test setup, for example C:\AuditProof\allow.txt and C:\AuditProof\deny.txt. Arrange for the test identity to have the selected right on the first and lack it on the second. Inspect both DACLs before proceeding; do not assume that a filename makes an access allowed or denied.
Microsoft documents -Audit as retrieving SACL data in Get-Acl. These commands adapt its documented parameters to the illustrative paths. Execute each line separately in Windows PowerShell or PowerShell on Windows:
$allowAcl = Get-Acl -LiteralPath 'C:\AuditProof\allow.txt' -Audit
$allowAcl.Audit
$allowAcl.Sddl
$denyAcl = Get-Acl -LiteralPath 'C:\AuditProof\deny.txt' -Audit
$denyAcl.Audit
$denyAcl.Sddl
Retain the returned audit entries and security descriptor for each file, or the exact error if inspection fails. Review the identity, audited rights, success/failure flags and inheritance scope. A count of entries is insufficient: the relevant entry must cover this identity and this operation on this object. An inherited rule should be assessed on the file actually used, not inferred solely from a parent folder.
The decision here is concrete: which SACL covers the required identity, outcomes and rights without excessive noise or sensitive content? State the selected rights and why they are sufficient for the proof. Avoid broadening the scope merely to obtain more events.
Step 3: Exercise the allowed and refused cases separately
Using the chosen test application under the ordinary test identity, perform the selected operation on allow.txt. Then attempt the same operation on deny.txt. Record start and end times, the application, identity, target and observed outcome for each case. Avoid using the inspection administrator as the access-test identity; the protocol needs to exercise the permissions under review.
For a read test, actually read the allowed dummy file rather than merely selecting it in a file picker. For the refused case, record the application's refusal and inspect the associated handle-request evidence. If refusal occurs before the intended file is reached, the case does not yet demonstrate auditing of that file. Keep such an outcome visible in the record and investigate the access path.
Do not expect a fixed number of events. Inspect the host's Security log in Event Viewer during the recorded window and filter for 4656 and 4663. Compare the account, object and access fields with the test worksheet before assigning an event to a case.
Step 4: Preserve the event and explain the decision
For each relevant event, retain the original event XML in the approved evidence location. Microsoft documents subject identity and logon ID, object type/name, process information, handle ID, and access fields. In 4663, the access list describes rights used; in 4656 it describes rights requested. For a file read, the documented ReadData right is 0x1; distinguish that from directory listing or metadata-only access when interpreting the object and operation.
Use handle ID for correlation when available, alongside the host, time, subject, process and object. Microsoft notes that the handle field can be 0x0; it must not be the sole join key. Write down whether each retained event supports the allowed operation or the refused request, and what remains unproven.
If the monitoring contract includes central collection, locate the same event there and compare its essential fields. A local event and a centrally usable record are separate evidence items. This comparison is a proposed validation step, not an assertion that any particular collector preserves those fields.
Remediation: Fix the Demonstrated Gap and Retest
Step 5: Change the policy or SACL that failed verification
If File System success or failure auditing is missing, address the applicable policy for the chosen server. The auditpol set documentation supports specifying a subcategory by name or GUID and enabling each outcome. On an approved pilot with an English subcategory name, the corresponding command is:
auditpol /set /subcategory:"File System" /success:enable /failure:enable
Treat this as a local pilot change, with the previous settings retained for rollback. For a managed deployment, correct the applicable policy through the team's GPO change process and verify the resulting host state again. A successful command response alone does not close the file-access evidence gap.
On localized systems, use the actual name or GUID obtained from Microsoft's documented auditpol list command:
auditpol /list /subcategory:* /r
If the policy is enabled but the SACL does not match, correct the audit entry for the chosen test identity, right and outcome using the approved object-security workflow. Preserve the DACL and the original SACL for review. Repeat inspection before repeating access; changing the allow/deny permissions would change the test itself.
Step 6: Resolve policy disagreement without declaring success
When legacy GPO settings look correct but host behavior differs, inspect the applicable advanced policy and the subcategory override security option. Microsoft documents SCENoApplyLegacyAuditPolicy as preventing category-level policy application. Our audit-policy guide to effective settings and legacy-versus-advanced conflicts provides the wider configuration context.
The unresolved decision is which evidence to retain when the expected event is absent despite reassuring legacy configuration. Keep the local policy output, actual SACL, test outcome, search window and collection location together. Assign the discrepancy to an owner. After the targeted change, repeat the same operation and evidence review; do not replace an unresolved case with a broader, easier test.
How EtcSec Detects This
At collector commit bcd03c540bfccdeecf70f36bb80fd58bbe0bef1d, HDS_5_4_LOG_ACCESS_TO_HEALTH_DATA reads GPOPolicies and their legacy EventAudit.AuditObjectAccess values. The SMB provider populates that field from [Event Audit] in GptTmpl.inf. It collects advanced audit.csv separately, but this Detect() does not consume it.
The implemented condition accepts any collected non-null GPO with non-null EventAudit and AuditObjectAccess >= 3. When any such GPO exists, Count is zero. Otherwise Count is one if the GPO policy collection is non-empty; an empty collection also gives Count zero. Although the comment describes requiring exactly 3, the executable condition is >= 3.
Consequently, a GPO outside the tested server's scope can suppress the finding. This check does not observe effective per-server policy, SACLs, file paths, access attempts, health-data classification or Security events. Neither a finding nor Count zero establishes the outcome of this validation protocol. Use the signal to request scoped evidence and document its limits.
Close the Review with a Scoped Verdict
Record a verdict for each server, object, identity and right: demonstrated, failed, or incomplete. Include the policy/SACL artifacts, actual application outcome, relevant events, any central-collection comparison, remediation decision and retest result. State exclusions explicitly so a reviewer can distinguish a passed dummy-file case from coverage that was never tested.
Technical sources and collector implementation reviewed on 4 October 2026. The examples remain a procedure to execute with approved dummy data, without capturing health-data contents.
Explore the identity security pages that support this topic