--_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%22%3Ehttps://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%22%3Ehttp://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_--