Neulinger, Nathan wrote:
I was basically meaning "take gssklogd and hack it to handle multiple realms with 2b, and not just a single realm" - i.e. pretend to be [EMAIL PROTECTED] to AFS, even though you're really [EMAIL PROTECTED]
It can already handle the multiple realms, see the multiple -E realm options to specify the "enterprise" realms, where [EMAIL PROTECTED] will map to [EMAIL PROTECTED]
What it does not do is return a 2b token, but it could; use RX or negotiate gss mechanisms.
-- Nathan
------------------------------------------------------------
Nathan Neulinger EMail: [EMAIL PROTECTED]
University of Missouri - Rolla Phone: (573) 341-6679
UMR Information Technology Fax: (573) 341-4216
-----Original Message-----
From: Douglas E. Engert [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 22, 2004 10:55 AM
To: Jeffrey Hutzelman
Cc: Neulinger, Nathan; [EMAIL PROTECTED]
Subject: Re: [OpenAFS-devel] Anyone supporting multiple realms in a "all realms are equal" type of setup?
Yes this could work for Kerberos.
You mentioned using an arbitrary gssapi with RX. If you use this approach vs a
mapping service, you will need to support the arbitrary gssapi in the client's
kernel as well as all the services. With the mapping service the arbitrary
gssapi is only needed for the initial acquisition of the token, and you can
use the krb5 2b tokens. An arbitrary gssapi may not give you access to the
session keys, but require you to use gs_wrap/unwrap whihc might be more
overhead then you want. There might also be more gss_name issues.
Only the initial token issuing mapping service need to be aware of the gssapi issues introduced with arbitrary GSSAPI.
Jeff Hutzelman wrote:
On Wednesday, September 22, 2004 10:07:57 -0500 "Neulinger, Nathan" <[EMAIL PROTECTED]> wrote:
I have a scenario that I'm needing to treat 5 or 6
different kerberos
realms as equivalent for access to AFS even though they
have different
sets of users in them. Other requirement is that users not
have to type
in the full "[EMAIL PROTECTED]" for acling.
Yes, CMU is doing that, with multiple sites each of which
has its own
realm and AFS cell, but which share a common user principal
namespace
with each user having a "primary" home realm. They're using that approach to support new campuses which have separate infrastructure while allowing users to move between campuses. I can't
provide more
details, since that's not actually my part of the
university, but I bet
Derrick or Chaskiel can.
One thought I had is that I could live with regular
cross-realm if there
was some way to add "aliases" to PTS. That would solve the "regular
userid for the acl" problem and eliminate #2 above in lieu
of just using
regular cross realm support. Basically, allow a PTS ID to
have multiple
possible principal names, so that "nneul" would also be known as "[EMAIL PROTECTED]" and "[EMAIL PROTECTED]", with only the primary (short) name being returned in a ID-to-Name lookup.
I've been thinking about something along these lines for a
while; in
fact, the issue just came up on zephyr. IMHO this is too major a feature to appear in 1.4 (especially since we've just begun
to design
it), but I do believe it's the right direction.
Basically, I envision augmenting the existing PTS database with a mapping from authentication identities to PTS entries.
Each entry in
the PTS database would continue to have a single canonical name. However, each entry would also have a set of authentication
identities
which correspond to that entry. Each identity would consist of an authentication mechanism ID (name?) and a name, so that it would be possible to add new authentication methods without changing the interface again. This is particularly interesting as rxgk makes it possible to use arbitrary GSSAPI or even other mechanisms.
Under this approach, the existing ptserver operations would
continue to
work as before, using the entry's canonical name only. A
new set of
operations would be added to examine and manipulate the
authentication
identity mappings, including a lookup-by-authid operation which the fileserver would use in lieu of a normal name-to-id mapping.
Comments?
-- Jeff _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
--
Douglas E. Engert <[EMAIL PROTECTED]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444
_______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
--
Douglas E. Engert <[EMAIL PROTECTED]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
