/opt/splunkforwarder/etc/passwd

[tinkster]

I'm trying to install splunkforwarder via saltstack on ~ 40 servers. This works well as such, but handling the password change (a different random password for each server) is proving a bit more tedious than we were hoping for.

For the time being I'm using my workstation and a bash-script to generate passwords over and over, by "rm'ing the current passwd, setting a new password programatically, cp'ing the generated passwd-file to passwd.FQDN, and saving the password to a seperate ASCII file so I can later add it to a keepass DB.

Then I copy the generated passwd files to the servers via jinja template and a salt-state.

How can I generate the passwd-hashes w/o having to recreate the passwd file over and over, so I can do this locally on the salt-master than than my desktop?

[mdsnmss]

Here is something that we use to accomplish this using server classes and deployment apps.

When a universal forward initially gets pointed to the deployment server the client name will be a unique GUID. We have an app that will set the "Client Name" to the same value for all systems (Host Name remains a unique value). With this configuration we are able to set up server classes that will catch all systems initially and deploy apps to the server briefly until the like value is set and then those apps will be removed from the system. We do this so that scripts can be deployed and run to do postinstall cleanup and to change the default password and then have the scripts removed right after.

The app that changes the password consists of two scripts, a batch file and a shell file, and an inputs.conf that contain paths for both Windows and *Nix installations to call the script. The scripts will generate a random password based on written functions and then call the "splunk edit user" command to change the password. The inputs is to set scripted input at an interval. Depending on how often your Universal forwarders are set to poll the deployment server and the interval specified in the inputs.conf for script execution the script may execute multiple times. After the first time it should just fail until the app is removed. You could probably include in the script to write the password to a file in a temporary network location if you needed it saved, though, you would probably have to put in a check to make sure the password was changed successfully since it may try to execute multiple times.

[mdsnmss]

To add onto this, here is an example of the bash script we use to install universal forwarders to all have a random password. We don't save the password as it is easy to reset with access to the filesystem and access is rarely a need to directly connect to a universal forwarder in our instance. If the password needs to be saved you could probably add in there to have it write password and hostname to a file somewhere to retrieve later. We have a similar script for Windows forwarders as well.

#!/bin/bash

groupadd -g 777 splunk
useradd -m -u 777 -g splunk splunk
tar -xzvf <forwarder-version>.tgz -C /opt/
chown -R splunk:splunk /opt/splunkforwarder/
su - splunk -c "/opt/splunkforwarder/bin/splunk start --accept-license"
su - splunk -c "/opt/splunkforwarder/bin/splunk set deploy-poll <deployment-server>:8089 -auth admin:changeme"
splpassword=$(head -c 500 /dev/urandom | sha256sum | base64 | head -c 32)
su - splunk -c "/opt/splunkforwarder/bin/splunk edit user admin -password $splpassword -auth admin:changeme"
su - splunk -c "/opt/splunkforwarder/bin/splunk restart"
/opt/splunkforwarder/bin/splunk enable boot-start -user splunk

[yong_ly]

Maybe I'm not understanding this correctly..

Why do you need to have different passwords for all the forwarders? Generally there's only really the admin user that's defined on the universal forwarders and you should change that when you install it. You can also script it using the CLI

/opt/splunkforwarder/bin/splunk edit user admin -password YOUR_NEW_PASSWORD -auth admin:changeme

where admin:changeme is the default user:password combination.

The only user who should be able to run the splunk binary is 'splunk' user or root.

To make it even easier, if you set up a deployment server, you can control all your forwarders from there and only have to remember the username/password for the deployment server.

[tinkster]

I don't know about your work-place, but here having uniform passwords for accounts (individual or service) over a fleet of machines is considered bad practice.

What you describe above is how I do deal w/ the password problem at the moment, and it doesn't scale well.

[matthewroberson]

tinkster. did you ever come up with a solution that scales?

[tinkster]

Nope 😕 ... no such luck. Sorry mate.

[Ayn]

It's worth to note also that as long as the default password hasn't been changed the forwarders will refuse any remote authentication. So while it may seem silly to keep the default password it's something one could only use with local access to the system anyway.