Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 667758

Summary: pam_ldap, running as root, does not authenticate a user on password expiration
Product: Red Hat Enterprise Linux 5 Reporter: ross tyler <retyler>
Component: nss_ldapAssignee: Nalin Dahyabhai <nalin>
Status: CLOSED ERRATA QA Contact: Ondrej Moriš <omoris>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.5CC: dpal, jplans, mpoole, nc, omoris
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: nss_ldap-253-42.el5 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 688747 (view as bug list) Environment:
Last Closed: 2011-07-21 08:08:24 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: 688747    
Attachments:
Description Flags
authenticate user during PAM_CHANGE_EXPIRED_AUTHTOK operation none

Description ross tyler 2011-01-06 17:31:05 UTC
Description of problem:
When a user is authenticated (PAM auth), if it is found that their password has expired, they will be asked to change their password (PAM password PAM_CHANGE_EXPIRED_AUTHTOK).
If pam_cracklib is part of the PAM password stack, it will be used to ensure that the user chooses and adequately strong password per a configurable policy.
First, it will be checked against cracklib.
Next, it will be checked for further strength (using _pam_unix_approve_pass) _but_ only if pam_cracklib can obtain the old password (PAM_OLDAUTHTOK) for the user.
These further strength checks are what enforce most of the pam_cracklib configurable policy and a simple check to make sure the new password is different than the old one.

This all works well for UNIX accounts (handled by pam_unix) but not for LDAP accounts (handled by pam_ldap) because pam_ldap does not authenticate the user (set PAM_OLDAUTHTOK for pam_cracklib).

The difference between pam_unix and pam_ldap in this regard is that pam_unix will force an authentication of root (getuid() == 0) if the password is being changed as part of a PAM_CHANGE_EXPIRED_AUTHTOK operation.

Version-Release number of selected component (if applicable):
RHEL 4.5 nss_ldap-226-18
RHEL 5.5 nss_ldap-253-25.el5
and, I suppose everything between and earlier.

How reproducible:
Every time


Steps to Reproduce:
1. Start with RHEL default PAM configuration (/etc/pam.d/) 
2. Configure PAM with authconfig --enableldap
3. Expire your pam_ldap/LDAP based account
4. Login to the console tty
5. Change password by reusing the same old password
6. pam_cracklib should not allow reuse of the same old password
  
Actual results:
Password: 
You are required to change your password immediately (password aged)
You are required to change your LDAP password immediately.
New password: 
Retype new password: 
LDAP password information changed

Expected results:
Password: 
You are required to change your password immediately (password aged)
You are required to change your LDAP password immediately.
Enter login(LDAP) password: 
New password: 
Password unchanged
New password:

Additional info:
RHEL 4.5
/etc/pam.d/system-auth

#%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_unix.so likeauth nullok
auth        sufficient    /lib/security/$ISA/pam_ldap.so 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 < 10000 quiet
account     [default=bad success=ok user_unknown=ignore] /lib/security/$ISA/pam_ldap.so
account     required      /lib/security/$ISA/pam_permit.so

password    requisite     /lib/security/$ISA/pam_cracklib.so debug retry=3 type= lcredit=-2 ucredit=-2 dcredit=-2 ocredit=-2 minlen=15
password    sufficient    /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow remember=5
password    sufficient    /lib/security/$ISA/pam_ldap.so debug 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_ldap.so

----

Find simple patch for (RHEL 4.5 nss_ldap-226-18) pam_ldap.c attached.

Comment 1 ross tyler 2011-01-06 17:35:32 UTC
Created attachment 472101 [details]
authenticate user during PAM_CHANGE_EXPIRED_AUTHTOK operation

Comment 2 ross tyler 2011-01-06 17:45:08 UTC
https://access.redhat.com/support/cases/00399942

Comment 3 ross tyler 2011-01-06 17:49:12 UTC
Replacing "LDAP" with "UNIX" in the "Expected results:" (above) yields the "Actual results:" when a UNIX account expires and you try to enter a password that is the same as the old password.

Comment 5 Nalin Dahyabhai 2011-03-18 15:59:00 UTC
It's worth noting that depending on the passwd command on a client to enforce password quality or policy via pam_ldap isn't dependable -- a client user can almost as easily invoke ldappasswd or ldapmodify to bypass any quality checks that are wired into the client's PAM configuration.  This sort of requirement really calls for server-side password policy enforcement.

Comment 8 errata-xmlrpc 2011-07-21 08:08:24 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-2011-1030.html