[Freeipa-devel] global account lockout

Rich Megginson rmeggins at redhat.com
Mon Apr 7 16:22:22 UTC 2014

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".

More information about the Freeipa-devel mailing list