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. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
