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