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...
--
-- Howard Chu
CTO, Symas Corp.
http://www.symas.com
Director, Highland Sun
http://highlandsun.com/hyc/
Chief Architect, OpenLDAP
http://www.openldap.org/project/