Windows Server auditing and the Security event log have really changed in Windows
Server 2008 and Windows Vista, and I'm glad to say that most of the changes
are good. The Security log is a little cleaner and a little easier to understand,
but you still need a lot of knowledge about Windows security and experience
in decoding mysteries to really "grok" it. I've spent the last decade deep in
the bowels of Windows security and auditing, and lately I've been concentrating
on Windows 2008 and Vista, so maybe I can help bring you up to date with the
changed event ID numbering, the new, more granular way that audit policy is
handled in Windows 2008 and Vista, the XML log format, and enhancements to the
Microsoft Management Console (MMC) Event Viewer snap-in.
New Event IDs
If you're already familiar with the Windows Security log, the first thing you'll
notice when you open Event Viewer in Windows 2008 is that none of the old event
IDs shows up. That's right! Just when you thought you knew the difference between
event ID 528 and event ID 529, Microsoft goes and changes the IDs. Actually,
Microsoft kept many of the events found in Windows Server 2003 but added 4,096
to the event ID. For instance, event ID 528 in Windows 2003 is event ID 4624
in Windows 2008.
I'm actually glad Microsoft changed all the event IDs because the company also
completely revamped the fields in the description of each event. In Windows
2003, Microsoft kept event IDs from Windows 2000 Server but changed the events
that they track, combined multiple event IDs into one, and changed the order
of fields in the descriptions. This wreaked havoc on automated log analysis
software. The new numbering lets you add Windows 2008 systems to your environment
and begin collecting logs without throwing off your existing filter, alert,
and reporting definitions. You will have to add new definitions for the
new event IDs.
Audit Policy Subcategories
One of the most frequent questions I've gotten from people over the years about
the Security log is how to stop Windows from logging so much #%*@&! noise
(i.e., useless events that make finding the important events that much more
difficult). My response has always been, "You can't configure the noise out
of the Windows Security log; that's the job of your log management solution."
Well, Microsoft has taken a small step in
the direction of helping you quiet things down.
The company didn't do it the way I would
have, which would have been to introduce a
firewall-like rule set that would let you define
on an event-ID-by-event-ID basis criteria for
whether to record the event. Instead, Microsoft
expanded the 9 audit policies (aka categories)
in Windows 2003 to 52 in Windows 2008.
Actually, Microsoft kept the existing 9 policies and broke them into subcategories,
each of which you can enable for success and/or failure events. If you like,
you can still manage audit policy with the 9 top-level categories. Figure
1 shows the 9 categories and 52 subcategories. (See http://www.ultimatewindowssecurity.com/newauditpol
for a table that decomposes the 9 categories into their respective subcategories
and provides a brief description of what kind of events and activity each category
tracks.)
This is all good news so far. In fact, you
can eliminate a number of old noisy events
with this more granular audit policy as well
as disable some of the new event IDs logged
by Windows 2008, which are pretty noisy
as well. For instance, most of you will want
to disable the Filtering Platform Packet
Drop and Filtering Platform Connection
subcategories, which are extremely noisy
because they record network traffic at the
packet level.
But here's some bad news: You can't manage audit policy at the subcategory
level by using Group Policy. Microsoft added the 52 new subcategories but didn't
update Group Policy with new policies to enable or disable the subcategories.
In fact, you won't find these subcategories anywhere in the GUI. The only way
to enable or disable at the subcategory level is with the Auditpol command.
The Microsoft article "Security auditing settings are not applied to Windows
Vista client computers when you deploy a domain-based policy" (http://support.microsoft.com/kb/921468)
proposes a method for configuring audit subcategories via startup scripts defined
via Group Policy, but the technique is something Rube Goldberg would be proud
of.
Working with Audit Policy
Let's delve a little into the Auditpol command as well as how Windows resolves
possible conflicts between the audit policy you configure in Group Policy Objects
(GPOs) and the subcategory policy you can configure with Auditpol. To find out
the current status of your 52 audit subcategories, just log on to the desired
system and type
auditpol /get /category:*
at the command prompt. This command produces output similar to that shown in
Figure 1. As you can see, the 9 top-level
categories are listed with their subcategories below and whether each is enabled
for success and/or failure.
To change auditing for a subcategory, just
run auditpol with the /set command and specify the subcategory and whether
to enable success and/or failure events. For instance,
auditpol /set
/subcategory:"System Integrity"
/failure:enable /success:enable
enables the System Integrity subcategory for
both success and failure events.
But what if you configure audit policies for the 9 top-level audit categories
in Group Policy that conflict with policies set for the 52 subcategories in
Auditpol or vice versa? For instance, let's say your computer W08-YHWH resides
in the Servers organizational unit (OU) in Active Directory (AD). You edit a
GPO linked to that OU to disable the Audit logon events (aka Logon/Logoff)
top-level category for both success and failure. Then you log on to W08-YHWH
and, with Auditpol, you enable the Logon subcategory for success and failure.
What will the final outcome be?