Hi,
I was not able to reproduce the issue with
ipa-server.x86_64                 4.5.0-21.el7_4.2.2

Do you still see the pop-up with search limit exceeded?

From your description it is not clear the exact error you are seeing, and with the config shown (Search size limit: 1000000) you would need more than 1000000 users to reproduce the issue.

Hello,

it's really fixed now with "90000000".

Sorry, after another refresh it's back. Even with 900000000 now.

The behavior is indeed the expected one. The server is showing a pop up to warn the user that the list of entries displayed can be missing entries because of a limit enforced by the LDAP server.

If the admin wants to be able to see all the entries he can tune the nsslapd-sizelimit (currently limited to 2000). This is not recommended as it would slow down the search requests. This value needs to be configured on each server as it is not replicated.

Moreover, the warning is a pop up that does not prevent the admin from navigating to other pages and does not require any interaction.
Hence closing as not a bug.

Hi,

I have tried to apply change, still have the message.

ldapmodify -D "cn=directory manager" -w PASSWORD -p 389 -h `hostname`
dn: cn=config
changetype: modify
replace: nsslapd-sizelimit
nsslapd-sizelimit: 10000

(tried different values here)

Can you describe your configuration?
- the value of nsslapd-sizelimit (in cn=config)
- the value of nsslapd-lookthroughlimit (in cn=config,cn=ldbm database,cn=plugins,cn=config)
- the value of ipaSearchRecordsLimit (in cn=ipaConfig,cn=etc,$BASEDN)
- the number of entries below cn=users,cn=accounts,$BASEDN

and provide the access log of 389-ds when you perform a search like this one:

ldapsearch -D uid=abondare,cn=users,cn=accounts,$BASEDN -W -b cn=users,cn=accounts,$BASEDN "(objectClass=posixaccount)"

It is possible that you are reaching the lookthrough limit in this case.

Hello,

I have set all limits to unreasonable values like 10 000.

Done

[idm-backup01.core.dev.int.devlab.redhat.com] [02:06:29 PM]
[root@idm-backup01 ~]# ldapsearch -D uid=admin,cn=users,cn=accounts,dc=ipa,dc=deviam,dc=redhat,dc=com -W -b cn=users,cn=accounts,dc=ipa,dc=deviam,dc=redhat,dc=com "(objectClass=posixaccount)"> 11.txt
Enter LDAP Password: 
[idm-backup01.core.dev.int.devlab.redhat.com] [02:07:25 PM]

Log files attached.

Created attachment 1381461 [details]
access log

Hi Andrey,

the last place where a size limit can be specified is inside the user entry. So in your case, what is the value of nssizelimit and nsLookThroughLimit of the entry uid=admin,cn=users,cn=accounts,dc=ipa,dc=deviam,dc=redhat,dc=com which is performing the search? (see https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/Finding_Directory_Entries#tab.resource-limits-attrs)

The logs show that the search returns at most 3000 entries, we need to identify where this limit comes from.

Hi Andrey,

other users had the same issue, and the problem was linked to the use of GSS-SPNEGO authentication mechanism. In order to check if you are indeed hitting the same problem, can you check:

1/ Anonymous size limits
ldapsearch -D 'cn=directory manager' -W -b cn=config -s base nsslapd-anonlimitsdn

it will provide you with a DN of the entry defining the anonymous limits (usually cn=anonymous-limits,cn=etc,$BASEDN), then:

$ ldapsearch -D 'cn=directory manager' -W -b cn=anonymous-limits,cn=etc,$BASEDN nsSizeLimit nsLookThroughLimit 

2/ Are you using GSS-SPNEGO?
$ cat /etc/openldap/ldap.conf | grep SASL_MECH

if SASL_MECH is GSS-SPNEGO, then you are using this mechanism, but I'm almost sure it's the case because the attached access log show:
conn=5683 op=0 BIND dn="" method=sasl version=3 mech=GSS-SPNEGO
conn=5683 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=admin,cn=users,cn=accounts,$BASEDN"
...
conn=5683 op=2 SRCH base="cn=users,cn=accounts,$BASEDN" scope=1 filter="(objectClass=posixaccount)" attrs="ipaSshPubKey uid"
conn=5683 op=2 RESULT err=4 tag=101 nentries=3000 etime=2

Can you provide me with the above information? If it's concluding, I will open an issue against 389-ds because it looks like GSS-SPNEGO authentication is using the anonymous limits instead of the user limits.
Thanks in advance

Hi Andrey,

I finally found that the issue you are seeing is coming from a bug in 389-ds:
https://pagure.io/389-ds-base/issue/49296

The limit that is applied is the anonymous lookthrough limit, although the search is authenticated and should not inherit this limit.

I propose to keep this BZ opened as a tracker of the 389-ds issue, until the 389-ds team clones the upstream pagure ticket into a BZ on RHEL.

Great news! Thank you!

Fixed upstream

Reproduction Steps:
=====================================================

[1]  Add 6000 users (make note of an entry and its password for step [4])
[2]  Set up anonymous resource limits

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

dn: cn=anonymous-limits,dc=example,dc=com
objectclass: top
objectclass: extensibleObject
nsLookThroughLimit: 5000

[3]  Continuously issue anonymous ldapsearch's that exceed the lookthroughlimit

  # ldapsearch -xLLL -b dc=example,dc=com objectclass=top > /dev/null 

  ---> I just write a shell script and do an endless loop with this search

[4]  Then continuously run an authenticated ldapsearch, and make sure we do not get any errors:

  # ldapsearch -xLLL -b dc=example,dc=com -D "uid=test_user,ou=people,dc=example,dc=com" -w password objectclass=top > /dev/null 

  ---> I script this as well

[5]  Problem typically appears with in a few seconds (30 seconds max).

These prerequisite steps were missing in the reproducer:

# ldapmodify -x -h localhost -p 389 -D "cn=Directory Manager" -w Secret123 << EOF
dn: cn=config
changetype: modify
replace: nssslapd-sizelimit
nsslapd-sizelimit: -1
-
dn: cn=config,cn=ldbm database,cn=plugins,cn=config
changetype: modify
replace: nsLookThroughLimit
nsLookThroughLimit: -1

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:3127