Bug 1813698

Steps to Reproduce
==================

1. Create an IPA user and set its password history = 3.

# ipa user-add ipauser
# ipa passwd ipauser

# ipa group-add newpolicy
# ipa pwpolicy-mod newpolicy --history=3 --priority=2 --maxlife=0 --minlife=0
# ipa group-add-member newpolicy --users=ipauser

========

2. Update user password as follows:

passwordA, passwordB, passwordC

# ldapmodify -D "cn=Directory Manager" -W -f moda.ldif    (PasswordA)
# ldapmodify -D "cn=Directory Manager" -W -f modb.ldif    (attempt 1 after passwordA)
# ldapmodify -D "cn=Directory Manager" -W -f modc.ldif    (attempt 2 after passwordA)

==> All 3 passwords are stored in history as verified from the updated passwordHistory attribute.

# ldapsearch -x -LLL -h localhost  -D 'cn=directory manager' -w RedHat1! -b "uid=ipauser,cn=users,cn=accounts,<base_dn>" passwordHistory

--------

==> Here, moda.ldif, modb.ldif and modc.ldif have the following contents:

dn: uid=ipauser,cn=users,cn=accounts,<base_dn>
changetype: modify
replace: userpassword
userpassword: PasswordA

dn: uid=ipauser,cn=users,cn=accounts,<base_dn>
changetype: modify
replace: userpassword
userpassword: PasswordB

dn: uid=ipauser,cn=users,cn=accounts,<base_dn>
changetype: modify
replace: userpassword
userpassword: PasswordC

========

3. Then change password to passwordB or passwordC, i.e. any used password except PasswordA.

# ldapmodify -D "cn=Directory Manager" -W -f modb.ldif    (attempt 3 after passwordA)

or,

# ldapmodify -D "cn=Directory Manager" -W -f modb.ldif

==> This fails as expected with the following error:

modifying entry "uid=ipauser,cn=users,cn=accounts,<base_dn>"
ldap_modify: Constraint violation (19)
	additional info: Password reuse not permitted


==> However, passwordHistory gets updated in spite of password rejection, as verified by the following:

# ldapsearch -x -LLL -h localhost  -D 'cn=directory manager' -w RedHat1! -b "uid=ipauser,cn=users,cn=accounts,<base_dn>" passwordHistory

========

4. Change password to passwordA, i.e. this comes after 3 password change attempts, whether successful or failed due to repeated passwords.

# ldapmodify -D "cn=Directory Manager" -W -f moda.ldif    (attempt has exceeded history=3)

==> This succeeds even though passwordA is among the last 3 used passwords. This is because passwordHistory entry for PasswordA had been overwritten in step 3, though the password change didn't happen.

==> Ideally this step should also throw the "Constraint violation (19): Password reuse not permitted" LDAP error. Is this a correct expectation ?

https://pagure.io/389-ds-base/issue/51027

Hi,
after more investigation, I found that the issue happens in IPA Password Policy code. 
passwordHistory in RHDS is okay and doesn't have the bug (I'll add a test to our codebase that I wrote while investigating).


I've tried to look into IPA's code and got only to this point:

- passwordHistory is set in two places:
https://github.com/freeipa/freeipa/blob/dbf5df4a66b68f62a9e063c43a30b46e539c603b/daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c#L895
https://github.com/freeipa/freeipa/blob/dbf5df4a66b68f62a9e063c43a30b46e539c603b/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c#L1132

- passwordHistory is checked here:
https://github.com/freeipa/freeipa/blob/6907a0cef7f22293c16df17aa486f7ec2d8a0899/util/ipa_pwd.c#L528
https://github.com/freeipa/freeipa/blob/dbf5df4a66b68f62a9e063c43a30b46e539c603b/daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c#L646

I hope that helps! Changing the component to IPA...

This is also reproducible as a user and that should really be the target case. It is a separate but related bug that password policy is applied at all to the DM.

The issue seems to be in prepost.c in ipapwd_pre_mod. The mods are calculated and policy checked but on exit if there are mods they are stored using:

slapi_pblock_set(pb, SLAPI_MODIFY_MODS, mods);

Which then carries onto the rest of the request and the password is updated. I'm not sure if the the right move here is to skip saving the mods if rc != 0 or if needs to be caught elsewhere.

Thank you taking your time and submitting this request for Red Hat Enterprise Linux 7. Unfortunately, this bug cannot be kept even as a stretch goal and was postponed to RHEL8.