[4996] in Kerberos
Re: kinit to another realm failing:, Can't send request
daemon@ATHENA.MIT.EDU (Joe Kovara)
Wed Apr 19 05:33:03 1995
To: kerberos@MIT.EDU
Date: Wed, 19 Apr 1995 00:39:16 -0700
From: Joe Kovara <joek@kerby.ocsg.com>
On 18 Apr 1995 eichin@MIT.EDU wrote:
> >> [...] it attepmts to guess the kerberos server [...]
> [...] much easier ways to do that -- after all, having the name in krb.conf
> often means that you look up the name via DNS or NIS anyway. Kerberos
> security is based on *cryptography* not merely naming.
I agree completely with Mark's statement. I would add that "guessing"
(assuming it is done correctly :-) is--at present--the only feasible way
of deploying Kerberos on a large scale.
Put yourself in the place of a network manager at a site with many realms
trying to deploy tens of thousands of clients onto everything from PCs to
Unix workstations. If they don't get the clients right the first time (or
they ever change their realm/kdc names) they're going to have to go back
and update all those config files. Automated or not, that's a disaster
waiting to happen. And if you put people in that position, they won't buy
into Kerberos (literally or figuratively).
There are many other issues that must be addressed in large deployments,
but this is one that network operations people (at least the smart ones)
tend to question first. And why this is important. I think we'd all like
to see Kerberos get more recognition as a network security solution that's
here, that's real, and that's stood the test of time. It's seemingly
"minor" issues such as the above that can stop Kerberos dead in its
tracks, and relegate it to forever being a lab specimen. That would be
very unfortunate.
Joe Kovara / Product Development Manager / CyberSAFE / joek@cybersafe.com
