Any way to encrypt bindPassword for LDAP?

399 views
Skip to first unread message

Henning

unread,
Jan 12, 2015, 5:20:14 AM1/12/15
to rundeck...@googlegroups.com
Hi,

It seems that if you want to use Rundeck with LDAP, you have to provide your bindPassword in your jaas-conf in plaintext. Does anyone know if this can be encrypted in any way?

Regards,
Henning

danifr

unread,
Jan 15, 2015, 2:51:53 AM1/15/15
to rundeck...@googlegroups.com
+1

David Newman

unread,
Jan 15, 2015, 10:54:15 AM1/15/15
to rundeck-discuss
At the risk of starting a flame war, this is my 2 cents.  In the end rundeck will need the actual un-encrypted password to connect to the service.  This means rundeck needs to be able to decrypt/decode the configured value.  That will mean that rundeck will then need access to whatever password was used to encrypt it and the algorithms used for the transform.  The password encrypting password would then need to be stored somewhere and the algorithms used would clearly be visible in the class files, not to mention the source code as rundeck is opensource.

This page explains it better than I can; http://wiki.apache.org/tomcat/FAQ/Password

So I feel time is better spent securing the server and the files in question than to hiding the password.  If someone has a solution I would love to hear it because I have been wrestling with this issue for years.

p.s. this is the primary reason I use rundeck, so I can allow support people to restart tomcat servers without allowing them to see the sensitive config files.


--
You received this message because you are subscribed to the Google Groups "rundeck-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rundeck-discu...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Henning

unread,
Jan 26, 2015, 4:08:07 AM1/26/15
to rundeck...@googlegroups.com
Hi David,

I thought that maybe it would be a good idea to provide a password on server startup as secret for encrypting the passwords, but then again this would keep us from doing unattended server restarts. Besides, this password would have to be shared to many users, which brings the usual security hassles. Seems like there is no good solution, indeed.

Thank you for your input!
Reply all
Reply to author
Forward
0 new messages