Hello, TL;DR version: Upgrade to 389-ds-base-1.3.5.6-1.fc24.
I was facing weird filter/ACI evaluation with 389 DS 389-ds-base-1.3.5.4-1.fc24.x86_64. Here is full story (written before I realized that DS is old one ...): Test ==== First, let's try LDAP search with OR filter consisting of 5 components: [16/Jun/2016:06:05:18.145159021 +0200] conn=119 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat....@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel" [16/Jun/2016:06:05:18.145920002 +0200] conn=119 op=3 SRCH base="cn=dns,dc=toplevel" scope=2 filter="(|(objectClass=idnsConfigObject)(&(objectClass=idnsServerConfigObject)(idnsServerId=vm-046.abc.idm.lab.eng.brq.redhat.com))(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))" attrs="objectClass" [16/Jun/2016:06:05:18.149821586 +0200] conn=119 op=3 RESULT err=0 tag=101 nentries=1 etime=0 [16/Jun/2016:06:05:18.150433307 +0200] conn=119 op=4 UNBIND [16/Jun/2016:06:05:18.150459102 +0200] conn=119 op=4 fd=108 closed - U1 It returns 1 entry - the idnsServerConfigObject object. Now let us re-try shortened filter containing only 4 OR components. I would expect to get less entries but that is not the case: [16/Jun/2016:06:05:21.007494823 +0200] conn=120 fd=108 slot=108 SSL connection from 2620:52:0:224e:21a:4aff:fe23:12d2 to 2620:52:0:224e:21a:4aff:fe23:12d2 [16/Jun/2016:06:05:21.022115576 +0200] conn=120 TLS1.2 128-bit AES [16/Jun/2016:06:05:21.029902095 +0200] conn=120 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI [16/Jun/2016:06:05:21.042047525 +0200] conn=120 op=0 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [16/Jun/2016:06:05:21.043007851 +0200] conn=120 op=1 BIND dn="" method=sasl version=3 mech=GSSAPI [16/Jun/2016:06:05:21.044811757 +0200] conn=120 op=1 RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress [16/Jun/2016:06:05:21.045183711 +0200] conn=120 op=2 BIND dn="" method=sasl version=3 mech=GSSAPI [16/Jun/2016:06:05:21.046395695 +0200] conn=120 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat....@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel" [16/Jun/2016:06:05:21.046947437 +0200] conn=120 op=3 SRCH base="cn=dns,dc=toplevel" scope=2 filter="(|(objectClass=idnsConfigObject)(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))" attrs="objectClass" [16/Jun/2016:06:05:21.052008250 +0200] conn=120 op=3 RESULT err=0 tag=101 nentries=11 etime=0 Huh? Now we got 11 entries. When I do the first search as Directory Manager it returns all 12 matching entries (which is expected number, at least according to my match-by-eye algorithm :-)). Schema ====== idnsServerId attribute definition contains an equality specification: ( 2.16.840.1.113730.3.8.5.31 NAME 'idnsServerId' DESC 'DNS server identifier' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'IPA v4.4' ) Indices ======= The attribute itself is not indexed but that should not hurt I guess. Mere addition of equality index to the attribute did not help. Reindexing using https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/applying-indexes.html#index-cn-tasks did not help either. ACI === Relevant ACIs are: (targetattr = "createtimestamp || entryusn || idnsforwarders || idnsforwardpolicy || idnsserverid || idnssoamname || idnssubstitutionvariable || modifytimestamp || objectclass")(targetfilter = "(objectclass=idnsServerConfigObject)")(version 3.0;acl "permission:System: Read DNS Servers Configuration";allow (compare,read,search) groupdn = "ldap:///cn=System: Read DNS Servers Configuration,cn=permissions,cn=pbac,dc=toplevel";) (targetattr = "idnsforwarders || idnsforwardpolicy || idnssoamname || idnssubstitutionvariable")(targetfilter = "(objectclass=idnsServerConfigObject)")(version 3.0;acl "permission:System: Modify DNS Servers Configuration";allow (write) groupdn = "ldap:///cn=System: Modify DNS Servers Configuration,cn=permissions,cn=pbac,dc=toplevel";) BIND DN krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat....@dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel is member of cn=DNS Servers,cn=privileges,cn=pbac,dc=toplevel which is member of cn=System: Read DNS Servers Configuration,cn=permissions,cn=pbac,dc=toplevel so we should be all good. Now was totally confused and was looking for a bug in bind-dyndb-ldap until I realized that DS is returning weird results... Upgrade to 389-ds-base-1.3.5.6-1.fc24.x86_64 fixed that. This would be a blocker for FreeIPA 4.4 because the old version totally breaks bind-dyndb-ldap. -- Petr^2 Spacek -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code