[OpenAFS] Re: Two realms and one cell

Andrew Deason adeason@sinenomine.net
Thu, 3 Jul 2014 11:38:17 -0500


On Wed, 02 Jul 2014 22:18:56 +0200
Jean-Marc Choulet <jm130794@gmail.com> wrote:

> A little question. We have one AFS cell myrealm.fr and a Kerberos
> realm myrealm.fr. We must use our AFS cell with a another realm named
> otherrealm.fr. There is no trusted relations between myrealm.fr and
> otherrealm.fr. Is it possible ?

Yes. Since you have no trust relationship between the realms, you'll
need to have both principals afs/myrealm.fr@MYREALM.FR and
afs/myrealm.fr@OTHERREALM.FR, and you need to have the key data for both
be in the rxkad.keytab/KeyFile files on your servers. If I recall
correctly, if you're using the single-DES KeyFile, those two principals
need to be using different kvnos, but I don't think there's any such
restriction when using rxkad.keytab.

You also need to tell the users or client machines in OTHERREALM.FR that
they need to look in OTHERREALM.FR for the AFS service princ, and not
MYREALM.FR. That is, by default 'aklog' will try to get tickets for
afs/myrealm.fr@MYREALM.FR, but username@OTHERREALM.FR won't be able to
get those without a cross-realm trust. Instead you want
username@OTHERREALM.FR to look at afs/myrealm.fr@OTHERREALM.FR. On
Unix, that's usually handled in the domain_realm mapping in your local
krb5.conf; you can also use the -k option to aklog.

If you want username@MYREALM.FR and username@OTHERREALM.FR to both be
the AFS user 'username', then also do what Mike Meffie said with
krb.conf. But if you want username@MYREALM.FR to be a different user
than username@OTHERREALM.FR, then you can use the concept of AFS
"foreign users". That appears to be discussed a little here
<http://docs.openafs.org/AdminGuide/HDRWQ36.html#HDRWQ40>, but you can
also probably find it mentioned elsewhere. That mentions using a
cross-realm trust, since using "foreign users" usually involves a
cross-realm trust, but I think you should be able to use them just fine
with separate AFS service principals, too.

-- 
Andrew Deason
adeason@sinenomine.net