Controlling 4662 Messages in the Windows Security Event Log

You’ve just installed the Splunk App for Windows Infrastructure, or its friend the Splunk App for Exchange. You’ve followed all the instructions, placed the Universal Forwarders on the domain controllers, and configured everything according to the documentation. Now your license is blowing up because you are getting too many EventCode=4662 in the Windows Security Event Log. How did this happen?

Security EventCode 4662 is an abused event code. It is used for directory access, like this:

An operation was performed on an object. 
Subject : 
    Security ID: NT AUTHORITY\SYSTEM 
    Account Name: EXCH2013$ 
    Account Domain: SPL 
    Logon ID: 0x177E5B394
Object: 
    Object Server: DS 
    Object Type: domainDNS 
    Object Name: DC=spl,DC=com 
    Handle ID: 0x0 
Operation: 
    Operation Type: Object Access 
    Accesses: Control Access 
    Access Mask: 0x100
    Properties: Control Access 
        Replicating Directory Changes
        domainDNS 
Additional Information: 
    Parameter 1: - 
    Parameter 2:

These are logged all the time and the more complicated your environment, the more of them you will see. They are also logged for other reasons, like when admon first starts – you’ll get one per record that admon reads, resulting in a large number of 4662 events that will quiet down after a while. Personally, I don’t see a whole lot of value in these messages. You can review another blog post for information on how to control the storm of events from admon initialization. Unfortunately, we need 4662 events for their other – rarer – purpose. That’s an event like this:

An operation was performed on an object. 
Subject : 
    Security ID: SPL\Administrator 
    Account Name: Administrator 
    Account Domain: SPL 
    Logon ID: 0x133857101 
Object: 
    Object Server: DS 
    Object Type: groupPolicyContainer 
    Object Name: CN={BFE075D4-186E-4762-A534-E993DEA898E0}CN=Policies,CN=System,DC=spl,DC=com 
    Handle ID: 0x0 
Operation: 
    Operation Type: Object Access 
    Accesses: Write Property 
    Access Mask: 0x20 
    Properties: Write Property 
        Default Property Set flags 
        groupPolicyContainer 
Additional Information: 
    Parameter 1: - 
    Parameter 2:

We need this one as it deals with a change to a group policy – something we report on within the Splunk App for Windows Infrastructure. However, group policy is the only time we need EventCode 4662. This allows us to filter out the other things – things we don’t need.

Sometimes your security policies require AD access monitoring, but most of the time it’s just noise. How do you log what is required but throw away what isn’t. Fortunately, Splunk Universal Forwarder v6.1 came to the rescue. We added a feature to black list and white list on a regular expression. In the case of the Security Windows Event Log, we need something like this:

[WinEventLog://Security]
blacklist1=EventCode="4662" Message=”Object Type:\s+(?!groupPolicyContainer)”

The black list is a set of key=regex pairs. The list of keys are things like “EventCode” and “TaskCategory” – i.e. the event log keys, not the Splunk fields. In this case we are going to black list EventCode 4662, but only when the Object Type is not groupPolicyContainer. You can do the same for the NT5 (Windows Server 2003) world by using EventCode=566. For more information on this use of regular expressions, see the tutorial at http://www.regular-expressions.info/lookaround.html

So, given all the advice we’ve given over this blog, here is our suggested WinEventLog:Security stanza. It’s fairly simple:

[WinEventLog://Security]
disabled=0
current_only=1
blacklist1=EventCode="4662" Message=”Object Type:\s+(?!groupPolicyContainer)”
blacklist2=EventCode="566" Message=”Object Type:\s+(?!groupPolicyContainer)”

Place this in your Splunk_TA_windows\local\inputs.conf file and push it out to your domain controllers. You should get all the regular Security Event Log entries, but the 566 and 4662 codes are filtered to only provide information on group policy containers. Don’t forget to also follow our advice on admon usage to further reduce the data you store.

Of course, you will have to upgrade your Universal Forwarder to the latest version (v6.1.1 at the time of writing), but the gains for your license usage will be worth it. In addition, this will not reduce the load on your domain controller – we will still do all the queries we need to do to turn SIDs and GUIDs into real names. However, they will no longer hit your license. Just ensure your log rotation settings for your security log are set appropriately.