On 7/23/07, Markus Pohle <[EMAIL PROTECTED]> 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
