Description of problem: Since Fedora Core Test 2, the pam_krb5 authentication module is broken. Every time I try to log on to the system using a user with a valid Kerberos V security principal, the following information is logged onto /var/log/ security: Sep 28 10:23:43 glass login: pam_krb5[2948]: default/local realm 'FELIPE-ALFARO.COM' Sep 28 10:23:43 glass login: pam_krb5[2948]: configured realm 'FELIPE-ALFARO.COM' Sep 28 10:23:43 glass login: pam_krb5[2948]: flags: forwardable Sep 28 10:23:43 glass login: pam_krb5[2948]: flag: user_check Sep 28 10:23:43 glass login: pam_krb5[2948]: flag: no krb4_convert Sep 28 10:23:43 glass login: pam_krb5[2948]: flag: warn Sep 28 10:23:43 glass login: pam_krb5[2948]: renewable lifetime: 36000 Sep 28 10:23:43 glass login: pam_krb5[2948]: banner: Kerberos 5 Sep 28 10:23:43 glass login: pam_krb5[2948]: ccache dir: /tmp Sep 28 10:23:43 glass login: pam_krb5[2948]: keytab: /etc/krb5.keytab Sep 28 10:23:43 glass login: pam_krb5[2948]: called to authenticate 'falfaro' Sep 28 10:23:43 glass login: pam_krb5[2948]: authenticating 'falfaro' Sep 28 10:23:43 glass login: pam_krb5[2948]: authentication fails for 'falfaro': Authentication failure (Generic error (see e-text)) pam_krb5 was working properly on Severn Beta 1. Upgrading Severn Beta 1 to latest RawHide components also breaks pam_krb5 authentication. What's curious about this issue is that: 1. This problem happens on every machine I installed Fedora Core Test 2 on. 2. I can successfully get a TGT (AS_REQ) by manually running "kinit" 3. I have configured OpenSSH to use Kerberos V authentication and it works perfectly. Kerberos V authentication on OpenSSH 3.6 only works when forcing the SSH protocol to version 1, and it does not rely on PAM. Thus, it works fine. 4. Other Linux distributions are able to authenticate via pam_krb5. In fact, my SuSE Linux 8.2 is authenticating via pam_krb5. 5. During the authentication process, no network traffic is emitted (tcpdump shows no TCP/UDP traffic directed to the Kerberos KDC), so it's clear to me it's a local problem and not related to an specific implementation or bug in the KDC software. 6. Unfortunately, it seems to be related to more components than pam_krb5 itself. Going back a few versions doesn't solve the problem. In fact, one of my Linux boxes have pam_krb5-2.0.2-1 and it's working flawlessly (it's a Severn Beta 1 machine). Attached to this message you will find my /etc/pam.d/system-auth and /etc/ krb5.conf files attached. Version-Release number of selected component (if applicable): pam_krb5-2.0.3-1 How reproducible: Always Steps to Reproduce: 1. Use authconfig to configure Kerberos V authentication. 2. Point to a valid Kerberos V kdc. 3. Create a Kerberos V security prinicipal. 4. Test you can acquire a TGT by running kinit manually. 5. Try logging from the console. It will probably work (if there is a local account in the machine with a shadow password), but no Kerberos V authentication will succeed. You can check this by running klist and seeing there are no Kerberos V tickets. Actual results: PAM authentication works, but authentication via Kerberos V (with pam_krb5) does not. Expected results: Kerberos V PAM authentication should work, as it did in Severn Beta 1. Additional info: Please, see attached files.
Created attachment 94798 [details] The contents of /etc/pam.d/system-auth
Created attachment 94799 [details] The contents of /etc/krb5.conf
Can you run 'kinit' and then attach the output of 'klist'?
Further, can you attach to the login process using 'strace -s128' and attach the output? (You can do this by entering your user name on one VT, switching VTs to one on which you are already logged in as the superuser, using 'ps' to find the process's ID, and running 'strace -s 128 -p PID -o /tmp/strace.out'.)
The strace of the login process is attached to this bug report. What's curious is that just sending the login process my username (just before being able to send the password) the following is logged into /var/log/secure: 1. tail -f /var/log/secure 2. on VT2, I enter "falfaro" as the user name and press ENTER. 3. The following is dumped onto /var/log/secure: Sep 29 16:16:03 glass login: pam_krb5[6423]: default/local realm 'FELIPE-ALFARO.COM' Sep 29 16:16:03 glass login: pam_krb5[6423]: configured realm 'FELIPE-ALFARO.COM' Sep 29 16:16:03 glass login: pam_krb5[6423]: flags: forwardable Sep 29 16:16:03 glass login: pam_krb5[6423]: flag: user_check Sep 29 16:16:03 glass login: pam_krb5[6423]: flag: no krb4_convert Sep 29 16:16:03 glass login: pam_krb5[6423]: flag: warn Sep 29 16:16:03 glass login: pam_krb5[6423]: renewable lifetime: 36000 Sep 29 16:16:03 glass login: pam_krb5[6423]: banner: Kerberos 5 Sep 29 16:16:03 glass login: pam_krb5[6423]: ccache dir: /tmp Sep 29 16:16:03 glass login: pam_krb5[6423]: keytab: /etc/krb5.keytab Sep 29 16:16:03 glass login: pam_krb5[6423]: called to authenticate 'falfaro' Sep 29 16:16:03 glass login: pam_krb5[6423]: authenticating 'falfaro' Sep 29 16:16:03 glass login: pam_krb5[6423]: authentication fails for 'falfaro': Authentication failure (Generic error (see e-text)) So, it seems pam_krb5 is trying Kerberos V authentication before I have specified my user password. Thus, it seems normal for pam_krb5 to fail.
Created attachment 94820 [details] Trace of the login process strace -s128 -o strace -p<pid_of_LOGIN_process>
Created attachment 94821 [details] Output of the klist command 1. kinit 2. klist
I see a different error (decrypt integrity check failed -- usually an incorrect password) in the strace output. Can you strace a case where the original bug is reproduced?
Hang on a second. In your system-auth file, you have: auth sufficient /lib/security/$ISA/pam_krb5.so use_first_pass auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok This signals that pam_krb5 should use the password set by a previously-run module when attempting to authenticate the user, but it is the first module listed which will prompt for a password. That won't work. Try removing "use_first_pass" from the pam_krb5 configuration line and appending it to the pam_unix configuration line, or swapping them so that "use_first_pass" is given to the second listed module. Please also read the PAM system administrator's guide in /usr/share/doc/pam*/txts/pam.txt for more information on the semantics of the "use_first_pass" option. Marking WORKSFORME because, well, it does.
Ok, Nalin, thanks for pointing me in the right direction. I have been able to solve the problem by simply swapping "use_first_pass" as you told me. Now, I've got the following in /etc/pam.d/system-auth: auth required /lib/security/$ISA/pam_env.so auth sufficient /lib/security/$ISA/pam_krb5.so auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok use_first_pass auth required /lib/security/$ISA/pam_deny.so Now, it's working flawlessly. Logging with a Kerberized user gets a TGT at a first time without needing to launch "kinit" manually. However, I have discovered that "authconfig" does not setup /etc/pam.d/ system-auth properly: it always forces pam_unix authentication before pam_krb5. That's the problem I was having at first: I could log, but my user didn't get any Kerberos V TGT. I will open a bug against authconfig for this to get solved. Thanks!