We will be using OpenLDAP with TLS, and also plan to use the OpenLDAP replication as well.
I would like to keep plain text passwords out of config files. We are using the '{SSHA}' configuration option for the 'rootdn' configuration variable. Is there something similar that I can use for the replication 'credentials'?
I considered using SASL, but SASL passwords are stored in plain text in the SASL password database, so that would just move the problem to a different file.
I unsuccessfully tried using the '{SSHA}' configuration option for the replication 'credentials'.
Is there a way to hash or encrypt the replication credentials without using SASL?
Thanks in advance of any replies,
Mark
On Wed, 7 May 2008, Mark W Apperson wrote:
I would like to keep plain text passwords out of config files. We are
I think we've discussed this quite a bit on the list. You'll need to use some mechanism other than a simple shared secret (perhaps certificates or Kerberos) if you've got reason to be scared that your shared secret will be read.
Mark W Apperson Mark_W_Apperson@raytheon.com wrote:
We will be using OpenLDAP with TLS, and also plan to use the OpenLDAP replication as well.
I would like to keep plain text passwords out of config files. We are using the '{SSHA}' configuration option for the 'rootdn' configuration variable. Is there something similar that I can use for the replication 'credentials'?
What about using certificate authentication? That completely removes the need for a replication password.
Emmanuel Dreyfus wrote:
Mark W Apperson Mark_W_Apperson@raytheon.com wrote:
We will be using OpenLDAP with TLS, and also plan to use the OpenLDAP replication as well.
I would like to keep plain text passwords out of config files. We are using the '{SSHA}' configuration option for the 'rootdn' configuration variable. Is there something similar that I can use for the replication 'credentials'?
What about using certificate authentication? That completely removes the need for a replication password.
Anyway either the private key has to be stored somewhere 1. in clear or 2. password-protected. 2. would require manual admin interaction during startup. (I don't know whether that's supported at all.)
Ciao, Michael.
Michael Ströder michael@stroeder.com wrote:
Anyway either the private key has to be stored somewhere 1. in clear or 2. password-protected. 2. would require manual admin interaction during startup. (I don't know whether that's supported at all.)
Sure, but it's not a shared secret.
On Wed, 7 May 2008, Emmanuel Dreyfus wrote:
Michael Ströder michael@stroeder.com wrote:
Anyway either the private key has to be stored somewhere 1. in clear or 2. password-protected. 2. would require manual admin interaction during startup. (I don't know whether that's supported at all.)
Sure, but it's not a shared secret.
I'm not sure what you mean by that.
In both cases--setups using passwords and setups using TLS client certs--the one end has enough info to verify authentications (but not to forge them) while the other has a file that contains enough data to generate (and forge) authentications. The name of the file containing that data is different, and the size of that data is different, but if you can read that file, you can forge connections.
Philip Guenther
Philip Guenther guenther+ldapsoft@sendmail.com wrote:
In both cases--setups using passwords and setups using TLS client certs--the one end has enough info to verify authentications (but not to forge them) while the other has a file that contains enough data to generate (and forge) authentications. The name of the file containing that data is different, and the size of that data is different, but if you can read that file, you can forge connections.
Yes, but if you can read the replica private key, this basically means that you have a shell access as the slapd pseudo-user on the replica. If you have this, then you can also trace slapd and extract whatever you want, reconfigure it to modify ACL, or just directly dump the replicated databases.
Emmanuel Dreyfus wrote:
Michael Ströder michael@stroeder.com wrote:
Anyway either the private key has to be stored somewhere 1. in clear or 2. password-protected. 2. would require manual admin interaction during startup. (I don't know whether that's supported at all.)
Sure, but it's not a shared secret.
Yes, but you won't gain much security compared to sending the password in clear over the wire (protected by encrypted tunnel) and let the server compare it to a hashed password. In both configurations you have to store the credentials in the client's configuration as clear-text.
Ciao, Michael.
openldap-software@openldap.org
-
Aaron Richton -
manu＠netbsd.org -
Mark W Apperson -
Michael Ströder -
Philip Guenther