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]
-- 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
