On Sunday, June 05, 2005 01:22:18 PM -0500 Troy Benjegerdes
<[EMAIL PROTECTED]> 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) <[EMAIL PROTECTED]>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
