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: [email protected] Valid starting Expires Service principal 01/27/11 05:22:17 01/28/11 05:22:17 krbtgt/[email protected] renew until 01/28/11 05:22:57 [john@horst ~]$ [john@horst ~]$ tokens Tokens held by the Cache Manager: Tokens for [email protected] [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:[email protected]' 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" ("afs/[email protected]") 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:[email protected]' 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:[email protected]' for internal use Jan 27 05:22:58 horst sshd[437]: pam_krb5[437]: copied credentials from "MEMORY:[email protected]" to "FILE:/tmp/krb5cc_2013_BKf437" for the user, destroying "MEMORY:[email protected]" 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 [email protected] [Expires Jan 28 05:22] --End of list-- [john@horst ~]$ klist Ticket cache: FILE:/tmp/krb5cc_2013_Zrlips Default principal: [email protected] Valid starting Expires Service principal 01/27/11 05:22:17 01/28/11 05:22:17 krbtgt/[email protected] renew until 01/28/11 05:22:57 01/27/11 06:08:22 01/28/11 05:22:17 afs/[email protected] renew until 01/28/11 05:22:57 Has anybody an idea how to track down this issue? Thanks a lot Andreas
