---
locale: "en"
updated_at: "2026-08-04T10:04:28.062Z"
canonical: "https://www.isdecisions.com/en/fileaudit/docs/reference/core-concepts/windows-audit"
---

# Windows audit

Native Windows auditing mechanisms used by FileAudit

## How FileAudit collects Windows file access events

FileAudit is agentless. It does not generate file access events on its own. Windows records file system operations (reads, writes, deletes, permission changes) in the **Security log** of each audited machine. 

The FileAudit service reads that log continuously, correlates the raw events into consolidated file operations, and stores them in the [FileAudit database](/fileaudit/docs/reference/database/architecture) for reporting and alerting.

Two prerequisites must be met for events to appear:

- A Windows **audit policy** must be active so the operating system writes Security log entries for file operations.
- A **SACL** (System Access Control List) must exist on each monitored folder, telling Windows which users and access types to audit.

The FileAudit audit path wizard can configure both automatically. For step-by-step instructions, see the [Manage Windows audit](/fileaudit/docs/guides/operations/manage-windows-audit) guide.

> **Note**
>
> - Supported file systems: **NTFS** and **ReFS**.
> - For auditing cloud storage providers, see [Cloud audit](/fileaudit/docs/reference/core-concepts/cloud-audit).

## Audit Object Access policy (basic)

The **Audit Object Access** policy is the simplest way to enable file auditing at the OS level. When active, Windows generates events each time a user accesses a file or folder that has a SACL.

> **Location**
>
> **Local Security Policy** → **Security Settings** → **Local Policies** → **Audit Policy** → **Audit Object Access**

Set both **Success** and **Failure** to **Enabled**:

- **Success**: records granted access events.
- **Failure**: records denied access events.

If this policy is disabled, Windows writes no file access events and FileAudit has nothing to collect.

⚠ In Active Directory environments, this policy is often controlled through a **Group Policy Object (GPO)**. If a GPO overrides the local setting, the local configuration has no effect. Verify with `gpresult /h report.html` on the target server.

![](https://a.storyblok.com/f/122374/1600x900/b9d86582e5/audit-object-access.png)

## Advanced Audit Policy Configuration

Windows Server 2008 R2 and later support **Advanced Audit Policy Configuration**, which provides finer control than the basic policy. Instead of auditing all object types, advanced policies target only file-related subcategories.

**Location:** Local Security Policy → Security Settings → Advanced Audit Policy Configuration → Audit Policies → Object Access

FileAudit uses three subcategories under Object Access:

| Subcategory | What it enables |
| --- | --- |
| Audit File System | Events for local file and folder access on NTFS/ReFS volumes |
| Audit Detailed File Share | Events for file access through network shares (includes source IP) |
| Audit Handle Manipulation | Handle open events, needed by FileAudit to detect unsuccessful attempts |

Each subcategory can be set to **Success**, **Failure**, or both.

Using advanced policies reduces Security log volume by excluding non-file events (registry, SAM, etc.).

> **Note**
>
> ⚠️ When both the basic and advanced policies are configured, the advanced policy takes **precedence**. Microsoft recommends using only one approach. 
> 
> To enforce advanced policy usage, enable `Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings` in the GPO.

![](https://a.storyblok.com/f/122374/1600x900/5f8e54b256/audit-avance.png)

## Windows Security Event IDs used by FileAudit

FileAudit processes events from the Microsoft-Windows-Security-Auditing source in the Windows Security log.

A single user action (saving a file, for example) may produce several raw events that FileAudit merges into one consolidated event.

FileAudit correlates these raw events into the access types displayed in the console: Read, Write, Delete, Rename, Move, Execute, Ownership, Permissions, Write attributes. 

For definitions, see [Access types](/fileaudit/docs/reference/core-concepts/access-types).

| Event ID | Meaning | Role in FileAudit |
| --- | --- | --- |
| 4656 | Handle to an object requested | Start of an access operation. Contains access mask and user identity. |
| 4663 | Attempt to access an object | Confirms the operation performed. FileAudit reads the access mask. |
| 4659 | Handle requested with intent to delete | Signals a deletion intent. Supported for backward compatibility. |
| 4670 | Permissions changed | NTFS permission modification (DACL change). |
| 5145 | Network share object checked | Network share access. Contains source IP address. |

## SACL configuration and the audit path wizard

A Windows audit policy alone does not generate events. Each folder must also have a SACL that specifies which users and operations to audit. Without a SACL, Windows writes nothing to the Security log for that folder.

FileAudit includes a configuration wizard that runs when adding an audited path. The wizard:

1. **Enables** the Audit Object Access policy on the target server if needed.
2. **Sets** the SACL on the folder and its child objects.
3. **Checks** that the SACL propagated correctly to subfolders and files.

Propagation verification may take time on large folder trees. The wizard optimizes SACL entries to generate only the events FileAudit needs.

Administrators can also configure the SACL manually: right-click the folder → **Properties** → **Security** → **Advanced** → **Auditing** tab.

For step-by-step instructions, see the [Manage Windows audit](/fileaudit/docs/guides/operations/manage-windows-audit) guide.

> **Note**
>
> ⚠️ Enabling **Audit file attributes changes** in Settings requires reconfiguring existing audited paths to add SACL entries for attribute tracking. Re-run the wizard or update the SACL manually.

## Audited servers

The **Audited servers** view on the FileAudit dashboard displays each monitored Windows machine as a tile. Each tile shows the server name, the number of audited paths, and the current audit status.

Clicking a server tile opens a detail panel with the following actions:

- **Active Audit** toggle: enables or disables event collection for this server. Disabling stops event collection and alert processing but preserves the configuration (paths, alerts). Re-enabling restores collection.
- **Check audit status**: verifies that the Windows audit policy is correctly applied on the server.
- **Revoke server**: permanently removes the server from FileAudit, deletes all associated events from the database, and frees one licensed server slot. You can also choose to remove the audited path configuration. This action is irreversible.

For operational procedures, see the [Manage Windows audit](/fileaudit/docs/guides/operations/manage-windows-audit) guide.

![Windows Audited servers](https://a.storyblok.com/f/122374/1248x638/a02330f267/windows-audited-servers.png)

## Audited paths

The **Audited paths** view lists all monitored folders, across all servers or filtered by a specific server.

Three actions are available from this view:

- **Add a path**: launches the configuration wizard described in SACL configuration and the audit path wizard.
- **Check audit**: verifies the NTFS audit configuration on a selected path. If the SACL was modified externally (by another tool or a GPO change), the wizard proposes to reconfigure it.
- **Delete**: removes the monitoring configuration for one or more paths. Existing access events already stored in the database are preserved.

> **Tip**
>
> **💡Avoid auditing folders that contain mostly system or application files** (e.g., `C:\Windows`). 
> 
> 
> 
> These generate large volumes of irrelevant events. 
> 
> 
> 
> Focus on shared folders, departmental data, and sensitive document locations. Use scan exclusions in [Settings](/fileaudit/docs/reference/settings) to filter noise from service accounts or background processes.

For step-by-step instructions, see the [Manage Windows audit](/fileaudit/docs/guides/operations/manage-windows-audit) guide.

![Windows Audited paths](https://a.storyblok.com/f/122374/1264x461/2cd9ec8e34/windows-audited-paths.png)

## Remote auditing requirements

FileAudit does not need to be installed on the audited server. The FileAudit service reads the Windows Security log remotely over the network.

Three conditions must be met on each remote server:

- **Remote Event Log Management** must be Authorized (Windows Firewall rule).
- The FileAudit impersonation account must have **read access to the Security log**.
- Configure a dedicated **impersonation account** with administrator privileges on each target server. Impersonation accounts are configured in [Settings](/fileaudit/docs/reference/settings).

If any of these conditions is not met, FileAudit cannot collect events from that server. Check the [Warnings](/fileaudit/docs/reference/warnings) page in the console for diagnostic messages.

For supported operating systems and detailed prerequisites, see [Requirements](/fileaudit/docs/getting-started/requirements).

![Settings configuration - Impersonation accounts](https://a.storyblok.com/f/122374/1264x786/52f1b183c9/settings-impersonation-accounts.png)

## Security log sizing and retention

FileAudit reads events from the Windows Security log. If the log reaches its maximum size and overwrites entries before FileAudit processes them, those events are permanently lost. Once stored in the FileAudit database, events remain available even if the Security log overwrites them.

Windows offers two retention modes when the log is full:

- "Do not overwrite events" stops logging entirely.
- "Overwrite events as needed" replaces the oldest entries silently. Use this mode and set the log large enough so FileAudit has time to read events before they are replaced.

**Recommended minimum log size:** 250 MB. On busy file servers with many audited paths, increase to 512 MB.

To check or change the log size:

1. Open **Event Viewer** on the target server.
2. Right-click **Security** under Windows Logs → **Properties**.
3. Set **Maximum log size** to at least 250,000 KB.

> **Tip**
>
> 💡 Enable email notifications for warning events in [Settings](/fileaudit/docs/reference/settings) to be alerted to log-related collection problems.

## DFS support

FileAudit supports DFS (Distributed File System) environments, but audited paths must point to the physical server hosting the files, not to the DFS namespace path.

When configuring a path on a DFS system, look up the actual UNC path of the physical server in the folder properties and enter that path in FileAudit. For example, if the DFS share is `\\domain\DFS\Sales_Marketing`, the physical path might be `\\FILESERVER01\Sales_Marketing`.

FileAudit also supports failover clusters (active/passive). When the active node changes, drive-to-logical-name mappings must be reconfigured manually in FileAudit.

## Known limitations

FileAudit relies entirely on the Windows auditing subsystem. The following limitations apply:

- Certain specific actions are not detected by the Microsoft audit, which instead decomposes them into basic native events. The actions ‘Copy/paste’, ‘Cut/paste’, ‘Create file/folder’ are not available as native Microsoft audit events and are decomposed in several basic events..
- Windows Explorer may generate unintentional Read events when browsing a folder (metadata loading, shell extensions reading file headers). For example, if WinZip is installed, the WinZip shell extension may read the header of any .zip file in a folder to determine the number of files in the archive, an action that will occur upon simply selecting a .zip file name.
  Consequently, a read operation may be involuntary. Thus, a read operation detected by FileAudit does not prove that the file was accessed, but merely signals a strong probability that the file was (or was close to being) accessed.
- Moving a file between servers is recorded as a Delete on the source and a Write on the target. FileAudit cannot link these into a single Move operation across servers.
  False positives moves can also be generated when moving empty files and folders, or when the execution time of the move is too long.