[OpenAFS] Fedora 7 pam_afs won't save tickets after login. How to find missing tokens, if they ever existed?

Paul Johnson pauljohn32@gmail.com
Fri, 15 Jun 2007 12:54:56 -0500

I've been running FC5 and FC6 systems with openafs as an
authentication server and file server.  After installing Fedora 7 this
week and building openafs 1.4.4 for it, I find I am able to use the
openafs authentication and also the login process does work to mount
the afs drives and a script that copies some configuration files from
the afs server to the local hard disk, which I have running through
the PreSession options in the Gnome Display Manager (gdm), does run.
However, when the session has started, the token is somehow lost, and
the user is not allowed to look at files in /afs/ku.edu/usr anymore.
If the user quickly opens a terminal and runs "klog" then all is well,
as the symbolic links from the server to the desktop are kept alive.

I barely understand the basics of pam and don't know what might have
changed in the kernel that would cause this to happen.  I've put
everything into the setup in the exact same way that it was in FC5 and
6.  Basically, I just insert the pam_afs line for auth. The only other
non-standard thing I do is allow the pam_mkhomedir to create local
user directories, but I don't understand why that would make tokens

Here's my /etc/pam.d/system-auth.

auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 100 quiet
auth        sufficient    pam_afs.so use_first_pass ignore_root
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass
password    required      pam_deny.so

session    required     /lib/security/$ISA/pam_mkhomedir.so
skel=/etc/skel/ umask=0022
session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in
crond quiet use_uid
session     required      pam_unix.so

Do you know what's wrong?

The server against which I am authenticating has not yet changed over
from the old AFS tokens to the krb5 type, so I think that means I'm
right to use pam_afs rather than pam_krb5 or whatever.  Eh?

Paul E. Johnson
Professor, Political Science
1541 Lilac Lane, Room 504
University of Kansas