[6440] in Kerberos
Re: Performance of CNS vs. AFS kaserver?
daemon@ATHENA.MIT.EDU (Derrick J. Brashear)
Fri Jan 5 16:11:36 1996
To: kerberos@MIT.EDU
Date: Fri, 5 Jan 1996 13:25:48 -0500
From: "Derrick J. Brashear" <shadow+@andrew.cmu.edu>
Excerpts from netnews.comp.protocols.kerberos: 4-Jan-96 Performance of
CNS vs. AFS .. by Trey Harris@email.unc.ed
> I read the documentation for CNS and see that you can create "slave"
> servers which maintain readonly data from the master. But from my reading
> of the documentation, these slave servers are fallbacks for failure or
> timeout rather than a mechanism for loadleveling.
>
> Is this true? If so, is my only choice to go with the AFS kaserver? I
> expect up to a thousand authentication attempts per minute at peak times.
As I see it (and others are of course welcome to disagree, and maybe
suggest something I haven't thought of), the problems with using
Kerberos 4 servers instead of kaservers is that the database isn;t truly
replicated. So, if the master goes down, no one changes their password
until it's back up.
And, when I change my password now, it doesn't propagate to slaves for
some amount of time. It depends on when i change it relative to the
slave update times. This isn't a problem if you point everything at the
master, unless the master goes offline before slaves get updated. But,
you can put slaves first in krb.confs, which is to say, do load
balancing by randomizing what appears in krb.conf on client machines. If
you do this, then the "I changed my password, but I need to use it for
some period of time after" can get more annoying.
Ideally, with a small amount of work, you could do:
All machines run a kadmind
Each accepts password changes, and sends them (encrypted of course) to
all the other kadminds, in such a way that the other kadminds know they
don't need to forward it on.
If a given machine or its kadmind is unreachable, the transaction gets
logged, with a timestamp. When a machine comes back, the log is
processed in timestamp order.
There are flaws in this scheme.
For example, I have three KDCs. At some point, all three lose contact
with each other, but maintain contact with some local clients,
presumably because each is in a building with a group of clients.
X changes its password with the server in building A
X then goes to lunch, comes back, and goes into building B
It uses its old password to log in because it can't seem to use its new one,
then changes it with the server in building B to something different.
To be annoying, before the network recovers, X goes to building C to see
a friend, and in the process of trying to read email, changes it again.
Now, given timestamps, things can be merged. It just means more work.
But you can't just flush a given database and pull in a new copy,
because all three databases are out of sync.
It can be done, but it takes more work. If you're willing to invest it,
you're set. Otherwise, you may just want to stick with the kaserver.
-D
