On Thu, Jun 25, 2009 at 1:09 PM, Miller Bonnie L.<[email protected]> wrote: > You need to click the drop-down by "keywords" and select "Audit Failure".
That was it! Thanks!! I spent an hour digging through the MSFT docs and searching the web and couldn't find anything. You always have the answers, Bonnie! :) > I think it's a pain compared to the old way, but I'm sure they have SOME kind > of reason for changing it. I'm sure they have a reason, but was it a good one? :) <RANT> I'm *REALLY* unimpressed by the security logging changes in Vista, especially after MSFT was telling us for years that Vista would fix all the deficiencies in the Windows security log. I guess they figured that sprinkling magic business pixie dust (also called "XML") on the logging subsystem would be all they needed to do. If anything, Vista is worse than before. It used to be that the "User" column only showed the relevant user ID for some events. The rest of the time it was "SYSTEM" or whatever. I had hoped Vista would change this. It sure did -- now the "User" column *NEVER* has any useful information in it! Other complaints: Trying to implement permissions auditing, I kept seeing messages with a "Task Category" of "Subcategory could not be determined". WTF?!? Microsoft, you *wrote* the fraking OS, how can you not know what generated the event? I'm supposed to trust an audit subsystem that can't figure out where it's own events came from? This is Event ID 4670, description says "Permissions on an object were changed", for those of you keeping score at home. If you enable policy change logging for any of the filtering subsystem subcategories, you get hundreds (if not thousands) of log messages during startup as each rule is loaded. Who the frell thought that would be helpful? Fortunately for me, I'm not using the filtering subsystem on these computers, but I'd be scared if I was. Trying to enable auditing on changes to file permissions is still a lost cause. Vista *still* does access auditing on *open*, against the open call's parameters. It appears that, in practice, just about every program (including programs that come with Windows) asks for WRITE_DAC on file open, even though the program never touches the DACL. The practical upshot is that Windows generates an audit message for *every file opened for writing*, when what you wanted was notification of DACLs being changed. Microsoft, this has been a problem since at least NT 4.0, how many decades is it going to take to fix this??? Privilege auditing is still a joke. If you want a flood of useless messages, enable this one. Microsoft event admits this: “Do not enable auditing for privilege use because of the high volume of events that this configuration would generate.” (http://technet.microsoft.com/en-us/library/cc875806.aspx) MICROSOFT, WHY DID YOU DO THIS IF IT WASN'T GOING TO BE USEFUL?? </RANT> -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
