Re: password policy: account idling in distributed systems

On Fri, 2010-07-02 at 16:45 -0700, Kurt Zeilenga wrote:
> 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.

Sorry, I was referring to the last login propagation.
Account idling is not very commonly done at the DSA level in the field I
care about. Usually it is done in the applications that access the DSA
here.
But it is perfectly fine as a feature if the DSA is directly exposed.

> > 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.

Yes I believe account idling is a good idea in some cases, although I
think you raised a valid concern when you posted the question of how an
admin can effectively control idling, when it is in force and there is a
need to "reset" it.

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

Does it mean that the same user is locked on a server but not on
another ? Interesting.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <[email protected]>
Principal Software Engineer at Red Hat, Inc. <[email protected]>