[OpenAFS-devel] Anyone supporting multiple realms in a "all realms
are equal" type of setup?
Douglas E. Engert
deengert@anl.gov
Wed, 22 Sep 2004 11:15:07 -0500
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
> fred@UMR.EDU to AFS, even though you're really fred@UM.UMSYSTEM.EDU
It can already handle the multiple realms, see the
multiple -E realm options to specify the "enterprise" realms,
where x@realm will map to x@cell
What it does not do is return a 2b token, but it could;
use RX or negotiate gss mechanisms.
>
> -- Nathan
>
> ------------------------------------------------------------
> Nathan Neulinger EMail: nneul@umr.edu
> University of Missouri - Rolla Phone: (573) 341-6679
> UMR Information Technology Fax: (573) 341-4216
>
>
>
>>-----Original Message-----
>>From: Douglas E. Engert [mailto:deengert@anl.gov]
>>Sent: Wednesday, September 22, 2004 10:55 AM
>>To: Jeffrey Hutzelman
>>Cc: Neulinger, Nathan; openafs-devel@openafs.org
>>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"
>>><nneul@umr.edu> 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 "user@realm" 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
>>>>"nneul@umr.edu" and "nneul@um.umsystem.edu", 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
>>>OpenAFS-devel@openafs.org
>>>https://lists.openafs.org/mailman/listinfo/openafs-devel
>>>
>>>
>>>
>>
>>--
>>
>> Douglas E. Engert <DEEngert@anl.gov>
>> Argonne National Laboratory
>> 9700 South Cass Avenue
>> Argonne, Illinois 60439
>> (630) 252-5444
>>
>>
>
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
>
>
>
--
Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444