[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#8501) OpenLdap not RFC 2891 complaint
--_000_AM4PR0101MB1954FD1169119D8DC1DD9008BBFE0AM4PR0101MB1954_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Howard,
This means I need to patch the openldap instance or a default ordering rule=
can be set for that attribute on the fly? Thanks again for your help and a=
ssistance.
BR,
Maria
________________________________
From: Howard Chu <hyc@symas.com>
Sent: Monday, September 12, 2016 6:31:25 PM
To: Maria Blagoeva; openldap-its@OpenLDAP.org
Subject: Re: (ITS#8501) OpenLdap not RFC 2891 complaint
mblagoeva@axway.com wrote:
> Full_Name: Maria Blagoeva
> Version: openldap-2.4.31/debian/build/servers/slapd
> OS: docker image with 3.10.0-327.28.2.el7.x86_64
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (194.88.228.86)
>
>
> It seems that openldap as of 2.4.31 is not RFC complaint
> (https://www.ietf.org/rfc/rfc2891.txt) due to failure in response when or=
dering
> match rule is empty while doing server side sorting. Example below:
False. OpenLDAP is completely correct and RFC-compliant in its behavior.
> empty ordering rule:
>
> ldapsearch -E sss=3Dcn '(cn=3Dccc*)' cn' (&(objectClass=3DinetOrgPerson)(=
cn=3Dccc*))' -H
> ldap://IP:389 -b "ou=3DUsers,dc=3Dopenstack,dc=3Dorg" -D "cn=3Daaa1,
> ou=3DUsers,dc=3Dopenstack,dc=3Dorg" -x -W
> # extended LDIF
> #
> # LDAPv3
> # base <ou=3DUsers,dc=3Dopenstack,dc=3Dorg> with scope subtree
> # filter: (cn=3Dccc*)
> # requesting: cn (&(objectClass=3DinetOrgPerson)(cn=3Dccc*))
> # with server side sorting control
> #
>
> # search result
> search: 2
> result: 18 Inappropriate matching
> text: serverSort control: No ordering rule
This result is correct since the cn attribute has no ordering rule defined =
in
the schema.
>
> # numResponses: 1
>
> caseIgnoreOrderingMatch ordering rule:
>
> ldapsearch -E sss=3Dcn:caseIgnoreOrderingMatch '(cn=3Dccc*)' cn'
> (&(objectClass=3DinetOrgPerson)(cn=3Dccc*))' -H ldap://IP:389 -b
> "ou=3DUsers,dc=3Dopenstack,dc=3Dorg" -D "c3D3Daaa1, ou=3DUsers,dc=3Dopens=
tack,dc=3Dorg" -x
> -W
> # extended LDIF
> #
> # LDAPv3
> # base <ou=3DUsers,dc=3Dopenstack,dc=3Dorg> with scope subtree
> # filter: (cn=3Dccc*)
> # requesting: cn (&(objectClass=3DinetOrgPerson)(cn=3Dccc*))
> # with server side sorting control
> #
>
> # ccc0, Users, openstack.org
> dn: cn=3Dccc0,ou=3DUsers,dc=3Dopenstack,dc=3Dorg
> # search result
> search: 2
> result: 0 Success
> control: 1.2.840.113556.1.4.474 false MAMKAQA=3D
> sortResult: (0) Success
>
>
> however the RFC states that the orderingRule is OPTIONAL as below:
>
> SortKeyList ::=3D SEQUENCE OF SEQUENCE {
> attributeType AttributeDescription,
> orderingRule [0] MatchingRuleId OPTIONAL,
> reverseOrder [1] BOOLEAN DEFAULT FALSE }
>
> however openldap fails to return entries.
The rule is optional in the control itself, but a valid ordering rule must
exist somewhere. Since the attribute schema doesn't define one then you mus=
t
provide one yourself.
Closing this ITS.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--_000_AM4PR0101MB1954FD1169119D8DC1DD9008BBFE0AM4PR0101MB1954_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<meta name=3D"Generator" content=3D"Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; pad=
ding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content=3D"text/html; charset=3DUTF-8">
<style type=3D"text/css" style=3D"">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir=3D"ltr">
<div id=3D"x_divtagdefaultwrapper" style=3D"font-size:12pt; color:#000000; =
background-color:#FFFFFF; font-family:Calibri,Arial,Helvetica,sans-serif">
<p>Hello Howard,</p>
<p><br>
</p>
<p>This means I need to patch the openldap instance or a default ordering r=
ule can be set for that attribute on the fly? Thanks again for your help an=
d assistance.</p>
<p><br>
</p>
<p>BR,</p>
<p>Maria<br>
</p>
</div>
<hr tabindex=3D"-1" style=3D"display:inline-block; width:98%">
<div id=3D"x_divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" =
color=3D"#000000" style=3D"font-size:11pt"><b>From:</b> Howard Chu <hyc@=
symas.com><br>
<b>Sent:</b> Monday, September 12, 2016 6:31:25 PM<br>
<b>To:</b> Maria Blagoeva; openldap-its@OpenLDAP.org<br>
<b>Subject:</b> Re: (ITS#8501) OpenLdap not RFC 2891 complaint</font>
<div> </div>
</div>
</div>
<font size=3D"2"><span style=3D"font-size:10pt;">
<div class=3D"PlainText">mblagoeva@axway.com wrote:<br>
> Full_Name: Maria Blagoeva<br>
> Version: openldap-2.4.31/debian/build/servers/slapd<br>
> OS: docker image with 3.10.0-327.28.2.el7.x86_64<br>
> URL: <a href=3D"ftp://ftp.openldap.org/incoming/";>ftp://ftp.openldap.o=
rg/incoming/</a><br>
> Submission from: (NULL) (194.88.228.86)<br>
><br>
><br>
> It seems that openldap as of 2.4.31 is not RFC complaint<br>
> (<a href=3D"https://www.ietf.org/rfc/rfc2891.txt";>https://www.ietf.org=
/rfc/rfc2891.txt</a>) due to failure in response when ordering<br>
> match rule is empty while doing server side sorting. Example below:<br=
>
<br>
False. OpenLDAP is completely correct and RFC-compliant in its behavior.<br=
>
<br>
> empty ordering rule:<br>
><br>
> ldapsearch -E sss=3Dcn '(cn=3Dccc*)' cn' (&(objectClass=3DinetOrgP=
erson)(cn=3Dccc*))' -H<br>
> ldap://IP:389 -b "ou=3DUsers,dc=3Dopenstack,dc=3Dorg" -D &qu=
ot;cn=3Daaa1,<br>
> ou=3DUsers,dc=3Dopenstack,dc=3Dorg" -x -W<br>
> # extended LDIF<br>
> #<br>
> # LDAPv3<br>
> # base <ou=3DUsers,dc=3Dopenstack,dc=3Dorg> with scope subtree<b=
r>
> # filter: (cn=3Dccc*)<br>
> # requesting: cn (&(objectClass=3DinetOrgPerson)(cn=3Dccc*))<br>
> # with server side sorting control<br>
> #<br>
><br>
> # search result<br>
> search: 2<br>
> result: 18 Inappropriate matching<br>
> text: serverSort control: No ordering rule<br>
<br>
This result is correct since the cn attribute has no ordering rule defined =
in <br>
the schema.<br>
><br>
> # numResponses: 1<br>
><br>
> caseIgnoreOrderingMatch ordering rule:<br>
><br>
> ldapsearch -E sss=3Dcn:caseIgnoreOrderingMatch '(cn=3Dccc*)' cn'<br>
> (&(objectClass=3DinetOrgPerson)(cn=3Dccc*))' -H ldap://IP:389 -b<b=
r>
> "ou=3DUsers,dc=3Dopenstack,dc=3Dorg" -D "c3D3Daaa1, ou=
=3DUsers,dc=3Dopenstack,dc=3Dorg" -x<br>
> -W<br>
> # extended LDIF<br>
> #<br>
> # LDAPv3<br>
> # base <ou=3DUsers,dc=3Dopenstack,dc=3Dorg> with scope subtree<b=
r>
> # filter: (cn=3Dccc*)<br>
> # requesting: cn (&(objectClass=3DinetOrgPerson)(cn=3Dccc*))<br>
> # with server side sorting control<br>
> #<br>
><br>
> # ccc0, Users, openstack.org<br>
> dn: cn=3Dccc0,ou=3DUsers,dc=3Dopenstack,dc=3Dorg<br>
> # search result<br>
> search: 2<br>
> result: 0 Success<br>
> control: 1.2.840.113556.1.4.474 false MAMKAQA=3D<br>
> sortResult: (0) Success<br>
><br>
><br>
> however the RFC states that the orderingRule is OPTIONAL as below:<br>
><br>
> SortKeyList ::=3D SEQUENCE OF SEQU=
ENCE {<br>
>  =
; attributeType AttributeDescript=
ion,<br>
>  =
; orderingRule [0] Matching=
RuleId OPTIONAL,<br>
>  =
; reverseOrder [1] BOOLEAN =
DEFAULT FALSE }<br>
><br>
> however openldap fails to return entries.<br>
<br>
The rule is optional in the control itself, but a valid ordering rule must =
<br>
exist somewhere. Since the attribute schema doesn't define one then you mus=
t <br>
provide one yourself.<br>
<br>
Closing this ITS.<br>
<br>
-- <br>
-- Howard Chu<br>
CTO, Symas Corp. &nbs=
p; <a href=3D"http://www.symas.com";>http://www.symas.com</a><br=
>
Director, Highland Sun <a href=3D"http=
://highlandsun.com/hyc/">http://highlandsun.com/hyc/</a><br>
Chief Architect, OpenLDAP <a href=3D"http://www.openldap=
.org/project/">http://www.openldap.org/project/</a><br>
</div>
</span></font>
</body>
</html>
--_000_AM4PR0101MB1954FD1169119D8DC1DD9008BBFE0AM4PR0101MB1954_--