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

      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)

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

          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.

          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.

          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.

          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.

          Jolly E added a comment -

          Can anybody help me with this?

          Jolly E added a comment - Can anybody help me with this?

          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)

          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)

          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.

          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.

          jnrg, 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.

          Kohsuke Kawaguchi added a comment - jnrg , 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.

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

              Created:
              Updated: