[Freeipa-devel] global account lockout

[Ludwig Krispenz]

On 04/09/2014 04:17 PM, Rich Megginson wrote:
> 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
my scenario was slightly differenent, without modrdn, but 
delete:oldvalue, add:newvalue[i] on three servers i=1,2,3 "simultaneously"
>
>>
>> Simo.
>>
>