>> Who's right, MIT or DEC? Using the realm as instance leads the way to
>> cross-realm authentication (which is a Good Thing), but the existing
>> setup works, and I'm loath to fiddle with such an important aspect of a
>> working system.
(Warning: I'm going to touch on some religious issues here ;-)
The use of afs.<cell>@<realm> is that you can have multiple cells
using principals in the same kerberos realm. At MIT, there are at
least seven cells using the ATHENA.MIT.EDU Kerberos realm. (The
support for cell-name != realm-name was written at MIT. I don't know
if it's part of the stock Transarc release.) For cross-cell
authentication, it makes more sense to use shared keys between the
Kerberos realms.
Here's a piece of my current ticket file:
% klist
Ticket file: /tmp/tkt_marc_tf0
Principal: [EMAIL PROTECTED]
Issued Expires Principal
Jul 5 15:10:06 Jul 6 01:10:06 [EMAIL PROTECTED]
Jul 5 15:10:10 Jul 6 01:10:10 [EMAIL PROTECTED]
Jul 5 15:11:32 Jul 6 01:11:32 [EMAIL PROTECTED]
Jul 5 15:11:34 Jul 6 01:11:34 [EMAIL PROTECTED]
Jul 5 15:11:34 Jul 6 01:11:34 [EMAIL PROTECTED]
And the output from tokens:
<20> steve-dallas:~> tokens
Tokens held by the Cache Manager:
[ 1]User's (AFS ID 458546) tokens for [EMAIL PROTECTED] [Expires Jul 6 01:11]
[ 2]User's (AFS ID 8888) tokens for [EMAIL PROTECTED] [Expires Jul 6 01:11]
[ 3]User's (AFS ID 8888) tokens for [EMAIL PROTECTED] [Expires Jul 601:10]
[ 4] --End of list--
I use these three cells regularly, and two more (not listed here)
irregularly. Note that I have tickets (and tokens) in two MIT cells
using the ATHENA.MIT.EDU kerberos realm, and a third cell using
Kerberos interrealm to get a service key for afs.<cell>@<realm> in a
completely different cell and realm (which is actually running Kv5!),
and aklog gets me a token, using the cross-cell support in afs 3.2.
>> Will AFS (3.2) trust both instances?
This is not an afs release issue. If you stick the afs key in your
kerberos database with the name 'i-love.transarc@<realm>', and modify
aklog accordingly, aklog will still work. As for the current
implementation, it appears that the aklog in use at MIT supports both
naming systems:
/*
* Try to obtain AFS tickets. Because there are two valid service
* names, we will try both, but trying the more specific first.
*
* afs.<cell>@<realm>
* afs@<realm>
*/
If the DEC release only supports the first naming system, then I'd say
that MIT is right and DEC is incomplete, not really wrong.
What this means is that you should be able to add an
afs.<cell>@<realm> key to your kdc, and your current aklog should
continue to work. But I'd check the sources, first, to be sure :-)
Marc
