Hi, I only bring this up because I can't tell you how often I have run into power users and server administrators trying to debug some application problem who were convinced they had no "permission" problems - because their security log showed nothing.
Not only did they not understand that auditing had been off - they had no idea how to turn it on to trace a problem to its roots. Auditing is a key aspect of running a secure system. Shipping a "secure" operating system with failure auditing turned off borders on a security vulnerability in my mind. >> create a huge security log file depending upon the configuration of the security log file. << If by default it would only audit "failure", then the log file should not be huge at all. I have never set up a machine (server OR workstation) where failure logging was off and never encountered any log size issues. In, fact if there ARE failures, then in most cases you do WANT to know about it. There may be certain folders where you expect "logon" errors, so you adjust the auditing for those folders. By inspecting the security log I've often identified client site problems (e.g., failed attempts to update web site files by the application) and was able to fix things for them before they even realized that there WAS a problem with their web site. >> Second, auditing can produce a lot of data, even if configured very narrowly << Yes, "success" auditing could. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax: +1 201 934-9206 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John T (Lists) Sent: Friday, November 03, 2006 02:37 AM To: declude.junkmail@declude.com Subject: RE: [Declude.JunkMail] Can someone help? > To turn on auditing (which I never understand, why it's not turned on > by default in Windows) - MS gives you quite a run-around: First, in the NT 4.0 days, auditing could easily use up resources and create a huge security log file depending upon the configuration of the security log file. Second, auditing can produce a lot of data, even if configured very narrowly, that one then has to wade through. > - Windows Explorer - go to the root directories of each disk, > properties, security, Advanced, Auditing, add the "Everyone" user and > mark the "failed" > checkmarks for the complete list of accesses (I personally also audit > successful change permissions and take ownership). Apply this and let > it propagate to all subfolders. > > - Local Security Policy - to to "Local Policies", "Audit Policies" and turn > on all failures. (I personally also audit successful account > management and > audit policy changes). Actually, what I do for my servers and for client, is in the Default domain policy (local security policy if no domain,) enable those auditing policies that are appropriate (not all are needed for normal business) AND enable both success and failure on object access. NOTE that auditing of object access is the ONLY auditing that requires 2 steps. All other auditing takes affect without further intervention. Then, only when needed, (or if by company policy they want to track changes to files in a particular folder such as say payroll data sheets) I go to the folders properties that I want to audit and enable auditing again for what is needed only. Once I am done auditing, I disable on that directory. John T eServices For You "Life is a succession of lessons which must be lived to be understood." Ralph Waldo Emerson (1802-1882) --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
