Thanks for the help everyone. I misunderstood how things were working. I now understand that you just have to set the client to transmit clear, and that doesn't mean it's being stored clear. Since I'm using TLS this should not present any security problems.
Matt
-----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Tuesday, May 10, 2011 6:06 AM To: Buchan Milne Cc: openldap-technical@openldap.org; Bidwell, Matt Subject: Re: pwdInHistory question
Buchan Milne wrote:
On Friday, 6 May 2011 00:11:32 Bidwell, Matt wrote:
I'm running OpenLDAP 2.5.24 on 2 servers. I'm trying to enforce some security rules on client machines through the ppolicy overlay. All the lockout stuff works fine. I understand that pwdMinLength will not work by design because the password is hashed.
This statement isn't true. If OpenLDAP receives the clear text password, length/content enforcements can be made. However, if your clients are sending the password hashed, it obviously can't.
You can either get your clients to use the Password Modify extended operation (e.g. with pam_ldap use 'pam_password exop'), or if your clients can send a modify with the userPassword unhashed, then you can use 'ppolicy_hash_cleartext yes' in slapd.conf.
I can't get pwdInHistory to work. If I set it to 5 I clearly see 5 pwdHistory entries, all hashed {crypt}, but I can go back and forth between two passwords without it rejecting them for being reused. My current theory is that it's not looking at the actual password to prevent reuse, but the hashed password, which is not going to be the same. Should it be working? Follow up question, shouldn't the password be stored {SSHA} and not {CRYPT} by default?
It will be hashed with whatever you have set with 'password-hash', which defaults to SSHA, *if* the server receives a password modify extended operation, or if the server receives the cleartext and has 'ppolicy_hash_cleartext'. If password-hash is not {CRYPT}, then most likely your clients are sending operations with pre-hashed passwords.
And if the clients are not completely broken, they're using a randomly generated salt each time, therefore the password history checking can never succeed.
Just to be clear, the password is being set on the client machine using passwd, not on the servers running OpenLDAP.
*Where* they are being set isn't that relevant, what software is doing it, and how it is configured, is more ...