Bug 1342585
Summary: | Wrong number passwords in passwordHistory | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Simon Pichugin <spichugi> |
Component: | 389-ds-base | Assignee: | Noriko Hosoi <nhosoi> |
Status: | CLOSED NOTABUG | QA Contact: | Viktor Ashirov <vashirov> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 7.3 | CC: | mreynolds, nkinder, rmeggins |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2017-03-21 20:16:04 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Simon Pichugin
2016-06-03 15:16:24 UTC
More I investigate, less sure I am... It is confusing, but it may be acceptable, as is? For instance, if updated by a directory manager, even if the password in the history, you can keep setting the same password. But considering it is done by a directory manager, it sounds ok to me. See this passwordhistory. (Please note that the passwordInHistory value has been changed from 4 to 3.) $ ldapsearch [...] -D 'cn=directory manager' -W -b "uid=t0user1,ou=people,dc=example,dc=com" passwordhistory dn: uid=t0user1,ou=People,dc=example,dc=com passwordhistory: 20160609003748Zt0user1_5 passwordhistory: 20160609003805Zt0user1_5 passwordhistory: 20160609003812Zt0user1_5 passwordhistory: 20160609003820Zt0user1_5 Now, let the user change the password to one in the history. Then it fails as expected. # ldapmodify [...] -D "uid=t0user1,ou=people,dc=example,dc=com" -w t0user1_5 << EOF dn: uid=t0user1,ou=People,dc=example,dc=com changetype: modify replace: userpassword userpassword: t0user1_5 EOF modifying entry "uid=t0user1,ou=People,dc=example,dc=com" ldap_modify: Constraint violation (19) additional info: password in history Check the history again. It shows 3 previous passwords. $ ldapsearch [...] -D 'cn=directory manager' -W -b "uid=t0user1,ou=people,dc=example,dc=com" passwordhistory dn: uid=t0user1,ou=People,dc=example,dc=com passwordhistory: 20160609003805Zt0user1_5 passwordhistory: 20160609003812Zt0user1_5 passwordhistory: 20160609003820Zt0user1_5 The important things are ... 1) the password set by a directory manager is now placed in the history which cannot be reused by the user him/herself. (See [1]) 2) the length of the history is applied to the user. [1] Ticket 48813 - password history is not updated when an admin resets the password I'm leaning toward to close this as WONTFIX... Hi Noriko, I think I've got your point and I fully agree with it. If we talking about Directory Manager ability to set any password (even those that is already in the PasswordHistory), then it sounds absolutely fair. My main concern is another thing. We have strange behavior at numbers of passwordInHistory regarding Directory Manager. There is situation. - For regular user: 1. set passwordInHistory = 8 2. change password 10 times 3. user entry contain 8 values at PasswordHistory attribute 4. set passwordInHistory = 5 5. change password 6. user entry contain 5 values at PasswordHistory attribute - For Directory Manager: 1. set passwordInHistory = 8 2. change password 10 times 3. user entry contain 8 values at PasswordHistory attribute 4. set passwordInHistory = 5 5. change password 6. user entry contain 8 values at PasswordHistory attribute But: 1. set passwordInHistory = 8 2. change password 10 times 3. user entry contain 8 values at PasswordHistory attribute 4. set passwordInHistory = 15 5. change password more times 6. user entry contain 15 values at PasswordHistory attribute In my opinion, passwordInHistory should be applied for everyone equally. For now, Directory Manager uses the largest number of passwordInHistory values (previous or current). Thank you for your input, Simon. We discussed in the weekly meeting and decided to push to 7.4. Let's continue the discussion! ;) Thank you, Noriko. :) To sum up my position. In my view, current situation wouldn't be so obvious for our customers. For example, a few guys administrating a server. First guy has come and set the passwordInHistory to 8. Second has come and set it to 5. So now we don't have any information that says that it is still equals 8 for Directory Manager. And if some third admin would come and change password for some user one more time, he will see 8 passwordHistory at the entry, when passwordInHistory == 5 at config. It, for sure, will confuse him and result an unnecessary mess. As a way to resolve this, we can ether: - document this situation like a feature; - or make passwordInHistory to behave equally for everyone. Upstream ticket: https://fedorahosted.org/389/ticket/49034 I've checked the steps ones again and the bug is still reproducible. Build tested: 389-ds-base-1.3.6.1-20161104gitc984499.fc24.x86_64 I've opened a doc bug for this already: https://bugzilla.redhat.com/show_bug.cgi?id=1427533 The server is working as expected, and does not require a change. Can this be closed? (In reply to mreynolds from comment #8) > I've opened a doc bug for this already: > > https://bugzilla.redhat.com/show_bug.cgi?id=1427533 > > The server is working as expected, and does not require a change. Can this > be closed? +1 Note: the upstream ticket 49034 is also already closed with Invalid. Thanks, Mark! |