Hide Forgot
This bug is created as a clone of upstream ticket: https://fedorahosted.org/sssd/ticket/1202 We added support for the Simple Paged Search in ticket #658 and SSSD 1.5.8. When we did so, we chose to default to always requesting paged searches for all requests. However, it turns out that RFC 2696 does not mandate that the LDAP server supports more than one paging search at a time on the same connection. Some LDAP servers (notably 389 DS 1.2.9 and older) allow only a single paged search to be in progress on a request at one time. This results in receiving an error from LDAP that the server refuses to perform the operation. Once ticket #1201 is fixed, this will result in offline operation (right now it's misbehaving as if it received zero results). We need to avoid both of these events. RFC 2696 does specify that if the result size being returned is smaller than the requested page size that the paging control '''should''' be ignored. This would mitigate the problem, but it appears that 389 DS also chooses to not ignore the control in this case. In general, we need to find ways to minimize our usage of the paging control where available. I propose the following changes: 1. Add a boolean option to {{{ldap_generic_search_send()}}} to specify whether to use the paging control (when available). 1. Do not request the paging control when we expect a single-valued return from the request. 1. Always request the paging control for enumeration requests. 1. Serialize paging requests by maintaining a queue of lookups requiring paging and allow only one to operate at a time.{{{[1]}}} 1. If it can be reasonably determined that replies will never exceed 500 entries, also omit the paging control{{{[2]}}} {{{[1]}}}: This will likely introduce apparent performance issues when performing initgroups() requests, since they will no longer be able to run in parallel. We must always assume that the user may belong to many groups. {{{[2]}}}: I'm not 100% sure about this one. It's possible for a server to manually set its page size smaller than 500, though I doubt very many would do so. On the other hand, I can't come up with any ideas offhand for lookups of greater than a single entry that could not therefore result in a potentially-infinite set of results. So this may be a moot point.
Please add steps to verify/reproduce this bug.
Ok, I need to clarify that we reduced the scope of this bug upstream (and split it into two). This bug is only for steps 1), 2) and 3) above; specifically, we will not request the paging control for requests that do not expect more than one result. This is best tested with 389 DS <= 1.2.9. Configure SSSD for id_provider = LDAP and then run multiple concurrent calls to 'getent passwd <username>' (with different users in each call. They need to be run in parallel. Prior to this patch, some of those lookups would fail, and the sssd_DOMAIN.log would contain a message similar to "Error [53]: Server unwilling to perform" (that may not be the exact syntax). With this patch, all of the 'getent passwd <username>' calls should succeed.
Tested and verified on sssd-1.8.0-22.el6.x86_64. Verified the bug against both Openldap and 389-DS server. As part of this, multiple user lookups were conducted concurrently by scheduling them at the same time using "at" command. All the user lookups were successful and cached.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: No documentation required.
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. http://rhn.redhat.com/errata/RHBA-2012-0747.html