Make Splunk Do It: How to Decrypt Passwords Encrypted by Splunk

Splunk is great at keeping plain-text passwords out of configuration files. Each Splunk server generates its own salt when it starts for the first time. So, this means the encrypted password can’t just be copied to another Splunk server. However, I need to be able to copy the configurations from the existing infrastructure when we’re setting up a new Splunk server. In this blog post, I’m going to give you a how-to on streamlining this entire process by making Splunk do the work for you when it comes to decrypting passwords.

The most common password that I need to decrypt is the LDAP bindDNpassword, which is used to authenticate Splunk users. The only alternative is to reset the password for the service account and update it everywhere that uses it. There has got to be a better way!

I have found a way to make Splunk decrypt this password for me. I use a new dev instance of Splunk to perform this procedure, to eliminate the risk of breaking a production server. It needs to be a fresh install of Splunk that hasn’t been started yet. Splunk keeps its salt in $SPLUNK_HOME/etc/auth/splunk.secret. So, I need to copy this file from the source server to my dev Splunk instance. After the file is copied over, I can then start Splunk.

Now, I can create a Splunk app with an app.conf file that has the password. From the app.conf spec the format for the credential is:

So, I add the following to $SPLUNK_HOME/etc/apps/test_app/local/app.conf, for example:

Then, I create the following script in $SPLUNK_HOME/etc/apps/test_app/bin/test.py:

NOTE: Make sure you change the app name and the Splunk username and password to match your environment. I used “test_app” for my app name, and my dev instance of Splunk just uses the default Splunk username/password.

Once I restart Splunk, I am ready to run the script to decrypt this password:

I get the following output:

Now, I can use that password on my new Splunk server. I also make sure to delete my dev Splunk instance so that when I need to test something else, it’s not using the splunk.secret from my production environment.