SCIENTIFIC-LINUX-USERS Archives

January 2011

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Stephan Wiesand <[log in to unmask]>
Reply To:
Stephan Wiesand <[log in to unmask]>
Date:
Thu, 27 Jan 2011 13:53:39 +0100
Content-Type:
multipart/signed
Parts/Attachments:
text/plain (5 kB) , smime.p7s (4 kB)
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: [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.

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:[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

-- 
Stephan Wiesand
DESY -DV-
Platanenallee 6
15738 Zeuthen, Germany






ATOM RSS1 RSS2