Re: [Freeipa-devel] Kerberos lockout policy
On Fri, Aug 27, 2010 at 1:32 PM, Rob Crittenden 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@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 > ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Kerberos lockout policy
On Fri, 27 Aug 2010 14:35:34 -0400 Rob Crittenden wrote: > Simo Sorce wrote: > > On Fri, 27 Aug 2010 09:41:57 -0400 > > Rob Crittenden wrote: > > > >> 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. > > > > Rob, we do not want to replicate counters or timestamps, but we > > certainly want to replicate an account lock. It should happen rarely > > enough to reach that stage that we can replicate nsAccountLock > > easily. > > > > Simo. > > > > I don't think that nsAccountLock gets set in this case. The KDC > evaluates the attributes on-the-fly as far as I can tell. That would be a problem I guess. Maybe we need some patching of the ldap database plugin ... Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Kerberos lockout policy
Simo Sorce wrote: On Fri, 27 Aug 2010 09:41:57 -0400 Rob Crittenden wrote: 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. Rob, we do not want to replicate counters or timestamps, but we certainly want to replicate an account lock. It should happen rarely enough to reach that stage that we can replicate nsAccountLock easily. Simo. I don't think that nsAccountLock gets set in this case. The KDC evaluates the attributes on-the-fly as far as I can tell. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Kerberos lockout policy
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
Re: [Freeipa-devel] Kerberos lockout policy
On Fri, 27 Aug 2010 09:41:57 -0400 Rob Crittenden wrote: > 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. Rob, we do not want to replicate counters or timestamps, but we certainly want to replicate an account lock. It should happen rarely enough to reach that stage that we can replicate nsAccountLock easily. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Kerberos lockout policy
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@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
