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....)