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