Getting Data In

system sslPassword not hashing

sloshburch
Ultra Champion

My universal fowarders are not hashing the sslPassword file stored at the etc/system location after restart. Instead, the hash is being created in a new outputs.conf in the SplunkUniversalForwarder local folder but still leaving the unhashed value in the etc/system/local/outputs.conf. I specifically moved the ssl config to etc/system because of the limitation of apps being unable to hash the sslPassword attribute.

Please help me make sure my sslPassword is hashed?

Config highlights:
This is the file after a restart:
/opt/splunkforwarder/etc/system/local/outputs.conf
[tcpout]
defaultGroup = splunk
sslCertPath = $SPLUNK_HOME/etc/auth/server.pem
sslPassword = password
sslRootCAPath = $SPLUNK_HOME/etc/auth/cacert.pem

(pulled from deployment server)
/opt/splunkforwarder/etc/apps/forwardingPropsToProdSplunk/default
[tcpout:splunk]
server = <hostname>:<port> #Replaced for posting in this forum
forwardedindex.0.whitelist = _internal

This is what is generated:
/opt/splunkforwarder/etc/apps/SplunkUniversalForwarder/local/outputs.conf
[tcpout]
dnsResolutionInterval = 300
sslPassword = $1$wlv2PW4J2Hah
useClientSSLCompression = true

0 Karma
1 Solution

sloshburch
Ultra Champion

It turns out that the sslPassword can only be hashed when it is in an outputs.conf in a local folder.

Support believes that the following two statements in the outputs.conf documentation are incorrect (but they are looking into it to be sure):

  • Starting with 4.2, the [tcpout] stanza is no longer required.
  • Starting with 4.2, this attribute is no longer required.

I was able to put the sslPassword in the outputs file in the local folder of an app that I use to specify the indexer and ssl configuration and the sslPassword autohash on the forwarders side when the forwarder restarted.

View solution in original post

sloshburch
Ultra Champion

It turns out that the sslPassword can only be hashed when it is in an outputs.conf in a local folder.

Support believes that the following two statements in the outputs.conf documentation are incorrect (but they are looking into it to be sure):

  • Starting with 4.2, the [tcpout] stanza is no longer required.
  • Starting with 4.2, this attribute is no longer required.

I was able to put the sslPassword in the outputs file in the local folder of an app that I use to specify the indexer and ssl configuration and the sslPassword autohash on the forwarders side when the forwarder restarted.

sloshburch
Ultra Champion

I am using a deployment server. I merely showed the resulting forwarder. Ideally I would be able to use the DS to push the cert info but the result is that the deployed app will not have a hashed password value after restart. I do understand config file precedence in the sense that I undersand the more specific wins over the more general (app vs system).

Does that help clarify? Sorry if my prior post was unclear. Thanks for your help on this.

0 Karma

bmacias84
Champion

I am sorry I confused as to why you are not using deployment server to deploy an app with all those settings. Also do you under stand config file precedence? I am currently doing what you want I'd be happy to detail its lay out. I also think I know why your password is not hashing correctly.

0 Karma
Got questions? Get answers!

Join the Splunk Community Slack to learn, troubleshoot, and make connections with fellow Splunk practitioners in real time!

Meet up IRL or virtually!

Join Splunk User Groups to connect and learn in-person by region or remotely by topic or industry.

Get Updates on the Splunk Community!

Announcing Modern Navigation: A New Era of Splunk User Experience

We are excited to introduce the Modern Navigation feature in the Splunk Platform, available to both cloud and ...

Modernize your Splunk Apps – Introducing Python 3.13 in Splunk

We are excited to announce that the upcoming releases of Splunk Enterprise 10.2.x and Splunk Cloud Platform ...

Step into “Hunt the Insider: An Splunk ES Premier Mystery” to catch a cybercriminal ...

After a whole week of being on call, you fell asleep on your keyboard, and you hit a sequence of buttons that ...