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:

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.

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

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.


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


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.

Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

Freeipa-devel mailing list

Reply via email to