And that almost killed our primary domain controller. For some reason all the forwarders tried to query this PDC instead of contacting their local domain controller so we have disabled the SID translation for now.
Couple of questions:
Is there any way to specify evt_dc_name in such a way that the universal fw uses its local domain controller instead of going to the PDC?
Could we potentially specify "evt_dc_name = localhost" to force the universal forwarders to translate SIDs locally? Will that work?
I know I could deploy different config files per sites simply by using whitelists and machine names, but this is not 100% reliable, how do you guys deal with event logs and sid translation in large infrastructures?
Finally, is there any way to tell the universal forwarders to cache SID previously translated for a certain period of time? it seems to me like a waster of resources to be querying the domain controllers all the time.
This behavior has been reported in splunk Version 6.2.1 and a Bug is logged.
Bug# SPL-92192-When evt_dc_name is not specified for Wineventlog input (and SID resolution) is enabled, use the local DC (not PDC) for SID resolution
For some customer patch for Bug SPL-92192was delivered that is to be deployed on the Universal Forwarder as that is where the SID translation is occurring..
Once the Patch is installed , below is what has been implemented -
• By default, auto DC discovery will be used to figure out which DC to bind to resolve GUIDs/SIDs.
• If config option to force PDC bind is specified, then PDC will get bound to resolve GUID/SIDs (overrides default)
• If evt_dc_name is specified and is an environment variable, then the value of the environment variable will be used to bind to resolve GUIDs/SIDs (overrides PDC bind config option)
• If evt_dc_name is specified and is DC name, then the DC name will be used to bind to resolve GUIDs/SIDs. (overrides PDC bind config option
look at inputs.conf.spec which has the exact options in question