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

Connect to update center via HTTP proxy that requires NTLM authentication

XMLWordPrintable

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major Major
    • plugin-proposals
    • None
    • Platform: All, OS: All

      Our company uses a proxy server that requires NTLM authentication for accessing the internet. We are running hudson on
      Windows XP.

      Even when I provide login and password in the "advanced" section of "manage plugins" I get:

      Preparation
      Checking internet connectivity
      Checking java.net connectivity
      java.io.IOException: Unable to tunnel through proxy. Proxy returns "HTTP/1.1 403 Forbidden" at
      sun.net.www.protocol.http.HttpURLConnection.doTunneling(HttpURLConnection.java:1472) at
      sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:164) at
      sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1026) at
      sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:234) at
      hudson.model.UpdateCenter$UpdateCenterConfiguration.testConnection(UpdateCenter.java:637) at
      hudson.model.UpdateCenter$UpdateCenterConfiguration.checkUpdateCenter(UpdateCenter.java:514) at
      hudson.model.UpdateCenter$ConnectionCheckJob.run(UpdateCenter.java:677) at
      java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at
      java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at
      java.util.concurrent.FutureTask.run(FutureTask.java:138) at
      java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at
      java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619)
      Cobertura Plugin
      Failure
      java.io.IOException: Unable to tunnel through proxy. Proxy returns "HTTP/1.1 403 Forbidden"
      at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
      at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
      at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
      at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
      at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1345)
      at java.security.AccessController.doPrivileged(Native Method)
      at sun.net.www.protocol.http.HttpURLConnection.getChainedException(HttpURLConnection.java:1339)
      at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:993)
      at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:234)
      at hudson.model.UpdateCenter$UpdateCenterConfiguration.download(UpdateCenter.java:563)
      at hudson.model.UpdateCenter$DownloadJob.run(UpdateCenter.java:754)
      at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
      at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
      at java.util.concurrent.FutureTask.run(FutureTask.java:138)
      at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
      at java.lang.Thread.run(Thread.java:619)
      Caused by: java.io.IOException: Unable to tunnel through proxy. Proxy returns "HTTP/1.1 403 Forbidden"
      at sun.net.www.protocol.http.HttpURLConnection.doTunneling(HttpURLConnection.java:1472)
      at
      sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:164)
      at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1026)
      at sun.net.www.protocol.http.HttpURLConnection.getHeaderField(HttpURLConnection.java:2107)
      at java.net.URLConnection.getHeaderFieldInt(URLConnection.java:579)
      at java.net.URLConnection.getContentLength(URLConnection.java:474)
      at sun.net.www.protocol.https.HttpsURLConnectionImpl.getContentLength(HttpsURLConnectionImpl.java:378)
      at hudson.model.UpdateCenter$UpdateCenterConfiguration.download(UpdateCenter.java:562)
      ... 7 more

      I have tried to prefix the login with the NT domain or not. It makes no difference. Googling around didn't provide any
      information about this issue. Someway hudson (java?) doesn't provide the right authentication information.

      Anyway we tried to deploy the same Hudson on Windows host where the logged user is allowed to access the internet through
      the proxy and it worked.

      Another interesting insight: we are running artifactory on the same host as the "failing" hudson. There you can provide
      login, password, and domain. In this case it works.

      So it seems that the issue is related in someway to the domain that seems not provided properly to the proxy server
      (BlueCoat).

      Any clues to push debugging further?

          [JENKINS-3350] Connect to update center via HTTP proxy that requires NTLM authentication

          jmborer created issue -

          jmborer added a comment -

          Java seems simply to ignore the login password provided for the proxy on
          Windows. I have no idea how to override this behavior except relying on third
          party libraries like jcifs or httpclient from Apache that provide their own
          implementation.

          jmborer added a comment - Java seems simply to ignore the login password provided for the proxy on Windows. I have no idea how to override this behavior except relying on third party libraries like jcifs or httpclient from Apache that provide their own implementation.

          Alan Harder added a comment -
              • Issue 3351 has been marked as a duplicate of this issue. ***

          Alan Harder added a comment - Issue 3351 has been marked as a duplicate of this issue. ***
          Alan Harder made changes -
          Link New: This issue is duplicated by JENKINS-3351 [ JENKINS-3351 ]

          Alan Harder added a comment -
              • Issue 3352 has been marked as a duplicate of this issue. ***

          Alan Harder added a comment - Issue 3352 has been marked as a duplicate of this issue. ***
          Alan Harder made changes -
          Link New: This issue is duplicated by JENKINS-3352 [ JENKINS-3352 ]

          leo682 added a comment -

          Hi All,

          Any progress on this issue? I run into this issue even I running a 1.6.0_16
          version of Java.

          leo682 added a comment - Hi All, Any progress on this issue? I run into this issue even I running a 1.6.0_16 version of Java.

          Alan Harder added a comment -

          The Hudson "ProxyConfiguration" class does mention NTLM, but perhaps it supports
          only v1 and not v2 (just guessing).. the only way I've worked with v2 before is
          using jcifs and apache httpclient4, as mentioned above.

          You can see the code in Hudson here:
          https://hudson.dev.java.net/source/browse/hudson/trunk/hudson/main/core/src/main/java/hudson/ProxyConfiguration.java?view=markup
          (scroll down to the open(URL url) method)

          If you can suggest any changes here to work better with NTLM, let us know.

          Alan Harder added a comment - The Hudson "ProxyConfiguration" class does mention NTLM, but perhaps it supports only v1 and not v2 (just guessing).. the only way I've worked with v2 before is using jcifs and apache httpclient4, as mentioned above. You can see the code in Hudson here: https://hudson.dev.java.net/source/browse/hudson/trunk/hudson/main/core/src/main/java/hudson/ProxyConfiguration.java?view=markup (scroll down to the open(URL url) method) If you can suggest any changes here to work better with NTLM, let us know.

          Richard Bywater added a comment -

          We have a similar setup except that we run Hudson as a Windows service running as a domain user. This seems to work. If you run Windows service as a system account and specify the username and password then it does not work.

          Don't know if this helps or not...

          Richard Bywater added a comment - We have a similar setup except that we run Hudson as a Windows service running as a domain user. This seems to work. If you run Windows service as a system account and specify the username and password then it does not work. Don't know if this helps or not...

          mdonohue added a comment -

          Also see similar issue JENKINS-1833

          mdonohue added a comment - Also see similar issue JENKINS-1833

            Unassigned Unassigned
            jmborer jmborer
            Votes:
            10 Vote for this issue
            Watchers:
            11 Start watching this issue

              Created:
              Updated: