Windows Server: Implementing Auditing Policies to Track Security Events

Windows Server auditing policies record who signed in, who failed, which accounts changed and which files were touched. This guide turns on the Advanced Audit Policy subcategories you actually need, adds file-level auditing on a folder, and shows you how to read the results in the Security event log without drowning in noise.

Everything below runs on a Windows VPS where you have Administrator rights. You will use auditpol for the policy itself, icacls for object auditing, and PowerShell for reading events.

Before you start

• A Windows VPS running Windows Server 2019, 2022 or 2025, with an Administrator session. Remote Desktop listens on TCP port 3389 by default, so connect to 203.0.113.10:3389.
• An elevated PowerShell window. Right-click PowerShell and choose Run as administrator — auditpol and wevtutil both fail without elevation.
• A short list of what you care about. Auditing everything generates enormous logs and hides the signal. Start with logons, account changes, privilege use and one sensitive folder.
• If the server is joined to an Active Directory domain, remember that a domain Group Policy Object overrides local policy. Configure auditing in the GPO instead, or your settings will be replaced at the next refresh.

How Windows auditing works

There are two layers. The legacy layer uses nine broad categories such as Logon/Logoff and Object Access. The advanced layer uses around fifty subcategories and gives you per-subcategory success and failure control. When both are configured, the advanced settings win only if the option Audit: Force audit policy subcategory settings to override audit policy category settings is enabled — it is on by default on current Windows Server builds.

The events land in the Security log. The ones worth knowing:

• 4624 — successful logon. Logon type 10 means Remote Desktop, type 3 means network, type 5 means a service.
• 4625 — failed logon. The most useful event for spotting brute-force attempts against RDP.
• 4634 and 4647 — logoff and user-initiated logoff.
• 4672 — special privileges assigned to a new logon, in practice an administrative session.
• 4720 and 4726 — a user account was created or deleted.
• 4688 — a new process was created. High volume; enable only when you need it.
• 4663 — an attempt was made to access an object, such as a file or folder.
• 1102 — the audit log was cleared. Treat this as a red flag.

Enable advanced auditing with auditpol

Check the current state first so you know what you are changing:

auditpol /get /category:*

Now enable the subcategories that matter. Run these in an elevated Command Prompt:

auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Logoff" /success:enable
auditpol /set /subcategory:"Account Lockout" /success:enable /failure:enable
auditpol /set /subcategory:"Special Logon" /success:enable
auditpol /set /subcategory:"User Account Management" /success:enable /failure:enable
auditpol /set /subcategory:"Security Group Management" /success:enable /failure:enable
auditpol /set /subcategory:"Audit Policy Change" /success:enable /failure:enable
auditpol /set /subcategory:"File System" /success:enable /failure:enable

Each command prints The command was successfully executed. when it works. Subcategory names are localised — on a non-English server, run auditpol /get /category:* and copy the exact names it shows.

Save a baseline so you can restore or compare later:

mkdir C:\audit
auditpol /backup /file:C:\audit\baseline.csv

Configure auditing through Group Policy

Local auditpol settings are fine for a standalone server, but Group Policy is easier to review and survives a rebuild. Open gpedit.msc and navigate to:

Computer Configuration > Policies > Windows Settings > Security Settings
> Advanced Audit Policy Configuration > Audit Policies

Set the same subcategories there — Logon/Logoff, Account Management, Policy Change and Object Access. When you are done, apply it:

gpupdate /force

Then confirm the running policy matches what you configured:

auditpol /get /category:*

If a domain GPO manages the server, edit that GPO instead. Local settings will be overwritten at the next policy refresh, usually within 90 minutes.

Audit file and folder access

Enabling the File System subcategory only tells Windows to record object access. You still have to mark each object with a system access control list (SACL), otherwise nothing is logged.

Pick a folder that matters — a shared data directory, a config folder, a web root — and add an audit entry. This example logs successful and failed read and write attempts by the account deploy:

icacls C:\Shares\Finance /audit "deploy:(OI)(CI)(R,W)"

(OI) and (CI) apply the entry to files and subfolders created later. To audit everyone instead, replace deploy with Everyone. To review or remove entries:

icacls C:\Shares\Finance
icacls C:\Shares\Finance /remove:g deploy

Read and filter the security events

The Security log is noisy, so filter rather than scroll. This returns failed logons from the last day:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddDays(-1)} -MaxEvents 50 |
  Format-Table TimeCreated, Id, Message -Wrap

For file access, look for 4663 events and pull out the object name:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4663; StartTime=(Get-Date).AddDays(-1)} -MaxEvents 100 |
  Select-Object TimeCreated, @{n='Object';e={$_.Properties[6].Value}}, @{n='User';e={$_.Properties[1].Value}}

The same query from Command Prompt, if you prefer wevtutil:

wevtutil qe Security /q:"*[System[(EventID=4624)]]" /c:20 /f:text

Finally, give the log room to breathe. This sets the Security log to 1 GB:

wevtutil sl Security /ms:1073741824

Check it works

1. Open a second Remote Desktop session to 203.0.113.10:3389 using a normal user account.
2. Sign out of that session.
3. Back in your administrator session, run:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624,4634; StartTime=(Get-Date).AddMinutes(-10)} |
  Format-Table TimeCreated, Id, @{n='LogonType';e={$_.Properties[8].Value}}

You should see a 4624 with logon type 10 for the new session and a 4634 when it closed. Then deliberately fail a logon — type the wrong password once on the RDP prompt — and confirm a 4625 appears. If both show up, auditing is live.

Troubleshooting

• No 4624 events for RDP sessions. The Logon subcategory is not enabled, or a legacy category policy is overriding it. Run auditpol /get /subcategory:"Logon" and confirm it says Success and Failure. If it does and events are still missing, check that the registry value SCENoApplyLegacyAuditPolicy under HKLM\SYSTEM\CurrentControlSet\Control\Lsa is set to 1.
• 4663 events never appear. Either the File System subcategory is off, or the folder has no SACL. Re-run icacls C:\path and look for an Audit section — if it is empty, add the entry again.
• auditpol /set returns "Access is denied". You are not elevated. Close the window and reopen PowerShell or Command Prompt as Administrator.
• Settings revert after a reboot or policy refresh. A domain GPO is enforcing its own audit policy. Configure the subcategories in that GPO rather than locally.
• The Security log fills up and overwrites old events. Increase the maximum size with wevtutil sl Security /ms:1073741824, or narrow the audit scope to fewer accounts and folders.

Next steps

• Advanced Windows Server: Implementing Group Policy Objects (GPO) for security — manage audit policy centrally and keep it consistent.
• Local Security Policy basics on Windows Server — the neighbouring settings that control lockout and password rules.
• Windows Server: Securing Remote Desktop Session Management (RDP) Best Practices — reduce the attack surface your 4625 events are reporting.
• First steps on a new Windows VPS — baseline configuration before you add auditing.