[Freeipa-devel] Kerberos lockout policy

Rich Megginson rmeggins at redhat.com
Fri Aug 27 17:23:25 UTC 2010


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.
>
> 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 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




More information about the Freeipa-devel mailing list