Re: LDAP Account expiry

[Andrew Findlay <andrew.findlay@skills-1st.co.uk>]

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
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------