[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