OL 2.2.23 extensible matching on dn components

["Kirk A. Turner-Rustin" <ktrustin@owu.edu>]

OpenLDAP 2.2.23
BDB 4.2.52 + 2 patches
Backend: back-bdb
RedHat Enterprise Linux 3.1 with all updates

We've upgraded from OL 2.1.30 to 2.2.23 this month. Among other
wonderful things about doing this, the slapd memory leak discussed
here:

http://www.openldap.org/lists/openldap-software/200403/msg00533.html

has gone away, for which I'm very grateful to the developers.

I've encountered one minor oddity. Prior to the upgrade, I had some
clients which I had configured to use extensible matching equality
filters against dn components in order to traverse multiple branches
of our DIT in a single search while avoiding other branches. For
example, given the following simplified DIT structure:

       dc=owu,dc=edu
            |
ou=Branch1 -+- ou=Branch2 --- ou=Branch3
  |                |              |
etc.              etc.           etc.

I could use this filter:

(&(uid=ktrustin)(!(ou:dn:=Branch3)))

To find entries whose uid=ktrustin in Branch1 and Branch2 only.

Since the upgrade, the above filter returns entries with matching
uid attributes from all three branches. In addition, this filter:

(&(uid=ktrustin)(ou:dn:=Branch1))

matches nothing at all even though there is an entry with a matching
uid and dn ou component in that branch.

Other bread crumbs:

*   Extensible matching filters using the few other dn components
    we employ here (uid, cn) seem to work OK, so my problem may be
    isolated to the 'ou' attribute.

*   On comparing core.schema from old and new OL versions, I saw that
    the 'ou' attribute is SUP 'name', but that the 'name' attribute
    was commented out in OL 2.2.23's core.schema (perhaps because it
    is now defined in the source code?). Thinking that this change
    might be somehow related to my problem, I tested another SUP
    'name' attribute (cn) in an extensible match filter against a
    dn component, but, as mentioned above, using 'cn' did not
    reproduce the problem.

*   After reviewing rfc2254 and draft-ietf-ldapbis-filter-xx,
    I also tried specifying the matching rule in the filter, e.g.:
	(&(uid=ktrustin)(!(ou:dn:2.5.13.2:=Branch3)))
    but (as expected) had the same undesirable results.

I've worked around the change by rewriting the clients to do
multiple searches, one on each desired branch, instead of using
extensible matching to traverse several branches at once. But I'm
curious whether others among you have encountered anything similar.

--
  Kirk Turner-Rustin       | Programmer/Analyst
  Ohio Wesleyan University | Libraries and Information Services
  http://www.owu.edu       | http://lis.owu.edu