Hi Andreas, On Jan 27, 2011, at 12:32, Andreas Donath wrote:
> 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... the openafs-info list would be a good choice, but sl-users is fine too. > 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. Yes, this has "just worked" (TM) since we tried it the first time on RHEL6 beta. > 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): The output below suggests you do get a token. > --- > 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. That's because you have one ;-) You may want to read the thread starting here: https://lists.openafs.org/pipermail/openafs-info/2010-March/033341.html Best regards, Stephan > 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 -- Stephan Wiesand DESY -DV- Platanenallee 6 15738 Zeuthen, Germany
smime.p7s
Description: S/MIME cryptographic signature
