Audit Permission Changes on Windows File Servers

Auditing is one of those subjects that tend to put people to sleep. But
understanding what is going on in your environment is critical for security and
maintaining service. That said, auditing isn’t a replacement for proper controls.
For example, you should always make sure that permissions on file servers
cannot be changed without some oversight. If all your IT staff has domain
admin privileges and there are no change control procedures in place,
auditing may help you rein in the chaos, but you are treating the symptom
rather than addressing the problem. That’s if a rogue IT staffer hasn’t already
disabled auditing with their admin rights.

With that said, let’s look at how to monitor changes to permissions on file
servers. Before Windows will log file system events, you need to enable
auditing in policy and configure system access control lists (SACLs) on the
file/folders that you want to audit. For the purposes of this article, I’ll use local
policy to configure audit policy but if your file servers are members of an
Active Directory domain, you can use Group Policy instead. For more
information on how to work with Group Policy

You have two options when it comes to which policy to enable. You can
enable object access, which is a legacy policy setting that logs more than just
file system access. If you are using Windows Server 2008 R2 or later, you can
enable file system object access in Advanced Audit Policy, which logs object
access events related to the file system only. Advanced auditing in Windows
Server gives administrators more granular control over what events are
collected. For a more detailed explanation,

So that I don’t log more events than necessary, I’m going to enable success
and failure for Audit File System events under Computer Configuration >
Windows Settings > Security Settings > Advanced Audit Policy Configuration
> System Audit Policies > Object Access.
 Configure System Access Control List (SACL)

And now for the second part of the configuration. There are two ways you can
configure SACLs. I have a folder (c:\accounts) that I want to monitor on my file
server. I can add a SACL directly to the folder using File Explorer.

 Right click the folder where you want to add an SACL.

 Select Properties from the context menu.
 Switch to the Security
 Click Advanced at the bottom of the dialog.
 Switch to the Auditing
 Click Add.
 Click Select a principal at the top of the dialog.
 In the Enter the object name to select box, type everyone and then click OK.
You could choose a specific user account or group, but we want to log
permission changes made by all users.
 Select All from the Type dropdown menu. You could choose
just Success or Failure, but All selects both.
 Select This folder, subfolders and files from the Applies to dropdown menu.
I want the SACL to be applied to the parent object and all child objects.
 Click Show advanced permissions on the right of the dialog.
 Make sure that Change permissions is checked.

I’m only interested in when permissions change, regardless of what those

permissions are, but you could decide to log specific actions. For example,
checking List folder / Read data would log an event whenever data is read.

 Click OK.
 Click OK again in the Advanced Security Settings dialog.
 Click OK in the Properties dialog.

Setting up and managing SACLs across many file servers isn’t so easy if you
do it manually using the steps above. But Global Object Access Auditing lets
administrators set file and registry SACLs configuration per computer, rather
than at the file system level. This makes it easier to track the settings across
servers on your network. For more information on how to set up Global Object
Access Auditing,
Use the Event Log to Check for Permission Changes

Now whenever somebody changes permissions on the accounts folder, or any

child object, EventID 4670 will be logged in the Windows Security event log. In
the screenshot below, you can see that I’ve created a custom view to see only
events with the ID 4670. Each event records the user who made the
permission change, the path of the object on which permissions where
changed, and before and after values. I.e. the old and new permissions.