I cannot reproduce this.

An administratively reset password does not count in the history so re-using the same password that the administrator assign is not advised but I can't reproduce the behavior you've reported.

I didn't know that an administratively reset password did not count in the history, however, what happens if the password expires on its own? I was under the impression the behaviour was exactly the same and you could just bypass the history.

The distinction is the user that is changing the password. If the user who owns the account is changing the password, like on an expiration, then password history is enforced.

It is the same behavior when the user forces a password change, like ipa passwd on the CLI. History will be enforced.

In this case it was not the admin changing the password. It was the user but as you said (i think) since the original password had been set by the admin when creating the user, this very first password never counted for the history.

Personally, I think the user should be forced to pick a different password, in particular because the user gets prompted with an error saying that the password cannot be the same and yet is allowed to pick the same password.

Nevertheless, as long as when the user's password expires on its own - without admin intervention - the history is properly enforced, then this shouldn't be a big problem.

You can use this query to see the password history for a user (the hashes anyway).

ldapsearch -x -D 'cn=directory manager' -W -b uid=tuser1,cn=users,cn=accounts,dc=example,dc=test passwordhistory

I'd suggest you run it in between these tests:

1. create a new user with a password, it should have no history
2. kinit as that user, it should have one history
3. there is a minimum password change time of 1 hour. After that do ipa passwd as the user to set a new password. The user should have a history of 2 now.