[Freeipa-devel] Kerberos lockout policy

[Rob Townley]

On Fri, Aug 27, 2010 at 1:32 PM, Rob Crittenden <rcritten at redhat.com> wrote:
> Rich Megginson wrote:
>>
>> Rob Crittenden wrote:
>>>
>>> I'm working on implementing kerberos lockout policy as defined at
>>> http://k5wiki.kerberos.org/wiki/Projects/Lockout
>>>
>>> We had talked about this at one point, perhaps in irc, and there was
>>> some reluctance to do this since every time a user logs in a number of
>>> attributes can get updated. The concern was the additional load added
>>> by replication. The suggested fix was to simply not replicate these.
>>
>> In 389 you can choose to replicate these or not. The reason to replicate
>> them is to make it harder for a hacker to keep retrying the password. If
>> you set your policy to lockout after 3 tries, but you have 6 masters,
>> then if you don't have global policy, you effectively give a hacker 18
>> tries instead of 3.
>
> The concern is that there is going to be a ton of network traffic for every
> login. So for 6 masters every login is going to generate 5 updates. Doing it
> per-server was a compromise.
>

Once systems are rooted, network traffic will burst out of the cat5.
i want replication of failed login attempts.

>>>
>>> If we switch to fractional replication, what impact, if any, is that
>>> going to have? It looks like configuring it is as simple as adding a
>>> new attribute when we create the agreement outlining the attributes we
>>> don't want to send.
>>
>> You could do it this way, and that's how it is handled in 389 if you
>> have local only policy.
>>>
>>> There is another problem, related to management, specifically being
>>> able to unlock an account for a user.
>>>
>>> Lets say we have 3 masters. Since we don't replicate the login policy
>>> attribute each stands alone in counting login failures. The admin
>>> trying to unlock the user account is going to need to figure out which
>>> KDC the user is locked out of. Once that is identified they need to
>>> execute the unlock from a machine that uses that IPA backend for its
>>> management interface (e.g. the IPA UI running on that KDC).
>>>
>>> Or we could try to identify all masters and unlock the user on all of
>>> them. We don't currently have an API for iterating through all masters
>>> right now, and I'm a little iffy if we can. If you had a replication
>>> topology of A <-> B <-> C then A probably doesn't even know C exists.
>>
>> It doesn't "know" that C exists, but it doesn't matter - A -> B, then B
>> -> C.
>
> I'm thinking in terms of the IPA XML-RPC server. Consider this situation.
> User X calls you on the phone and says his cat just walked across his
> keyboard (on take your cat to work day) and now he's locked out. You want to
> help him but in order to do so you'd need to know which KDC the user is
> connecting to. He has no idea.
>
> So you could try every single XML-RPC server, the is one on every KDC, but
> that is not trivial using the command-line. Using the UI you could simply
> browse to all the servers and unlock on all of them.
>
> Otherwise every IPA server would need to know about every other one unless
> we somehow handle the request locally and then forward it to all the servers
> we know and they do the same, assuming we could be smart enough to only try
> each server once.
>
> rob
>
>>>
>>>
>>> I'm a bit stumped by this one. Suggestions would be greatly appreciated.
>>>
>>> rob
>>>
>>> _______________________________________________
>>> Freeipa-devel mailing list
>>> Freeipa-devel at redhat.com
>>> https://www.redhat.com/mailman/listinfo/freeipa-devel
>>
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel
>