[Freeipa-devel] global account lockout

[Rich Megginson]

On 04/09/2014 08:09 AM, Simo Sorce wrote:
> On Wed, 2014-04-09 at 15:50 +0200, Ludwig Krispenz wrote:
>>> Something like this is what we have experienced for real and cause
>> us to
>>> actually disable replication of all the lockout related attributes
>> in
>>> the past.
>> But also here it can get complicated, we cannot really use
>> failedlogincount and replicate it, eg if it is "2" on each server an
>> their are parallel login attempts, we would increment it to "3" and
>> replicate, so we would have 3 on all servers, not what we wanted.
>> We could replicate changes to lastfailedauth and when receiving an
>> update for this attribute locally increase failedcount, but it would
>> also have to be used for resets (deleting lastFailedAuth), but there
>> could also be race conditions, maybe there are other local attrs
>> needed.
> Yes, the current mechanism is deficient in many ways. For example the
> failedcount/lastfailedauth attibutes are really suboptimal, a better
> mechanism woul dbe to have a failedauths (not plural) multivalued
> attribute and just append dates there (perhaps pre/postfixed with the
> replica idto avoid any possible conflict). This way if 2 servers are
> being attacked simultaneously they still should replicate their own
> failure and each server can see that 5 dates are present in the last X
> minutes and quickly lock the user, nor failedcount would be necessary
> and no races incrementing it would occur.

This is an interesting idea.  Please file a ticket in the 389 trac 
explaining this.

>
> The only issue would be in cleaning up the attribute to not let it grow
> to much, but that could be accomplished by simply *not adding any more
> failed counts once the account is locked (only logging locally that
> someone tried to log in on a locked account) and deleting the attribute
> completely when the acocunt is unlocked, this again would reduce the
> attributes necessary for handling locking own to 1 from the current 3
> (lastsuccessauth/lastafiledauth/failedcounter) however it still does
> nothing to solve replication issues and has other replication races
> problems (not sure what happens if a server try store a new failed auth
> date and the other is deleting the old values at the same time.
> Perhaps deleting by value is safe enough and won't cause issues,
> Deleting the whole attribute may cause issues instead).

Handling of simultaneous updates of multi-valued attributes and update 
resolution works well.

>
>> And the bad news: I claimed that the replication protocol ensures that
>> the last change wins except for bugs, and looks like we have one bug
>> for single valued attributes in some scenarios. I have to repeat the
>> test to double check.
>> The update resolution code for single valued attrs is a nightmare,
>> Rich and I several times said we need to rewrite it :-(
> Is there a ticket that tracks this and explains the issue(s) ?

https://fedorahosted.org/389/ticket/47442

>
> Simo.
>