[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#5977) pcache and broken Active Directory equality matching rules
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#5977) pcache and broken Active Directory equality matching rules
- From: hyc@symas.com
- Date: Fri, 27 Feb 2009 00:34:47 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
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...
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/