Hi folks,

I'm not completely sure whether this is the correct list,
but in the end it's a user related issue for SL6 so...
 
We try to setup KRB5/LDAP based login for our users on SL6.
The file system of the user-homes is OpenAFS so
we need to get an afs token at login time.

We first started using sssd but could not get an afs token
at all. Following the bugreport on RH:
https://bugzilla.redhat.com/show_bug.cgi?id=186527#c82
we realized, that sssd is not the weapon of choice at the
moment and we switched to the "classical" method,
set up ldap and krb5 via the usual config files and disabled 
sssd via authconfig.

Reading the documentation I understand that generating an AFS-Token
in RH-based distributions is also done by pam_krb5.so. 
So we tuned /etc/pam.d/system-auth and  so far the connection to our KDC + openLDAP is fine.
The password gets accepted and a KRB5 ticket gets created but apparently no AFS-Token (only the TGT):

---
john@horst's password: 
Last login: Thu Jan 27 05:20:34 2011 from 172.17.1.3
[john@horst ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_2013_Zrlips
Default principal: [log in to unmask]

Valid starting     Expires            Service principal
01/27/11 05:22:17  01/28/11 05:22:17  [log in to unmask]
        renew until 01/28/11 05:22:57
[john@horst ~]$ 
[john@horst ~]$ tokens

Tokens held by the Cache Manager:

Tokens for [log in to unmask] [Expires Jan 28 05:22]
   --End of list--
---

But: the strange thing is, that the system behaves exactly as if I had a correct AFS-Token.
I can read and write in my home, but can't in others.

The secure logfile supports the existence of a ticket:

Jan 27 05:22:58 horst sshd[437]: pam_krb5[437]: token strategy: v4,524,2b,rxk5
Jan 27 05:22:58 horst sshd[437]: pam_krb5[437]: saving v5 credentials to 'MEMORY:[log in to unmask] for internal use
Jan 27 05:22:58 horst sshd[437]: pam_krb5[437]: obtaining afs tokens
Jan 27 05:22:58 horst sshd[437]: pam_krb5[437]: creating new PAG
Jan 27 05:22:58 horst sshd[437]: pam_krb5[437]: obtaining tokens for local cell 'myrealm.local'
Jan 27 05:22:58 horst sshd[437]: pam_krb5[437]: trying with v5 ticket (2b)
Jan 27 05:22:58 horst sshd[437]: pam_krb5[437]: attempting to determine realm for "myrealm.local"
Jan 27 05:22:58 horst sshd[437]: pam_krb5[437]: file server for "/afs/myrealm.local" is X.X.X.X
Jan 27 05:22:58 horst sshd[437]: pam_krb5[437]: file server X.X.X.X has name afs1.myrealm.local
Jan 27 05:22:58 horst sshd[437]: pam_krb5[437]: afs1.myrealm.local is in realm MYREALM.LOCAL
Jan 27 05:22:58 horst sshd[437]: pam_krb5[437]: attempting to obtain tokens for "myrealm.local" ("[log in to unmask]")
Jan 27 05:22:58 horst sshd[437]: pam_krb5[437]: got tokens for cell "myrealm.local"
Jan 27 05:22:58 horst sshd[437]: pam_krb5[437]: no additional afs cells configured
Jan 27 05:22:58 horst sshd[437]: pam_krb5[437]: removing ccache 'MEMORY:[log in to unmask]
Jan 27 05:22:58 horst sshd[437]: pam_krb5[437]: creating v5 ccache for 'john', uid=2013, gid=5001
Jan 27 05:22:58 horst sshd[437]: pam_krb5[437]: saving v5 credentials to 'MEMORY:[log in to unmask] for internal use
Jan 27 05:22:58 horst sshd[437]: pam_krb5[437]: copied credentials from "MEMORY:[log in to unmask]" to "FILE:/tmp/krb5cc_2013_BKf437" for the user, destroying "MEMORY:[log in to unmask]"
Jan 27 05:22:58 horst sshd[437]: pam_krb5[437]: created v5 ccache 'FILE:/tmp/krb5cc_2013_Zrlips' for 'john'
Jan 27 05:22:58 horst sshd[437]: pam_krb5[437]: pam_open_session returning 0 (Success)

----

So our impression is, that the token is still in memory but does not make it into the machine's KRB Cache (where klist would look for it?).
The File /tmp/krb5cc_2013_BKf437 (as shown in the log) has never been seen.
Also, as soon as I execute aklog everything is correctly shown:

[john@horst ~]$ aklog
[john@horst ~]$ tokens

Tokens held by the Cache Manager:

User's (AFS ID 2013) tokens for [log in to unmask] [Expires Jan 28 05:22]
   --End of list--
[john@horst ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_2013_Zrlips
Default principal: [log in to unmask]

Valid starting     Expires            Service principal
01/27/11 05:22:17  01/28/11 05:22:17  [log in to unmask]
        renew until 01/28/11 05:22:57
01/27/11 06:08:22  01/28/11 05:22:17  [log in to unmask]
        renew until 01/28/11 05:22:57

Has anybody an idea how to track down this issue?

Thanks a lot

Andreas