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@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@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 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/