How are Splunk passwords encrypted in inputs.conf and outputs.conf?

[samlll42]

Could someone please document how the Splunk passwords are encrypted (in inputs and outputs.conf) so that we can setup our configuration management tools (Chef, Puppet etc...) to properly encrypt the passwords in the conf files without provisioning clear password and restarting Splunk a each chef run?

Just a shell, perl, python or other example using the etc/auth/splunk.secret would help a LOT

we figured out how dbconnect does (even had to fix a bug when passwords contains a "=") - can't find any details on the $1$xxxxxxxxxx passwords used in inputs.conf and outputs.conf

Thanks!!

[keinoda]

Challenge accepted. Problem solved.

http://maratto.blogspot.com/2016/03/reverse-engineering-splunk-password.html

[dougmartin]

What is the "xor 'DEFAULTSADEFAULTSA....'" string we xor with?

[dmourati]

I read this as just the string DEFAULTSA repeating to match the length of the string constructed by joining the first 16 bytes of the splunk.secret and your plaintext password.

[yannK]

Here is the DOC :
http://docs.splunk.com/Documentation/Splunk/6.2.3/Security/Deploysecurepasswordsacrossmultipleserver...
the password to be encrypted are usually : the one for ssl in outputs.conf, in inputs.conf, in web.conf, and the ldap bind passwor din authorize.conf

To clarify the behavior
When splunk starts,
If it finds a password field, it will check if it is encrypted of in clear.
- if encrypted, it will leave it
- if encrypted and if the splunk.secret cannot decrypt it, splunk will report an error in splunkd.log and disable ssl.
- If in clear, splunk will encrypt it using the “$SPLUNK_HOME/etc/auth/splunk.secret”
the password will be saved in the “local” configuration (it will not touch the "default”)

The consequences are :
- you may have an encrypted password in local, and a clear one in default or you may end-up with an encrypted one on local only.
- If you are copying a configuration from a forwarder to another, it may not be able to decrypt the password.
- If the configuration contains a clear password and is pushed by a deployment server, then it will be encrypted on the forwarder, therefore modify the file and may force a looping resinstallayion if you deployment tool are checking the CRC of the files (chef, puppet, or splunkdeployment server)

[Georgiev]

Working link at https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/Deploysecurepasswordsacrossmultipleserve... now

[isoutamo]

And link to instructions how to generate hashed password on cli Create admin credentials for automated installations with the 'hash-passwd' CLI command

[starcher]

Make sure you are grabbing the matching splunk.secret from $splunk_home/etc/auth then you can deploy the config files with the hashes already in place.

[samlll42]

Thanks - thats a possibility that we have thought about, we would still prefer to know how the password is encrypted so we can just encrypt it dynamically and change it dynamically on a regular basis. We are doing it just fine with DB Connect. Some of our customers require regular service account password changes for regulatory reasons.
Thanks

[starcher]

I would say just use a test instance of Splunk that has the desired splunk.secret in place. Set the password then copy the resulting encrypted section out. Then push both splunk.secret and the conf file together. Working fine for us with Puppet.

[samlll42]

Thanks - I understand splunk.secret is the key. The question is how can a inputs/outputs.conf password be encoded with the key - what exact algorithm is used?

I don't have a problem propagating the secret from one server to another. I just want to provision encoded passwords when I run chef, without having to pre-encoded them and always use the same splunk secret.