Last Update: Sep 04, 2024 | Published: Mar 22, 2019
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.
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.
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.
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.
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.
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.