We currently use RedHat Enterprise Server 4 and openLDAP 2.2.13 to provide a directory service to Mozilla Thunderbird email clients on our internal network. The information is actually stored in a MySQL Contact Database, so we use back_sql with the necessary translation databases.
We are upgrading our servers to RedHat 5.1, and in the process trying to migrate to openLDAP 2.3.27 (the latest version that RH provides). The application does not work in this release. In fact, if a Thunderbird user tries to do a directory search as before, openLDAP fails. When it fails, it does not write anything to the log explaining why.
The databases, ldap.conf, slapd.conf and odbc.ini are identical in both cases.
I have used an LDAP browser to eliminate some of the variables and do some simple testing to help isolate the problem. What I have found is: - One-level searches work in both releases - Sub-Tree searches work in 2.2.13 and fail in 2.3.27 (causing openLDAP to terminate)
I am not familiar with the code, so I can't be very helpful there, but I did notice the following from the logs:
- One-level search: The details of the log entries are somewhat different for the two releases, but the SELECT DISTINCT statements that actually pick entries from the DB are the same
- Sub-Tree search: The SELECT DISTINCT statements are NOT the same. In both cases, testing was done with a base DN like:
ou=Unit2,dc=company,dc=com
Users use a base DN like this to isolate their directory entries to a particular company Unit.
In 2.2.13, the result is:
Mar 21 17:30:12 apps slapd[11205]: ==>backsql_oc_get_candidates(): oc="organizationalUnit" Mar 21 17:30:12 apps slapd[11205]: ==>backsql_srch_query() Mar 21 17:30:12 apps slapd[11205]: ==>backsql_process_filter() Mar 21 17:30:12 apps slapd[11205]: <==backsql_process_filter() succeeded Mar 21 17:30:12 apps slapd[11205]: <==backsql_srch_query() returns SELECT DISTINCT ldap_entries.id,ou.id,'organizationalUnit' AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,ou WHERE ou.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND ldap_entries.dn LIKE ? AND 1=1 Mar 21 17:30:12 apps slapd[11205]: Constructed query: SELECT DISTINCT ldap_entries.id,ou.id,'organizationalUnit' AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,ou WHERE ou.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND ldap_entries.dn LIKE ? AND 1=1 Mar 21 17:30:12 apps slapd[11205]: id: '2' Mar 21 17:30:12 apps slapd[11205]: (sub)dn: "%ou=Unit2,dc=company,dc=com" Mar 21 17:30:12 apps slapd[11205]: backsql_oc_get_candidates(): added entry id=2, keyval=3 dn="ou=Unit2,dc=company,dc=com" Mar 21 17:30:12 apps slapd[11205]: <==backsql_oc_get_candidates(): 1
In 2.3.27, the result is:
Mar 21 17:33:38 db slapd[7350]: ==>backsql_oc_get_candidates(): oc="organizationalUnit" Mar 21 17:33:38 db slapd[7350]: ==>backsql_srch_query() Mar 21 17:33:38 db slapd[7350]: ==>backsql_process_filter() Mar 21 17:33:38 db slapd[7350]: <==backsql_process_filter() succeeded Mar 21 17:33:38 db slapd[7350]: <==backsql_srch_query() returns SELECT DISTINCT ldap_entries.id,ou.id,'organizationalUnit' AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,ou WHERE ou.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND 9=9 AND 3=3 Mar 21 17:33:38 db slapd[7350]: Constructed query: SELECT DISTINCT ldap_entries.id,ou.id,'organizationalUnit' AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,ou WHERE ou.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND 9=9 AND 3=3 Mar 21 17:33:38 db slapd[7350]: id: '2' Mar 21 17:33:38 db slapd[7350]: >>> dnPrettyNormal: <ou=Unit1,dc=company,dc=com> Mar 21 17:33:38 db slapd[7350]: <<< dnPrettyNormal: <ou=Unit1,dc=company,dc=com>, <ou=unit1,dc=company,dc=com> Mar 21 17:33:38 db slapd[7350]: backsql_oc_get_candidates(): added entry id=1, keyval=1 dn="ou=Unit1,dc=company,dc=com" Mar 21 17:33:38 db slapd[7350]: >>> dnPrettyNormal: <ou=Unit2,dc=company,dc=com> Mar 21 17:33:38 db slapd[7350]: <<< dnPrettyNormal: <ou=Unit2,dc=company,dc=com>, <ou=unit2,dc=company,dc=com> Mar 21 17:33:38 db slapd[7350]: backsql_oc_get_candidates(): added entry id=2, keyval=3 dn="ou=Unit2,dc=company,dc=com" Mar 21 17:33:38 db slapd[7350]: >>> dnPrettyNormal: <ou=Unit3,dc=company,dc=com> Mar 21 17:33:38 db slapd[7350]: <<< dnPrettyNormal: <ou=Unit3,dc=company,dc=com>, <ou=unit3,dc=company,dc=com> Mar 21 17:33:38 db slapd[7350]: backsql_oc_get_candidates(): added entry id=3, keyval=4 dn="ou=Unit3,dc=company,dc=com" Mar 21 17:33:38 db slapd[7350]: <==backsql_oc_get_candidates(): 3
In 2.2.13, openLDAP isolated the ou to the specific one requested, while in 2.3.27, openLDAP is not testing for a specific ou and instead is getting all of them.
I would appreciate any help anyone can give to solve this issue. If more information is needed, please let me know.