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

Automatic Usage of SSL after Upgrading to 1.17

    XMLWordPrintable

Details

    Description

      Hudson must not use LDAPS by default - i.e. our active directory system does not provide
      LDAPS. My windows admins opened the port but did not provide ldap via SSL....

      This reders hudson unusable - any ideas for a workaround?

      WARNUNG: Failed to bind to foobar-l02-dc01.foobar.local:3269
      javax.naming.CommunicationException: simple bind failed: foobar-l02-dc01.foobar.local:3269 [Root exception is javax.net.ssl.SSLException: java.net.SocketException: Connection reset]
      at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:197)
      at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2694)
      at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:293)
      at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:175)
      at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:134)
      at hudson.plugins.active_directory.ActiveDirectorySecurityRealm$DesciprotrImpl.bind(ActiveDirectorySecurityRealm.java:281)
      at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:135)
      at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:109)
      at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:75)
      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 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:195)
      at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:368)
      at winstone.RequestDispatcher.forward(RequestDispatcher.java:333)
      at winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:244)
      at winstone.RequestHandlerThread.run(RequestHandlerThread.java:150)
      at java.lang.Thread.run(Thread.java:619)
      Caused by: javax.net.ssl.SSLException: java.net.SocketException: Connection reset
      at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
      at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1623)
      at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1586)
      at com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1550)
      at com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1495)
      at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:86)
      at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
      at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
      at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
      at com.sun.jndi.ldap.Connection.run(Connection.java:808)
      ... 1 more
      Caused by: java.net.SocketException: Connection reset
      at java.net.SocketInputStream.read(SocketInputStream.java:168)
      at com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293)
      at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331)
      at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:789)
      at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1120)
      at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:744)
      at com.sun.net.ssl.internal.ssl.AppInputStream.read(AppInputStream.java:75)
      ... 5 more

      Attachments

        Issue Links

          Activity

            rioch rioch added a comment -

            I also have this problem. The following instructions allow you to gain access to your hudson configuration and downgrade the plugin:

            1. Open ./hudson/.config.xml
            2. Change <useSecurity>true</useSecurity> to false
            3. Restart hudson
            4. Go to installed plugins and downgrade to 1.16
            5. Change <useSecurity>false</useSecurity> back to true
            6. Restart hudson

            rioch rioch added a comment - I also have this problem. The following instructions allow you to gain access to your hudson configuration and downgrade the plugin: 1. Open ./hudson/.config.xml 2. Change <useSecurity>true</useSecurity> to false 3. Restart hudson 4. Go to installed plugins and downgrade to 1.16 5. Change <useSecurity>false</useSecurity> back to true 6. Restart hudson

            Hmm, my understanding of the way AD works is that LDAPS is always on by default. But it must be that I'm wrong. Does anyone have a pointer about it?

            Would it be reasonable to try LDAPS first and then fall back to LDAP? Perhaps AD itself advertises whether there's a LDAPS port available and we should check that?

            The change is motivated by the security requirements from some users that the password don't hit the network unencrypted. So I don't want to just revert the change, and it seems to me that this is something that should just work automatically without requiring the user to configure whether he opts to LDAPS or not.

            kohsuke Kohsuke Kawaguchi added a comment - Hmm, my understanding of the way AD works is that LDAPS is always on by default. But it must be that I'm wrong. Does anyone have a pointer about it? Would it be reasonable to try LDAPS first and then fall back to LDAP? Perhaps AD itself advertises whether there's a LDAPS port available and we should check that? The change is motivated by the security requirements from some users that the password don't hit the network unencrypted. So I don't want to just revert the change, and it seems to me that this is something that should just work automatically without requiring the user to configure whether he opts to LDAPS or not.

            It is be good to try ssl by default and to fail if ssl is not available

            • users should be aware of a degraded
              ldap connection (automatic degradation to plain ldap might not be
              recognized be the user) .
              In my opinion the plugin should provide a configuration switch do
              disable ssl.

            It might also a good idea to provide a dialog to debug ldap-connectivity
            (do test-login, display attributes available for that user) to check
            if ldap connection is working as expected.

            scoopex Marc Schoechlin added a comment - It is be good to try ssl by default and to fail if ssl is not available users should be aware of a degraded ldap connection (automatic degradation to plain ldap might not be recognized be the user) . In my opinion the plugin should provide a configuration switch do disable ssl. It might also a good idea to provide a dialog to debug ldap-connectivity (do test-login, display attributes available for that user) to check if ldap connection is working as expected.
            kohsuke Kohsuke Kawaguchi added a comment - - edited

            Attached the proposed fix that connects to LDAP and then attempts StartTLS (to secure the connection.)

            If it fails (for example if the server doesn't have a certificate to make LDAPS possible), then the authentication continues with plain LDAP.

            kohsuke Kohsuke Kawaguchi added a comment - - edited Attached the proposed fix that connects to LDAP and then attempts StartTLS (to secure the connection.) If it fails (for example if the server doesn't have a certificate to make LDAPS possible), then the authentication continues with plain LDAP.

            It'd be great if the affected people can try out this proposed fix to report back so that I can feel more confident before posting a release.

            kohsuke Kohsuke Kawaguchi added a comment - It'd be great if the affected people can try out this proposed fix to report back so that I can feel more confident before posting a release.
            kohsuke Kohsuke Kawaguchi added a comment - Additional discussion about this issue in https://groups.google.com/d/topic/jenkinsci-dev/ZLMRDjBytAY/discussion
            kyran Kyran Lange added a comment -

            The proposed fix works for me.

            kyran Kyran Lange added a comment - The proposed fix works for me.
            bimargulies bimargulies added a comment - - edited

            Jenkins doesn't offer me a downgrade. Any chance of a release soon?

            I'm not entirely sure that I have the same problem; without a baseDN 'test' succeeds, with one it fails, and all authentication fails.

            bimargulies bimargulies added a comment - - edited Jenkins doesn't offer me a downgrade. Any chance of a release soon? I'm not entirely sure that I have the same problem; without a baseDN 'test' succeeds, with one it fails, and all authentication fails.
            slydog John Schleigh added a comment -

            The proposed fix solved the problem for me as well.

            slydog John Schleigh added a comment - The proposed fix solved the problem for me as well.
            acwwat Anthony Wat added a comment -

            I've also confirmed the fix on Jenkins 1.418. It would be appreciated if you could commit the fix soon. Thanks a bunch!

            acwwat Anthony Wat added a comment - I've also confirmed the fix on Jenkins 1.418. It would be appreciated if you could commit the fix soon. Thanks a bunch!
            acwwat Anthony Wat added a comment -

            Can the patch be committed into the next version of the plugin?

            acwwat Anthony Wat added a comment - Can the patch be committed into the next version of the plugin?

            Code changed in jenkins
            User: Kohsuke Kawaguchi
            Path:
            src/main/java/hudson/plugins/active_directory/ActiveDirectorySecurityRealm.java
            http://jenkins-ci.org/commit/active-directory-plugin/a0a130eb6ed978731e14313ba65f0be17e6253dd
            Log:
            [FIXED JENKINS-8132] Fixed a bug in TLS upgrade. Setting the socket factory kills the connection and the next time it tries to connect the client will attempt LDAPS.
            The server, expecting an LDAP (without S) connection, resets the connection, which results in "connection reset" error. All in all, it wasn't working as TLS.

            The correct way to specify the SSLSocketFactory is apparently to pass it to the negotiate method.

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: src/main/java/hudson/plugins/active_directory/ActiveDirectorySecurityRealm.java http://jenkins-ci.org/commit/active-directory-plugin/a0a130eb6ed978731e14313ba65f0be17e6253dd Log: [FIXED JENKINS-8132] Fixed a bug in TLS upgrade. Setting the socket factory kills the connection and the next time it tries to connect the client will attempt LDAPS. The server, expecting an LDAP (without S) connection, resets the connection, which results in "connection reset" error. All in all, it wasn't working as TLS. The correct way to specify the SSLSocketFactory is apparently to pass it to the negotiate method.

            Fixed and released in 1.21.

            kohsuke Kohsuke Kawaguchi added a comment - Fixed and released in 1.21.
            dogfood dogfood added a comment -

            Integrated in plugins_active-directory #39
            [FIXED JENKINS-8132] Fixed a bug in TLS upgrade. Setting the socket factory kills the connection and the next time it tries to connect the client will attempt LDAPS.

            Kohsuke Kawaguchi :
            Files :

            • src/main/java/hudson/plugins/active_directory/ActiveDirectorySecurityRealm.java
            dogfood dogfood added a comment - Integrated in plugins_active-directory #39 [FIXED JENKINS-8132] Fixed a bug in TLS upgrade. Setting the socket factory kills the connection and the next time it tries to connect the client will attempt LDAPS. Kohsuke Kawaguchi : Files : src/main/java/hudson/plugins/active_directory/ActiveDirectorySecurityRealm.java

            People

              Unassigned Unassigned
              scoopex Marc Schoechlin
              Votes:
              10 Vote for this issue
              Watchers:
              11 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: