[OpenAFS-devel] Krb5-only and KeyFile?

[Jeffrey Hutzelman]

On Sunday, June 05, 2005 01:22:18 PM -0500 Troy Benjegerdes 
<hozer@hozed.org> wrote:

> On Sun, Jun 05, 2005 at 12:08:35PM -0400, Jeffrey Altman wrote:
>> Troy Benjegerdes wrote:
>>
>>  > This seems to keep getting discussed. Does anyone have a roadmap of
>>  > what needs to be done to get to full native Krb5 support, and doing
>> > away with a dependence on des keys?
>>
>> Full krb5 support is available to you now.   The only restriction is
>> that you must use a DES key for the AFS service principal.
>
> So is there an aklog (or something like it) that does not require running
> krb524d?

It is possible to build such an aklog, yes.  Heimdal's libkafs and afslog 
support this mode of operation; to enable it, you need to set "afs-use-524" 
to either "local" or "2b" in the [appdefaults] section of krb5.conf (the 
"local" setting will set full krb5 tickets as tokens; the "2b" setting will 
set rxkad-2b tokens, which are smaller and may be required for older cache 
managers or if your tickets are unusually large for some reason).


> Are user/admin type AFS names supported by default by
> the ptserver? (as opposed to 'user.admin')

No.  The AFS usernames appearing in the ptserver are strings, not krb4 
principal names.  The mapping from the authenticated principal to the AFS 
username of the client is done in each server.  About half of the work is 
done inside rxkad, and the rest in rxkad-specific code in each server. 
Right now, this mapping is fixed and is fairly simple:

 - for single-component names (V4 or V5), we use the one component
 - for two-component V4 names, we use the two components separated by dots.
 - for two-component V5 names, we use the two components separated by dots,
   except that host/foo is converted to rcmd.foo, and for some 40 services
   the second component is truncated at the first dot (*)
 - names with more than two components are rejected
 - if the realm is not one of the server's local realms, we add @realm,
   with the realm coerced to lower case.
 (*) This rule is odd, but is designed to ease transition by ensuring that
     in a realm supporting both krb4 and krb5, clients get the same viceID
     regardless of which authentication protocol is used.


I expect that at some point after the rxgk work has been integrated, the 
fileserver and ptserver will be extended to allow more complex mappings to 
vice ID's from authentication identities provided by krb5 or other GSSAPI 
mechanisms.  We may even end up with something that allows administrators 
to specify completely arbitrary mappings.


-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA