Bug 437179 - pam_krb5.so doesn't seem to set the password correctly for other PAM modules
pam_krb5.so doesn't seem to set the password correctly for other PAM modules
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: pam_krb5 (Show other bugs)
All Linux
low Severity medium
: rc
: ---
Assigned To: Nalin Dahyabhai
Brian Brock
Depends On:
Blocks: 391511
  Show dependency treegraph
Reported: 2008-03-12 15:01 EDT by John Caruso
Modified: 2010-10-22 19:12 EDT (History)
4 users (show)

See Also:
Fixed In Version: 2.1.17-7.el4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-05-18 16:20:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description John Caruso 2008-03-12 15:01:44 EDT
Description of problem:
On RHEL 4.6, the default auth section for /etc/pam.d/system-auth looks like this:
auth        required      /lib/security/$ISA/pam_env.so
auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullok
auth        required      /lib/security/$ISA/pam_deny.so
We wanted to put pam_krb5.so before pam_unix.so so that if a user's Kerberos
password is the same as their Unix password, they'll still get their Kerberos
credentials.  So we inserted pam_krb5.so before pam_unix.so and added
"use_first_pass" (or "try_first_pass") on the pam_unix.so line, so that it would
get the stored password from the preceding module:
auth        required      /lib/security/$ISA/pam_env.so
auth        sufficient    /lib/security/$ISA/pam_krb5.so
auth        sufficient    /lib/security/$ISA/pam_unix.so use_first_pass likeauth
auth        required      /lib/security/$ISA/pam_deny.so
This works, but it has one flaw: when SSH'ing to this server, on the first
prompt the user can enter either their Kerberos password or their Unix password
to authenticate, just as expected.  However, if they enter an incorrect password
the first time, on subsequent attempts they can ONLY authenticate using their
Kerberos password...even if they enter the correct Unix password it will be
I believe the problem here is that pam_krb5.so is storing the password the first
time it's called but is NOT changing it on subsequent calls--and therefore, the
pam_unix.so module is seeing the initial incorrect password every time through.
I've tested this same configuration change on a server running RHEL5, and it
works perfectly there.  Also, FYI, this is the only change we've made to the PAM
configuration, and the SSH configuration is unchanged from a stock RHEL4
install.  So if my guess is right, it would appear that this is a bug in the
pam_krb5.so that's distributed with RHEL 4.6 (namely pam_krb5-2.1.17-1).

Version-Release number of selected component (if applicable):

How reproducible:
(see above)

Steps to Reproduce:
1. Configure /etc/pam.d/system-auth as per the above description
2. Sign in via SSH
3. Specify an incorrect password the first time you're prompted for it
4. Specify the correct password the second time you're prompted for it; it will
be rejected by PAM
Actual results:
A correct password is rejected after an incorrect password has been entered

Expected results:
A correct password should allow the user to sign in regardless of any preceding
errors (as it does on RHEL5).

Additional info:
See Redhat service request 1806540 for further information on this issue.
Comment 1 Sadique Puthen 2008-03-13 06:13:42 EDT
Test case can be simplified as below. There is no need to have users defined in
kerberos to reproduce this issue. So this can be reproduced using the belows
simple steps.

- Configure /etc/pam.d/system-auth as below

# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
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
auth        required      /lib/security/$ISA/pam_deny.so

account     required      /lib/security/$ISA/pam_unix.so broken_shadow
account     sufficient    /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet
#account     [default=bad success=ok user_unknown=ignore]
account     required      /lib/security/$ISA/pam_permit.so

password    requisite     /lib/security/$ISA/pam_cracklib.so retry=3
password    sufficient    /lib/security/$ISA/pam_unix.so nullok use_authtok md5
password    sufficient    /lib/security/$ISA/pam_krb5.so use_authtok
password    required      /lib/security/$ISA/pam_deny.so

session     required      /lib/security/$ISA/pam_limits.so
session     required      /lib/security/$ISA/pam_unix.so
session     optional      /lib/security/$ISA/pam_krb5.so

- Add a new user and set him a password. (useradd test; passwd test).

- ssh to the machine as test. On the first prompt enter a wrong "password". On
the second and third prompt enter the "right" password. The second and third
prompt wouldn't authenticate the user even after entering the right password.

- If I specify pam_ldap.so or any other pam modules before pam_unix.so this does
not happen. So this is a bug with pam_krb5.so.
Comment 7 RHEL Product and Program Management 2008-09-05 13:06:01 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
Comment 12 errata-xmlrpc 2009-05-18 16:20:41 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.