[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#5977) pcache and broken Active Directory equality matching rules

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) (
>>> 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/