Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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
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
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.