kerberos password change in master-slave environ

[Donn Cave]

In article <200403242017.i2OKH6Je022028 at ginger.cmf.nrl.navy.mil>,
 kenh at cmf.nrl.navy.mil (Ken Hornstein) wrote:

> >Our realm has 43,000+ principals so for us, its a big deal. :)  We have
> >slaves not only for redundancy, but also for load balancing.  We don't want
> >all the users on our campus authenticating or changing passwords against
> >just one machine.  
> 
> With ticket caching, the load against one KDC hasn't been really that bad,
> from my experience.

I'll second that.  We have roughly twice as many, and I have never
noticed any significant amount of traffic to the secondary, even
without much caching (Kerberos per se has never really caught on
here, mainly due to lack of applications, so authentication mostly
means acquiring initial credentials and then throwing them away.)

However, dump propagation and performance were part of the issue
when we set up our own multimaster system some years back.

- Propagation takes up resources on the master, especially during
  the dump.  Not a desperate problem if you have a fast computer
  and you're doing it once an hour, but I didn't think we could
  afford to do it, say, every 5 minutes (and that's the minimum,
  because we couldn't finish it in less than 5 minutes.)

- Fallback to slave servers will be infrequent, but significant.
  We couldn't totally disregard the phenomenon for user support
  purposes, it will happen often enough that it has to work right.
 
- Lag between master and slave - 30 minutes, 60 minutes, something
  like that - would be a user support issue.  See previous point:
  hard to say `has to work right' and then allow this.  People's
  new passwords would not work, perhaps intermittently, during a
  fallback episode.

Our system revolves around some software locally developed out
of a legacy system, with only minimal changes to the KDC.  This
approach has been very successful, in my opinion, and if anyone
is thinking about developing a more general solution in this
area, it's a model to consider.  Useful in a heterogeneous
authentication environment.

   Donn Cave, donn at u.washington.edu