--_000_AM4PR0101MB1954B05EC18907733774338FBBFE0AM4PR0101MB1954_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello Howard,
And just one more follow-up question, if you do not mind, just to have the =
full picture. The way the RFC is construct, it seems that if the ordering r=
ule is omitted in the request one that is defined must be used, but if noth=
ing is defined in the schema nothing will be used, but I do not understand =
why the openlap will fail than. Exactly the same request works fine with Ac=
tiveDirectory server.
The quotes from the RFC directly:
The MatchingRuleId, as defined in section 4.1.9 of [LDAPv3], SHOULD
be one that is valid for the attribute type it applies to. If it is
not, the server will return inappropriateMatching.
If the orderingRule is omitted, the ordering MatchingRule defined for
use with this attribute MUST be used.
Thanks again for your insights.
________________________________
From: Maria Blagoeva
Sent: Tuesday, September 13, 2016 8:50:45 AM
To: Howard Chu; openldap-its(a)OpenLDAP.org
Subject: Re: (ITS#8501) OpenLdap not RFC 2891 complaint
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(a)symas.com
Sent: Monday, September 12, 2016
6:31:25 PM
To: Maria Blagoeva; openldap-its(a)OpenLDAP.org
Subject: Re: (ITS#8501) OpenLdap not RFC 2891 complaint
mblagoeva(a)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_AM4PR0101MB1954B05EC18907733774338FBBFE0AM4PR0101MB1954_
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
<style
type=3D"text/css" style=3D"display:none;"><!-- P
{margin-top:0;margi=
n-bottom:0;} --></style
<div
id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;back=
ground-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;"
<p>Hello Howard,</p
<p><br
</p
<p>And just one more follow-up question, if you do not mind, just to have t=
he full picture. The way the RFC is construct, it seems that if the orderin=
g rule is omitted in the request one that is defined must be used, but if n=
othing is defined in the schema
nothing will be used, but I do not understand why the openlap will fail th=
an. Exactly the same request works fine with ActiveDirectory server.
<br
</p
<p><br
</p
<p>The quotes from the RFC
directly:</p
<p><br
</p
<p></p
<pre>The MatchingRuleId, as defined in section 4.1.9 of
[LDAPv3], SHOULD=0A=
be one that is valid for the attribute type it applies to. If it is=0A=
not, the server will return inappropriateMatching.</pre
<p></p
<p><br
</p
<p></p
<pre> If the orderingRule is omitted, the ordering
MatchingRule defined for=
=0A=
use with this attribute MUST be used.<br><br><span
style=3D"font-family:=
Calibri,Arial,Helvetica,sans-serif;">Thanks again for your insights. </spa=
n></pre
<br
<p></p
</div
<hr style=3D"display:inline-block;width:98%"
tabindex=3D"-1"
<div
id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri,
sans-serif" st=
yle=3D"font-size:11pt" color=3D"#000000"><b>From:</b>
Maria Blagoeva<br
<b>Sent:</b> Tuesday,
September 13, 2016 8:50:45 AM<br
<b>To:</b> Howard Chu; openldap-its(a)OpenLDAP.org<br
<b>Subject:</b> Re: (ITS#8501) OpenLdap not RFC
2891 complaint</font
<div> </div
</div
<div
<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(a)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(a)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.ie...
/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></div
</body
</html
--_000_AM4PR0101MB1954B05EC18907733774338FBBFE0AM4PR0101MB1954_--