Diego, You and I have the same issue. UID and CN are not in the schema they are compiled into LDAP some how, so there is no way to apply an ordering rule. I can not find if this is possible, or what is involved in making it happen. As you can see uid is commented in the schema file as is cn # attributetype ( 0.9.2342.19200300.100.1.1 # NAME ( 'uid' 'userid' ) # DESC 'RFC1274: user identifier' # EQUALITY caseIgnoreMatch # SUBSTR caseIgnoreSubstringsMatch # SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) In the past this was possible, or the attributes had an ordering. I do not know when this changed.

On Fri, 2010-01-15 at 11:27 -0200, Diego Lima wrote: > I have enabled the server-side sorting overlay and I received the > following error on a search: > sssvlv: no ordering rule specified and no default ordering rule for > attribute uid > <= get_ctrls: n=1 rc=18 err="serverSort control: No ordering rule" > send_ldap_result: conn=1000 op=7 p=3 > send_ldap_response: msgid=8 tag=101 err=18 > ber_flush2: 50 bytes to sd 13 > Where should I specify the ordering rule for the uid attribute? The > core schema? I believe I have this issue as well. Since upgrading to OL 2.4.20 our OpenFire XMPP server has been logging an unending stream of -

On Thu, 2010-02-18 at 08:29 -0500, Adam Tauno Williams wrote: > On Fri, 2010-01-15 at 11:27 -0200, Diego Lima wrote: >> I have enabled the server-side sorting overlay and I received the >> following error on a search: >> sssvlv: no ordering rule specified and no default ordering rule for >> attribute uid >> <= get_ctrls: n=1 rc=18 err="serverSort control: No ordering rule" >> send_ldap_result: conn=1000 op=7 p=3 >> send_ldap_response: msgid=8 tag=101 err=18 >> ber_flush2: 50 bytes to sd 13 >> Where should I specify the ordering rule for the uid attribute? The >> core schema? > I believe I have this issue as well. Since upgrading to OL 2.4.20 our > OpenFire XMPP server has been logging an unending stream of - > 2010.02.15 11:02:26 > [org.jivesoftware.openfire.ldap.LdapManager.retrieveList(LdapManager.java:1709)] > javax.naming.directory.InvalidSearchFilterException: [LDAP: error code 18 - serverSort control: No ordering rule]; remaining name '' > at com.sun.jndi.ldap.LdapCtx.mapErrorCode(Unknown Source) > at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source) > at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source) > at com.sun.jndi.ldap.LdapCtx.searchAux(Unknown Source) > at com.sun.jndi.ldap.LdapCtx.c_search(Unknown Source) > at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(Unknown Source) > No changes were made to the OpenFire configuration, so the issue must be > do to a change in OL schema. Browsing our DSA's schema and cn and uid > have no ordering rule. Setting the OpenFire server property "ldap.clientSideSorting" to "true" seems to have cleared up this issue. Without that property OpenFire was requesting the control 1.2.840.113556.1.4.473 on the "uid" attribute.