Since upgrading out OpenLDAP DSA to 2.4.20 OpenFire is logging a lot 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)
And users seem to get bounced out, and then logged back in. There were no changes to the OpenFire configuration (3.6.4). How can I chase down what is causing this issue. AFAIK, OpenLDAP doesn’t support serverSort and never has.
Message was edited by: Adam Tauno Williams Why would OpenFire depend on an ordering rule? And a non-RFC one at that.
I've verified via pcap dump that search request includes the control 1.2.840.113556.1.4.473 on
attributeType uid. uid, does in fact (as described in section 2.39 of RFC4519) have no
ordering rule - so the DSA is obligated to respond with the 18 [inappropriateMatching]
response code. Is there a way to supress OpenFires use of this control?
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.
This is INCORRECT BEHAVIOR; see section 2.39 of RFC4519, the uid/userid attribute has no ordering rule.
Same problem here, but ldap.clientSideSorting seems to be a non-option for us as when it is enabled, I appear to lose the last user/group returned by the LDAP server.
For example, with clientSideSorting enabled, the groups list indicates there is a total of 3 groups (which is corrent). but only two are shown. The same behaviour happens for users.