Search Head Cluster: How to properly implement LDAP authentication?

[jeffland]

I am trying to use LDAP authentication on my SHC.

Follwing the advice from here, I set up a working LDAP authentication and user role on a separate system and placed the resulting .conf files in an app with the intent of distributing that app to my cluster. I then deleted the line bindDNpassword from the authentication.conf in the app, as the hashed value there of course doesn't work to log in to the LDAP server. I also created a new authentication.conf with the same stanza as in the file of the app, and added the bindDNpassword line back in there, with the password entered in cleartext. The link above mentions that this would get encrypted on startup.
I then placed the file with the single stanza and cleartext password line in each SHC member's etc/system/local directory and proceeded to deploy the app through the deployer. After the restart of each machine, I was able to log on to the SHC members with authentication provided via LDAP without any trouble, but the password in etc/system/local/authentication.conf stays there in cleartext even after a second deliberate rolling restart of the SHC.

So now I'm wondering: is this actually the official way to do it, placing a separate authentication.conf on each SHC member manually, with the cleartext LDAP password in it? And, more importantly, is there a reason why the password stays there in cleartext (or something I can do about that)?
Also, I read somewhere (and personally agree) that it is a good idea to test the settings on another separate machine before deploying to the SHC. For this step, I wonder if that would work the same way as above - having to enter the password in cleartext into the .conf file (though without splitting the file into two places).

[thomasbn]

To anyone having trouble with the /system/local authentication.conf files not hashing their values:

try removing the files on each SH member, doing a rolling restart or app push from your deployer
re-create those same files on each search head. Should only take a minute or so, only having the stanza title and bindDN password in plaintext

re-push the app or do a rolling cluster restart, and this should re-hash the values.

I ran into this issue when i updated the password on the local auth.conf files after creation. I think they only do the hashing upon the first time the file is found...

[maciep]

We do things exactly that way and the bind password gets encrypted on startup.

So we have an ldap app we push down from the deployer that has authentication and authorize conf files - those conf files contain everything except the bind password.

The bind password is stored in the authentication.conf file, under the strategy stanza in system local on all of the search head cluster members - nothing else in that file. They were entered there in plain text and encyrpted on next restart.

Not sure what might be different for you, but generally speaking that should work.

[dflodstrom · Accepted solution]

I can't explain why you still see the password in cleartext in your ../local/authentication.conf but I can tell you that I manage my LDAP configurations locally on each clustered search head and the password is obfuscated. If you are already going to maintain a /local/authentication.conf why not put the entire config in there?

If you use the deployer to push authentication.conf with the cleartext password it will get obfuscated on each of your search heads when Splunk restarts, the issue with this method is the plaintext password is stored in your custom TA. I have used this method in a lab environment where no /local/authentication.conf exists.

[jeffland]

That's strange - I just re-did everything from the start and this time it worked like a charm.

Thanks!

[dflodstrom]

That's how it goes right? Thanks for closing the loop on this.