Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1342585
Description of problem: If we decrease passwordInHistory attribute (for instance, from 4 to 3) while user entry already has some passwordHistory values (four), we will still have four values even after changing password one more time. It applied for Directory Manager only. So he can break passwordInHistory rule, he even can change password to value that is not in passwordHistory. Build tested: 389-ds-base-1.3.5.4-1.el7.x86_64 How reproducible: Always Steps to Reproduce: 1) configure password history feature with, for instance: passwordInHistory: 4 passwordHistory: on 2) add a new user ldapmodify -p 389 -h localhost -D "cn=directory manager" -w Secret123 dn: uid=user50,ou=people,o=redhat changetype: add objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson uid: user50 cn: user50 sn: user50 userpassword: user50 3) change password 4 times. 4) verify passwordHistory has the four values: ldapsearch -xLLL -p 389 -h localhost -D "cn=directory manager" -w Secret123 -b "uid=user50,ou=people,o=redhat" passwordHistory dn: uid=user50,ou=people,o=redhat passwordHistory: 20150724075220Zuser50 passwordHistory: 20150724075328Zuser50_1 passwordHistory: 20150724075341Zuser50_2 passwordHistory: 20150724075352Zuser50_3 5) decrease passwordInHistory to 3. ldapmodify -p 389 -h localhost -D "cn=directory manager" -w Secret123 dn: cn=config changetype: modify replace: passwordInHistory passwordInHistory: 3 6) change password one more time to value that is not in passwordHistory: ldapmodify -p 389 -h localhost -D "cn=directory manager" -w Secret123 dn: uid=user50,ou=people,o=redhat changetype: modify replace: userPassword userPassword: anotherpass 7) verify passwordHistory has the three values Actual results: ldapsearch -xLLL -p 389 -h localhost -D "cn=directory manager" -w Secret123 -b "uid=user50,ou=people,o=redhat" passwordHistory dn: uid=user50,ou=people,o=redhat passwordHistory: 20150724075352Zuser50_4 passwordHistory: 20150724075220Zuser50 passwordHistory: 20150724075328Zuser50_1 passwordHistory: 20150724075341Zuser50_2 Expected results: ldapsearch -xLLL -p 389 -h localhost -D "cn=directory manager" -w Secret123 -b "uid=user50,ou=people,o=redhat" passwordHistory dn: uid=user50,ou=people,o=redhat passwordHistory: 20150724075352Zuser50_4 passwordHistory: 20150724075220Zuser50 passwordHistory: 20150724075328Zuser50_1 Additional info: Also, on the step 6, Directory Manager can change password that is in passwordHistory. But changing passwords while binding as regular user works as expected.
Metadata Update from @nhosoi: - Issue set to the milestone: 1.3.6.0
Metadata Update from @mreynolds: - Issue assigned to mreynolds
This is the expected behaviour. Directory manager, or a password admin, can violate all password policies.
Metadata Update from @mreynolds: - Issue close_status updated to: invalid - Issue status updated to: Closed (was: Open)
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/2093
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: invalid)
Login to comment on this ticket.