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

Connect to update center via HTTP proxy that requires NTLM authentication

    Details

    • Type: Improvement
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: plugin-proposals
    • Labels:
      None
    • Environment:
      Platform: All, OS: All
    • Similar Issues:

      Description

      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?

        Attachments

          Issue Links

            Activity

            Hide
            mdonohue mdonohue added a comment -

            Also see similar issue JENKINS-1833

            Show
            mdonohue mdonohue added a comment - Also see similar issue JENKINS-1833
            Hide
            jmborer jmborer added a comment -

            I have a little more knowledge now how all the proxy stuff works in Java:

            Hudson uses the proxy authentication of the Java JVM. The latter implements the NTLM authentication scheme. However it uses the Windows credentials of the process. So by default it uses the login profile if you don't specify one. This means what ever you provide as login and password for the proxy authentication, when your are on Windows and NTLM authentication is required, the JVM will provide the credentials of the process and ignore what you provide.

            Artifactory relies on a third party library (HTTPClient) for all its HTTP connection related stuff. This means the JVM authentication is bypassed and the third party proxy authentication is used. HTTPClient has a NTLM v1 implementation and partial but anyway working NTLM v2 implementation. In this case the credentials you provide will be used and not those of the JVM.

            Which one is the best to use. Well it depends on the context. HTTPClient might be more flexible (in my case for example) because I cannot run a process under an identity that has proxy access. Moreover you can run your process on a non Windows host. However your NTLM v2 proxy is fully supported by the JVM and may not work with HTTPClient. Then you must deploy on Windows...

            Show
            jmborer jmborer added a comment - I have a little more knowledge now how all the proxy stuff works in Java: Hudson uses the proxy authentication of the Java JVM. The latter implements the NTLM authentication scheme. However it uses the Windows credentials of the process. So by default it uses the login profile if you don't specify one. This means what ever you provide as login and password for the proxy authentication, when your are on Windows and NTLM authentication is required, the JVM will provide the credentials of the process and ignore what you provide. Artifactory relies on a third party library (HTTPClient) for all its HTTP connection related stuff. This means the JVM authentication is bypassed and the third party proxy authentication is used. HTTPClient has a NTLM v1 implementation and partial but anyway working NTLM v2 implementation. In this case the credentials you provide will be used and not those of the JVM. Which one is the best to use. Well it depends on the context. HTTPClient might be more flexible (in my case for example) because I cannot run a process under an identity that has proxy access. Moreover you can run your process on a non Windows host. However your NTLM v2 proxy is fully supported by the JVM and may not work with HTTPClient. Then you must deploy on Windows...
            Hide
            ultra99 Matthew O'Connell added a comment -

            Yes, I look to have the same issue, we are running Jenkins as a windows service on a virtualised Win2008 server and get the following when we try to do any updates - even after supplying the proxy details in the advanced tab (we have configured proxy exactly as it is setup in IE internet options, and the username provided is the same domain user that the service runs under - this user has proxy access, surfing the web from the server works when logged in as this user):

            Checking internet connectivity
            Checking update center connectivity
            java.io.IOException: Authentication failure at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) at hudson.model.UpdateCenter$UpdateCenterConfiguration.testConnection(UpdateCenter.java:737) at hudson.model.UpdateCenter$UpdateCenterConfiguration.checkUpdateCenter(UpdateCenter.java:586) at hudson.model.UpdateCenter$ConnectionCheckJob.run(UpdateCenter.java:884) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source)

            I see this issue on StackOverflow saying to supply parms to the JRE directly when starting Jenkins, but am unsure as to how we could do this with the windows service setup - in any case from the comment above, it sounds as if it should work when the service user has proxy access:

            http://stackoverflow.com/questions/1975564/how-can-i-get-hudson-to-update-through-proxy

            Show
            ultra99 Matthew O'Connell added a comment - Yes, I look to have the same issue, we are running Jenkins as a windows service on a virtualised Win2008 server and get the following when we try to do any updates - even after supplying the proxy details in the advanced tab (we have configured proxy exactly as it is setup in IE internet options, and the username provided is the same domain user that the service runs under - this user has proxy access, surfing the web from the server works when logged in as this user): Checking internet connectivity Checking update center connectivity java.io.IOException: Authentication failure at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) at hudson.model.UpdateCenter$UpdateCenterConfiguration.testConnection(UpdateCenter.java:737) at hudson.model.UpdateCenter$UpdateCenterConfiguration.checkUpdateCenter(UpdateCenter.java:586) at hudson.model.UpdateCenter$ConnectionCheckJob.run(UpdateCenter.java:884) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) I see this issue on StackOverflow saying to supply parms to the JRE directly when starting Jenkins, but am unsure as to how we could do this with the windows service setup - in any case from the comment above, it sounds as if it should work when the service user has proxy access: http://stackoverflow.com/questions/1975564/how-can-i-get-hudson-to-update-through-proxy
            Hide
            kohsuke Kohsuke Kawaguchi added a comment -

            Updating the title. The problem is in the NTLM authentication. Basic auth works fine.

            Show
            kohsuke Kohsuke Kawaguchi added a comment - Updating the title. The problem is in the NTLM authentication. Basic auth works fine.
            Hide
            ton_tanasin Tanasin Vivitvorn added a comment -

            I just follow suggestion in https://issues.jenkins-ci.org/browse/JENKINS-32293 by modify start command as below but I still got the error.

            my start command
            java jar jenkins.war -Djava.net.useSystemProxies=true --httpPort=9999 --logfile=logs/winstone_`date +"%Y%m-%d_%H-%M"`.log &

            This is an error.

            Feb 17, 2016 4:57:47 PM INFO org.apache.commons.httpclient.HttpMethodDirector processProxyAuthChallenge

            Failure authenticating with NTLM <any realm>@172.31.250.200:8080

            Feb 17, 2016 4:58:08 PM INFO org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme

            ntlm authentication scheme selected

            Feb 17, 2016 4:58:08 PM SEVERE org.apache.commons.httpclient.HttpMethodDirector authenticate

            Credentials cannot be used for NTLM authentication: org.apache.commons.httpclient.UsernamePasswordCredentials
            org.apache.commons.httpclient.auth.InvalidCredentialsException: Credentials cannot be used for NTLM authentication: org.apache.commons.httpclient.UsernamePasswordCredentials

            Show
            ton_tanasin Tanasin Vivitvorn added a comment - I just follow suggestion in https://issues.jenkins-ci.org/browse/JENKINS-32293 by modify start command as below but I still got the error. my start command java jar jenkins.war -Djava.net.useSystemProxies=true --httpPort=9999 --logfile=logs/winstone_`date +"%Y %m-%d_%H-%M"`.log & This is an error. Feb 17, 2016 4:57:47 PM INFO org.apache.commons.httpclient.HttpMethodDirector processProxyAuthChallenge Failure authenticating with NTLM <any realm>@172.31.250.200:8080 Feb 17, 2016 4:58:08 PM INFO org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme ntlm authentication scheme selected Feb 17, 2016 4:58:08 PM SEVERE org.apache.commons.httpclient.HttpMethodDirector authenticate Credentials cannot be used for NTLM authentication: org.apache.commons.httpclient.UsernamePasswordCredentials org.apache.commons.httpclient.auth.InvalidCredentialsException: Credentials cannot be used for NTLM authentication: org.apache.commons.httpclient.UsernamePasswordCredentials

              People

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

                Dates

                • Created:
                  Updated: