I'm using Google Apps Directory Sync (GADS) to synchronize group
memberships from an OpenLDAP (2.4.41) directory. GADS uses the Paged
Results control (1.2.840.113556.1.4.319) to retrieve results in batches
of 1000. One of the searches that it does is as follows:
base: ou=groups,dc=example,dc=com
filter: (mail=*(a)example.com)
attributes requested: member owner [and some others]
There are more than 1000 groups that match, so it returns the results in
batches as expected. Some of these groups are dynlist groups that have
memberURL attributes set, which dynamically expand the member attribute
when retrieved. For dynlist groups that show up in the first page of
results, their members are properly retrieved. But after the first page,
the results for dynlist groups only return a subset of the proper
membership. As a result, an incomplete membership is being synced to
Google for those subsequent groups, and the missing members are causing
problems.
To rule out GADS from being the root cause of the problem, I ran a
standalone perl script to search with the Paged Results control, with
the page size set to a small number of entries. Just as with GADS, after
the first page of results, the entries started to return fewer members
from dynlist groups than should be returned. With a page size of 1, the
second dynlist group started to show fewer members (125 vs 127).
My guess is that the dynlist code is somehow getting confused by the
presence of the Paged Results control in the top-level search, when it
does its internal searches to retrieve the individual group memberships.
I wanted to ask whether this is enough detail to file an ITS, or whether
more information was desired. It could take some more time to put
together a generically reproducible LDIF file, so I figured I would post
this now in case someone familiar with the dynlist code might recognize
this and see how the presence of the Paged Results control might be
interfering with its behavior.
Thanks,
-Kartik