ando@sys-net.it wrote:

ando@sys-net.it wrote:

...

quanah@zimbra.com wrote:

...

test_filter returned LDAP_INVALID_SYNTAX.

I think the culprit of the issue is here ^^^

...

| dn: cn=blank,o=Example | queryId: c975e84a-0e16-102d-8355-4be7c415200f | queryId: 9b7f1afa-0e17-102d-8bae-452c11e3ff2d | objectClass: inetOrgPerson | objectClass: organizationalPerson | objectClass: person | objectClass: ndsLoginProperties | objectClass: top

The backend server is a Novell eDirectory and the proxy don't have information about the complete schema.

I suspect the remote server is returning an objectClass that is unknown to the proxy; for example, ndsLoginProperties. So, not ours :)

I could reproduce the issue by caching an entry with an objectClass not known to the proxy :). So the "right" solution consists in fixing the proxy's schema. Of course, OpenLDAP could inform the proxy administrator with some intelligible message or, even better, try to repair itself (e.g. by checking the remote server's subschemaSubentry).

Probably not a good idea to do that automagically. Perhaps with a config switch. Also, not a good idea to import miscellaneous foreign schema globally; we should implement per-database schema instead.