directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: [ApacheDS 1.5.0 + DirStudio] Search result differs between Uppercase and Lowercase Searchstring
Date Tue, 24 Jul 2007 01:24:10 GMT
On 7/23/07, Markus Pohle <> wrote:
> Hi List-users,
> following problem I see during my tests with ApacheDS. Would like to
> know if someone of you do know what the problem is... any hint or tip is
> really appreciated.
> If my webapp tries to get the roles which contain a given user
> "p.groesche" as a uniqueMember, I do get a resultset of zero when the
> search string is like this:
> (uniqueMember=uid=p.groesche
> ,cn=users,cn=cas,dc=APPLICATIONS,dc=DOUGLASHOLDING)
> If I modify the search string so that it looks like this
> (uniqueMember=uid=p.groesche
> ,cn=users,cn=cas,dc=APPLICATIONS,dc=DOUGLASHOLDING)
> I do get a result set of one.


This looks the same to me or am I going blind?

I am able to reproduce this behaviour thru Directory Studio searches.
> Can anybody explain this behaviour to me? I would really like to know
> what the problem is, 'cause I thought ApacheDS is case-insensitive.

Case sensitivity depends on the matching rules used by the attributeType.
For example uniqueMember's attributeType description is below from RFC 2256

5.51. uniqueMember

    ( NAME 'uniqueMember' EQUALITY uniqueMemberMatch
      SYNTAX )

The matching characteristics of this attributeType are determined by this
which ApacheDS implements or should :).  Let's see what the RFCs say about
that in
(4517) :

4.2.31.  uniqueMemberMatch

   The uniqueMemberMatch rule compares an assertion value of the Name
   And Optional UID syntax to an attribute value of a syntax (e.g., the
   Name And Optional UID syntax) whose corresponding ASN.1 type is

   The rule evaluates to TRUE if and only if the <distinguishedName>
   components of the assertion value and attribute value match according
   to the distinguishedNameMatch rule and either, (1) the <BitString>
   component is absent from both the attribute value and assertion
   value, or (2) the <BitString> component is present in both the
   attribute value and the assertion value and the <BitString> component
   of the assertion value matches the <BitString> component of the
   attribute value according to the bitStringMatch rule.

   Note that this matching rule has been altered from its description in
   X.520 [X.520] in order to make the matching rule commutative.  Server
   implementors should consider using the original X.520 semantics
   (where the matching was less exact) for approximate matching of
   attributes with uniqueMemberMatch as the equality matching rule.

   The LDAP definition for the uniqueMemberMatch matching rule is:

      ( NAME 'uniqueMemberMatch'
         SYNTAX )

   The uniqueMemberMatch rule is an equality matching rule.


Ok what the heck does this mean.  It means that each DN component within the
for the DN will be compared according to the matchingRules of the DN
attribute.  So if
the you have the following two DN's:


They will evaluate to being equal since ou uses caseIgnoreMatch I do
believe.  However
these two DNs will not be equal:


This is because the uid attribute uses caseExactMatch for equality matching.

Making sense now? Basically the equality matchingRule of the attributeType
how matching is conducted during the filter evaluation process.

Since your example strings above were the same I did not see the difference
now you can use this information to figure out what's going on.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message