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

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