Re: COTS application suggestions for auditing

From: Eric Fitzgerald [MSFT] (ericf_at_online.microsoft.com)
Date: 04/27/05 

Date: Wed, 27 Apr 2005 10:37:28 -0700

Security.evt is held open exclusively

The performance impact is probably caused by having to perform two disk
i/o's for every disk i/o (one to do the "real" i/o, and one to record it).

My suggestion is to get a faster system drive (RAID 0 or RAID 0+1), or move
the audit log to a different volume.

I also suggest against auditing reads of any sort, and against auditing
"write attributes" or "write extended attributes". These are the really
high-volume accesses.

Finally I suggest that you don't audit failed access attempts without a plan
for what you're going to do with them. Many failures are normal (Windows
often tries things with more privilege, and if the access fails, retries
automatically and transparently with less privilege- this allows Explorer to
disable menu items in the UI, for instance). Without a baseline the data is
uninterpretable; without a plan the data is just extra perf impact and
storage cost.

Eric

Eric Fitzgerald
Program Manager, Windows Auditing
Microsoft Corporation 

-- 
This information is provided "AS-IS" with no warranty, and confers no 
rights.
"Roger Abell" <mvpNOSpam@asu.edu> wrote in message 
news:eSeKAnzSFHA.2556@TK2MSFTNGP12.phx.gbl...
> OMG - I had never thought of this before, but they are
> making you success audit all disk file accesses ?? that is,
> as in, successful access to system32\config\SecEvent.Evt
> ?? setting up a no-win recursive write demand ?
>
> For success audits they MUST be selective - file access
> success audit across the board on the systems' files (not
> just the reg+evt config folder) is guaranteed to bog a
> system down.
>
> -- 
> Roger Abell
> Microsoft MVP (Windows  Security)
> MCSE (W2k3,W2k,Nt4)  MCDBA
> "Adam Sandler" <corn29@excite.com> wrote in message
> news:1114611150.109795.219800@g14g2000cwa.googlegroups.com...
>>
>> > permission changes, failed access attempts, policy changes
>> > will not of themselves cause much overhead
>>
>> But it does... The mere act of signing on touches lots of objects on
>> the system.  With tracking object access enabled, I get over fifty 560
>> event ids in the log just from a single signon only.  With Dfs and AD
>> running, there's always some kind of replication going on... that
>> generates a lot of Account and Object accesses... (the system doesn't
>> distinguish between user account and system accounts) which in turn
>> bogs the performance down with all this writing to the log.
>>
>> I'm not making this stuff up you know... you're more than welcome to
>> come to my site (I'll foot the airfare) so you can view the event logs
>> yourself.
>>
>
>

Relevant Pages

  • Re: Choosing the proper disk setup. I need help and advice.
    ... no amount of hardware will fix the problem. ... something like 18 disk spindles across 4 SCSI channels. ... Don't fret too much about disk I/O most arrays go much faster than the ... > inadequeate CPU speed, or network I/O as the bottleneck. ...
    (microsoft.public.windows.server.general)
  • Re: store.exe memory usage
    ... Ed Crowley MVP ... another hard disk, which of the following options would improve the disk I/O ... >> IMAP is not MAPI. ...
    (microsoft.public.exchange.admin)
  • Re: Best way to design multithreading application
    ... is what we write to each file, along with the averaged array. ... BeginInvoke() would pass whatever data is useful ... just how fast the data gets to the disk). ... good to stick with the original plan of a separate thread for disk I/O ...
    (microsoft.public.dotnet.framework)
  • Re: Exchange performance help
    ... about 90% of the time the popup is caused by disk I/O ... How many users are on the server and how many physical disks make up the ... We are getting the 9548 warnings about master sid approximately 15-30 ...
    (microsoft.public.exchange.admin)