How to 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, see How to Create and Link a Group Policy Object in Active Directory on Petri.

Configure Audit 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, see Enable Advanced Auditing in Windows Server on Petri.

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, see Configure Global Object Access Auditing in Windows Server on Petri.

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.

To find out more about creating custom views in Event Viewer, see How to Create Custom Views in Windows Server 2012 R2 Event Viewer on Petri.