[Freeipa-devel] global account lockout

[Gabe Alford]

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?

http://technet.microsoft.com/en-us/library/cc772726%28v=ws.10%29.aspx
http://blogs.technet.com/b/askds/archive/2010/08/18/fine-grained-password-policy-and-urgent-replication.aspx

Gabe


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
>>>>>
>>>> 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.
>>>
>>>
>>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140409/ccd2f6f1/attachment.htm>