[WinEventLog://Security] default for evt_resolve_ad_obj (Automatic Decoding of SIDs/GUIDs) broken in v6.2.5

[woodcock]

According to section "Resolve Active Directory objects in event log files" in all versions of this document:

http://docs.splunk.com/Documentation/Splunk/6.2.5/Data/MonitorWindowsdata

The following (direct quote) is true:

The evt_resolve_ad_obj attribute is on by default for the Security channel.

We upgraded to 6.2.5 and discovered that THIS IS NO LONGER TRUE (and caused us a HUGE headache). At some point between Splunk v6.? when everything was fine and v6.2.5 which is where we are now, Splunk changed (probably accidentally) the default value for parameter “evt_resolve_ad_obj” from “true” to “false”. So once we upgraded, the automatic decoding of SIDs and GUIDs stopped happening. If you are using Splunk for Enterprise Security or anything else that requires consistent WinEventLog Security events, this bug could be a huge problem for you.

[malmoore]

After some research I've determined that this was indeed changed for all versions of 6.2.

The documentation has been updated and an upgrade note has been added.

Apologies for any inconvenience.

[woodcock]

This was much more than a mere "inconvenience" for my client; it was a very big problem that WOULD NOT have been so painful to isolate (and maybe not have happened at all) had the documentation here mentioned it (so these should all be updated, too!):

http://docs.splunk.com/Documentation/Splunk/6.2.ALL-VERSIONS/ReleaseNotes/Knownissues
I suggest a note both in the "Data Input" and "Known Issues" sections!

[malmoore]

Technically it's not a known issue, but a reversion to a previous behavior that was not caught in the documentation. It has been added now.

Again, sincere apologies for the headache that this caused.

[woodcock · Accepted solution]

The solution is simple: do not rely on the default value and add the following explicit configuration string to all [WinEventLog://Security] stanzas inside of inputs.conf:

evt_resolve_ad_obj = 1

This can be a preventative change made to any version of Splunk so it should be made ASAP, regardless of your specific upgrade plans. If the change is preventative you are done; if it is corrective, then you must restart all splunk instances on effected forwarders.