Security

LDAP Authentication Best Practice 6.6.4

halbeisendv
Path Finder

We've been wondering whether modifying the LDAP BIND password through the Web GUI (clustered environment) or modifying /opt/splunk/etc/shcluster/APPNAME/authentication.conf and pushing from the deployer to the search head cluster is a better method. The Web GUI seems easier/faster. The greater goal is to push one authentication.conf to not only the search head cluster, but also a suite of other enterprise servers. Effectively, a one-stop shop for changing one LDAP BIND password in one place rather than several since our Enterprise server count is significant.

0 Karma
1 Solution

sloshburch
Ultra Champion

I would recommend controlling it all from an app that is deployed where needed. This will ensure you have captured the exhaustive set of configuration for the LDAP strategy in one app vs having it persist in various locations (or $SPLUNK_HOME/etc/system/local) - which may happen if you set this in the web UI.

This will also ensure you only have to update the config in one location and can have it updated whereever the config is needed. If you did the UI then you'd have to manually go to every UI, log in, navigate to the settings, and make the change there.

Also, you'll likely want the config attribute with the bind password to live in the app's local directory to ensure it becomes hashed (obfuscated) by Splunk after restart. If that config is put in the default directory of your custom app, there's a chance the hashed password gets put in the local directory while the unhashed persists in the default one.

View solution in original post

0 Karma

sloshburch
Ultra Champion

I would recommend controlling it all from an app that is deployed where needed. This will ensure you have captured the exhaustive set of configuration for the LDAP strategy in one app vs having it persist in various locations (or $SPLUNK_HOME/etc/system/local) - which may happen if you set this in the web UI.

This will also ensure you only have to update the config in one location and can have it updated whereever the config is needed. If you did the UI then you'd have to manually go to every UI, log in, navigate to the settings, and make the change there.

Also, you'll likely want the config attribute with the bind password to live in the app's local directory to ensure it becomes hashed (obfuscated) by Splunk after restart. If that config is put in the default directory of your custom app, there's a chance the hashed password gets put in the local directory while the unhashed persists in the default one.

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!

Self-Healing Pipeline Is Now Generally Available: AI-Powered CIM Compliance

Maintaining data integrity across security and analytics pipelines is an ongoing challenge. Data ...

[Puzzles] Solve, Learn, Repeat: Family Trees

This puzzle (first published here is based on finding grandparents and grandchildren (inspired by a question ...

Break the Build: Inside the KubeDoom Lounge at .conf26

    You step up to the machine. The pixelated corridors of a certain 1993 FPS load in front of you, EMP Pulse ...