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.
Bug 1563999 - Is it possible for Directory server to reject the current password only?
Summary: Is it possible for Directory server to reject the current password only?
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.5
Hardware: Unspecified
OS: Unspecified
high
low
Target Milestone: rc
: 7.7
Assignee: mreynolds
QA Contact: RHDS QE
Marc Muehlfeld
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-05 06:58 UTC by Ming Davies
Modified: 2021-06-10 15:40 UTC (History)
7 users (show)

Fixed In Version: 389-ds-base-1.3.9.1-1.el7
Doc Type: Bug Fix
Doc Text:
.Directory Server now correctly rejects the current password if `passwordInHistory` is set to `0` Previously, administrators could not set the `passwordInHistory` attribute in Directory Server to `0`. As a consequence, Users could reset their password to the same password as they currently use. With this update, users can now set `passwordInHistory` to `0` and, as a result, to check the current password.
Clone Of:
Environment:
Last Closed: 2019-08-06 12:58:23 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 3214 0 None None None 2020-09-13 22:18:02 UTC
Red Hat Product Errata RHBA-2019:2152 0 None None None 2019-08-06 12:58:42 UTC

Description Ming Davies 2018-04-05 06:58:13 UTC 
Description of problem:
Customer would like the current password ONLY to be rejected when updating a user's password as himself/herself.

We currently have an attribute called passwordInHistory, which can only take values of 1 to 24, By specifying "passwordInHistory: 1", it not only rejects the current password but also "current password - 1"! Please see my test below:


1. Create a test user called arichardson

2. Create a user level password policy:
dn: cn=cn\3DnsPwPolicyEntry\2Cuid\3Darichardson\2Cou\3DPeople\2Cdc\3Dmytestrea
 lm\2Cdc\3Dcom,cn=nsPwPolicyContainer,ou=People,dc=mytestrealm,dc=com
objectClass: ldapsubentry
objectClass: passwordpolicy
objectClass: top
cn: cn=nsPwPolicyEntry,uid=arichardson,ou=People,dc=mytestrealm,dc=com
passwordMustChange: off
passwordExp: off
passwordMinAge: 0
passwordChange: on
passwordInHistory: 1  <<<<<<<<<<<<<<<<<<<
passwordStorageScheme: ssha512



3. Bind as the user using his current password "password"
# ldapsearch -h localhost -p 2389 -D "uid=arichardson,ou=People,dc=mytestrealm,dc=com" -w password -b "uid=arichardson,ou=People,dc=mytestrealm,dc=com"
# extended LDIF
#
# LDAPv3
# base <uid=arichardson,ou=People,dc=mytestrealm,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# arichardson, People, mytestrealm.com
dn: uid=arichardson,ou=People,dc=mytestrealm,dc=com
uid: arichardson
givenName: Alan
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
sn: Richardson
cn: Alan Richardson



4. Attempt to change the user arichardson's password using the current password:
# ldapmodify -h localhost -p 2389 -D "uid=arichardson,ou=People,dc=mytestrealm,dc=com" -w password 
dn: uid=arichardson,ou=People,dc=mytestrealm,dc=com 
changetype: modify
replace: userpassword
userpassword: password

modifying entry "uid=arichardson,ou=People,dc=mytestrealm,dc=com "
ldap_modify: Constraint violation (19)
	additional info: password in history



5. Replace the user arichardson's password with "Canget1n":
# ldapmodify -h localhost -p 2389 -D "uid=arichardson,ou=People,dc=mytestrealm,dc=com" -w password 
dn: uid=arichardson,ou=People,dc=mytestrealm,dc=com 
changetype: modify
replace: userpassword
userpassword: Canget1n

modifying entry "uid=arichardson,ou=People,dc=mytestrealm,dc=com "


6. Now attempted to change  user arichardson's password with the current passwod -1 , i.e. "password":
# ldapmodify -h localhost -p 2389 -D "uid=arichardson,ou=People,dc=mytestrealm,dc=com" -w Canget1n
dn: uid=arichardson,ou=People,dc=mytestrealm,dc=com 
changetype: modify
replace: userpassword
userpassword: password

modifying entry "uid=arichardson,ou=People,dc=mytestrealm,dc=com "
ldap_modify: Constraint violation (19)
	additional info: password in history


7. Now attempted to change  user arichardson's password with the current password "Canget1n":
# ldapmodify -h localhost -p 2389 -D "uid=arichardson,ou=People,dc=mytestrealm,dc=com" -w Canget1n
dn: uid=arichardson,ou=People,dc=mytestrealm,dc=com 
changetype: modify
replace: userpassword
userpassword: Canget1n

modifying entry "uid=arichardson,ou=People,dc=mytestrealm,dc=com "
ldap_modify: Constraint violation (19)
	additional info: password in history


As you  can see from the above that both "password" (current password - 1) and "Canget1n" (current) are rejected. The customer only wants the current password, i.e. Canget1n, in the above example to be rejected. 

If I dump out passwordHistory of the user:
dn: uid=arichardson,ou=People,dc=mytestrealm,dc=com
passwordHistory: 20180329113642Z{SSHA512}lCNNXqM9CzmtsUyXxdLomk2
 r1NJlwD10dHaYzd1nLqwuvmX7MsMaEqCtdjSyNHdoJOXMV0bdzkLZG7oKYprsnWwkbvPEVw9e

It seems that even with  "passwordInHistory: 1",the passwordhistory attribute seems to remember the  password right before the current password and the current password!


Version-Release number of selected component (if applicable):
redhat-ds-10.1.0-2.el7dsrv.x86_64
389-ds-base-1.3.7.5-18.el7.x86_64

How reproducible:
Please see above

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
This is a Request For Enhancement rather than product defect.
Comment 2 mreynolds 2019-01-14 17:38:00 UTC 
Upstream ticket:
https://pagure.io/389-ds-base/issue/50155
Comment 4 bsmejkal 2019-04-26 08:05:32 UTC 
=============================================================================================== test session starts ===============================================================================================
platform linux -- Python 3.6.3, pytest-4.4.1, py-1.8.0, pluggy-0.9.0 -- /opt/rh/rh-python36/root/usr/bin/python3
cachedir: .pytest_cache
metadata: {'Python': '3.6.3', 'Platform': 'Linux-3.10.0-1034.el7.x86_64-x86_64-with-redhat-7.7-Maipo', 'Packages': {'pytest': '4.4.1', 'py': '1.8.0', 'pluggy': '0.9.0'}, 'Plugins': {'metadata': '1.8.0', 'html': '1.20.0'}}
389-ds-base: 1.3.9.1-4.el7
nss: 3.43.0-6.el7
nspr: 4.21.0-1.el7
openldap: 2.4.44-21.el7_6
cyrus-sasl: 2.1.26-23.el7
FIPS: disabled
rootdir: /mnt/tests/rhds/tests/upstream/ds/dirsrvtests/tests/suites/password
plugins: metadata-1.8.0, html-1.20.0
collected 1 item                                                                                                                                                                                                  

pwp_history_test.py::test_basic PASSED                                                                                                                                                                      [100%]

====================================================================================== 1 passed in 14.81 seconds ==================================================================================================
Comment 8 Marco Favero 2019-08-06 08:12:26 UTC 
I'm a little confused. The last Doc Text reports "Directory Server now correctly rejects the current password if `passwordInHistory` is set to `1`". In the new code it seems you achieve this with passwordInHistory = `0`. Uhm...

Really, I think passwordInHistory = `0` is the better choice to reject the current password only, because you don't change the previous configuration behavior.
Comment 9 Marco Favero 2019-08-06 08:19:13 UTC 
https://pagure.io/389-ds-base/pull-request/50156
Comment 10 errata-xmlrpc 2019-08-06 12:58:23 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:2152
Comment 11 mreynolds 2019-08-06 16:54:13 UTC 
(In reply to Marco Favero from comment #8)
> I'm a little confused. The last Doc Text reports "Directory Server now
> correctly rejects the current password if `passwordInHistory` is set to
> `1`". In the new code it seems you achieve this with passwordInHistory =
> `0`. Uhm...
> 
> Really, I think passwordInHistory = `0` is the better choice to reject the
> current password only, because you don't change the previous configuration
> behavior.

Marco, you are absolutely correct, great catch!  It should be "0", not "1". 

Marc, so the RN should really read something like:

Previously passwordInHistory would not allow a setting of "0", so only previous passwords , not the current password, would be checked.  This allows the a user to reset their password to the same value.  Now you can set passwordInHistory to "0" which checks the current password.

Thanks,
Mark
Comment 14 Marc Muehlfeld 2019-08-07 15:01:47 UTC 
I republished the RHDS 10.4 Release Notes document.
The RHEL 7.7 RNs will also be republished later today.
Note You need to log in before you can comment on or make changes to this bug.