Rob Crittenden wrote:
I'm working on implementing kerberos lockout policy as defined at

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.


Freeipa-devel mailing list

Freeipa-devel mailing list

Reply via email to