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

Active Directory authentication for Subversion plugin fails

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Blocker Blocker
    • subversion-plugin
    • Windows Server 2008 R2, Jenkins installed as a service. Java version for Jenkins is 1.7.0.07-b11 (32 bit).

      We've set up SVNKit in our Jenkins instance to use JNA to collect credentials for SVN access by setting -Dsvnkit.http.ntlm=jna in jenkins.xml. This has been working perfectly until we tried to upgrade Jenkins to 1.586, when the Jenkins JNA implementation was bumped to jna 4.10. After that, we get an "E200015: No credential to try." error.
      The last working version was Jenkins 1.585 and subversion plugin 2.4.5. If I upgrade any of them, we get the error.

          [JENKINS-26158] Active Directory authentication for Subversion plugin fails

          Björn Olsson added a comment -

          Updated the summary and description.

          Björn Olsson added a comment - Updated the summary and description.

          Björn Olsson added a comment -

          I've done some more tests using the SVNKit property "svnkit.http.ntlm" of switching between ntlm implementations. I've tested "jna" (which works in jenkins 1.585 and subversion plugin 2.4.5), "java:apache" and "java:jcifs" (both give me the same "no credentials to try" error, regardless of the versions of Jenkins/subersion plugin installed).

          Björn Olsson added a comment - I've done some more tests using the SVNKit property "svnkit.http.ntlm" of switching between ntlm implementations. I've tested "jna" (which works in jenkins 1.585 and subversion plugin 2.4.5), "java:apache" and "java:jcifs" (both give me the same "no credentials to try" error, regardless of the versions of Jenkins/subersion plugin installed).

          Björn Olsson added a comment -

          I got suspicious on the NEGOTIATE part of the log, and started to investigate a little deeper; I believe the default order of the svnkit.http.methods list (i.e. where NTLM, Basic, Negotiate and igest are specified) must havee changed between svn plugin 2.4.5 and 2.5. When I explicitly set the order to NTLM,Negotiate,Basic,Digest (NTLM before Negotiate) it uses NTLM in the latest verison of svn plugin on jenkins 1.585. This does not, however, fix my issues with "no credential to try" in later versions of Jenkins. I just thought I should put up as much information here as I can find, to aid in the bug hunt.

          Björn Olsson added a comment - I got suspicious on the NEGOTIATE part of the log, and started to investigate a little deeper; I believe the default order of the svnkit.http.methods list (i.e. where NTLM, Basic, Negotiate and igest are specified) must havee changed between svn plugin 2.4.5 and 2.5. When I explicitly set the order to NTLM,Negotiate,Basic,Digest (NTLM before Negotiate) it uses NTLM in the latest verison of svn plugin on jenkins 1.585. This does not, however, fix my issues with "no credential to try" in later versions of Jenkins. I just thought I should put up as much information here as I can find, to aid in the bug hunt.

          ruiling huang added a comment -

          I found when I enable Basic Authentication only in SVN Server the error about "svn: E170001: Negotiate authentication failed: No valid credentials provided" disappeared, but if I enable both of Integrated Windows Authentication and enable Basic Authentication this error will happen. But I'm not sure why?

          ruiling huang added a comment - I found when I enable Basic Authentication only in SVN Server the error about "svn: E170001: Negotiate authentication failed: No valid credentials provided" disappeared, but if I enable both of Integrated Windows Authentication and enable Basic Authentication this error will happen. But I'm not sure why?

          Rafael Wolf added a comment -

          I have the same issue, any solutions ?

          Rafael Wolf added a comment - I have the same issue, any solutions ?

          Benny Prange added a comment -

          I'm having the same issue. My workaround is to use <exec> in ant and call svn directly from commandline. Eg:

           
          <exec executable="svn">
            <arg line="checkout --non-interactive --trust-server-cert --username ${svn.user} --password ${svn.psw} ${svn.url} ${param.dep.dest}" />
          </exec>
          

          Nevertheless I would love to see this bug fixed.

          Benny Prange added a comment - I'm having the same issue. My workaround is to use <exec> in ant and call svn directly from commandline. Eg: <exec executable= "svn" > <arg line= "checkout --non-interactive --trust-server-cert --username ${svn.user} --password ${svn.psw} ${svn.url} ${param.dep.dest}" /> </exec> Nevertheless I would love to see this bug fixed.

          I could solve a similar problem by setting the following JAVA option on jenkins startup:

          -Dsvnkit.http.methods=Basic,Digest,Negotiate,NTLM
          

          Andreas Schrell added a comment - I could solve a similar problem by setting the following JAVA option on jenkins startup: -Dsvnkit.http.methods=Basic,Digest,Negotiate,NTLM

          It seems this issue is duplicate. Take a look JENKINS-27084.

          Manuel Recena Soto added a comment - It seems this issue is duplicate. Take a look JENKINS-27084 .

          schristou, What do you think if we resolve this ticket as duplicated?

          Manuel Recena Soto added a comment - schristou , What do you think if we resolve this ticket as duplicated?

          This issue is a duplicate of JENKINS-27084 which was fixed in 2.5.1.

          Steven Christou added a comment - This issue is a duplicate of JENKINS-27084 which was fixed in 2.5.1.

            schristou Steven Christou
            ursus_b Björn Olsson
            Votes:
            7 Vote for this issue
            Watchers:
            15 Start watching this issue

              Created:
              Updated:
              Resolved: