RE: Extensible matches in Active Directory

["Bennett, Tony - CNF" <Bennett.Tony@cnf.com>]

-----Original Message-----
From: owner-openldap-software@OpenLDAP.org [mailto:owner-openldap-software@OpenLDAP.org] On Behalf Of Vladimir Pastukhov
Sent: Tuesday, August 17, 2004 12:35 PM
To: OpenLDAP-software@OpenLDAP.org
Subject: Extensible matches in Active Directory

Hello,

I am trying to use extensible matches to filter out system and disabled user records in the Windows 2000 Active Directory.
AD implements two bit-checking operations, which I apply against userAccountControl attribute as follows:

(&
   (objectClass=user)
   (&
     (userAccountControl:1.2.840.113556.1.4.803:=512)
     (!(userAccountControl:1.2.840.113556.1.4.804:=50))
   )
)

ldapsearch from OpenLDAP 2.0.11 works fine, and from 2.2.15 reports an error "ldap_result: Can't contact LDAP server (-1)", so do various 2.1.x that I have tested.  If I search for just
(objectClass=user) using 2.2.15, it works.

After investingating client-server network conversation I have found that OpenLDAP omits dnAttributes parameter from the query, presumably because it has its default value, as RFC 2251 states:

"""
MatchingRuleAssertion ::= SEQUENCE {
         matchingRule    [1] MatchingRuleId OPTIONAL,
         type            [2] AttributeDescription OPTIONAL,
         matchValue      [3] AssertionValue,
         dnAttributes    [4] BOOLEAN DEFAULT FALSE }
...
    (4) If a value of a type is its default value, it MUST be absent.
        Only some BOOLEAN and INTEGER types have default values in this
        protocol definition.
"""

It appears that Active Directory server does not strictly conform to the RFC for that matter and requires dnAttributes to present.
Searching for userAccountControl:dn:... works, so I consider my guess confirmed.

I see three possible solutions here:

1. Report bug to Microsoft (anyway) and wait for them to release a patch - a very uncertain period.

2. Implement Active Directory compatibility configuration option in OpenLDAP - ugly, and slothful to write.

3. Stick to using :dn as a hazardous workaround - there is a chance that it can find something unwanted this way.

Which one to choose?

--
С уважением, Пастухов Владимир
vpastukhov@naumen.ru

=====================================================================================
Chose option #  1

I have already done so.
IIRC they've acknowledged the non-compliance.

More people complaining, means higher visability...and a quicker patch. 

Additionally, Window's clients "always" include "dnAttributes", even when 
its value is the default... which is also a violation.  Therefore, they have problems
on both the Client side as well as the Server side.

-tony