On Mon, 2014-04-07 at 14:28 -0600, 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"?
I am thinking about those case when we end up with duplicate objects. In many (most ?) case we should just throw away one of the 2 and keep the other, not end up with 2 objects. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel