[Freeipa-devel] global account lockout

[Rob Crittenden]

Rich Megginson wrote:
> On 04/07/2014 01:00 PM, Simo Sorce wrote:
>> On Mon, 2014-04-07 at 14:47 -0400, Dmitri Pal wrote:
>>> On 04/07/2014 02:31 PM, Simo Sorce wrote:
>>>> On Mon, 2014-04-07 at 10:22 -0600, Rich Megginson wrote:
>>>>> On 04/07/2014 10:13 AM, Simo Sorce wrote:
>>>>>> On Mon, 2014-04-07 at 12:10 -0400, Simo Sorce wrote:
>>>>>>> On Mon, 2014-04-07 at 12:01 -0400, Simo Sorce wrote:
>>>>>>>> On Mon, 2014-04-07 at 11:26 -0400, Rob Crittenden wrote:
>>>>>>>>> Ludwig Krispenz wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> please review the following feature design. It introduces a
>>>>>>>>>> global
>>>>>>>>>> account lockout, while trying to keep the replication traffic
>>>>>>>>>> minimal.
>>>>>>>>>> In my opinion for a real global account lockout the basic lockout
>>>>>>>>>> attributes have to be replicated otherwise the benefit is
>>>>>>>>>> minimal: an
>>>>>>>>>> attacker could perform (maxFailedcount -1) login attempts on
>>>>>>>>>> every
>>>>>>>>>> server before the global lockout is set. But the design page
>>>>>>>>>> describes
>>>>>>>>>> how it could be done if it should be implemented - maybe the
>>>>>>>>>> side effect
>>>>>>>>>> that accounts could the be unlocked on any replica has its own
>>>>>>>>>> benefit.
>>>>>>>>>>
>>>>>>>>>> http://www.freeipa.org/page/V4/Replicated_lockout
>>>>>>>>> One weakness with this is there is still a window for extra
>>>>>>>>> password
>>>>>>>>> attempts if one is clever, (m * (f-1))+1 to be exact, where m
>>>>>>>>> is the
>>>>>>>>> number of masters and f is the # of allowed failed logins.
>>>>>>>> Yes, but that is a problem that cannot be solved w/o full
>>>>>>>> replication at
>>>>>>>> every authentication attempt.
>>>>>>>>
>>>>>>>> What we tried to achieve is a middle ground to at least ease
>>>>>>>> administration and still lock em up "earlier".
>>>>>>> Let me add that we "could" have yet another closer step by
>>>>>>> finding a way
>>>>>>> to replicate only failed attempts and not successful attempts in
>>>>>>> some
>>>>>>> case. Assuming a setup where most people do not fail to enter their
>>>>>>> password it would make for a decent compromise.
>>>>>>>
>>>>>>> That could be achieved by not storing lastsuccessful auth except
>>>>>>> when
>>>>>>> that is needed to clear failed logon attempts (ie when the failed
>>>>>>> logon
>>>>>>> counter is > 0)
>>>>>>>
>>>>>>> If we did that then we would not need a new attribute actually, as
>>>>>>> failed logins would always be replicated.
>>>>>>> However it would mean that last Successful auth would never be
>>>>>>> accurate
>>>>>>> on any server.
>>>>>>>
>>>>>>> Or perhaps we could have a local last successful auth and a
>>>>>>> global one
>>>>>>> by adding one new attribute, and keeping masking only the successful
>>>>>>> auth.
>>>>>>>
>>>>>>> The main issue about all these possibilities is how do we present
>>>>>>> them ?
>>>>>>> And how do we make a good default ?
>>>>>>>
>>>>>>> I think a good default is defined by these 2 characteristics:
>>>>>>> 1. lockouts can be dealt with on any replica w/o having the admin
>>>>>>> hunt
>>>>>>> down where a user is locked.
>>>>>>> 2. at least successful authentications will not cause replication
>>>>>>> storms
>>>>>>>
>>>>>>> If we can afford to cause replications on failed authentication by
>>>>>>> default, then we could open up replication for failedauth and
>>>>>>> failedcount attributes but still bar the successful auth attribute.
>>>>>>> Unlock would simply consist in forcibly setting failed count to 0
>>>>>>> (which
>>>>>>> is replicated so it would unlock all servers).
>>>>>>> This would work w/o introducing new attributes and only with minimal
>>>>>>> logic changes in the KDC/pwd-extop plugins I think.
>>>>>> Sigh re[plying again to myself.
>>>>>> note that the main issue with replicating failed accounts is that you
>>>>>> can cause replication storms by simply probing all user accounts with
>>>>>> failed binds or AS requests. In some environments that may cause DoSs
>>>>>> (if you have slow/high latency links on which replication runs for
>>>>>> example).
>>>>>> So I think we should always give the option to turn off failed
>>>>>> date/count attributes replication, which in turn would mean we still
>>>>>> require a new attribute to replicate for when a user is finally
>>>>>> locked
>>>>>> out on one of the servers or we fail requirement 1.
>>>>>>
>>>>>> Simo.
>>>>>>
>>>>> Another problem with keeping track of bind attributes in a replicated
>>>>> environment is the sheer size of the replication metadata.
>>>>> Replicating
>>>>> 1 failed bind attempt might be 100kbytes or more data to all servers.
>>>>> We should have a way to perhaps say "only keep last N CSNs" or maybe
>>>>> even "don't keep CSNs for these attributes".
>>>> Yes, but this look a lot like general replication improvement (would
>>>> also be cool to have "better" conflict resolution), not lockout
>>>> specific.
>>>>
>>>> Simo.
>>>>
>>> My only comment is actually about conflict resolution. What would happen
>>> if I attack (flood) two replicas at the same time beating the
>>> replication. It would mean both servers would generate the global
>>> attributes and try to replicate to each other. If the replicas are on
>>> the edges of topology it might take some time and it might even happen
>>> that admin already unlocked the account while the old lock is still
>>> trying to propagate. IMO we need collisions resolution logic taken care
>>> of first. I suspect that any real attack would lead to collisions and if
>>> it would leave the deployment unstable even after the attack ended we
>>> lost.
>> Yes, this is a valid concern. We need a last-wins conflict resolution
>> strategy for some cases.
>
> I'm not sure what you mean.  The 389 conflict resolution strategy is
> "last-wins" already.  Or do you mean "for some cases, but not all cases"?

He may be thinking entry vs attribute reconciliation. We definitely 
wouldn't want a replication conflict entry created in case there were 
conflicting updates.

rob