My quest to refresh my AFS knowledge continues, with mixed results.
I can get as far as rebooting the first AFS machine, and the server and
client seems to come up fine, and talk to each other. I can run any
administrative command as long as I use -localauth, and while I can get
tokens for the localcell just fine, the AFS server processes aren't trusting
them.
I'm using CentOS 5.4 on x86_64, using the Kerberos version which is packaged
with CentOS by default. I've had no problem setting up my krb5 realm
(BOOT.EFS) and using it (my product already uses GSSAPI for basic
authentication). Here's the Kerberos-related details of how this was
setup.
The AFS cell name is 'd.fh.nyc.us.boot.efs':
[r...@fhcore etc]# kadmin -k
Authenticating as principal host/fhcore.boot....@boot.efs with default
keytab.
kadmin: add_principal -randkey -e des-cbc-crc:v4 afs/d.fh.nyc.us.boot.efs
WARNING: no policy specified for afs/d.fh.nyc.us.boot....@boot.efs;
defaulting to no policy
Principal "afs/d.fh.nyc.us.boot....@boot.efs" created.
kadmin: ktadd -k /etc/afs.keytab -e des-cbc-crc:v4 afs/d.fh.nyc.us.boot.efs
Entry for principal afs/d.fh.nyc.us.boot.efs with kvno 3, encryption type
DES cbc mode with CRC-32 added to keytab WRFILE:/etc/afs.keytab.
[r...@fhcore etc]# asetkey add 3 /etc/afs.keytab afs/d.fh.nyc.us.boot.efs
After rebooting, everything comes up without error. So, I get tokens as
the afsadmin used (which I've defined instead of the generic "admin"):
[r...@fhcore ~]# kinit afsadmin
Password for afsad...@boot.efs:
[r...@fhcore ~]# aklog
[r...@fhcore ~]# tokens
Tokens held by the Cache Manager:
User's (AFS ID 500) tokens for a...@d.fh.nyc.us.boot.efs [Expires Oct 1
07:13]
--End of list--
So far, this looks good. However, the server processes do not trust these
tokens.
[r...@fhcore ~]# pts examine afsadmin
pts: Permission denied ; unable to find entry for (id: 500)
[r...@fhcore ~]# pts examine afsadmin -localauth
Name: afsadmin, id: 500, owner: system:administrators, creator: anonymous,
membership: 1, flags: S----, group quota: unlimited.
Note that I had to use -localauth to get the information. This user is
defined as a member of system:administrators, and is a bos superuser:
[r...@fhcore ~]# pts mem afsadmin -local
Groups afsadmin (id: 500) is a member of:
system:administrators
[r...@fhcore ~]# bos listusers localhost -local
SUsers are: afsadmin
[r...@fhcore ~]# bos listhosts localhost
Cell name is d.fh.nyc.us.boot.efs
Host 1 is fhcore
I'm not seeing any errors at all in my Kerberos logs when I acquire these
tickets/tokens, and I see no errors in any of the AFS logs of any kind
whatsoever.
This was always my weak area with AFS, back when I was still an elder, since
I had Kerberos gurus working with me (and dealing with the non-Kerberos AFS
issues kept me busy enough :-P), so I'm not entirely sure how to debug this.
How do I get the AFS server process to tell me how the credentials are being
handled? I can get the bosserver to log who did something successfully,
but I can't see how I can get it to log the denials of access, so I can
perhaps figure out why it doesn't like my tokens.
Is there a step in the kerberos setup missing from the Quick Start Guide,
perhaps? At this point, I'm stuck because while I can manage the server
process fine using -localauth, these tokens are not working for filesystem
access, and therefore filesystem administration.
