Results 1 to 3 of 3

Thread: external LDAP authentication: TLS negotiation failure

  1. #1
    Join Date
    Jun 2010
    Posts
    17
    Rep Power
    5

    Default external LDAP authentication: TLS negotiation failure

    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

  2. #2
    Join Date
    Jun 2010
    Posts
    17
    Rep Power
    5

    Exclamation where to configure TLS cipher suite?

    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

  3. #3
    Join Date
    Jun 2010
    Posts
    17
    Rep Power
    5

    Default

    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?

Similar Threads

  1. External LDAP Authentication Load Balancing
    By jrparrish in forum Administrators
    Replies: 0
    Last Post: 09-19-2007, 08:40 AM
  2. 3 testing: LDAP: 389 Failed when restore zimbra
    By victorLeong in forum Administrators
    Replies: 15
    Last Post: 05-24-2007, 06:45 AM
  3. External LDAP Authentication
    By samdm in forum Administrators
    Replies: 3
    Last Post: 12-20-2006, 08:01 AM
  4. ldap external authentication
    By tdi in forum Administrators
    Replies: 2
    Last Post: 10-21-2006, 04:53 AM
  5. Replies: 5
    Last Post: 08-03-2006, 01:21 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •