whitelist1=528, 529, 538, 592 ,593, 624, 630, 636, 637, 513
index = winsecurity
Above is my configuration in inputs.conf. I suppose evtresolvead_obj is to prevent any resolving of GUID etc? But however it doesn't work! How do I fix this, this is for Windows XP.
Left is the intended result I want it to be shown on Splunk but however it was converted which is what I do not want.
The etcresolvead_obj attribute, which controls whether or not Splunk
Enterprise attempts to resolve SIDs and GUIDs when it monitors event log
channels, is now disabled by default for all channels. When you upgrade,
any inputs.conf monitor stanzas that do not explicitly define this
attribute will no longer perform this translation.
I suspect this may be a typo however, and they mean evtresolvead_obj. For the automatic translation to work, you will likely need to change this in your inputs.conf stanza from 0 to 1, like the following:
[WinEventLog://Security] disabled=0 start_from=oldest current_only=0 evt_resolve_ad_obj=1 checkpointInterval=5 whitelist1=528, 529, 538, 592 ,593, 624, 630, 636, 637, 513 index = winsecurity renderXml=false
Note: This attempts to resolve the object ID using the local machine's domain controller.
Installed the add-on and also turning value of evtresolvead_obj into 1.
My new stanza:
disabled = 0
startfrom = oldest
evtresolveadobj = 1
checkpointInterval = 5
whitelist1 = 528, 529, 538, 540, 592 ,593, 624, 630, 636, 637
index = winsecurity
renderXml = false
However my result is still the same.
To be able to provide some insight on the issue that you are currently experiencing please understand that Windows XP has not been a Support Operating System since Splunk 5.x for 64bit versions of XP & Splunk 6.0.14 for 32bit version of XP. The following is the last version of Splunk that Supported Windows XP:
Windows XP, 2003, Vista, Windows 7, 2008, 2008 R2 (64-bit) 5.0.18
Windows XP, 2003, Vista, Windows 7, 2008 (32-bit) 6.0.14:
If you are using any other version of Splunk on those Windows XP Systems this could cause the type of issue being seen. Can you advise of the version of Splunk that you are currently using on those Windows XP Systems as again this could be the direct cause of what you are experiencing.
What could be happening here, if you are using a newer version of Splunk and the Windows TA, could be caused by changes made to the way the Windows Event Viewer functions in Newer Versions of Windows which is what the Windows TA is designed for.
Once there is clarification on the version of Splunk being used this may provide further insight in regards to the issue being seen.
Please understand that there have been some changes to the Splunk Windows TA that may not work as expected when running on a Windows XP System as its not a Supported OS at this time. Now with that being said if you are using Splunk 6.x on the Windows XP Forwarder you would want to make sure that you have the following App/Add-ons installed:
Splunk App for Windows Infrastructure
https://splunkbase.splunk.com/app/1680/ --> Oldest version of Splunk supported is Splunk 6.3
Splunk Add-on for Microsoft Windows
https://splunkbase.splunk.com/app/742/ --> Oldest version of Splunk supported is Splunk 6.0
The following provides further information on the Splunk Add-on for Microsoft Windows and the Supported OSes as well as installation instructions:
I would also like to point out the following from the Splunk inputs.conf Spec Page:
evt_resolve_ad_obj = [1|0] * How the input should interact with Active Directory while indexing Windows Event Log events. * If you set this setting to 1, the input resolves the Active Directory Security IDentifier (SID) objects to their canonical names for a specific Windows Event Log channel. * If you enable the setting, the rate at which the input reads events on high-traffic Event Log channels can decrease. Latency can also increase during event acquisition. This is due to the overhead involved in performing AD translations. * When you set this setting to 1, you can optionally specify the domain controller name or dns name of the domain to bind to with the 'evt_dc_name' setting. The input connects to that domain controller to resolve the AD objects. * If you set this setting to 0, the input does not attempt any resolution. * Defaults to 0 (disabled) for all channels.
From the description of the issue that you have advised of the issue is that you are Wanting the AD SID translated into the Canonical Name. You would need to enable the evtresolvead_obj to get the Canonical Names for the Events being seen. With this setting set to 0 (disabled) then you will see the SID/GUID of the Event Data instead of the Canonical Name.
If you are not wanting the Canonical Name to display then you have the setting correct and would get the AD SID instead of the Canonical Name as you advised you are wanting to obtain. There would be no way to obtain a Canonical Name without using AD Resolution against the AD SID inside of the Event. The default behavior is to "NOT CONVERT" to the Canonical Name which is what you are seeing.
If you change evtresolvead_obj from 0 to 1 and restart Splunk this should resolve the issue that you are seeing. Now you will want to make sure you make this setting change on both the Universal Forwarder as well as the Indexer/s where you have the the Windows TA installed. If after making this change you are not seeing the desired results I am going to suggest you submit a Support Case for further assistance.
What you are seeing in the Event Viewer are IDs that have been converted for display. But what is stored locally and what is then submitted to Splunk are the SID values that you see on the right. So it's not that Splunk is converting them to GUIDs; rather, Splunk is indexing GUIDs and not converting them.
Here is a good discussion of options for converting SIDs to friendly names: