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!