I failed to reproduce you test case, I mean the aci granted the add
right to a group member to ADD an entry with the filtered attribute.
Now I have a doubt to test attribute valule on an entry that does not
Would you run /usr/lib64/mozldap/ldapsearch -D "cn=directory manager"
W -b "cn=cas,cn=ca,dc=ipa,dc=local " -J
to get the effective rights under cn=cas,cn=ca,dc=ipa,dc=local
Also you may replay your test case with ACL logs
On 01/13/2017 07:21 AM, Fraser Tweedale wrote:
In ca_add.pre_callback, we have:
if not ldap.can_add(dn[1:]):
`can_add' uses the GetEffectiveRights control to see what rights the
When a user with the 'System: Add CA' permission attempts to add a
CA, the above ACIError gets raised. This is definitely a bug. I
think it is a bug in DS GetEffectiveRights code.
The ACI in play is:
aci: (targetfilter = "(objectclass=ipaca)")(version 3.0;acl
: Add CA";allow (add) groupdn = "ldap:///cn=System: Add
The user definitely has the right membership:
memberof: cn=CA Administrator,cn=roles,cn=accounts,dc=ipa,dc=local
memberof: cn=LWCA Administration,cn=privileges,cn=pbac,dc=ipa,dc=local
memberof: cn=System: Add CA,cn=permissions,cn=pbac,dc=ipa,dc=local
William suggested I check whether direct vs. indirect membership
made a difference. It does not.
A wild guess is that the algorithm that computes whether the subject
has add access under the given entry does not take the targetfilter
into account. To solve, perhaps we could ignore ACI targetfilter when
computing add access for GER.
Alternatively, is there another way for a user to determine if they
can add an entry at a particular place, without actually doing the
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code