Mailing-List: contact users-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@directory.apache.org
Received-SPF: pass (herse.apache.org: domain of akarasulu@gmail.com designates
 64.233.162.231 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth;
        b=eHcFB0a+Hq2uAcS1ZflfVIdj512EYUNExfcr9wuHzVlq7yigrNxaDw18WkDEqBXR755BTIkySv9XQpIj8T5hRKbzbA5icEBqoEtDUOG4+G+dF+uVu/u7hkUK7LEIjeJh2x5qHFLyaeqlybRzKFWyxkcYH0FmAO8VCIZnYcRzYfs=
Message-ID: <a32f6b020707231824m7bc66b56uacef709a91e35cd7@mail.gmail.com>
Date: Mon, 23 Jul 2007 21:24:10 -0400
From: "Alex Karasulu" <akarasulu@apache.org>
Sender: akarasulu@gmail.com
To: users@directory.apache.org
Subject: Re: [ApacheDS 1.5.0 + DirStudio] Search result differs between
 Uppercase and Lowercase Searchstring
In-Reply-To: <46A4D732.2020107@webunity.de>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_199335_20501886.1185240250722"
References: <46A4D732.2020107@webunity.de>

------=_Part_199335_20501886.1185240250722
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 7/23/07, Markus Pohle <apacheds.users@webunity.de> 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.


(uniqueMember=uid=p.groesche
,cn=users,cn=cas,dc=APPLICATIONS,dc=DOUGLASHOLDING)
(uniqueMember=uid=p.groesche
,cn=users,cn=cas,dc=APPLICATIONS,dc=DOUGLASHOLDING)

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
[http://www.faqs.org/rfcs/rfc2256.html]:

5.51. uniqueMember

    ( 2.5.4.50 NAME 'uniqueMember' EQUALITY uniqueMemberMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )

The matching characteristics of this attributeType are determined by this
matchingRule
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
   NameAndOptionalUID.

   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:

      ( 2.5.13.23 NAME 'uniqueMemberMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )

   The uniqueMemberMatch rule is an equality matching rule.

==========

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

ou=engineering
ou=ENGINeering

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

uid=RockStar
uid=rockstar

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


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

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

Alex

Alex

------=_Part_199335_20501886.1185240250722--