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 ...

Hi all. I'm trying to use slapd-sock as a way to do some ancillary processing, external to the openLDAP database, when entries are updated. Following a suggestion I got on this list some weeks back, I wrote a little Python program to listen on a Unix socket and do the actual processing; then I set up a consumer replica using the socket backend to pass updates along to the socket.

Here's my problem: Whenever I stop and then restart the replica server, it re-loads the whole tree from the master. I conjecture that this is because it doesn't have a persistent location to store the contextCSN on shutdown. Am I right so far?

I see from logging what comes across the socket that contextCSN gets *set* over the socket when the reload finishes. However, it doesn't appear that it is being *requested* (via a search operation) across the socket when the consumer replication engine starts up. Again, am I correct so far?

My socket listener could always squirrel away the contextCSN and then provide it to the replication engine in response to a search, if the search were being requested, but apparently it's not.

Is there any way for either my socket program or something internal to the openLDAP server to persist and then provide the contextCSN on server startup?

Or have I completely misunderstood how this all works?

Suggestions for alternative design approaches also welcomed, and many thanks as always to the local sages.