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.
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@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
