topic Re: Splunk Universal Forwarder 6.1.1 ignoring evt_dc_name setting in Getting Data In

Splunk Universal Forwarder 6.1.1 ignoring evt_dc_name setting

gn694 — Mon, 28 Sep 2020 16:56:32 GMT

We recently upgraded the Splunk Universal Forwarder to version 6.1.1 on our Domain Controllers.

Splunk-winevtlog.exe seems to always bind to the DC holding the PDC emulator role. In an attempt to distribute the load of resolving SIDs in events from their Security logs, I attempted to configure Splunk on our DCs to use themselves for resolving SIDs using the following line in the [WinEventLog://Security] stanza of inputs.conf:
evt_dc_name = localhost

After restarting Splunk, I verifed that splunk-winevtlog.exe was still contacting the PDC by looking at the TCP connections made by splunk-winevtlog.exe in Resource Monitor.
Looking in splunkd.log, I do not see any mention of which DC is was binding to for the last restart. The last mention of which DC it was binding two is from over a month ago just before I upgraded the Splunk Universal Forwarder from 4.3 to 6.1.

Looking at our other servers that are still running Splunk 4.3, every time I restart Splunk I get the following lines in splunkd.log:
WinEventLogChannel - init: Binding to DC to translate guids/sids for channel='Security'
WinEventLogChannel - EvtDC::bind: Found DC='\DC1.domain.com', DCsite='Default-First-Site-Name', ClientSite = 'Default-First-Site-Name', Domain='domain.com'
WinEventLogChannel - init: Successfully bound to DC, dc_bind_time=32 msec

Is the evt_dc_name not supported anymore in Splunk 6.1? Is there a differnet way to configure which DC Splunk binds to now for resolving SIDs in the Security log?

Re: Splunk Universal Forwarder 6.1.1 ignoring evt_dc_name setting

dstaulcu — Fri, 03 Oct 2014 01:17:24 GMT

http://answers.splunk.com/answers/171507/universal-forwarder-wineventlog-handler-affinity-f.html

Re: Splunk Universal Forwarder 6.1.1 ignoring evt_dc_name setting

dstaulcu — Mon, 28 Sep 2020 18:01:38 GMT

TLDR:
-had problem too, have a workaround

[WinEventLog://(System|Application|any other channels you don't want resolution for)]
evt_resolve_ad_obj = 0 # must explicitly do this, default of 0 isn't working (bug)
evt_dc_name = dnsNameOfAdDomain # results in DNS round robin among DCs
evt_dns_name = dnsNameOfAdDomain # results in evt_resolve_ad_obj=0 actually being honored

Don't ask me how I figured this out.. I'll just admit I was highly motivated for a workaround after learning that our Splunk instance was responsible for DDoS of our Active Directory Infrastructure services.

Note - these problems still exist in 6.2 and these workarounds still work.