Re: [ldapext] password policy: account idling in distributed systems

[Kurt Zeilenga <Kurt.Zeilenga@Isode.com>]

Some additional thoughts here...

The primary problem with this feature is assumes that there either a single DSA used by the user, or that all of the DSAs used by the user share last-login information.  While it might be oddly useful in some distributed environments to idle accounts on a per DSA basis, in general this would be un-usefully odd.

There are a number of approaches one could use to share state.

1) have all DSAs be masters in a multi-master DSA system,
2) have all shadow/caching servers issue an operation to update the master DSA (or a master of a multi-master deployment), or
3) have all shadow/caching servers chain the Bind request.

Option 1 is problematic as multi-master systems (with no shadow/caching DSAs) tend not to scale as broadly as single-master/shadowing/caching systems.

For Simple password Bind and SASL/PLAIN, there isn't much difference between option 2 and 3.  But 3 is problematic when SCRAM and like mechanisms are used.  And 3 is also problematic when the master(s) are unreachable.  With 2, the master update can be deferred until the master(s) become reachable.

Another approach, which I think is more generally applicable, would be last successful login to recorded in a dsaOperation attribute and then have a separate directory application that could be ran at a suitable interval, that would for each user, check each DSA for the last login time, determine the latest login time across all DSAs, and if not recent enough, lock the account via an accountLock attribute.

To unlock, the management client likely should, in addition to clearing the accountLock attribute, set some attribute to exclude subsequent idling locking for some period of time (see my how question about how to unlock an idle account).

-- Kurt
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext