#48972 ACI behaves erratically
Closed: Fixed None Opened 2 years ago by nhosoi.

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.

define DENY_PW_CHANGE_ACI "(targetattr = \"userPassword\") ( version 3.0; acl \"disallow_pw_change_aci\"; deny (write ) userdn = \"ldap:///self\";)"

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.

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

2 years ago

Login to comment on this ticket.

Metadata