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