[OpenAFS] ADS and MIT Kerberos transition auth continued

[Jeffrey Altman]

Eric Chris Garrison wrote:
>> From: Andrew Deason <adeason@sinenomine.net>
>>> I've added an afs service principal from each of two realms to the
>>> KeyFile using asetkey.   I've added both realms in /etc/krb.conf, the
>>> first two lines of the file being the two realms.
>> You probably want /usr/afs/etc/krb.conf (if using transarc paths), or
>> /etc/openafs/server/krb.conf.
> 
> Thanks, that did help, I've gotten further now.
> 
> What I'm seeing now though, is that although used asetkey to add the
> service principal from the ADS realm to my test cell, permissions aren't
> working as I'd expect.
> 
> So, we have realm AFSTEST.IU.EDU and ADS.IU.EDU.  Both in the KeyFile and
> in the /usr/afs/etc/krb.conf and both listed in the /etc/krb5.conf.
> 
> On a client machine, I can kinit as the original, as
> ecgarris@AFSTEST.IU.EDU and can get permissions as expected to OpenAFS
> directories with ACLs granted to OpenAFS user ecgarris.
> 
> I would expect on a multi-realm cell, that I could come in as
> ecgarris@ADS.IU.EDU and have the same permissions as
> ecgarris@AFSTEST.IU.EDU, but I don't, I get permission denied.  If I
> create a file in an anyuser-writable directory, the UNIX permissions show
> it as owned by ecgarris, but I still get Permission Denied when I try to
> access directories owned by OpenAFS ecgarris.
> 
> If I make the ONLY realm ADS.IU.EDU I have the same problem as well.
> 
> Does this mean if we switch domains, all existing users will need extra
> ACLs inserted to accommodate the new domain?  Is there a better answer?
> Am I just missing something simple?

it means you have done something wrong.

what adding multiple realm names to /usr/afs/etc/krb.conf tells the AFS
services after a restart is that all of the specified realms should be
considered as sources of local authentication identities.  If the
krb.conf file states

  ADS.IU.EDU AFSTEST.IU.EDU

then both the name ecgarris@ADS.IU.EDU and ecgarris@AFSTEST.IU.EDU will
be treated as "ecgarris".

When debugging authentication you should turn auditing on for all of
your services so that you can see what the authentication identities are
from the perspective of each service.

I would also verify that the keytabs that you are using are in fact
correct.  You can do so using the MIT Kerberos kvno command.  Obtain a
TGT for ecgarris@ADS.IU.EDU and then issue:

  kvno -k <keytab> afs/afstest.iu.edu@ADS.IU.EDU

If the key verifies then it can be imported into the AFS KeyFile and
distributed to all of your services.

Jeffrey Altman