Kerberos tickets and AFS tokens demystified

[predragp at andrew.cmu.edu]

Dear Jeff,

First off I would like to apologize for wasting your time with improperly
set AFS. After I left yesterday I got mad at myself for not taking the
time to truly understand how Kerberos and AFS work so I did some
experimenting and reading. I would like to summarize things in few short
paragraphs which will hopefully help you and other Auton Lab affiliates to
use AFS more efficiently.


CMU SCS uses Kerberos, an authentication protocol which works on the basis
of 'tickets', to allow access to its infrastructure over hostile network.
kinit command (part of krb5-workstation package on Red Hat) obtains the
master Kerberos ticket. You should type this command first whenever you
want to use AFS. klist shows you all of your tickets and tells you when
they will expire. In my understanding CMU Kerberos server will issue
tickets up to 30 days. Having a Kerberos ticket is not sufficient to grant
you access to your files on AFS!


AFS does secure authentication through tokens. You get token after
obtaining Kerberos ticket first by typing

klog.krb5 <account>@CS.CMU.EDU -c cs.cmu.edu -k CS.CMU.EDU

(alternatively you can also use aklog command). The above command is part
of openafs-krb5 package. An AFS token is a Kerberos ticket for the AFS
service, stored in the kernel file system layer. The

> tokens

command will show you your current AFS tokens and when they expire. CMU
SCS issues tokens for
up to 25 hours. That creates problems as you found out when your data
stored on AFS is used by computer programs which run longer than 25h.

>  krenew

command renews an existing renewable Kerbers tickets but more importantly
it has an important
switch -t to run external program like aklog and obtain/renew AFS taken.
If you want to run programs which will use AFS for longer than 25 hours
you should run krenew command as a demon.

Finally the fact that you were able to use klog.krb5 alone on your works
station to access CS.CMU.EDU AFS tells me that either their server is
misconfigured or that they were automatically assuming that all machines
on the domain name cs.cmu.edu are Kerberised. Since our computing nodes
are not the part of cs.cmu.edu domain you have to use both kinit and
krb5.klog commands.


Few other remarks for other Auton Lab members. Only people with CS.CMU.EDU
accounts (cost $100 a month) have access to AFS and other network services
(like personal web page hosting) provided by the school of computer
science. If your LDAP username like in my case is different than your CS
account name you will have to get Kerberos ticket as

kinit account at CS.CMU.EDU

AFS requires kernel module which has to be identical to the kernel I am
running. As of yesterday I have OpenAFS kernel modules available for all
Red Hat kernels including the latest  2.6.32-504.1.3 which currently runs
on LOT2 for example. AFS is unforgiving when it comes to network
connection. If

service openafs-client start

command is issued at the moment when AFS servers (note plural as we are
talking about distributed file system here) not available (use many UDP
ports in range 7000-7010) AFS daemon afsd will become zombie process. Such
a zombie process can be killed only by rebooting the machine. Due to my
lack of understanding of Kerberos and AFS I have such zombie processes
running on several computing nodes which will have to be rebooted if you
guys want to use AFS.


Most Kind Regards,
Predrag Punosevac