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