external LDAP authentication: TLS negotiation failure

[dgsohard]

We are running a zimbra 6.0.7 pilot testing whether we can deploy zimbra for production in our company.

At the moment I encounter the following problem:

We have an external LDAP server, which works fine for Apache and Samba user authentication and I want to integrate it with zimbra.

Therefore I go to configuration / Domains and use the "Configure Authentication" wizard in the Admin web UI.
The authentication mechanism is "external LDAP".

In the settings I activate TLS and provide a bind DNS with password.

When I test the configuration with a valid user I get the following error message:

javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRec ord(SSLSocketImpl.java:808)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.perform InitialHandshake(SSLSocketImpl.java:1112)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHa ndshake(SSLSocketImpl.java:1139)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHa ndshake(SSLSocketImpl.java:1123)
at com.sun.jndi.ldap.ext.StartTlsResponseImpl.startHa ndshake(StartTlsResponseImpl.java:344)
at com.sun.jndi.ldap.ext.StartTlsResponseImpl.negotia te(StartTlsResponseImpl.java:208)
at com.sun.jndi.ldap.ext.StartTlsResponseImpl.negotia te(StartTlsResponseImpl.java:161)
at com.zimbra.cs.account.ldap.ZimbraLdapContext.tlsNe gotiate(ZimbraLdapContext.java:359)
at com.zimbra.cs.account.ldap.ZimbraLdapContext.<init >(ZimbraLdapContext.java:488)
at com.zimbra.cs.account.ldap.ZimbraLdapContext.<init >(ZimbraLdapContext.java:422)
at com.zimbra.cs.account.ldap.LdapUtil.ldapAuthentica te(LdapUtil.java:120)
at com.zimbra.cs.account.ldap.Check.checkAuthConfig(C heck.java:168)
at com.zimbra.cs.service.admin.CheckAuthConfig.handle (CheckAuthConfig.java:53)
at com.zimbra.soap.SoapEngine.dispatchRequest(SoapEng ine.java:420)
at com.zimbra.soap.SoapEngine.dispatch(SoapEngine.jav a:274)
at com.zimbra.soap.SoapEngine.dispatch(SoapEngine.jav a:158)
at com.zimbra.soap.SoapServlet.doWork(SoapServlet.jav a:291)
at com.zimbra.soap.SoapServlet.doPost(SoapServlet.jav a:212)
at javax.servlet.http.HttpServlet.service(HttpServlet .java:727)
at com.zimbra.cs.servlet.ZimbraServlet.service(Zimbra Servlet.java:181)
at javax.servlet.http.HttpServlet.service(HttpServlet .java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(Ser vletHolder.java:511)
at org.mortbay.jetty.servlet.ServletHandler$CachedCha in.doFilter(ServletHandler.java:1166)
at com.zimbra.cs.servlet.SetHeaderFilter.doFilter(Set HeaderFilter.java:79)
at org.mortbay.jetty.servlet.ServletHandler$CachedCha in.doFilter(ServletHandler.java:1157)
at org.mortbay.servlet.UserAgentFilter.doFilter(UserA gentFilter.java:81)
at org.mortbay.servlet.GzipFilter.doFilter(GzipFilter .java:132)
at org.mortbay.jetty.servlet.ServletHandler$CachedCha in.doFilter(ServletHandler.java:1157)
at org.mortbay.jetty.servlet.ServletHandler.handle(Se rvletHandler.java:388)
at org.mortbay.jetty.security.SecurityHandler.handle( SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(Se ssionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(Co ntextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebA ppContext.java:418)
at org.mortbay.jetty.handler.ContextHandlerCollection .handle(ContextHandlerCollection.java:230)
at org.mortbay.jetty.handler.HandlerCollection.handle (HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(Ha ndlerWrapper.java:152)
at org.mortbay.jetty.handler.rewrite.RewriteHandler.h andle(RewriteHandler.java:230)
at org.mortbay.jetty.handler.HandlerWrapper.handle(Ha ndlerWrapper.java:152)
at org.mortbay.jetty.handler.DebugHandler.handle(Debu gHandler.java:77)
at org.mortbay.jetty.handler.HandlerWrapper.handle(Ha ndlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(Htt pConnection.java:543)
at org.mortbay.jetty.HttpConnection$RequestHandler.co ntent(HttpConnection.java:939)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser. java:755)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpPa rser.java:218)
at org.mortbay.jetty.HttpConnection.handle(HttpConnec tion.java:405)
at org.mortbay.io.nio.SelectChannelEndPoint.run(Selec tChannelEndPoint.java:409)
at org.mortbay.thread.BoundedThreadPool$PoolThread.ru n(BoundedThreadPool.java:451)
Caused by: java.io.EOFException: SSL peer shut down incorrectly
at com.sun.net.ssl.internal.ssl.InputRecord.read(Inpu tRecord.java:333)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRec ord(SSLSocketImpl.java:789)
... 47 more



On the LDAP side (it is an openLDAP system) I find the following in the log file:

Jun 23 19:11:13 xxx slapd[965]: conn=1107 fd=20 ACCEPT from IP=192.168.144.82:46312 (IP=0.0.0.0:389)
Jun 23 19:11:13 xxx slapd[965]: conn=1107 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jun 23 19:11:13 xxx slapd[965]: conn=1107 op=0 STARTTLS
Jun 23 19:11:13 xxx slapd[965]: conn=1107 op=0 RESULT oid= err=0 text=
Jun 23 19:11:13 xxx slapd[965]: conn=1107 fd=20 closed (TLS negotiation failure)


What could be the problem?


Regards,

Detlef Grittner

[dgsohard]

Now I have some more debug information and it seems that the TLS cipher suite, which Zimbra uses, could be the problem.

Can someone tell me where I can view and configure the TLS cipher suite for LDAP access in Zimbra?


This is the cipher suite on the external LDAP (gnuTLS notation)
cn=config.ldif: olcTLSCipherSuite: +RSA:+AES-256-CBC:+SHA1


Here the debug output of the external LDAP, when connecting from Zimbra:

daemon: listen=7, new connection on 13
daemon: added 13r (active) listener=(nil)
daemon: activity on 1 descriptor
daemon: activity on:
daemon: epoll: listen=7 active_threads=0 tvp=zero
daemon: epoll: listen=8 active_threads=0 tvp=zero
daemon: activity on 1 descriptor
daemon: activity on: 13r
daemon: read active on 13
daemon: epoll: listen=7 active_threads=0 tvp=zero
daemon: epoll: listen=8 active_threads=0 tvp=zero
connection_get(13): got connid=1001
connection_read(13): checking for input on id=1001
ber_get_next
ber_get_next: tag 0x30 len 29 contents:
op tag 0x77, time 1277383235
ber_get_next
conn=1001 op=0 do_extended
ber_scanf fmt ({m) ber:
send_ldap_extended: err=0 oid= len=0
send_ldap_response: msgid=1 tag=120 err=0
ber_flush2: 14 bytes to sd 13
daemon: activity on 1 descriptor
daemon: activity on:
daemon: epoll: listen=7 active_threads=0 tvp=zero
daemon: epoll: listen=8 active_threads=0 tvp=zero
daemon: activity on 1 descriptor
daemon: activity on: 13r
daemon: read active on 13
daemon: epoll: listen=7 active_threads=0 tvp=zero
daemon: epoll: listen=8 active_threads=0 tvp=zero
connection_get(13): got connid=1001
connection_read(13): checking for input on id=1001
TLS: can't accept: Could not negotiate a supported cipher suite..
connection_read(13): TLS accept failure error=-1 id=1001, closing
connection_closing: readying conn=1001 sd=13 for close
connection_close: conn=1001 sd=13
daemon: removing 13
daemon: activity on 1 descriptor
daemon: activity on:
daemon: epoll: listen=7 active_threads=0 tvp=zero
daemon: epoll: listen=8 active_threads=0 tvp=zero

[dgsohard]

It is definitively the cipher suite, because adding +AES-128-CBC to the LDAP configuration actually solves the negotiation problem.

But I'm not yet satisfied, because I am not happy about weakening encryption only for Zimbra.

The weaker cipher could be related to a Java problem, if Zimbra uses Java for the LDAP authentication.


Maybe I should ask about this in the developer forum?