>At that point, you may as well run krb524d on your KDC or AFS database
>servers, and use krb524init and the V4 aklog (in fact, I believe someone
>has released a V5-aware aklog that rolls the krb524 operation into the same
>binary. You still have to be running a krb524 service, of course, since
>one needs the service key in order to do the translation). This is a
>solution that will work _today_ for people who want to use a DCE or Win2K
>KDC with their AFS cell.
I know that Doug said he did that in his aklog, but I'd like to mention
that I took his work and rolled it into the aklog that I distribute
in the AFS/Kerberos 5 Migration Kit.
>> One of the questions is: Should AFS be treated as a service, in a realm,
>> running under principals such as: afs/<afscell>@<k5-relam>
>>
>> This could allow multiple AFS cells to be served by a single realm, or
>> even multiple realms could issue tickets for the same cell.
>
>There is precedent for this -- there are several cells at MIT which all use
>the ATHENA.MIT.EDU realm, using service keys named
>afs.<cellname>@ATHENA.MIT.EDU.
>I think the correct behaviour is pretty obvious -- first try
>afs/cellname@REALM, and then just afs@REALM; in both cases, REALM is the
>realm containing the cell according to domain_realm mappings. (the current
>MIT aklog actually uses the realm containing the cell's database servers; a
>subtle but potentially important distinction). The resulting ticket can be
>used as-is with mythical V5-aware rxkad, or handed to the krb524 translator
>to get a V4 ticket that can be used with the currentlty-available AFS
>software.
What I implement in the aklog that I use is I try afs/cellname IFF the
cellname != Kerberos realm. Seems to work reasonably well.
--Ken
