On 08/23/2011 04:26 PM, Anthony Messina wrote: > On 08/23/2011 09:26 AM, Rich Megginson wrote: >> Can you provide the exact aci you used below? >>> dc=messinet,dc=com (anonymous perms removed, all other defaults intact) >>> | >>> +-ou=People (allowed dns=localhost,messinet.com,*.messinet.com) >>> | >>> +-ou=Groups (allowed dns=localhost,messinet.com,*.messinet.com) >>> | >>> +-ou=Special Users (allowed dns=localhost,messinet.com,*.messinet.com) >>> | >>> +-ou=Computers (allowed dns=localhost,messinet.com,*.messinet.com) >>> | >>> +-ou=eGW (allowed dns=localhost,messinet.com,*.messinet.com) >>> >>> -A > Attached, find the original ACIs I used prior to > 389-ds-base-1.2.9.6-1.fc15.i686 > > Since the upgrade, I have needed to leave the following default in place: > > aci: (targetattr != "userPKCS12 || userPassword")(version 3.0;acl > "Enable anon > ymous access"; allow (read,compare,search)(userdn = "ldap:///anyone";);) > > But as you can see, the makes it incredibly difficult to restrict acces > based on tree structure as everyone already has read access. -A Thanks. It seems to have something to do with the number and type of acis being used. I don't have all of the schema for these, but this revealed another bug - https://bugzilla.redhat.com/show_bug.cgi?id=733103 - but I don't think you are running into this problem - do you ever get syntax errors attempting to add acis? Do you ever have the problem while adding acis? Even after fixing this bug, I'm still unable to reproduce the problem. I've tried something like this: $ ii=0; while [ $ii -lt 10000 ] ; do ldapsearch -x -LLL -h localhost -p 1389 -b "ou=people,dc=example,dc=com" > /dev/null & ii=`expr $ii + 1` ; done Perhaps it has something to do with the search base, scope, filter, and attrs your application uses? At -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
