-
Bug
-
Resolution: Fixed
-
Low
-
3.0.0, 3.1.0, 4.4.1, 4.5.0
-
Severity 3 - Minor
-
5
-
HTR:
- Install VisualSVN enterprise
- Enable Windows authentication
- Try to authenticate against the server in FishEye
2013-09-20 10:30:41,361 DEBUG [qtp1564035725-243 ] fisheye ProfilingServletFilter-logRequest - start request POST /fecru/gwt/RepositoryAdminRpcService sessionid=63ux2ajuv6j05j3xen8lj0fk 2013-09-20 10:30:41,368 DEBUG [qtp1564035725-243 ection-1379665841363] fisheye SvnRepositoryTester-checkRepoSettings - Checking repository: ntlm:https://fecru-komputer/svn/test/ 2013-09-20 10:30:41,369 DEBUG [SvnExecution4 testing] fisheye SvnTask-run - Executing svn info -r HEAD https://fecru-komputer/svn/test/@HEAD 2013-09-20 10:30:41,388 DEBUG [SvnExecution4 testing] fisheye SvnPasswordSupplier-prompt - prompting for realm: <https://fecru-komputer:443> with username: FECRU-KOMPUTER\\fecru, maySave = true 2013-09-20 10:30:41,388 DEBUG [SvnExecution4 testing] fisheye SvnPasswordSupplier-getPassword - Getting password 2013-09-20 10:30:41,392 WARN [qtp1564035725-243 ection-1379665841363] fisheye SvnRepositoryTester-getServerRootURL - Unable to get info for the repository root for ntlm com.cenqua.fisheye.rep.RepositoryClientException: org.apache.subversion.javahl.ClientException: svn: E170001: Negotiate authentication failed: 'No valid credentials provided' at com.cenqua.fisheye.svn.SvnThrottledClient.executeNoThrottle(SvnThrottledClient.java:176) at com.cenqua.fisheye.svn.SvnThrottledClient.execute(SvnThrottledClient.java:145) at com.cenqua.fisheye.svn.SvnThrottledClient.info(SvnThrottledClient.java:110) at com.cenqua.fisheye.svn.SvnRepositoryTester.getServerRootURL(SvnRepositoryTester.java:91) ... Caused by: org.apache.subversion.javahl.ClientException: svn: E170001: Negotiate authentication failed: 'No valid credentials provided' at org.apache.subversion.javahl.ClientException.fromException(ClientException.java:68) at org.tmatesoft.svn.core.javahl17.SVNClientImpl.getClientException(SVNClientImpl.java:1274) ... Caused by: org.tmatesoft.svn.core.SVNAuthenticationException: svn: E170001: Negotiate authentication failed: 'No valid credentials provided' at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:62) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.DefaultHTTPNegotiateAuthentication$1.run(DefaultHTTPNegotiateAuthentication.java:175) at org.tmatesoft.svn.core.internal.io.dav.http.DefaultHTTPNegotiateAuthentication$1.run(DefaultHTTPNegotiateAuthentication.java:166) at org.tmatesoft.svn.core.internal.io.dav.http.DefaultHTTPNegotiateAuthentication.authenticate(DefaultHTTPNegotiateAuthentication.java:221)
Workaround:
1. Enable basic auth in VisualSVN, potentially also using native svn client.
2. Customer implemented workaround: enable the svn protocol on the VisualSVN server so access the repository with the svn: protocol.
Resolution
https://confluence.atlassian.com/fishkb/fisheye-and-ntlm-1189783826.html
[FE-4879] Problems authenticating against NTLM challenge with VisualSVN server
I really can't believe that this security important issue is still open. As at Diebold Nixdorf as enterprise company it is not allowed to connect to Subversion in any other fashion than via https and native windows AD authentication. With the problem described in this issue it is not possible for us to use Fisheye.
So please and finally after several year fix this security issue with fisheye!
David.Cecil@drs.com
added a comment - I have the same problem with Visual SVN and Crucible with Windows NTLM authentication. Would really like for Atlassian to come up with a solution. It's been years since this was originally reported as a problem, it seems.
David.Cecil@drs.com
added a comment - I have the same problem with Visual SVN and Crucible with Windows NTLM authentication. Would really like for Atlassian to come up with a solution. It's been years since this was originally reported as a problem, it seems. 
Chris Watts
added a comment - To anyone reading this "minor" bug report in the future.. the work around is to enable the svn protocol on the VisualSVN server (so you end up being able to access the server by svn://yourserver/repositoryname. if you enable anonymous read in the svnserve.conf files for each repository, the crucible server will be able to read, and work as normal.
Chris Watts
added a comment - To anyone reading this "minor" bug report in the future.. the work around is to enable the svn protocol on the VisualSVN server (so you end up being able to access the server by svn://yourserver/repositoryname. if you enable anonymous read in the svnserve.conf files for each repository, the crucible server will be able to read, and work as normal. Evaluating Crucible as well and will not be able to use the product without this being resolved.
Chris Watts
added a comment - Cant believe this is "minor". To enable basic auth sets our entire source control system back a year, in addition to being completely ridiculous! with Jetbrains stuff, i can put "Domain\User" and that works, why cant i do that with Atlassian stuff? currently evaluating crucible and getting very frustrated with it.
Chris Watts
added a comment - Cant believe this is "minor". To enable basic auth sets our entire source control system back a year, in addition to being completely ridiculous! with Jetbrains stuff, i can put "Domain\User" and that works, why cant i do that with Atlassian stuff? currently evaluating crucible and getting very frustrated with it. Cant believe that this is marked as MINOR an not yet solved! This prevents my company from using FishEye...
when using Native Subversion Client, we will need to login as the user and perform a svn command to cache the credential
I found out that when using NTLM authentication in Subversion server, if the FishEye/Crucible server is started with the user "UserA", we need to use the credential for the user "UserA" for the repository setting in FishEye/Crucible.
If FishEye/Crucible is started by "UserA" and then we try to use "UserB" credential in the repository, it will have authentication error.
I'm not a Java or Linux developer and don't know what the situation is in those spaces, but impersonation of the specified username/password is quite easy with .NET (https://stackoverflow.com/questions/125341/how-do-you-do-impersonation-in-net).
For a Windows server application I use LOGON32_LOGON_BATCH instead of LOGON32_LOGON_INTERACTIVE. This requires that in the server's local security policy (Admin Tools | Local Security Policy | Local Policies | User Rights Assignment), the login that Fecru runs under requires "Impersonate a user after authentication" and the impersonated account requires "Log on as a batch job".