Howard Chu wrote:One last question that may need an answer: what groups does user X belong to?
Obviously you need to perform a search to determine this. And with the current indexing mechanisms, dynamic groups will fail to be matched since they don't actually contain an indexed static member list. If this is the question you're trying to answer, the solution is simply to maintain a list of dynamic group objects (as your current code already does) but not to populate them. Instead, just use a search response callback and see if "member" is a part of the filter. If it is, iterate through the dynamic groups and test the entry whose DN is in the filter assertion against all of the dynamic group filters. This solution will use far less memory than your approach, and it will run efficiently for just about all use cases.
This was actually the first idea we thought of, we concluded that it would slow the search down, because then the algorithmic complexity of the search would be O(n), with n as the number of dynamic groups. We think this would be somewhat against the idea of LDAP directories, where the number of search operations far outweigh the number of updates. It is a trade-off between update speed and search speed, but we think that the search speed is essential, and the update operations are not our primary concern speed-wise.