I'm implementing file auditing on a directory on a IIS server in order to get notification when someone attempts to modify or delete any documents.
I set Advanced Auditing Policy\Audit Policies\Object Access:File System to audit Success and Failure.
The next stage according to all the documentation I've read is to set the SACL on whatever files/directories I need to monitor.
However, checking the Security event log before setting the SACLs shows many event id 4656 (A handle to an object was requested). Reading these events shows that they are being raised for access to various system files.
I accessed the Properties dialog for these files/directories and clicked on the Security tab. Next I clicked on Advanced button and selected the Auditing tab. There I see that auditing has been set up for the Everyone user to log all Writes.
I next ran a powershell script:
Get-ChildItem -Path "C:\" -Recurse | ForEach-Object {
$file = $_.FullName
$(Get-Acl -Audit $file).GetAuditRules($true,$false, [System.Security.Principal.SecurityIdentifier]) | ForEach-Object { Write-Output $file }
}
to list all files/directories with auditing enabled on them. It turns out that on this IIS box I have over 32,000 files with auditing enabled.
Thinking that I may have enabled these somehow in the past, I next ran the same script against a domain controller and counted a similar number. These were both in a test environment, so I next ran the scripts against another production IIS server (which I didn't build) and got similar results.
Therefore, my questions are:
Is this normal? Are over 32K files installed with Auditing SACLs on them, but the policy initially disabled? Enabling the policy causes the event logs to fill with useless events - on the test IIS server, I noticed about 100 events in an hour.
While I can easily modify the above script to remove these SACLs then add only the ones I need, is this a safe thing to do?
Even more general - have I missed something obvious?
0 Answers