Re: password policy: account idling in distributed systems

Kurt Zeilenga <[email protected]>
Newsgroups gmane.ietf.ldapext
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.