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

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

On Jul 2, 2010, at 4:21 PM, simo wrote:
> 
> These options are usually not implemented in real deployments

Account idling is one of Isode's most requested features.  Of course, our market may well be unique.

> because
> they are way too expensive.

I believe trying to share user-specific information produced at any DSA across all DSAs (which might need that information) is not generally feasible.

> The bind operation is quite common and
> changing an object in the DIT every time it succeeds and then
> replicating it to all servers is costly.

Which is why I offered an approach to providing account idling which doesn't require replication of successful login information.

> The only information that is usually propagated to all servers is the
> final account lock if one of the servers detect too many attempts.

For failed attempt lockout, our customers seem to happy with per server lockout.

> In
> general it is considered a good compromise to limit counting login
> attempts to determine if the account should be locked on a per server
> basis.

For failed attempt lockout, yes.  For idling, I think our customers want any use of the account on any DSA to prevent lockout on other DSAs.   But as I noted, this can be implemented without replicating last login information.

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