[Freeipa-devel] global account lockout
redhatrises at gmail.com
Wed Apr 9 15:43:30 UTC 2014
I came across these articles that may be of some use in this topic. I
humbly admit that I am no expert on this topic, and these may not be of any
use. Plus, I am not a fan of the product, but maybe it helps?
On Wed, Apr 9, 2014 at 8:40 AM, Ludwig Krispenz <lkrispen at redhat.com> wrote:
> 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
>>>>> 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
>>> 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) ?
> my scenario was slightly differenent, without modrdn, but delete:oldvalue,
> add:newvalue[i] on three servers i=1,2,3 "simultaneously"
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Freeipa-devel