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.