[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] 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 <simo@samba.org>
Principal Software Engineer at Red Hat, Inc. <simo@redhat.com>
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext