Bug 437179

Summary: pam_krb5.so doesn't seem to set the password correctly for other PAM modules
Product: Red Hat Enterprise Linux 4 Reporter: John Caruso <jcaruso>
Component: pam_krb5Assignee: Nalin Dahyabhai <nalin>
Status: CLOSED ERRATA QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: low    
Version: 4.6CC: k.georgiou, mkoci, sputhenp, tao
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 2.1.17-7.el4 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-05-18 20:20:41 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 391511    

Description John Caruso 2008-03-12 19:01:44 UTC
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
nullok
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
rejected.
 
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):
pam_krb5-2.1.17-1

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 10:13:42 UTC
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

#%PAM-1.0
# 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
use_first_pass
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]
/lib/security/$ISA/pam_krb5.so
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
shadow
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 Program Management 2008-09-05 17:06:01 UTC
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
release.

Comment 12 errata-xmlrpc 2009-05-18 20:20:41 UTC
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.

http://rhn.redhat.com/errata/RHBA-2009-0987.html