Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 56201

Summary: Password changing fails with message 'Strong authentication required.'
Product: [Retired] Red Hat Linux Reporter: John Dalbec <jpdalbec>
Component: pam_ldapAssignee: Nalin Dahyabhai <nalin>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 7.2   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-11-15 18:41:05 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:
Attachments:
Description Flags
This patch allows users to change passwords again.
none
Revised - shadowLastChange wasn't updating none

Description John Dalbec 2001-11-13 20:55:31 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (Windows NT 5.0; U)

Description of problem:
Changing an expired password fails:
[jpdalbec@mail01 nss_ldap-172]$ su ...
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 UNIX password: 
Retype new UNIX password: 
LDAP password information update failed: Strong authentication required
su: incorrect password
[jpdalbec@mail01 nss_ldap-172]$ 


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


How reproducible:
Always

Steps to Reproduce:
1.Install RH 7.1, upgrade bash, filesystem, setup, nss_ldap, db3, openssl, openldap, cyrus-sasl, readline, reiserfsprogs to 7.2.
2.Try to change password of LDAP account.
3.
	

Actual Results:  Password change fails.

Expected Results:  All authentication tokens updated successfully.

Additional info:
Comment 1 John Dalbec 2001-11-14 12:29:59 UTC 
It looks like pam_ldap is trying to perform the password change extended
operation while bound anonymously.  At line 2301 of pam_ldap.c do you really
want to be checking the EUID?  At line 1059 (and 2755) you only bind as the
rootdn if the real UID is 0.
/etc/ldap.conf:
host 150.134.10.203
base dc=ysu,dc=edu
rootbinddn cn=Manager,dc=ysu,dc=edu
pam_password exop
ssl start_tls
ssl on
Yes, I have the correct password in /etc/ldap.secret.
Comment 2 John Dalbec 2001-11-15 14:23:08 UTC 
Password changing as root works.  I will try changing geteuid() to getuid() and see whether that works.  I don't understand the comment in that 
section of the code.  What configurations will allow bypassing password controls?  Do you recommend not allowing users to change passwords 
without binding as a special dn (not themselves)?  Should I check that UID!=0 and EUID==0?
Comment 3 John Dalbec 2001-11-15 18:01:29 UTC 
Created attachment 37603 [details]
This patch allows users to change passwords again.
Comment 4 John Dalbec 2001-11-15 18:32:21 UTC 
Created attachment 37605 [details]
Revised - shadowLastChange wasn't updating
Comment 5 John Dalbec 2001-11-15 18:40:59 UTC 
Changing geteuid to getuid allowed password changing (bound as user), but the
shadowLastChange field wasn't being updated because I didn't put that in my
ACL.  I knew this used to work, so instead I tried changing getuid to geteuid in
the section that reads the rootbindpw.  This seems to work, but am I creating a
security hole?