Bug 56201 - Password changing fails with message 'Strong authentication required.'
Summary: Password changing fails with message 'Strong authentication required.'
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: pam_ldap   
(Show other bugs)
Version: 7.2
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2001-11-13 20:55 UTC by John Dalbec
Modified: 2008-05-01 15:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-11-15 18:41:05 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
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 18:01 UTC, John Dalbec
no flags Details | Diff
Revised - shadowLastChange wasn't updating (366 bytes, patch)
2001-11-15 18:32 UTC, John Dalbec
no flags Details | Diff

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 ...
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:

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.

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.
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?

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