[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] password policy: account idling in distributed systems
On Jul 2, 2010, at 4:59 PM, simo wrote:
> 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.
so was I. 'last login' recording is for account idling.
> Account idling is not very commonly done at the DSA level in the field I
> care about.
Understandable.
> 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.
I look at this specification as focused on password policy for directory applications (one where the user directly uses a directory client to talk to the directory service), though I am interested in how one might extend this specification to address issues in application services which use directory service as a database backend.
>>> 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.
Yes. Otherwise you'd have to replicate the per-user failed login state information, and do that in a manner which couldn't be abused by an attacker to get than N*M guesses (N DSAs, M guesses per DSA) due to the eventual convergent replication of the state information. But, as I noted earlier in this thread, such replication can be used to mount a magnification attack. If one has N shadow DSAs hanging directly off a single master, one guess leads directly to N operations to update each shadow DSA (plus a chain operation if the guess was issued at a shadow DSA).
In some of deployments, private pipes are used for replication traffic. Often these pipes have less bandwidth than between any DSA and the clients which access it. So an attacker can easily mount a successful attack upon directory replication if one were to replicate such state information.
But I also note that I tend to recommend against enabling account lockout due to excessive failed login attempts, this because doing so enables a DoS attack on user access. I generally recommend brute force attacks by other means.
>
> 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
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext