Bug 1515190 - "Truncated search results" pop-up appears in user details in WebUI
Summary: "Truncated search results" pop-up appears in user details in WebUI
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.4
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: mreynolds
QA Contact: RHDS QE
Marc Muehlfeld
Depends On: 1436319
Blocks: 1554720
TreeView+ depends on / blocked
Reported: 2017-11-20 11:15 UTC by Andrey Bondarenko
Modified: 2020-09-13 22:01 UTC (History)
16 users (show)

Fixed In Version: 389-ds-base-
Doc Type: Bug Fix
Doc Text:
Directory Server clients are no longer randomly restricted by anonymous resource limits Previously, Directory Server did not remember when the first operation, bind, or a connection was started. As a consequence, the server applied in certain situations anonymous resource limits to an authenticated client. With this update, Directory Server properly marks authenticated client connections. As a result, it applies the correct resource limits, and authenticated clients no longer get randomly restricted by anonymous resource limits.
Clone Of: 1436319
: 1554720 (view as bug list)
Last Closed: 2018-10-30 10:13:31 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 2355 0 None closed Binded ldapsearch hitting administrative limit for anonymoys rule. 2020-11-02 19:26:08 UTC
Red Hat Product Errata RHSA-2018:3127 0 None None None 2018-10-30 10:14:55 UTC

Comment 3 Florence Blanc-Renaud 2017-12-06 15:48:32 UTC
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.

Comment 4 Andrey Bondarenko 2017-12-07 07:18:56 UTC

it's really fixed now with "90000000".

Comment 5 Andrey Bondarenko 2017-12-07 07:23:37 UTC
Sorry, after another refresh it's back. Even with 900000000 now.

Comment 8 Florence Blanc-Renaud 2017-12-19 12:54:15 UTC
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.

Comment 9 Andrey Bondarenko 2018-01-10 13:29:01 UTC

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)

Comment 10 Florence Blanc-Renaud 2018-01-11 08:16:23 UTC
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.

Comment 11 Andrey Bondarenko 2018-01-15 14:09:27 UTC

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


[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.

Comment 12 Andrey Bondarenko 2018-01-15 14:10:07 UTC
Created attachment 1381461 [details]
access log

Comment 14 Florence Blanc-Renaud 2018-01-15 14:32:38 UTC
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.

Comment 16 Florence Blanc-Renaud 2018-02-15 10:13:03 UTC
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

Comment 20 Florence Blanc-Renaud 2018-02-16 17:00:50 UTC
Hi Andrey,

I finally found that the issue you are seeing is coming from a bug in 389-ds:

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.

Comment 21 Andrey Bondarenko 2018-02-19 08:02:02 UTC
Great news! Thank you!

Comment 22 mreynolds 2018-02-20 14:07:02 UTC
Fixed upstream

Comment 23 mreynolds 2018-02-20 17:27:50 UTC
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).

Comment 26 mreynolds 2018-04-09 14:32:25 UTC
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

Comment 36 errata-xmlrpc 2018-10-30 10:13:31 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.