On Dec 10, 2007, at 18:58, Nicolas Williams wrote: > The answer is that an MIT KDC with plain old db2 backend can't do it. > An MIT KDC with an LDAP backend could do it, but it doesn't yet.
The code to support this in either back end is there, but not compiled by default. Unfortunately, some changes a while back caused it to stop compiling if you try to enable it. We need to figure out what the deal's going to be with that code... I suspect the problem with the db2 version that Nico is thinking of is that the number of failed attempts is tracked in the database, and with db2, the database gets periodically copied from the master KDC to the slave KDCs, wiping out any record on the slaves of failed attempts. There's also no coordination between KDCs to track the info. So, if someone attempting to break into the account avoids using the master KDC, they can make N attempts on each slave in each window between propagations. It won't lock out access to the account overall, but it will rate-limit the attack, depending how often the propagations happen. (For that matter, the LDAP back end probably won't handle the database updates atomically, so attacks made in parallel on multiple KDCs *might* cause some of the failed attempts to not be counted. Not as bad as the db2 case, but still far from perfect. The original database design wasn't set up to assume multiple KDCs would be modifying the database at once....) Ken ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
