Replying to [ticket:446 jraquino]:

Performing an ldapsearch in 389-ds-base-1.2.10.14-1.fc16.x86_64 in a container with > 5000 entries errors with result: 11 Administrative limit exceeded.

The dse.ldif is set for appropriately high limits.

What do you have set in dse.ldif? Note that err=11 is not a sizelimit or timelimit error - those errors have their own specific error codes. err=11 is usually lookthroughlimit or idlistscanlimit.

I am using the Directory Manager user to perform the search. The search is being performed locally but the limit is still getting hit

ping - any update on this?

what is the exact ldapsearch command line?
* ldapsearch -x -D "cn=Directory Manager" -H ldap://authmgr1.example.com -b cn=computers,cn=accounts,dc=example,dc=com '(fqdn=*)' -W

what is the result line from the access log showing the error?
# search result
search: 2
result: 11 Administrative limit exceeded

# numResponses: 5001
# numEntries: 5000

what is your lookthrough limit?
* nsslapd-lookthroughlimit: 1000000
* nsslapd-pagedlookthroughlimit: 0

what is your idlistscanlimit?
nsslapd-idlistscanlimit: 1000000
nsslapd-pagedidlistscanlimit: 0

user was using cn=directory manager - confirmed the password was correct
looked for a limit of 5000 for anything in cn=config - nothing
however, there is this:
{{{
dn: cn=anonymous-limits,cn=etc,dc=expertcity,dc=com
objectClass: nsContainer
objectClass: top
nsSizeLimit: 5000
nsLookThroughLimit: 5000
cn: anonymous-limits
}}}
It appears as though the search is using the anon limits - looks like there is a bug - directory manager should not use these limits

attachment
0001-Ticket-446-anonymous-limits-are-being-applied-to-dir.patch

Here are the exact steps to reproduce the issue:

[1] Add the resource limit entry:

dn: cn=anonymous limits,dc=example,dc=com
cn: anonymous limits
objectClass: top
objectClass: nscontainer
nsLookThroughLimit: 5000

[2] Then add this to cn=config:

nsslapd-anonlimitsdn: cn=anonymous limits,dc=example,dc=com

[3] Add 5001 entries

[4] do a ldapsearch for objectclass=*:

ldapsearch -D "cn=directory manager" -w password -xLLL -b "dc=example,dc=com" objectclass=* dn

Administrative limit exceeded (11)

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=864594

git merge ticket446
Updating c19bb9d..53e16ed
Fast-forward
ldap/servers/slapd/pblock.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)

git push origin master
Counting objects: 11, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 883 bytes, done.
Total 6 (delta 4), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
c19bb9d..53e16ed master -> master

[mareynol@localhost slapd]$ git push origin 389-ds-base-1.2.11
Counting objects: 11, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 936 bytes, done.
Total 6 (delta 4), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
4d82507..3e9a21a 389-ds-base-1.2.11 -> 389-ds-base-1.2.11

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/446

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.