Showing results for 
Search instead for 
Did you mean: 
Create Post

Managing File Auditing Noise

The Log and Event Manager can handle a lot of events in a day, but something support sees a lot is excessive file auditing.

"But wait!" I already hear you saying, "How can there possibly be such a thing as too much auditing?!  My auditors tell me to audit everything!"


The Experiment

Yeah, well...let me paint you a picture.  I created a folder on my machine, C:\Temp\THWACK.  Here's the auditing on that folder:

2014-06-04 08_09_07-Auditing Entry for THWACK.png

I bet some of you have auditing set like this.

And then I set the local policy on my machine like so:

2014-06-04 09_08_42-Administrator_ C__windows_system32_cmd.exe.png

Again, I bet this'll look familiar.  In fact, I bet you have the Filtering Platform stuff on as well.

So I did some simple tasks and took notes on what sort of traffic that created.

  • Create a folder called "New Folder" - 184 events in LEM
  • Open that folder - 106 events in LEM
  • Create a blank text file called "Sample Document.txt" - 203 events
  • Added a line of text to the document and saved it - 149 events
  • Deleted the text file - 87 events
  • Renamed "New Folder" to "Renamed Folder" - 127 events
  • Deleted "Renamed Folder" - 115 events

I have attached the output from my LEM monitor console as an Excel if you all want to take a look at it.  You really should, and ask yourself: how many of these events do I actually need?  How many of them actually tell me anything useful?

And if one person in one share on one machine can generate a thousand events in just a few minutes, how many events is your file server with thousands of files and dozens of users doing hundreds of operations creating?

If you've given your LEM all the memory in the world (and be honest, you didn't), and it's humming along in a perfectly optimized world (that probably only exists in the land of imagination), you can squeeze it for 200 million events per day.  But I managed to generate a thousand events in about 10 seconds, and I'm one person.  Sure, you only have 20 nodes, but if you're auditing like this and they're all file servers, that may be too much for your LEM.

Reducing traffic to the LEM will increase it's performance and responsiveness.  Getting the traffic tuned so it's actually meaningful means that when something bad happens, or when the auditor asks you a specific question, you can provide a meaningful answer.  Instead of getting this:

Object access "user.account (DOM) 0x33c"
Object access "user.account (DOM) 0x15f4"
Object access "user.account (DOM) 0xafc"
Object access "user.account (DOM) 0x1154"
Object access "user.account (DOM) 0x16d4"
Object access "user.account (DOM) 0x11a0"
Object access "user.account (DOM) 0xd3c"
Object access "user.account (DOM) 0x1528"
Object access "user.account (DOM) 0x33c"
Object access "user.account (DOM) 0x11a0"
Object access "user.account (DOM) 0x300"
Object access "user.account (DOM) 0x155c"

Do you have any idea what these mean as they stream past in the Monitor view?  Or when you're doing nDepth searches?  Are you really going to Google all those hex codes to find their real meaning?

Probably not.


First, your audit policy should probably never be for "Everyone Everywhere."  Everyone includes all those Windows accounts that chatter to themselves all the time.  "Authenticated Users" might work better, or "Domain Users."

Second, I'm auditing a directory in a directory and got 1000 events for 10 seconds.  If you go to the C: root and turn on all the auditing, you're going to watch a lot of activity in the C:\Windows directory because Windows is messing with itself all the time.  Do you have a group for Server, Workstation, Domain, Schema, Local and Enterprise Admins?  Audit them in the C: root.  Everyone else should be constrained by Active Directory to C:\Shares\.  Audit that folder for everyone or match the auditing to the groups that have access to those folders.  Take advantage of the feature in Windows that means you can audit your Executive Office user group like crazy in the "Critical Financial Documents" share but you can be less stringent with the accounting users who live and work in that share.

Third, learn what all those different policies do and how they look in the LEM and reports.

For example, SAM generates events when a SAM object is accessed.  Almost everything is a SAM object, and you get events like this:

ObjectDeleteObject deleted by "DOM\user.account"

Something was deleted! What was it?  SAM doesn't care.  But SAM also generates these:

FileAuditFile operation on "C:\Temp\THWACK\New Folder" user "DOM\user.account"

And these are actually sort of useful.  So, SAM on or off?  In a lot of cases, the File System category will still catch a lot of these events.  SAM just displays them differently.  Maybe your environment has a need for that extra set of events, but maybe it doesn't?

And what about all those events with the hex codes?  It looks like those only happen when Handle Manipulation is being audited.  Do you need those?  Maybe that one could be turned off?


More than anything, I want your LEM to run forever and provide you nothing but useful, meaningful data that helps you squash network issues, vanquish evil-doers and keep your auditors and managers happy.  I'd like to see your LEM not crash because you added 14 new file servers and murdered it with a flood of events.

And there's definitely a balancing act: the auditors want a certain amount of detail, you want a LEM that works, your managers want to be able to track changes effectively.  Turning on all the auditing might actually be detrimental if it means any good data is buried in a mountain of "Huh?"  What it means is that homework has to be done, risk assessments taken and decisions made on how much of all the things you need to audit.  The end result is worth it though: a LEM that runs forever, auditors who are pleased with your work and managers who get what they want in reports!


Excellant write up!

Good article, now I just need to figure out how to make the changes.

Version history
Revision #:
1 of 1
Last update:
‎06-04-2014 11:00 AM
Updated by: