[Freeipa-devel] global account lockout

Tue Apr 8 10:00:37 UTC 2014

Looks like there was a great discussion while I was away :-)

There seem to be great concerns (and mybe confusion) about replication 
update resoultions, conflicts and amount of meta data stored. I think 
it's not as bad as you may think.

Large amounts of metadata can only accumulate for multivalued 
attributes, for single valued attributes only the latest value and in 
some cases one! previous value is stored. For multivalued attributes the 
amount of data were considerably reduced with the fix for #569

The replication protocol and its update resolution is designed to follow 
a single master model: the final result should be the same as if the 
modifications were applied in the order of the csns on a single master, 
this implies that the last change wins. T
There are some cases where conflicting entries  or conflict attributes 
are generated. conflict entries should only be generated if the same 
entry (dn) is concurrently added on different masters. Conflict 
attribute are only genrated in some rare corner cases.
In the case of krbLastFailedAuth or krbFailedLoginCount always the value 
with the highest csn will win, no scenario for a conflict.

Replication storms. In my opinion the replication of a mod of one or two 
attribute in a entry will be faster than the bind itself. If an attacker 
knows all the dns of the entries in a server the denial of service could 
be that it just does a sequence of failed logins for any user and nobody 
will be able to login any more, replication would help to propagate this 
to other servers, but not prevent it. This would also be the case if 
only the final lockout state is replicated.

I like the idea of replicating the attributes changed at failed logins 
(or reset) only.

Regards,
Ludwig

On 04/08/2014 12:56 AM, Simo Sorce wrote:
> 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.
>