Description of problem: Customer is seeing "interesting" behavior with one particular ACIs in a standalone RHDS instance (with no replication). They have the following ACI defined globally: aci: (targetattr = "userPassword") ( version 3.0; acl "disallow_pw_change_aci"; deny (write ) userdn = "ldap:///self";) Customer said that if they delete the above mentioned ACI either via the admin console or via ldapmodify, the ACI reappears after restarting the RHDS instance! This is what I see from the audit log: time: 20160810083530 dn: o=abc changetype: modify delete: aci aci: (targetattr = "userPassword") ( version 3.0; acl "disallow_pw_change_aci" ; deny (write ) userdn = "ldap:///self";) - time: 20160810084531 dn: o=abc changetype: modify add: aci aci: (targetattr = "userPassword") ( version 3.0; acl "disallow_pw_change_aci" ; deny (write ) userdn = "ldap:///self";) - replace: modifiersname modifiersname: cn=server,cn=plugins,cn=config <<<<<<<<<<<<<<<<<<<<<< - replace: modifytimestamp modifytimestamp: 20160810074531Z 389-ds-base-devel-1.3.4.0-26.el7_2.x86_64 389-ds-base-1.3.4.0-26.el7_2.x86_64 389-ds-base-libs-1.3.4.0-26.el7_2.x86_64 How reproducible: I managed to reproduce the customer's issue, and I observed two rather interesting behaviors! Steps to Reproduce: Test A: 1. I started the instance with start-slapd 2. Created the following aci: $ ldapmodify -h tigger.redhat.com -p 1389 -D "cn=directory manager" -w passworddn: o=abc changetype: modify add: aci aci: (targetattr = "userPassword") ( version 3.0; acl "disallow_pw_change_aci"; deny (write ) userdn = "ldap:///self";) modifying entry "o=abc" 3. ldapsearch'ed to check that the ACI was there: # abc dn: o=abc ... aci: (targetattr = "userPassword") ( version 3.0; acl "disallow_pw_change_aci" ; deny (write ) userdn = "ldap:///self";) 4. Stopped the DS instance with stop-slapd and restarted the DS instance with start-slapd, and the ACI I added in step2 disappeared! If I take a look at the audit log, I see: time: 20160810151736 dn: o=abc changetype: modify delete: aci aci: (targetattr = "userPassword") ( version 3.0; acl "disallow_pw_change_aci" ; deny (write ) userdn = "ldap:///self";) - Test B: 1. I started the instance with start-slapd 2. Instead of adding the "problem" ACI manually via ldapmodify, I followed the customer's steps: 2a. Enable "Global fine-grained password policy" via the Admin console (Configuration tab-> select Data from the left hand-> then password window) 2b. In global policy, "User may change password" is unchecked. 2c. Enable "fine-grained subtree policy" (Admin console-> Directory tab-> Right click the basedn -> Manage password policy -> For subtree) 2d. "User may change password" is checked 3. ldapsearch'ed to check that the ACI was there. 4. Deleted the "problem ACI" via ldapmodify: $ ldapmodify -p 1389 -h localhost -D "cn=directory manager" -w password dn: o=abc changetype: modify delete: aci aci: (targetattr = "userPassword") ( version 3.0; acl "disallow_pw_change_aci"; deny (write ) userdn = "ldap:///self";) modifying entry "o=abc" 5. Repeated ldapsearch to check the ACI has gone 6. Stopped the DS instance and restarted it 7. The "problem" ACI reappeared!!! 8. However, instead of deleting the "problem" ACI via ldapmodify, I used the following workaround: $ ldapmodify -p 1389 -h localhost -D "cn=directory manager" -w password dn: cn=config changetype: modify replace: passwordChange passwordChange: on modifying entry "cn=config" step8 seems to got rid of the "problem" ACI permanently.
The function pw_init called from main calls pw_mod_allowchange_aci with the argument (!slapdFrontendConfig->pw_policy.pw_change && !slapdFrontendConfig->pw_policy.pw_must_change). Which means if the global password policy allows password change, 1 is passed; otherwise, 0. pw_mod_allowchange_aci adds this ACI if 1 is given; it deletes it in case 0.
Probably, it was useful only when a global password policy existed, but it would rather do harm with the fine grained password policy available which could set different policy from the global one per subtree and entry.
Can we remove pw_mod_allowchange_aci from our code?
It is being called at the startup time via pw_init and when either pw_change or pw_must_change is modified.
attachment 0001-Ticket-48972-remove-old-pwp-code-that-adds-removes-A.patch
Amazing... There were more codes which modify the aci's...
Thanks for the complete patch, Mark!
cdf4fb4..32881be master -> master commit 32881be Author: Mark Reynolds mreynolds@redhat.com Date: Fri Aug 26 18:51:42 2016 -0400
792aa66..f823ea0 389-ds-base-1.3.4 -> 389-ds-base-1.3.4 commit f823ea0
f4df06b..4108fbd 389-ds-base-1.3.3 -> 389-ds-base-1.3.3 commit 4108fbd
Metadata Update from @nhosoi: - Issue assigned to mreynolds - Issue set to the milestone: 1.3.5.13
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/2031
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: Fixed)
Login to comment on this ticket.