[Kolab-devel] [issue4732] OpenLDAP rejects searches when server side sorting is requested

[Thomas Arendsen Hein]

Address book search via LDAP is broken with Kolab Server 2.3.0
(openldap-2.4.23-20110308) using a Brother MFC printer/scanner. Searching via
Outlook might be affected, too, but searching via kontact e35 still works.

With Kolab Server 2.2.4 the log messages when the search is performed were:
<debug> slapd[1564]: slap_global_control: unrecognized control:
1.2.840.113556.1.4.473
(but the search was performed without problems)

With Kolab Server 2.3.0 it is:
<debug> slapd[5821]: conn=141806 op=1 do_search: get_ctrls failed
(and the search results in an error)

1.2.840.113556.1.4.473 is server-side sorting, see e.g.:
http://www.mail-archive.com/openldap-technical@openldap.org/msg00495.html
http://www.openldap.org/lists/openldap-software/200408/msg00321.html

These postings suggest that access to this feature can be disabled by using:
access to dn.exact="" attrs=supportedControl val=1.2.840.113556.1.4.473 by * none

But this results in the server not starting anymore and yields the following
error message:
<debug> slapd[27208]: /kolab/etc/openldap/slapd.conf: line 116: attr
"supportedControl" does not have an EQUALITY matching rule.

To reproduce without the printer or Outlook:
/kolab/bin/ldapsearch -E 'sss=cn' '(cn=*)'

There is a configure option --enable-sssvlv, which is not used when compiling
OpenLDAP in server 2.3.0, but enabling this does not make any difference.

I found out that there are no ordering rules for the CN attribute and that it
can only be added by changing the source code, so as a workaround I configured
the printer to use the SN attribute and add an ORDERING line to
/kolab/etc/openldap/schema/core.schema for the SN attribute so it reads:

attributetype ( 2.5.4.4 NAME ( 'sn' 'surname' )
	DESC 'RFC2256: last (family) name(s) for which the entity is known by'
	ORDERING caseIgnoreOrderingMatch
	SUP name )


After "/kolab/bin/openpkg rc openldap restart" I verified that it works now
by using the printer and by executing:
/kolab/bin/ldapsearch -E 'sss=sn' '(cn=*)'


Regarding Outlook, http://support.microsoft.com/kb/820864 mentions:
"For Outlook to provide this functionality for an LDAP server address list,
the LDAP server must support either the Virtual List View (VLV) extension or a
combination of two LDAP controls (the paged results and the server-side sort
controls)."
We had a related problem regarding paged results in the past: kolab/issue79


Any idea how to continue here? Possibilities:
- see what upstream suggests
- patch openldap to allow server side ordering on cn
- document above workaround in the wiki
- ...?

Assigning to jmeeuwen for now, because he has the best connections to upstream.

----------
assignedto: jmeeuwen
keyword: regression, server
messages: 27706
nosy: jmeeuwen, martin, thomas, wickert, wilde, wrobel
priority: bug
related: openLDAP does not work with OL XP
status: unread
title: OpenLDAP rejects searches when server side sorting is requested

______________________________________
Kolab issue tracker <issues at kolab.org>
<https://issues.kolab.org/issue4732>
______________________________________