Hello,
Based on the fact that the userPassword attribute is NOT single-valued in the schema definition, I was wondering whether there are cases where we could use a double-password approach or if doing that would just cause a mess.
For example, could we store both a clear-text password (to be used e.g. in DIGEST authentication) AND an encrypted (SSHA or MD5) one for standard use? If that could work, (I assume that) openldap would know which one to use based on the negotiation with the client application, which would normally try different authentication methods in a particular order. Openldap would then use the right password automatically (ideally), depending on the authentication method used each time.
Any info would be appreciated.
Thanks, Nick
Nick Milas writes:
Based on the fact that the userPassword attribute is NOT single-valued in the schema definition, I was wondering whether there are cases where we could use a double-password approach or if doing that would just cause a mess.
Sure. For example, when you change an entry's password, you may want a grace period where both passwords are accepted. In particular if you have a service which Binds with its own DN and password, and you don't want it to fail while you are changing the passwords at both ends (in the service and in LDAP). You'll have to remember removing the old password yourself though, I don't think OpenLDAP has anything which can remember it for you. Unless the ppolicy overlay can be used for that.
On the other hand,
For example, could we store both a clear-text password (to be used e.g. in DIGEST authentication) AND an encrypted (SSHA or MD5) one for standard use?
Why? The encryption buys you no security when the cleartext password is also available in the same attribute.
OTOH - userPassword is for Simple Bind, while DIGEST means SASL Bind. SASL uses its own subsystems. It can be configured to use passwords from LDAP but need not be. See the Adming Guide at www.openldap.org. I don't know SASL, but I expect it can take the password from some other attribute than userPassword.
On 20/9/2011 11:53 πμ, Hallvard B Furuseth wrote:
Sure. For example, when you change an entry's password, you may want a grace period where both passwords are accepted. In particular if you have a service which Binds with its own DN and password, and you don't want it to fail while you are changing the passwords at both ends (in the service and in LDAP). You'll have to remember removing the old password yourself though, I don't think OpenLDAP has anything which can remember it for you. Unless the ppolicy overlay can be used for that.
Thank you for your reply.
So, when there are more than one values in the attribute, openldap starts testing them until one succeeds?
For example, could we store both a clear-text password (to be used e.g. in DIGEST authentication) AND an encrypted (SSHA or MD5) one for standard use?
Why? The encryption buys you no security when the cleartext password is also available in the same attribute.
It would be a *different* password stored in clear text.
OTOH - userPassword is for Simple Bind, while DIGEST means SASL Bind. SASL uses its own subsystems. It can be configured to use passwords from LDAP but need not be. See the Adming Guide at www.openldap.org. I don't know SASL, but I expect it can take the password from some other attribute than userPassword.
I used as an example (of using multiple passwords, for a number of applications each) the case where we store (different!) passwords in clear text in the userPassword attribute (as explained here: http://www.openldap.org/doc/admin24/sasl.html).
If feasible, in such a scenario, openldap would be able to handle both basic AND sasl/digest-md5 authentication at the same time (for different needs). Is it possible? Or the authentication identity mappings needed for DIGEST-MD5 (and SASL in general) "break" simple binds?
Nick
openldap-technical@openldap.org
-
Hallvard B Furuseth -
Nick Milas