Re: (ITS#8501) OpenLdap not RFC 2891 complaint

[hyc@symas.com]

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/