Description of problem: When a group or user query is very general, and a sync is run to select all groups matching the filter, the result set size can exceed what the LDAP server allows. In that case, running a group sync returns "LDAP Result Code 4 "Size Limit Exceeded" Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: In the sync config file, the result page size should be able to be specified for user and group queries. Additional info:
Until paging is supported for the LDAP queries, the best way to work around this issue is to use selective whitelists of groups to sync, or more specific filters, in order to reduce the number of LDAP entries being fetched by the queries.
Work for this is happening: https://github.com/openshift/origin/pull/7309
Sample config for paged query can be seen here: https://github.com/openshift/origin/blob/master/test/extended/authentication/ldap/rfc2307/sync-config-paging.yaml https://github.com/openshift/origin/blob/master/test/extended/authentication/ldap/ad/sync-config-paging.yaml https://github.com/openshift/origin/blob/master/test/extended/authentication/ldap/augmentd-ad/sync-config-paging.yaml Setting page size to 1 and confirming that sync occurs as expected is how we are testing this feature internally.
Checked with devenv-rhel7_3467, the paging work well now for both groups and users. For user: 1> with paging 56c6b922 conn=1025 fd=16 ACCEPT from IP=172.17.42.1:41375 (IP=0.0.0.0:389) 56c6b922 conn=1025 op=0 SRCH base="ou=people,ou=ad,dc=example,dc=com" scope=2 deref=0 filter="(objectClass=inetOrgPerson)" 56c6b922 conn=1025 op=0 SRCH attr=mail testMemberOf 56c6b922 conn=1025 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= 56c6b922 conn=1025 op=1 SRCH base="ou=people,ou=ad,dc=example,dc=com" scope=2 deref=0 filter="(objectClass=inetOrgPerson)" 56c6b922 conn=1025 op=1 SRCH attr=mail testMemberOf 56c6b922 conn=1025 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= 56c6b922 conn=1025 op=2 SRCH base="ou=people,ou=ad,dc=example,dc=com" scope=2 deref=0 filter="(objectClass=inetOrgPerson)" 56c6b922 conn=1025 op=2 SRCH attr=mail testMemberOf 56c6b922 conn=1025 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= 56c6b922 conn=1025 op=3 SRCH base="ou=people,ou=ad,dc=example,dc=com" scope=2 deref=0 filter="(objectClass=inetOrgPerson)" 56c6b922 conn=1025 op=3 SRCH attr=mail testMemberOf 56c6b922 conn=1025 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text= 56c6b922 conn=1025 op=4 SRCH base="ou=people,ou=ad,dc=example,dc=com" scope=2 deref=0 filter="(objectClass=inetOrgPerson)" 56c6b922 conn=1025 op=4 SRCH attr=mail testMemberOf 56c6b922 conn=1025 op=4 SEARCH RESULT tag=101 err=0 nentries=1 text= 56c6b922 conn=1025 fd=16 closed (connection lost) 2> without paging: 56c6b946 conn=1026 fd=16 ACCEPT from IP=172.17.42.1:41385 (IP=0.0.0.0:389) 56c6b946 conn=1026 op=0 SRCH base="ou=people,ou=ad,dc=example,dc=com" scope=2 deref=0 filter="(objectClass=inetOrgPerson)" 56c6b946 conn=1026 op=0 SRCH attr=mail testMemberOf 56c6b946 conn=1026 op=0 SEARCH RESULT tag=101 err=0 nentries=5 text= 56c6b946 conn=1026 fd=16 closed (connection lost) For groups: 1> with paging: 56c6b775 conn=1013 fd=16 ACCEPT from IP=172.17.42.1:41132 (IP=0.0.0.0:389) 56c6b775 conn=1013 op=0 SRCH base="ou=groups,ou=rfc2307,dc=example,dc=com" scope=2 deref=0 filter="(objectClass=groupOfNames)" 56c6b775 conn=1013 op=0 SRCH attr=cn dn member 56c6b775 conn=1013 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= 56c6b775 conn=1013 op=1 SRCH base="ou=groups,ou=rfc2307,dc=example,dc=com" scope=2 deref=0 filter="(objectClass=groupOfNames)" 56c6b775 conn=1013 op=1 SRCH attr=cn dn member 56c6b775 conn=1013 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= 56c6b775 conn=1013 op=2 SRCH base="ou=groups,ou=rfc2307,dc=example,dc=com" scope=2 deref=0 filter="(objectClass=groupOfNames)" 56c6b775 conn=1013 op=2 SRCH attr=cn dn member 56c6b775 conn=1013 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= 56c6b775 conn=1014 fd=23 ACCEPT from IP=172.17.42.1:41134 (IP=0.0.0.0:389) 56c6b775 conn=1013 fd=16 closed (connection lost) 2> without paging: 56c6b80d conn=1019 fd=16 ACCEPT from IP=172.17.42.1:41223 (IP=0.0.0.0:389) 56c6b80d conn=1019 op=0 SRCH base="ou=groups,ou=rfc2307,dc=example,dc=com" scope=2 deref=0 filter="(objectClass=groupOfNames)" 56c6b80d conn=1019 op=0 SRCH attr=cn dn member 56c6b80d conn=1019 op=0 SEARCH RESULT tag=101 err=0 nentries=3 text= 56c6b80d conn=1019 fd=16 closed (connection lost) 56c6b80d conn=1020 fd=16 ACCEPT from IP=172.17.42.1:41225 (IP=0.0.0.0:389)
Also check with OSE with openshift v3.1.1.903 , paging work well.
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-2016:1064