[OpenAFS-devel] Anyone supporting multiple realms in a "all realms are equal" type of setup?

[Neulinger, Nathan]

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

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@umr.edu
University of Missouri - Rolla         Phone: (573) 341-6679
UMR Information Technology             Fax: (573) 341-4216
=20

> -----Original Message-----
> From: Douglas E. Engert [mailto:deengert@anl.gov]=20
> 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=20
> realms in a "all realms are equal" type of setup?
>=20
> Yes this could work for Kerberos.
>=20
> You mentioned using an arbitrary gssapi with RX. If you use=20
> this approach vs a
> mapping service, you will need to support the arbitrary=20
> gssapi in the client's
> kernel as well as all the services.  With the mapping service=20
> the arbitrary
> gssapi is only needed for the initial acquisition of the=20
> token, and you can
> use the krb5 2b tokens. An arbitrary gssapi may not give you=20
> access to the
> session keys, but require you to use gs_wrap/unwrap whihc=20
> might be more
> overhead then you want. There might also be more gss_name issues.
>=20
> Only the initial token issuing mapping service need to be aware of the
> gssapi issues introduced with arbitrary GSSAPI.
>=20
>=20
> Jeff Hutzelman wrote:
>=20
> >=20
> >=20
> > On Wednesday, September 22, 2004 10:07:57 -0500 "Neulinger, Nathan"=20
> > <nneul@umr.edu> wrote:
> >=20
> >> I have a scenario that I'm needing to treat 5 or 6=20
> different kerberos
> >> realms as equivalent for access to AFS even though they=20
> have different
> >> sets of users in them. Other requirement is that users not=20
> have to type
> >> in the full "user@realm" for acling.
> >=20
> >=20
> > Yes, CMU is doing that, with multiple sites each of which=20
> has its own=20
> > realm and AFS cell, but which share a common user principal=20
> namespace=20
> > with each user having a "primary" home realm.  They're using that=20
> > approach to support new campuses which have separate infrastructure=20
> > while allowing users to move between campuses.  I can't=20
> provide more=20
> > details, since that's not actually my part of the=20
> university, but I bet=20
> > Derrick or Chaskiel can.
> >=20
> >=20
> >=20
> >=20
> >=20
> >> One thought I had is that I could live with regular=20
> 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=20
> of just using
> >> regular cross realm support. Basically, allow a PTS ID to=20
> 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.
> >=20
> >=20
> > I've been thinking about something along these lines for a=20
> while; in=20
> > fact, the issue just came up on zephyr.  IMHO this is too major a=20
> > feature to appear in 1.4 (especially since we've just begun=20
> to design=20
> > it), but I do believe it's the right direction.
> >=20
> >=20
> > Basically, I envision augmenting the existing PTS database with a=20
> > mapping from authentication identities to PTS entries. =20
> Each entry in=20
> > the PTS database would continue to have a single canonical name. =20
> > However, each entry would also have a set of authentication=20
> identities=20
> > which correspond to that entry.  Each identity would consist of an=20
> > authentication mechanism ID (name?) and a name, so that it would be=20
> > possible to add new authentication methods without changing the=20
> > interface again.  This is particularly interesting as rxgk makes it=20
> > possible to use arbitrary GSSAPI or even other mechanisms.
> >=20
> > Under this approach, the existing ptserver operations would=20
> continue to=20
> > work as before, using the entry's canonical name only.  A=20
> new set of=20
> > operations would be added to examine and manipulate the=20
> authentication=20
> > identity mappings, including a lookup-by-authid operation which the=20
> > fileserver would use in lieu of a normal name-to-id mapping.
> >=20
> > Comments?
> >=20
> > -- Jeff
> > _______________________________________________
> > OpenAFS-devel mailing list
> > OpenAFS-devel@openafs.org
> > https://lists.openafs.org/mailman/listinfo/openafs-devel
> >=20
> >=20
> >=20
>=20
> --=20
>=20
>   Douglas E. Engert  <DEEngert@anl.gov>
>   Argonne National Laboratory
>   9700 South Cass Avenue
>   Argonne, Illinois  60439
>   (630) 252-5444
>=20
>=20