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 _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
