New "feature" for Kerberos?

[Donn Cave]

Quoth John Hascall <john at iastate.edu>:
|   Measurements that I have done, and similar ones done at
|   U Mich show only a small performance hit from turning on
|   with-kdc-kdb-update.

I'm not trying to say you can't do this, if it's what you want to do.
Just pointing out that there might be other ways to go about it, that
for one thing would have no impact at all on the KDC.

| > And then we have multiple KDCs, which would have to be taken into account.
|
|   IMO, w/o a "real-time" replication (like U Mich developed)
|   the only possible use for slaves is disaster recovery,
|   (which is how we use ours), so this concerns me not.
|
|   [We've had 500 password changes in an hours upon
|   ocassion, kproping twice a day doesn't really capture
|   that very well if somebody is "load balanced" to
|   the slave.]

Right, we're real time too.  (So to speak.)  We couldn't see how load
balancing to a slave server could work, either.  Our system isn't a
response to a support load emergency, incidentally - our KDC has never
been a very heavy load on its host, and I'm pretty sure one host could
still provide reasonable service for the whole site.  We're here just
because the current generation of our local accounts software gives us
the luxury, basically.  Amendments to the KDC are just a couple of lines
that route passwords out to that system if they come in via kpasswd.

	Donn Cave, donn at u.washington.edu