Introducing Auditing Changes in Windows 2008

Introducing Auditing Changes in Windows 2008

  • Comments 5
  • Likes

Hi, Dave here. Auditing is a wonderful tool and we highly recommend that everyone use it on their servers.  It can really help out with diagnosing problems and determining the root cause, and of course with protecting your servers and your network.  However, over-auditing your servers can be a bad thing.  The reason that too much auditing is bad is that it can flood the event logs with extraneous information.  This makes finding the events that you DO need very difficult and time consuming.  Not to mention that your security logs can only hold so many events – here in DS, we routinely run up against systems where the security log wraps every few minutes, making those logs almost useless for any troubleshooting.

The resolution to this problem, of course, is only audit stuff you really need to audit.  That’s easier said than done though.  Or at least it used to be.

You’re probably familiar with this from Windows Server 2003:

image

This is the default audit policy that comes in when you install your first 2003 domain controller.  As you can see, we turn on auditing for several categories.  This generally results in some number of events in the security event logs, but not so much as to cause problems.  Obviously a lot depends on the domain and what people are doing on the network.

What many administrators do is add to this default policy.  In fact, in order to comply with legal requirements like Sarbanes-Oxley, many companies are required to add to this policy.  It’s often in these scenarios where the amount of auditing on the system begins to cause problems for administrators who need to be able to find and act on events in the logs.

In Windows 2008 we decided to change the way auditing works to help with this problem.  If you install a brand new Windows 2008 domain controller in a fresh domain, here’s what you get:

image

Don’t panic!  You’re still getting an audit policy on your domain controllers; it’s just not visible here.  Open up a command prompt and run auditpol.exe /get /Category:* and here is what you’ll see:

image

Obviously we’ve added quite a bit.  You’ll notice that the original top-level categories, like Account Logon and Object Access, are still there.  There are  also a few new categories as well.

So now we have all these cool new subcategories which you can use to manage auditing in a much more granular way.  This is really helpful for making sure that you’re only auditing the things you need.  For example, if we were trying to troubleshoot a replication problem and wanted to enable some auditing to see what was happening, instead of turning on the entire DS Access category, we would just turn on the subcategory for Directory Service Replication.  Now we can see detail as specific as:

===

Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 10/11/2007 6:07:13 PM
Event ID: 4932
Task Category: Directory Service Replication
Level: Information
Keywords: Audit Success
User: N/A
Computer: 2008SRV10.cohowinery.com
Description:
Synchronization of a replica of an Active Directory naming context has begun.

Destination DRA: CN=NTDS Settings,CN=2008SRV10,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=cohowinery,DC=com
Source DRA: CN=NTDS Settings,CN=2008SRV11,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=cohowinery,DC=com
Naming Context:    DC=ForestDnsZones,DC=cohowinery,DC=com
Options: 19
Session ID: 46
Start USN: 16449

===

Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 10/11/2007 6:07:13 PM
Event ID: 4933
Task Category: Directory Service Replication
Level: Information
Keywords: Audit Success
User: N/A
Computer: 2008SRV10.cohowinery.com
Description:
Synchronization of a replica of an Active Directory naming context has ended.

Destination DRA: CN=NTDS Settings,CN=2008SRV10,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=cohowinery,DC=com
Source DRA: CN=NTDS Settings,CN=2008SRV11,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=cohowinery,DC=com
Naming Context:    DC=ForestDnsZones,DC=cohowinery,DC=com
Options: 19
Session ID: 46
End USN: 16483
Status Code: 0

===

The benefit of doing things this way is that it allows us to get much more specific about what we audit, and the net is that we’ll be able to audit more meaningful information while generating less noise in the event logs.

To manage the new auditing you will need to use auditpol.exe.  If you try to set up a group policy you’ll only have the top-level categories available and turning one of those on turns on all the subcategories underneath it.  However, all hope is not lost.  You can still centrally administer your audit policies, you just have to do it via a script.  Ned Pyle wrote KB article 921469 that talks about how to do this for Vista – the process is exactly the same for 2008.

The main reason that the policies only manage the top-level categories is backwards compatibility.  2003 and XP don’t understand the granular auditing subcategories, and their security client-side extensions (the engine that reads the policies and implements the settings) wouldn’t really know what to do with a policy containing those settings.  The amount of code work required to enable backwards compatibility for the policy engine and still allow the policy to manage the new subcategories is pretty extensive, and so the product team wasn’t able to get the change in for 2008 RTM.

If you’d like to examine all the possible audit events that can be generated in Windows Vista or Windows Server 2008, you can execute the following command (in an elevated CMD prompt as an Administrator):

wevtutil gp Microsoft-Windows-Security-Auditing /ge /gm:true

Here’s a snippet from the output:

event:
    value: 4729
    version: 0
    opcode: 0
    channel: 10
    level: 4
    task: 0
    keywords: 0x8000000000000000
    message: A member was removed from a security-enabled global group.
Subject:
        Security ID:            %6
        Account Name:           %7
        Account Domain:         %8
        Logon ID:               %9
Member:
        Security ID:            %2
        Account Name:           %1
Group:
        Security ID:            %5
        Group Name:             %3
        Group Domain:           %4
Additional Information:
        Privileges:             %10


Obviously all of this is just the tip of the iceberg – there are around 360 events here, after all.  You may see us talk about more specific auditing scenarios from time to time here.  You can also find quite a bit more information related to auditing can be found at the Windows Security Logging and Other Esoterica.

- David Beach

  • PingBack from http://beach.wpbloggers.com/?p=5537

  • Hi, Ned here again. Today I’m going to show some interesting new features of Auditing in Windows

  • I hope this post will act as a good reference point to be able to quickly understand the good and bad

  • Will we have a graphical interface later?

    Not easy to administrate and have troubles with french version....

  • Hi,

    Then's definitely a high priority for the Product Group. I do not have any kind of word on when this might occur though, unfortunately.

    - Ned