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.