openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#8501) OpenLdap not RFC 2891 complaint
by hyc＠symas.com 13 Sep '16

13 Sep '16

Maria Blagoeva wrote: > 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 rule > is omitted in the request one that is defined must be used, but if nothing 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 > ActiveDirectory server. ActiveDirectory is not RFC-compliant. > 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. And when no MatchingRule exists for an attribute, matching cannot be performed. That is part of RFC4511 so there's no need to state it here. > 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 > assistance. > > > 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 ordering >> 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=cn '(cn=ccc*)' cn' (&(objectClass=inetOrgPerson)(cn=ccc*))' -H >> ldap://IP:389 -b "ou=Users,dc=openstack,dc=org" -D "cn=aaa1, >> ou=Users,dc=openstack,dc=org" -x -W >> # extended LDIF >> # >> # LDAPv3 >> # base <ou=Users,dc=openstack,dc=org> with scope subtree >> # filter: (cn=ccc*) >> # requesting: cn (&(objectClass=inetOrgPerson)(cn=ccc*)) >> # 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=cn:caseIgnoreOrderingMatch '(cn=ccc*)' cn' >> (&(objectClass=inetOrgPerson)(cn=ccc*))' -H ldap://IP:389 -b >> "ou=Users,dc=openstack,dc=org" -D "c3D3Daaa1, ou=Users,dc=openstack,dc=org" -x >> -W >> # extended LDIF >> # >> # LDAPv3 >> # base <ou=Users,dc=openstack,dc=org> with scope subtree >> # filter: (cn=ccc*) >> # requesting: cn (&(objectClass=inetOrgPerson)(cn=ccc*)) >> # with server side sorting control >> # >> >> # ccc0, Users, openstack.org >> dn: cn=ccc0,ou=Users,dc=openstack,dc=org >> # search result >> search: 2 >> result: 0 Success >> control: 1.2.840.113556.1.4.474 false MAMKAQA= >> sortResult: (0) Success >> >> >> however the RFC states that the orderingRule is OPTIONAL as below: >> >> SortKeyList ::= 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 must > 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/ -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8502) mdb_cursor_count() == EINVAL for empty DB
by h.b.furuseth＠usit.uio.no 13 Sep '16

13 Sep '16

Full_Name: Hallvard B Furuseth Version: mdb.master, 26e226b2a8cdba4208eabca394537900c4eda3b3 OS: URL: Submission from: (NULL) (81.191.45.31) Submitted by: hallvard mdb_cursor_count() has code to return MDB_NOTFOUND if !mc_snum, but it comes after if (! ... C_INITIALIZED) return EINVAL.

1 0

Re: (ITS#8501) OpenLdap not RFC 2891 complaint
by mblagoeva＠axway.com 13 Sep '16

13 Sep '16

--_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"> <style></style> </head> <body> <style type=3D"text/css" style=3D"display:none;"></style> <div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;back= ground-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;"> Hello Howard, 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. The quotes from the RFC directly: <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> <pre> If the orderingRule is omitted, the ordering MatchingRule defined for= =0A= use with this attribute MUST be used. Thanks again for your insights. </spa= n></pre> </div> <hr style=3D"display:inline-block;width:98%" tabindex=3D"-1"> <div id=3D"divRplyFwdMsg" dir=3D"ltr">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 <div> </div> </div> <div> <meta content=3D"text/html; charset=3DUTF-8"> <style type=3D"text/css" style=3D"">  </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"> Hello Howard, 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. BR, Maria </div> <hr tabindex=3D"-1" style=3D"display:inline-block; width:98%"> <div id=3D"x_divRplyFwdMsg" dir=3D"ltr">From: Howard Chu <hyc@= 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 <div> </div> </div> </div> <div class=3D"PlainText">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: <a href=3D"ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.o= rg/incoming/</a> > Submission from: (NULL) (194.88.228.86) > > > It seems that openldap as of 2.4.31 is not RFC complaint > (<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 > match rule is empty while doing server side sorting. Example below:<br= > False. OpenLDAP is completely correct and RFC-compliant in its behavior.<br= > > empty ordering rule: > > ldapsearch -E sss=3Dcn '(cn=3Dccc*)' cn' (&(objectClass=3DinetOrgP= erson)(cn=3Dccc*))' -H > ldap://IP:389 -b "ou=3DUsers,dc=3Dopenstack,dc=3Dorg" -D &qu= ot;cn=3Daaa1, > ou=3DUsers,dc=3Dopenstack,dc=3Dorg" -x -W > # extended LDIF > # > # LDAPv3 > # base <ou=3DUsers,dc=3Dopenstack,dc=3Dorg> with scope subtree<b= r> > # 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<b= r> > "ou=3DUsers,dc=3Dopenstack,dc=3Dorg" -D "c3D3Daaa1, ou= =3DUsers,dc=3Dopenstack,dc=3Dorg" -x > -W > # extended LDIF > # > # LDAPv3 > # base <ou=3DUsers,dc=3Dopenstack,dc=3Dorg> with scope subtree<b= r> > # 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 SEQU= ENCE { >           &nbsp= ;      attributeType   AttributeDescript= ion, >           &nbsp= ;      orderingRule    [0] Matching= RuleId OPTIONAL, >           &nbsp= ;      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.       &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>    Chief Architect, OpenLDAP  <a href=3D"http://www.openldap= .org/project/">http://www.openldap.org/project/</a> </div> </div> </body> </html> --_000_AM4PR0101MB1954B05EC18907733774338FBBFE0AM4PR0101MB1954_--

1 0

Re: (ITS#8501) OpenLdap not RFC 2891 complaint
by mblagoeva＠axway.com 13 Sep '16

13 Sep '16

--_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(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_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"> <style></style> </head> <body> <meta content=3D"text/html; charset=3DUTF-8"> <style type=3D"text/css" style=3D"">  </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"> Hello Howard, 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. BR, Maria </div> <hr tabindex=3D"-1" style=3D"display:inline-block; width:98%"> <div id=3D"x_divRplyFwdMsg" dir=3D"ltr">From: Howard Chu <hyc@= 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 <div> </div> </div> </div> <div class=3D"PlainText">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: <a href=3D"ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.o= rg/incoming/</a> > Submission from: (NULL) (194.88.228.86) > > > It seems that openldap as of 2.4.31 is not RFC complaint > (<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 > match rule is empty while doing server side sorting. Example below:<br= > False. OpenLDAP is completely correct and RFC-compliant in its behavior.<br= > > empty ordering rule: > > ldapsearch -E sss=3Dcn '(cn=3Dccc*)' cn' (&(objectClass=3DinetOrgP= erson)(cn=3Dccc*))' -H > ldap://IP:389 -b "ou=3DUsers,dc=3Dopenstack,dc=3Dorg" -D &qu= ot;cn=3Daaa1, > ou=3DUsers,dc=3Dopenstack,dc=3Dorg" -x -W > # extended LDIF > # > # LDAPv3 > # base <ou=3DUsers,dc=3Dopenstack,dc=3Dorg> with scope subtree<b= r> > # 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<b= r> > "ou=3DUsers,dc=3Dopenstack,dc=3Dorg" -D "c3D3Daaa1, ou= =3DUsers,dc=3Dopenstack,dc=3Dorg" -x > -W > # extended LDIF > # > # LDAPv3 > # base <ou=3DUsers,dc=3Dopenstack,dc=3Dorg> with scope subtree<b= r> > # 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 SEQU= ENCE { >           &nbsp= ;      attributeType   AttributeDescript= ion, >           &nbsp= ;      orderingRule    [0] Matching= RuleId OPTIONAL, >           &nbsp= ;      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.       &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>    Chief Architect, OpenLDAP  <a href=3D"http://www.openldap= .org/project/">http://www.openldap.org/project/</a> </div> </body> </html> --_000_AM4PR0101MB1954FD1169119D8DC1DD9008BBFE0AM4PR0101MB1954_--

1 0

Re: (ITS#8501) OpenLdap not RFC 2891 complaint
by hyc＠symas.com 12 Sep '16

12 Sep '16

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 ordering > 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=cn '(cn=ccc*)' cn' (&(objectClass=inetOrgPerson)(cn=ccc*))' -H > ldap://IP:389 -b "ou=Users,dc=openstack,dc=org" -D "cn=aaa1, > ou=Users,dc=openstack,dc=org" -x -W > # extended LDIF > # > # LDAPv3 > # base <ou=Users,dc=openstack,dc=org> with scope subtree > # filter: (cn=ccc*) > # requesting: cn (&(objectClass=inetOrgPerson)(cn=ccc*)) > # 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=cn:caseIgnoreOrderingMatch '(cn=ccc*)' cn' > (&(objectClass=inetOrgPerson)(cn=ccc*))' -H ldap://IP:389 -b > "ou=Users,dc=openstack,dc=org" -D "c3D3Daaa1, ou=Users,dc=openstack,dc=org" -x > -W > # extended LDIF > # > # LDAPv3 > # base <ou=Users,dc=openstack,dc=org> with scope subtree > # filter: (cn=ccc*) > # requesting: cn (&(objectClass=inetOrgPerson)(cn=ccc*)) > # with server side sorting control > # > > # ccc0, Users, openstack.org > dn: cn=ccc0,ou=Users,dc=openstack,dc=org > # search result > search: 2 > result: 0 Success > control: 1.2.840.113556.1.4.474 false MAMKAQA= > sortResult: (0) Success > > > however the RFC states that the orderingRule is OPTIONAL as below: > > SortKeyList ::= 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 must 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/

1 0

(ITS#8501) OpenLdap not RFC 2891 complaint
by mblagoeva＠axway.com 12 Sep '16

12 Sep '16

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 ordering match rule is empty while doing server side sorting. Example below: empty ordering rule: ldapsearch -E sss=cn '(cn=ccc*)' cn' (&(objectClass=inetOrgPerson)(cn=ccc*))' -H ldap://IP:389 -b "ou=Users,dc=openstack,dc=org" -D "cn=aaa1, ou=Users,dc=openstack,dc=org" -x -W # extended LDIF # # LDAPv3 # base <ou=Users,dc=openstack,dc=org> with scope subtree # filter: (cn=ccc*) # requesting: cn (&(objectClass=inetOrgPerson)(cn=ccc*)) # with server side sorting control # # search result search: 2 result: 18 Inappropriate matching text: serverSort control: No ordering rule # numResponses: 1 caseIgnoreOrderingMatch ordering rule: ldapsearch -E sss=cn:caseIgnoreOrderingMatch '(cn=ccc*)' cn' (&(objectClass=inetOrgPerson)(cn=ccc*))' -H ldap://IP:389 -b "ou=Users,dc=openstack,dc=org" -D "c3D3Daaa1, ou=Users,dc=openstack,dc=org" -x -W # extended LDIF # # LDAPv3 # base <ou=Users,dc=openstack,dc=org> with scope subtree # filter: (cn=ccc*) # requesting: cn (&(objectClass=inetOrgPerson)(cn=ccc*)) # with server side sorting control # # ccc0, Users, openstack.org dn: cn=ccc0,ou=Users,dc=openstack,dc=org # search result search: 2 result: 0 Success control: 1.2.840.113556.1.4.474 false MAMKAQA= sortResult: (0) Success however the RFC states that the orderingRule is OPTIONAL as below: SortKeyList ::= SEQUENCE OF SEQUENCE { attributeType AttributeDescription, orderingRule [0] MatchingRuleId OPTIONAL, reverseOrder [1] BOOLEAN DEFAULT FALSE } however openldap fails to return entries.

1 0

(ITS#8500) typo in slapo-ppolicy(5)
by michael＠stroeder.com 12 Sep '16

12 Sep '16

Full_Name: Version: git master OS: - URL: Submission from: (NULL) (85.115.23.42) diff --git a/doc/man/man5/slapo-ppolicy.5 b/doc/man/man5/slapo-ppolicy.5 index 91e0f8f..8306f97 100644 --- a/doc/man/man5/slapo-ppolicy.5 +++ b/doc/man/man5/slapo-ppolicy.5 @@ -104,7 +104,7 @@ object class. The definition of that class is as follows: pwdLockout $ pwdLockoutDuration $ pwdMaxFailure $ pwdFailureCountInterval $ pwdMustChange $ pwdAllowUserChange $ - pwdSafeModify 4 pwdMaxRecordedFailure ) ) + pwdSafeModify $ pwdMaxRecordedFailure ) ) .RE This implementation also provides an additional

1 0

(ITS#8499) fixes documentation typo
by gerardo.santana＠gmail.com 11 Sep '16

11 Sep '16

Full_Name: Gerardo Santana Gomez Garrido Version: 2.4 OS: Mac OS X URL: ftp://ftp.openldap.org/incoming/gerardo-santana-160911.patch Submission from: (NULL) (70.113.112.97) documentation typo

1 0

Re: (ITS#8498) slapadd complains about missing attrs
by quanah＠zimbra.com 09 Sep '16

09 Sep '16

--On Friday, September 09, 2016 11:32 PM +0100 Howard Chu <hyc(a)symas.com> wrote: >> I'd generally expect the warning to be consistently shown (or not). I >> don't think it's valid in the case of "". > > The warning is only printed in single-master replication configs. My point is the warning is invalid, and it was printed on the replica, nothing to do with a master... --Quanah -- Quanah Gibson-Mount

1 0

Re: (ITS#8498) slapadd complains about missing attrs
by hyc＠symas.com 09 Sep '16

09 Sep '16

quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.44+ITS8432 > OS: Linux 3.13 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.52.177) > > > When slapadding a database rooted at "" on a replica, it outputs the following > warning: > > zimbra@zre-ldap014:~$ time ./libexec/zmslapadd > /home/build/ldap.bak.20160909144406 > 57d32561 slapadd: warning, missing attrs entryUUID,entryCSN from entry dn="" > -######## 42.58% eta 01m39s elapsed 01m13s spd 292.8 k/s > > > Interestingly enough, when slapadded to a master with cn=accesslog in play, it > doesn't output anything: > > zimbra@zre-ldap008:~$ ./libexec/zmslapadd /home/build/ldap.bak.20160909144406 > *#################### 100.00% eta none elapsed 02m45s spd 3.1 M/s > Closing DB... > > I'd generally expect the warning to be consistently shown (or not). I don't > think it's valid in the case of "". The warning is only printed in single-master replication configs. 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/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs