Proxy for Kerberos?

[John Hascall]

> >>>>> "John Hascall" == John Hascall <john at iastate.edu> writes:
> > > Some KDCs are configured to enforce account lockouts on successive
> > > AS_REQ failures. Exposing your KDC to the internet means you are
> > > willing to let your users get DOSed via this mechanism by yet another
> > > community of users (or bots, if there are any out there).

> > BTW, it is a rather simple code-mod to change the MIT KDC
> > to automatically re-enable locked out accounts after your
> > choice of interval.  We chose 60 seconds -- we figure that
> > allowing 7200 (5 * 60 * 24) attempts/day at a password is a
> > whole lot better than 103,680,000 (1200/sec * 60 * 60 * 24).
> > And a minute's wait after 5 mistakes has so far not been
> > seen as too onerous a price to pay for our users (certainly
> > it's a lot quicker than calling the help desk).

> I've been away from the MIT and Heimdal KDC implementations for some
> time, but for installations with [lots of] slaves, would both of these
> features (lockout and unlock) sufficiently frequent replication, of at
> least those bit of the kdb, in both directions (master <=> slaves) to
> be all that effectivep?
>
> I guess that's a rhetorical question, so I guess what I'm really
> asking is how does MIT/Heimdal handle replicating this data at
> sufficiently frequent intervals?

I'm only familiar with the Heimdal client, but (sadly) the MIT KDC
has only 'kprop' to do a bulk dump to slaves and most places (of
any size) only do that infrequently, perhaps a few times a day.

Long ago, we added 'real-time' delta propagation from the KDC
(we use it to sync our slaves as well as our Windows-AD and Novell-NDS).
Without it, N-strikes and you're out becomes (N*M-strikes),
which is not horrible, but sub-optimal.

John