>From: [EMAIL PROTECTED] (Mike McNally)

>> From: [EMAIL PROTECTED] (Joe Ramus)

>>> From: Derek Atkins <[EMAIL PROTECTED]>
 [Stuff deleted]
>>> I have a bug-list so big that I can't even submit it!!!

>> It would be a BIG help if an "expert" would write a good "how-to"
>> document about using Kerberos V4 and V5 with AFS.   As you observe,
>> ...
>>   USE MIT KERBEROS!  ***DO NOT USE KASERVER*** --

Why or Why not? What are the issues?

>  Absolutely.  Does such a document exist?  If so, I'd love to know about
>it.  If not, I'd be very grateful to the first person to whip one up.  
>Trying MIT kerberos in our AFS cell has been on my list of things to 
>try for a while but it keeps getting pushed back because I just don't have
                                                        ^^^^^^^^^^^^^^^^^^^ 
>the time to figure out everything that needs to be done.  A reasonably 
^^^^^^^^^ 
>...

I can't take this anymore....

Maybe I'm missing something, but I haven't found Transarc to be as
unresponsive as is implied by this thread.  It really should not be
necessary to MAKE the time necessary to re-engineer a supported product. 
If this effort is really required, wouldn't it would be far more effective
if those with the available expertise and time worked with Transarc to
improve the product rather than codify procedures to build a patchwork? 
At least then the effort need only be invested once...

Actually, I recall some messages [two are excerpted below] exchanged about
a year ago discussing real [i.e. technical] issues vis-a-vis kaserver and
(kadmin?); the pluses were not all on the side of kadmin.  My recollection
is that some kind of concensus was reached that it is easier/better? to
use MIT clients with kaserver than to use AFS with MIT kerberos and some
program(s) to support this were made available via grand.central.org.

Perhaps the "right" thing to do has changed with Kerberos V5?  I confess
that I haven't made time to investigate whether this is even desirable.
However, given that DCE integration work is [or had better be] in progress
somewhere, it is difficult to believe that this work isn't already well
underway if not completed.  If the differences are important, it seems
hard to believe that this work could not be made accessible so we could
move "forward".

I for one would rather see [more] discussion of the merits than procedures
to support various positions.  Whatever the result, it seems clear that a
afs-kerberos.FAQ is warranted.

Thank you,
-Charles Ball
[EMAIL PROTECTED]

-------------------------------------------------------------------------
Appologies in advance if I've taken these excerpts too far out of context.

Date: Fri, 24 Jan 1992 23:24:33 -0500 (EST)
From: John Gardiner Myers <[EMAIL PROTECTED]>

"Peter Lister, Cranfield Computer Centre" <[EMAIL PROTECTED]> writes:
> I would like to use both kinds of Kerberos clients out of the box, which
> implies  running  both  Kerberos servers in parallel.

andrew.cmu.edu uses both kinds of Kerberos clients clients more or
less out of the box.  We only run the Transarc server.

 
Date: Mon, 27 Jan 92 15:39 GMT
From: "Peter Lister, Cranfield Computer Centre" <[EMAIL PROTECTED]>

> One thing I just don't understand is why people have this pathological
> desire to run the MIT implementation of the Kerberos server.  The

Because  we are a pilot site for DECathena, that's why. It might be sort
of tactless to junk their Kerberos, much though I'd like to.

> Transarc implementation is just so much better.  It's administerable,
> it talks both protocols (excepting password changes), changes
> propagate to redundant servers transparently, the master key is
> automatically changed periodically, etc.  The only real disadvantage
> is that you have to use the RX protocol to change your password.

I  agree!  A recent article on [EMAIL PROTECTED] says that the MIT
kerberos is "crufty", and that's from one of the guys who wrote it!


Reply via email to