Bug 56201 - Password changing fails with message 'Strong authentication required.'
Password changing fails with message 'Strong authentication required.'
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: pam_ldap (Show other bugs)
7.2
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-11-13 15:55 EST by John Dalbec
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-11-15 13:41:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
This patch allows users to change passwords again. (382 bytes, patch)
2001-11-15 13:01 EST, John Dalbec
no flags Details | Diff
Revised - shadowLastChange wasn't updating (366 bytes, patch)
2001-11-15 13:32 EST, John Dalbec
no flags Details | Diff

  None (edit)
Description John Dalbec 2001-11-13 15:55:31 EST
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 07:29:59 EST
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 09:23:08 EST
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 13:01:29 EST
Created attachment 37603 [details]
This patch allows users to change passwords again.
Comment 4 John Dalbec 2001-11-15 13:32:21 EST
Created attachment 37605 [details]
Revised - shadowLastChange wasn't updating
Comment 5 John Dalbec 2001-11-15 13:40:59 EST
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?

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