Hi, Evgeniy. Seems like your backend limits number of entries returned at once to 100. Try to set "Search size limit" CR's property to 100 or less, that controls LDAP request's pagination. Best regards, Alex.

yes, you may want to use the root user which bypasses search limit controls. Or create a user with a larger search limit...

I've tried with the search limits behind 100 and the result is the same. And from the security perspective we can't change the limits. Also, from http://stackoverflow.com/questions/24637056/java-ldapsearchexception-size-limit-exceeded-setmaxresults there is some information that com.unboundid.ldap.sdk.LDAPConnection does not support setSearchConstraints.

And we have more than 100 000 users, so we can't increase the search limits over that anyway...

Hi, Evgeniy. Still not sure what your problem is. Here is a capture of LDAP search request issued by my Gluu instance to AD backend, while "Search size limit" is set to 100 entries (please see in attachments). As you can see, CR includes controlType of "1.2.840.113556.1.4.319" (what is paged result control) which allows it to request all entries, in blocks of size 100 entiers, in series of subsequent requests, adding so called "cookie" value to get the next portion. This feature should resolve limitation on the response size imposed by your backend. Could you also provide output of this command (outside of container): `# rpm -qi gluu-server-2.4.3` ? Btw, is there any reason why you must use version 2.4.3? The current one is 2.4.4 and it includes a lot of important bug fixes and feature enhancements.

Sorry, here is the picture.

There was no problem with AD, but there is a problem with OpenLDAP. I have installed **GLUU 2.4.4** and the problem still exists: ``` 2016-09-27 07:37:54,617 INFO [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-3-thread-3) Attempting to load entries from source server 2016-09-27 07:37:56,717 ERROR [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (pool-3-thread-3) Exception happened while executing cache refresh synch ronization org.gluu.site.ldap.persistence.exception.EntryPersistenceException: Failed to find entries with baseDN: <SKIPPED>, filter: (&(uid=ab*)(objectClass=<SKIPPED>)) at org.gluu.site.ldap.persistence.LdapEntryManager.findEntries(LdapEntryManager.java:320) at org.gluu.site.ldap.persistence.LdapEntryManager.findEntries(LdapEntryManager.java:289) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: LDAPSearchException(resultCode=4 (size limit exceeded), numEntries=1000, numReferences=0, errorMessage='size limit exceeded') at com.unboundid.ldap.sdk.LDAPConnection.search(LDAPConnection.java:3648) at com.unboundid.ldap.sdk.AbstractConnectionPool.search(AbstractConnectionPool.java:2020) ``` We have also increased the limit to **1000** (instead of 100). Also, I have tried different settings with no luck. All requests with ldapsearch using the credentials from GLUU settings work fine. **# dpkg -s gluu-server-2.4.4** ``` Package: gluu-server-2.4.4 Status: install ok installed Priority: optional Section: java Installed-Size: 1253361 Maintainer: Gluu Developers <support@gluu.org> Architecture: amd64 Version: 1-2~xenial+Ub16.04 Depends: bash (>= 2.05a-11), sed (>= 3.02-8), grep (>= 2.4.2-3), coreutils (>= 5.0-5) Conffiles: /etc/init.d/gluu-server-2.4.4 5743d31c7db34ca1a437e1a6121ab319 Description: Gluu Server Community Edition Homepage: http://www.gluu.org Original-Maintainer: Adrian Alves <support@gluu.org> ```

Hi, Evgeniy. This fragment ``` Exception happened while executing cache refresh synch ronization org.gluu.site.ldap.persistence.exception.EntryPersistenceException: Failed to find entries with baseDN: <SKIPPED>, filter: (&(uid=ab*)(objectClass=<SKIPPED>)) ``` let me think you may be using **"Load source data with limited search"** feature of CR. Have it been enabled all the time, from the first moment you had your issues with CR? If it's so, let's try to disable it for now, I'm not sure it's designed to work well with standard LDAP pagination. It's a totally different approach to the problem intended as a workaround in the past. For now, let's try to limit your search sizes with **"Search size limit"** alone.

Initially I have tried without **"Load source data with limited search"** and the filter was "**`(&(uid=*)(objectClass=<SKIPPED>))`**". But the error message and the result were the same.

I still can't reproduce it. In my setup I'm using AD instance on Windows Server 2012 with default settings. When I try to request all my user entries from it with `ldapsearch` I also see it being interrupted after 1000 entries had been delivered due to "Size Limit Exceeded". 1000 per one response is the default cap for modern AD instances. Yet, CR seems to cope well with it using the pagination feature, both for default value of 1000, and for 100 I set manually for a test. What else I need to re-configure to be able to reproduce your issue?

We also have 2.4.4 installed at many customer's systems, which mostly use AD, and also with numerous user base. Still, it's the first case like this. Though, they don't use Xenial, mostly CentOS and RHEL distros. May I ask you to spin up some CentOS/RHEL vm and try to install Gluu CE there, then check whether you'll still have this issue?

Evgeniy, A suggestion for you if you haven't tried that. There is a field in Cache Refresh where you can specify Search limit ( screenshot attached ). - Stop Cache Refresh - Add your search limit [ if your search limit is 1000, use 999 as search limit value there. For 100, use 99 ] - Update configuration - Enable Cache Refresh.

To Aliaksandr Samuseu: There is no problem with AD, as I said before. There is a problem with OpenLDAP.

Evgeniy, have you tried to use one of our .rpm packages? As mentioned, most of our customers using 2.4.4 instances (mostly on RHEL/CentOS distro families) have AD as backend, and so far no issues like that have been reported.

To **mohib zico** ``` Caused by: LDAPSearchException(resultCode=4 (size limit exceeded), numEntries=1000, numReferences=0, errorMessage='size limit exceeded') ``` Nothing has been changed.

Okay, you need to check from your backend LDAP side it seems. No issue from Gluu Server; just checked for 2.4.4.

To **mohib zico**: Anyway, if I use a filter which limits the number of records below 1000 (our limit), than the cache refresh works fine.

I think that's what we suggested in one answer. :)

But it also means I can't get all the records. I just intentionally limit it with the filter.