--_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 <[email protected]> Sent: Monday, September 12, 2016 6:31:25 PM To: Maria Blagoeva; [email protected] Subject: Re: (ITS#8501) OpenLdap not RFC 2891 complaint [email protected] 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; [email protected]<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">[email protected] 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_--
