Bug 979054 - shadowLastChange updates even when PAM reports password change failed
shadowLastChange updates even when PAM reports password change failed
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd (Show other bugs)
7.0
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Jakub Hrozek
Kaushik Banerjee
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-27 09:45 EDT by Dmitri Pal
Modified: 2014-07-09 06:03 EDT (History)
4 users (show)

See Also:
Fixed In Version: sssd-1.10.1-1.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-06-13 08:24:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dmitri Pal 2013-06-27 09:45:50 EDT
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/sssd/ticket/1999

Description:

ldap_auth.c code which was added to SSSD for updating the shadowLastChange when "ldap_chpass_update_last_change" option is enabled updates shadowLastChange
even when the PAM password change status reports failure.

We should only update shadowLastChange on PAM password change success or we open up a work around for users to avoid changing their passwords periodically as required by policy. The user simply attempts to change password, fails by trying to set new password which invalid (denied due to password history check) yet shadowLastChange is updated, avoiding their need to actually change the password they are using.

How reproducible:

1. Enforce ppolicy on OpenLDAP server.
2. Enable "ldap_chpass_update_last_change" in sssd.conf and restart.
3. Attempt to change password, using new password which fails to meet ppolicy requirements (e.g. previously used password which is present in password history)


Actual results:

password change fails but shadowLastChange for user entry is updated anyway

User POV:
[jcvm20:~]$ passwd
Changing password for user jcollins.
Current Password:
New password:
Retype new password:
Password change failed. Server message: Password is in history of old passwords
passwd: all authentication tokens updated successfully
Comment 1 Jakub Hrozek 2013-07-11 16:25:05 EDT
Fixed upstream in the 1-10 branch.
Comment 2 Jakub Hrozek 2013-10-04 09:23:09 EDT
Temporarily moving bugs to MODIFIED to work around errata tool bug
Comment 4 Amith 2014-03-12 07:14:59 EDT
Verified the bug on SSSD Version: sssd-1.11.2-40.el7.x86_64

Steps followed during verification:

1. Setup ppolicy in Openldap server with an attribute say, pwdInHistory: 3

2. Try changing a ldap user's password by providing previously used passwords from history. Password change should fail with following message:

[tuuser2@rhel-7 ~]$ passwd
Changing password for user tuuser2.
Current Password: 
New password: 
Retype new password: 
Password change failed. Server message: Please make sure the password meets the complexity constraints.
passwd: Authentication token is no longer valid; new one required

3. Verify the user attribute shadowLastChange, before and after attempting the passowrd change. shadowLastChange value should stay unchanged.

See an example of user attributes below:

[root@rhel-7 ~]# ldapsearch -xv -h ibm-dx360m4-02.rhts.eng.bos.redhat.com -D "cn=Manager,dc=example,dc=com" -b "uid=tuuser2,dc=example,dc=com" -w Secret123
ldap_initialize( ldap://ibm-dx360m4-02.rhts.eng.bos.redhat.com )
filter: (objectclass=*)
requesting: All userApplication attributes
# extended LDIF
#
# LDAPv3
# base <uid=tuuser2,dc=example,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# tuuser2, example.com
dn: uid=tuuser2,dc=example,dc=com
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
objectClass: pwdPolicy
cn: tuuser2
uidNumber: 32111
gidNumber: 32111
homeDirectory: /home/tuuser2
loginShell: /bin/bash
pwdAttribute: userPassword
uid: tuuser2
userPassword:: e1NTSEF9bUpOM0lUbis5cFhkaDNJb25DdUl4V2tkbzQ0a0RxRks=
shadowLastChange: 16141
Comment 5 Ludek Smid 2014-06-13 08:24:09 EDT
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

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