[Freeipa-devel] global account lockout

[Simo Sorce]

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.

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

> 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) ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York