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
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
