On Thu, Mar 08, 2018 at 05:18:55AM +0000, Brad Marshall wrote:

As I understand there's no native way to do this, I've written a python script that loops over and checks the authTimestamp from the lastbind overlay, which is all good.  To lock the account I set the pwdAccountLockTime to the timestamp, which all works well with the ppolicy overlay in place.

The problem becomes when we want to unlock the accounts, and give the end users a chance to auth so it will clear out the lock.  My understanding from reading the code was that I could set the timestamp for pwdAccountLockTime into the future, and it should expire the account when it gets to that time.  This gives the users a grace period in which to authenticate.

As you have found, that is not going to work. pwdAccountLockedTime is an operational attribute used by the server to *record* when the password was actually locked. It does not mean 'lock the account at this time'. In OpenLDAP the mere presence of this attribute in an entry locks the password.

This is a bit of a fudge in the "standard" (actually a long series of Internet Drafts) or perhaps in OpenLDAP's interpretation of it. Operational attributes are not supposed to be modified directly, yet the standard way to lock an account is to set pwdAccountLockedTime to 000001010000Z.

Should any of this be working?  Am I missing any piece of this puzzle here?  Has anyone got any suggestions on how to solve this problem, either via the approach I'm trying or any alternative solution?  Please let me know if I've left any useful information out about this.

You might get somewhere by artificially expiring the password and giving the account a couple of grace authentications, but this also requires modifying operation attributes and it does not set a time limit.

I think you are going to have to create a new attribute to hold the time you want the password to re-lock. You can then either write an overlay to enforce it or (simpler perhaps) extend your python script to check and re-lock accounts that have not logged in before the deadline.

This is one of the problems with the existing password policy framework. It mixes password policy with account policy for historical reasons (most of the concepts came from Unix password policy files). As you say above, you want to unlock the *accounts* which is not the same as unlocking the *passwords* because there may be non-password ways of authenticating and you want to block those too.

Note also that some features of password policy have "interesting" behaviour when replication is involved.

Andrew