hyc@symas.com wrote:
ando@sys-net.it wrote:
mhardin@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.
Never mind, cn is DirectoryString and has no pretty function.
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.
Fixed now in HEAD for -ldap and -meta; it only checks for duplicates on attributes that were configured for sorting. I suppose a config option to check all attrs may be useful, but for now it seems unnecessary.
Of course, the best solution in your case would probably be to fix your data... :)
Agreed on all points...
-
hyc＠symas.com