[OpenAFS] Quick Start Kerberos problem: can acquire tokens, but they don't work

Phillip Moore w.phillip.moore@gmail.com
Thu, 30 Sep 2010 07:56:46 -0400


--0015175cd5f6bbebad049178c518
Content-Type: text/plain; charset=ISO-8859-1

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':

[root@fhcore etc]# kadmin -k
Authenticating as principal host/fhcore.boot.efs@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.efs@BOOT.EFS;
defaulting to no policy
Principal "afs/d.fh.nyc.us.boot.efs@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.

[root@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"):

[root@fhcore ~]# kinit afsadmin
Password for afsadmin@BOOT.EFS:
[root@fhcore ~]# aklog
[root@fhcore ~]# tokens

Tokens held by the Cache Manager:

User's (AFS ID 500) tokens for afs@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.

[root@fhcore ~]# pts examine afsadmin
pts: Permission denied ; unable to find entry for (id: 500)
[root@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:

[root@fhcore ~]# pts mem afsadmin -local
Groups afsadmin (id: 500) is a member of:
  system:administrators
[root@fhcore ~]# bos listusers localhost -local
SUsers are: afsadmin
[root@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.

--0015175cd5f6bbebad049178c518
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

My quest to refresh my AFS knowledge continues, with mixed results. =A0<div=
><br></div><div>I can get as far as rebooting the first AFS machine, and th=
e server and client seems to come up fine, and talk to each other. =A0I can=
 run any administrative command as long as I use -localauth, and while I ca=
n get tokens for the localcell just fine, the AFS server processes aren&#39=
;t trusting them. =A0</div>
<div><br></div><div>I&#39;m using CentOS 5.4 on x86_64, using the Kerberos =
version which is packaged with CentOS by default. =A0I&#39;ve had no proble=
m setting up my krb5 realm (BOOT.EFS) and using it (my product already uses=
 GSSAPI for basic authentication). =A0 Here&#39;s the Kerberos-related deta=
ils of how this was setup. =A0</div>
<div><br></div><div>The AFS cell name is &#39;d.fh.nyc.us.boot.efs&#39;:</d=
iv><div><br></div><div><div>[root@fhcore etc]# kadmin -k</div><div>Authenti=
cating as principal host/fhcore.boot.efs@BOOT.EFS with default keytab.</div=
>
<div>kadmin: =A0add_principal -randkey -e des-cbc-crc:v4 afs/d.fh.nyc.us.bo=
ot.efs</div><div>WARNING: no policy specified for afs/d.fh.nyc.us.boot.efs@=
BOOT.EFS; defaulting to no policy</div><div>Principal &quot;afs/d.fh.nyc.us=
.boot.efs@BOOT.EFS&quot; created.</div>
</div><div><div>kadmin: =A0ktadd -k /etc/afs.keytab -e des-cbc-crc:v4 afs/d=
.fh.nyc.us.boot.efs</div><div>Entry for principal afs/d.fh.nyc.us.boot.efs =
with kvno 3, encryption type DES cbc mode with CRC-32 added to keytab WRFIL=
E:/etc/afs.keytab.</div>
</div><div><br></div><div><div>[root@fhcore etc]# =A0asetkey add 3 /etc/afs=
.keytab afs/d.fh.nyc.us.boot.efs</div></div><div><br></div><div>After reboo=
ting, everything comes up without error. =A0 So, I get tokens as the afsadm=
in used (which I&#39;ve defined instead of the generic &quot;admin&quot;):<=
/div>
<div><br></div><div><div>[root@fhcore ~]# kinit afsadmin</div><div>Password=
 for afsadmin@BOOT.EFS:=A0</div><div>[root@fhcore ~]# aklog</div><div>[root=
@fhcore ~]# tokens</div><div><br></div><div>Tokens held by the Cache Manage=
r:</div>
<div><br></div><div>User&#39;s (AFS ID 500) tokens for afs@d.fh.nyc.us.boot=
.efs [Expires Oct =A01 07:13]</div><div>=A0=A0 --End of list--</div></div><=
div><br></div><div>So far, this looks good. =A0However, the server processe=
s do not trust these tokens.</div>
<div><br></div><div><div>[root@fhcore ~]# pts examine afsadmin</div><div>pt=
s: Permission denied ; unable to find entry for (id: 500)</div><div>[root@f=
hcore ~]# pts examine afsadmin -localauth</div><div>Name: afsadmin, id: 500=
, owner: system:administrators, creator: anonymous,</div>
<div>=A0=A0membership: 1, flags: S----, group quota: unlimited.</div></div>=
<div><br></div><div>Note that I had to use -localauth to get the informatio=
n. =A0 This user is defined as a member of system:administrators, and is a =
bos superuser:</div>
<div><br></div><div><div>[root@fhcore ~]# pts mem afsadmin -local</div><div=
>Groups afsadmin (id: 500) is a member of:</div><div>=A0=A0system:administr=
ators</div><div>[root@fhcore ~]# bos listusers localhost -local</div><div>S=
Users are: afsadmin=A0</div>
</div><div><div>[root@fhcore ~]# bos listhosts localhost</div><div>Cell nam=
e is d.fh.nyc.us.boot.efs</div><div>=A0=A0 =A0Host 1 is fhcore</div></div><=
div><br></div><div>I&#39;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.</div>
<div><br></div><div>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 wit=
h the non-Kerberos AFS issues kept me busy enough :-P), so I&#39;m not enti=
rely sure how to debug this. =A0</div>
<div><br></div><div>How do I get the AFS server process to tell me how the =
credentials are being handled? =A0 I can get the bosserver to log who did s=
omething successfully, but I can&#39;t see how I can get it to log the deni=
als of access, so I can perhaps figure out why it doesn&#39;t like my token=
s.</div>
<div><br></div><div>Is there a step in the kerberos setup missing from the =
Quick Start Guide, perhaps? =A0At this point, I&#39;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.</di=
v>

--0015175cd5f6bbebad049178c518--