Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-13677

Active Direcoty Plugin not encrypted - FINE: Failed to start TLS. Authentication will be done via plain-text LDAP

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      FINE: Failed to start TLS. Authentication will be done via plain-text LDAP
      javax.naming.CommunicationException: Remote host closed connection during handshake [Root exception is javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake]
      at com.sun.jndi.ldap.LdapCtx.extendedOperation(LdapCtx.java:3204)
      at hudson.plugins.active_directory.ActiveDirectorySecurityRealm$DesciprotrImpl.bind(ActiveDirectorySecurityRealm.java:400)
      at hudson.plugins.active_directory.ActiveDirectorySecurityRealm$DesciprotrImpl.bind(ActiveDirectorySecurityRealm.java:357)
      at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:275)
      at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:180)
      at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:133)
      at org.acegisecurity.providers.dao.AbstractUserDetailsAuthenticationProvider.authenticate(AbstractUserDetailsAuthenticationProvider.java:119)
      at org.acegisecurity.providers.ProviderManager.doAuthentication(ProviderManager.java:195)
      at org.acegisecurity.AbstractAuthenticationManager.authenticate(AbstractAuthenticationManager.java:45)
      at org.acegisecurity.ui.webapp.AuthenticationProcessingFilter.attemptAuthentication(AuthenticationProcessingFilter.java:71)
      at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:252)
      at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
      at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173)
      at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
      at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:63)
      at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
      at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249)
      at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:66)
      at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
      at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
      at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
      at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
      at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
      at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81)
      at winstone.FilterConfiguration.execute(FilterConfiguration.java:194)
      at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366)
      at winstone.RequestDispatcher.forward(RequestDispatcher.java:331)
      at winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:215)
      at winstone.RequestHandlerThread.run(RequestHandlerThread.java:138)
      at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
      at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
      at java.util.concurrent.FutureTask.run(FutureTask.java:166)
      at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
      at java.lang.Thread.run(Thread.java:679)
      Caused by: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
      at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:869)
      at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1190)
      at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:657)
      at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:108)
      at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
      at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
      at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:409)
      at com.sun.jndi.ldap.LdapClient.extendedOp(LdapClient.java:1190)
      at com.sun.jndi.ldap.LdapCtx.extendedOperation(LdapCtx.java:3151)
      ... 35 more
      Caused by: java.io.EOFException: SSL peer shut down incorrectly
      at sun.security.ssl.InputRecord.read(InputRecord.java:352)
      at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:850)

        Attachments

          Issue Links

            Activity

            Hide
            kohsuke Kohsuke Kawaguchi added a comment -

            Is the server actually configured for LDAPS? That involves setting a certificate and etc.

            This seems like the server just isn't configured for it.

            Show
            kohsuke Kohsuke Kawaguchi added a comment - Is the server actually configured for LDAPS? That involves setting a certificate and etc. This seems like the server just isn't configured for it.
            Hide
            jolly_e Jolly E added a comment -

            Yes. I use LDAPS for other systems authenticating against the same directory. I just haven't been able to find documentation about how to make the active directory plugin recognize the ssl certificates that encrypt it. I added the certs to the keystore that does the ssl encryption for the jenkins ( --httpsPort=8443 --httpsKeyStore=/var/lib/jenkins/.keystore --httpsKeyStorePassword=******* ) as well as to the /etc/pki/java/cacerts keystore.

            Show
            jolly_e Jolly E added a comment - Yes. I use LDAPS for other systems authenticating against the same directory. I just haven't been able to find documentation about how to make the active directory plugin recognize the ssl certificates that encrypt it. I added the certs to the keystore that does the ssl encryption for the jenkins ( --httpsPort=8443 --httpsKeyStore=/var/lib/jenkins/.keystore --httpsKeyStorePassword=******* ) as well as to the /etc/pki/java/cacerts keystore.
            Hide
            jolly_e Jolly E added a comment -

            Can anybody help me with this?

            Show
            jolly_e Jolly E added a comment - Can anybody help me with this?
            Hide
            jnrg Julien R. added a comment - - edited

            Same issue here :
            Domain controller : ldap1.acme.com:3268
            user & pass works fine (no anonymous bind on our server)

            Domain controller : ldap1.acme.com:3269

            error:
            "Bad bind username or password"

            It is misleading, after enabling ALL logging for the plugin, got :

            Nov 1, 2012 7:04:01 PM hudson.plugins.active_directory.ActiveDirectorySecurityRealm
            FINE: Binding as DOMAIN\ldapauth to ldap://ldap1.acme.coms:3269/
            Nov 1, 2012 7:04:01 PM hudson.plugins.active_directory.ActiveDirectorySecurityRealm
            FINE: Failed to start TLS. Authentication will be done via plain-text LDAP

            One thing that puzzles me is the "to ldap://ldap1.acme.coms:3269/" it doesn't seem to even attempt to use ssl (was expecting 'to ldaps://ldap1.acme.com:3269'

            Our certificate are self signed but I'm imported the certificate (I see it in the keystore list)

            Show
            jnrg Julien R. added a comment - - edited Same issue here : Domain controller : ldap1.acme.com:3268 user & pass works fine (no anonymous bind on our server) Domain controller : ldap1.acme.com:3269 error: "Bad bind username or password" It is misleading, after enabling ALL logging for the plugin, got : Nov 1, 2012 7:04:01 PM hudson.plugins.active_directory.ActiveDirectorySecurityRealm FINE: Binding as DOMAIN\ldapauth to ldap://ldap1.acme.coms:3269/ Nov 1, 2012 7:04:01 PM hudson.plugins.active_directory.ActiveDirectorySecurityRealm FINE: Failed to start TLS. Authentication will be done via plain-text LDAP One thing that puzzles me is the "to ldap://ldap1.acme.coms:3269/" it doesn't seem to even attempt to use ssl (was expecting 'to ldaps://ldap1.acme.com:3269' Our certificate are self signed but I'm imported the certificate (I see it in the keystore list)
            Hide
            kohsuke Kohsuke Kawaguchi added a comment -

            http://www.zimbra.com/forums/administrators/41167-external-ldap-authentication-tls-negotiation-failure.html mentions an interesting data point for SSLHandshakeException: Remote host closed connection during handshake that the negotiation has failed due to a cipher suite:

            TLS: can't accept: Could not negotiate a supported cipher suite..
            

            In the cited case, this was because the server demands AES-256-CBC but the Java client is demanding AES-128-CBC (presumably because 256bit requires JCE unlimited strength jurisdiction policy files.) If anyone has managed to fix this by either tweak the server to accept 128bit AES or installed JCE policy file, please share it.

            Show
            kohsuke Kohsuke Kawaguchi added a comment - http://www.zimbra.com/forums/administrators/41167-external-ldap-authentication-tls-negotiation-failure.html mentions an interesting data point for SSLHandshakeException: Remote host closed connection during handshake that the negotiation has failed due to a cipher suite: TLS: can't accept: Could not negotiate a supported cipher suite.. In the cited case, this was because the server demands AES-256-CBC but the Java client is demanding AES-128-CBC (presumably because 256bit requires JCE unlimited strength jurisdiction policy files.) If anyone has managed to fix this by either tweak the server to accept 128bit AES or installed JCE policy file, please share it.
            Hide
            kohsuke Kohsuke Kawaguchi added a comment -

            Julien R., I don't think your issue is the same.

            This ticket deals with the inability to use TLS, but the authentication is still successful after falling back to the plain text LDAP. In your case, in addition to failing to negotiate TLS, it's failing to authenticate. That needs to be a separate ticket.

            Show
            kohsuke Kohsuke Kawaguchi added a comment - Julien R. , I don't think your issue is the same. This ticket deals with the inability to use TLS, but the authentication is still successful after falling back to the plain text LDAP. In your case, in addition to failing to negotiate TLS, it's failing to authenticate. That needs to be a separate ticket.

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              jolly_e Jolly E
              Votes:
              5 Vote for this issue
              Watchers:
              10 Start watching this issue

                Dates

                Created:
                Updated: