external ldap auth against Sun DSEE

[seriv]

I have problem configuring Zimbra-4.5.8 GA on Centos5 to authenticate users against Sun Directory Server (DSEE).
I have configured according to LDAP Authentication - Zimbra :: Wiki and have DSEE filled with users and groups. I can use /opt/zimbra/openldap/ldapsearch to test authentication of the users, like:
---
/opt/zimbra/bin/ldapsearch -h 192.168.1.203 -x -D 'uid=seriv,ou=people,dc=outspark,dc=com' -w'testing' -b 'ou=people,dc=outspark,dc=com' '(uid=seriv)' '*' -LLL
dn: uid=seriv,ou=People,dc=outspark,dc=com
uid: seriv
cn: seriv
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
shadowLastChange: 13803
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 505
gidNumber: 506
homeDirectory: /home/seriv
---
But when I'm trying to test authentication, I'm getting java error message window with the following text:
---
javax.naming.directory.InvalidSearchFilterExceptio n: Missing 'equals'; remaining name 'ou=People,dc=outspark,dc=com'
at com.sun.jndi.ldap.Filter.encodeSimpleFilter(Filter .java:305)
at com.sun.jndi.ldap.Filter.encodeFilter(Filter.java: 151)
at com.sun.jndi.ldap.Filter.encodeFilterString(Filter .java:55)
at com.sun.jndi.ldap.LdapClient.search(LdapClient.jav a:520)
at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:19 48)
at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1 810)
at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:17 35)
at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_sea rch(ComponentDirContext.java:368)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContex t.search(PartialCompositeDirContext.java:338)
at javax.naming.directory.InitialDirContext.search(In itialDirContext.java:257)
at com.zimbra.cs.account.ldap.LdapUtil.searchDir(Ldap Util.java:1005)
at com.zimbra.cs.account.ldap.LdapUtil.ldapAuthentica te(LdapUtil.java:268)
at com.zimbra.cs.account.ldap.Check.checkAuthConfig(C heck.java:142)
at com.zimbra.cs.service.admin.CheckAuthConfig.handle (CheckAuthConfig.java:43)
at com.zimbra.soap.SoapEngine.dispatchRequest(SoapEng ine.java:266)
at com.zimbra.soap.SoapEngine.dispatch(SoapEngine.jav a:163)
at com.zimbra.soap.SoapEngine.dispatch(SoapEngine.jav a:85)
at com.zimbra.soap.SoapServlet.doPost(SoapServlet.jav a:220)
at javax.servlet.http.HttpServlet.service(HttpServlet .java:709)
at com.zimbra.cs.servlet.ZimbraServlet.service(Zimbra Servlet.java:152)
at javax.servlet.http.HttpServlet.service(HttpServlet .java:802)
at org.apache.catalina.core.ApplicationFilterChain.in ternalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.do Filter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invo ke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invo ke(StandardContextValve.java:178)
at org.apache.catalina.core.StandardHostValve.invoke( StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invok e(StandardEngineValve.java:107)
at org.apache.catalina.valves.AccessLogValve.invoke(A ccessLogValve.java:541)
at org.apache.catalina.connector.CoyoteAdapter.servic e(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(H ttp11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11 ConnectionHandler.processConnection(Http11BaseProt ocol.java:667)
at org.apache.tomcat.util.net.PoolTcpEndpoint.process Socket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThr ead.runIt(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlR unnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:619)
---
This seems to me as an error in zimbra collaboration suite.
If I switch to binding with administrator's bind DN, the message looks the same.
In Sun's DS log I see only attempts to connect, like:
---
[23/Oct/2007:11:04:27 -0700] conn=41 op=-1 msgId=-1 - fd=14 slot=14 LDAP connection from 192.168.1.203:50671 to 192.168.1.203
---
and sometimes - successfull binding.
--
WBR,
Sergey Ivanov