In this post, we will dive into how to configure file access auditing on a Windows file server and explore the challenges with interpreting critical access events.
Background
The first step in developing an effective audit strategy is to gain a good understanding of your systems, use cases and business needs, so you can avoid the impact of configuring a wider audit scope than is actually needed. The more audit policy settings you choose and the more files and folders you audit, the more work the file server has to do to log the events, the more storage is required to accommodate the volume of events, and the more data admins have to parse through to understand who is accessing what.
Accordingly, before enabling an audit policy, make sure to:
- Determine where your organization’s most critical data is stored and prioritize which files and folders need to be audited.
- Determine the amount of storage that will be required to support the chosen audit settings.
Configuring File Access Auditing on a Windows File Server
In this blogpost, I will show how to enable an advanced audit policy through Group Policy on a domain controller running Windows Server 2016 R2. (If you have just a single file server, you could use Local Security Policy instead.)
Advanced audit policy allows administrators to be more selective in the types and number of events to be returned than they can with the basic audit policy settings. In particular, when it comes to auditing file access, basic audit policy provides a single setting while advanced policy provides 14 subcategories. In this example, we will enable the following options:
- Audit File System — Audits user attempts to access file system objects.
- Audit Handle Manipulation — Adds visibility into failed access attempts.
- Create a new Group Policy object (GPO) through Group Policy Management and enter a suitable name.
- Right-click the new GPO to launch the Group Policy Management Editor window.
- Navigate to Computer Configuration –> Windows Settings –> Advanced Audit Policy Configuration –> Audit Policies –> Object Access.
- Double-click Audit File System. Then select Configure the following audit events and choose both Success and Failure. Save your changes by clicking Apply and then click OK.
- Double-click Audit Handle Manipulation. Select Configure the following audit events and choose both Success and Failure. Then click Apply and then OK.
- Now we need to link the new GPO with the OU that contains the file servers. In Group Policy Management, right-click the OU, select Link an existing GPO…, select the GPO we created (File System Access Policy) and click OK to apply it to the selected OU. Then force the file servers to check the new group policy: Right-click the OU in Group Policy Management again, click Group Policy Update and follow the steps in the wizard.
- Navigate to the properties of the Security log on the target Windows file server. Then configure the Maximum log size (KB) and the action to be taken if the maximum event log size is reached.
- Navigate to the security tab of each target folder’s properties –> click Advanced –> navigate to the Auditing tab –> click Add –>configure the auditing settings. Assuming these folders contain your organization’s most critical assets, you will likely want to monitor access events from all users by selecting the “Everyone” principal.
Challenges with File Access Auditing
Now let’s review some of the top challenges in file access auditing.
High Event Volume
Administrators often struggle to effectively manage the huge volume of audit data that is produced. For example, let’s examine the events created by the following common scenario:
- A user opens a Microsoft Word document on a file share.
- The user edits the document.
- The user saves and closes the document.
This ordinary behavior would result in over 200 events being written to the event log, as shown below. Multiply this by the number of times this activity will be performed by users every day, and it’s easy to see how quickly the task of monitoring file access becomes unwieldy!
Here are more details on the events that could be returned in our simple scenario:
| Event ID | Description | Details |
| 4656 | A handle to an object was requested | This is the first event recorded when a user attempts to access a file; it includes the type of access that is being requested. |
| 4658 | The handle to an object was closed | This event logs when a handle to an object was closed. It is useful in determining how long a file was open. |
| 4660 | An object was deleted | This event is logged when an object was deleted. To find which object it was, you must relate it to a corresponding 4656 event. |
| 4663 | An attempt was made to access an object | This event identifies the operation attempted against a file or folder, such as ReadData, WriteData or Delete. |
| 4670 | Permissions on an object were changed | This event is logged when permissions to a file or folder were changed. It shows who made the change and the before and after values. |
Noise from Temporary Files
The example above returned 230 events — but nearly half of them are logged against temporary files that existed only for a short time.
Microsoft Office uses temporary files for multiple purposes, including to auto-save data during editing, free up memory and prevent data loss. While this provides users with a better experience, it’s a huge headache for the admin tasked with managing the audit trail: In order to make sense of which objects are being accessed, they not only have to correlate several different Event IDs, they also gave to identify and discard the events related to temporary files.
Difficulty Understanding Changes to Permissions
Event 4670 is logged when a permission on a file or folder is changed. It’s vital to monitor these events since they can put sensitive information at risk, such as when a folder permission is added to the Domain Users group. Here is a sample event:
Event 4670 can be difficult to work with for several reasons:
- The security descriptor is represented using Security Descriptor Definition Language (SDDL), so the admin needs to translate it into a readable format.
- Once translated, the admin needs to painstakingly compare the original and new security descriptors in order to identify the changed permission.
Correlating Events to Understand File Movement
Understanding the movement of files from one location to another can be critical, for example, when a user’s documents are missing and need to be found. But moving a file, whether via drag-and-drop or cut-and-paste, generates multiple events, many of which are 4663 events. In order to determine where a file was moved, admins have to manually filter out the noise events and correlate the 4663 events that have a matching Handle ID.
How can Netwrix help?
As we’ve seen, native file access auditing overwhelms admins with so much event data and manual filtering and correlation effort that it is not a viable way to answer crucial questions about file access, permission changes and file movement.
Data access governance software from Netwrix provides an effective and scalable approach to file activity monitoring. Moreover, it will help you reduce the risk of cybersecurity incidents by enabling you to understand who has access to what and strictly limit access to sensitive data. You can:
- Audit activity across your IT ecosystem.
- Reduce access to sensitive data to the required minimum to reduce the risk of insider threats and minimize the damage from ransomware and other attacks.
- Streamline regular privilege attestations by data owners.
- Protect sensitive data whenever it goes with accurate and consistent tagging of content.
FAQ
How to monitor file access in Windows?
Windows file access monitoring requires enabling the audit policy for object access and configuring specific folders for auditing. Start by opening Group Policy Management (gpedit.msc) and navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > Audit Policy. Enable “Audit object access” for both success and failure events. Next, right-click the folders you want to monitor, select Properties > Security > Advanced > Auditing, and add users or groups with the specific access types you want to track.
The challenge with native Windows monitoring is that it generates massive amounts of log data without context. You’ll see who accessed what file, but connecting that activity to actual business risk requires manual analysis. Data security that starts with identity means understanding not just file access, but whether that access aligns with job responsibilities and business needs. Organizations need solutions that automatically correlate file access patterns with user roles, data sensitivity, and compliance requirements to spot risky behavior before it turns into a breach.
How to enable file auditing in Windows Server 2016?
Windows Server 2016 file auditing configuration follows a two-step process: enabling the audit policy and configuring folder-level auditing. Open the Group Policy Management Console and navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Object Access. Enable “Audit File System” for success and failure events. Apply the policy using gpupdate /force.
For folder-specific auditing, access the target folder’s Properties > Security tab > Advanced > Auditing tab. Click Add to create new audit entries, specifying which users or groups to monitor and which actions trigger audit events (Read, Write, Delete, Change Permissions). Windows Server 2016 introduced improved filtering capabilities, but you’ll still need to manage the flood of audit data manually. The key is focusing on high-value data repositories and understanding that effective monitoring connects file access to identity context – not just logging everything that moves.
How to enable file auditing in Windows Server 2019?
Windows Server 2019 streamlines file auditing with enhanced Group Policy options and improved event filtering. Access Advanced Audit Policy Configuration through Group Policy Management > Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Object Access. Enable “Audit File System” and consider enabling “Audit File Share” for network access monitoring.
Configure folder auditing through the Security tab > Advanced > Auditing, where Server 2019 offers more granular control over which file operations generate events. The platform includes better filtering for temporary files and system processes, reducing noise in audit logs. However, the fundamental challenge remains: raw audit data doesn’t automatically translate to security insights. You can log every file touch, but without identity-based context, you’re collecting data instead of actionable intelligence. Organizations focus on connecting file access patterns to user behavior analytics and data classification to identify genuine threats rather than drowning in log entries.
Where do Windows file system audit events get logged?
Windows file system audit events are logged in the Windows Security Event Log, accessible through Event Viewer under Windows Logs > Security. These events typically appear with Event IDs 4656 (handle requested), 4658 (handle closed), 4663 (access attempted), and 4660 (object deleted). You can filter the Security log by these specific Event IDs to focus on file access activity.
The Security Event Log has limitations for enterprise file monitoring. It fills up quickly, events lack business context, and correlating access patterns across multiple servers becomes a manual process. Each event shows technical details like user SIDs and file paths, but doesn’t indicate whether the access represents normal business activity or potential insider threat. Enterprise-grade file monitoring requires centralized log collection, automated correlation with identity information, and intelligent filtering based on data sensitivity and user roles. The goal isn’t just capturing every file touch – it’s understanding which access patterns represent actual risk to your data security posture.
