[Freeipa-devel] global account lockout

Simo Sorce simo at redhat.com
Mon Apr 7 16:13:42 UTC 2014

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
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 Sorce * Red Hat, Inc * New York

More information about the Freeipa-devel mailing list