ando(a)sys-net.it wrote: > mhardin(a)symas.com wrote: >> Full_Name: Matthew Hardin >> Version: 2.4.14 >> OS: RHEL4 x86 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (74.44.226.116) >> >> >> Given an Active Directory group object containing the following two members: >> >> member: cn=Frank Y. Ewe,ou=Important Accounts,ou=User >> Accounts,ou=Common,dc=ad,dc=foobar,dc=com >> >> and >> >> member: cn=Frank Y. Ewe,ou=Important Accounts,ou=User >> Accounts,ou=Common,dc=ad,dc=foobar,dc=com >> >> (note the extra space between "Frank" and "Y" in the second member) >> >> Active Directory sees these as different entries and allows them to both be >> members of the same group. Back-LDAP and back-meta happily return both of these >> values. > I'd expect slapd-ldap to return two identical values, since value > prettification also eliminates multiple spaces in directoryString values. Right. It's strange that the value with two spaces was preserved.

>> When 'sortvals member' is turned on, the pcache overlay will cache this value >> but will not return it on subsequent searches because it sees these two values >> as duplicates. According to Howard Chu, this is because the equality matching >> rule for the 'member' attribute collapses multiple spaces into one before doing >> the comparison and so reports these two values as duplicates. >> >> Howard asked me to file this ITS as a means to solicit guidance from others as >> to the best way/place to fix this. > After value normalization, slapd-ldap I think should also check for > duplicates (possibly leaving this as an option), and discard them. In > fact, it is the proxy backend that injects broken data into the loop.

> Of course, the best solution in your case would probably be to fix your > data... :) Agreed on all points...