Eric Chris Garrison wrote: >> From: Andrew Deason <[email protected]> >>> 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 > [email protected] 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 > [email protected] and have the same permissions as > [email protected], 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 [email protected] and [email protected] 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 [email protected] and then issue: kvno -k <keytab> afs/[email protected] If the key verifies then it can be imported into the AFS KeyFile and distributed to all of your services. Jeffrey Altman _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
