10

I have a build server that is not part of a Windows domain trying to connect to a VisualSVN server running HTTPS via apache with domain login via Active Directory. When I try to connect to the server using specifying a domain username I observe a client hang:

svn ls --username=domainuser https://subversion.mydomain/svn/repo1/

The logs on the server show Windows authentication failures using the login-name for the build-machine, and the build-machine's hostname in the Domain name field. The username provided on the command-line is completely ignored.

SVN Client: TortoiseSVN commandline tools: svn, version 1.8.1 (r1503906)

On a separate machine (on the domain) - I found that the --username would not be ignored if I used the cygwin svn instead.

Greg
  • 2,549
  • 2
  • 24
  • 30
  • When you specified your domain username, did you specif it in this format: *svn ls --username username@domainxx.com* – Chelseawillrecover Nov 06 '13 at 05:58
  • I tried multiple combinations with no change - the root issue was that the --username field was being ignored. I assume requiring @domain will depend on the server configuration. With my fix below the server didn't require the domain to be specified (it only validates against one domain). – Greg Nov 07 '13 at 03:21

2 Answers2

15

The solution I found was to disable the http-auth-type 'negotiate'. This prevents Windows credentials being automatically shared.

I verified this using a command-line override, it asked for password for the user on the command-line:

svn ls --username=domainuser --config-option servers:global:http-auth-types=basic;digest https://subversion.mydomain/svn/repo1/
Authentication realm: <https://subversion.mydomain/svn/repo1/> VisualSVN Server
Password for 'domainuser':

(Note for Cygwin users: If you use SVN under Windows via Cygwin then you will need to add quotes to your command like this: $ svn ls --username=domainuser --config-option "servers:global:http-auth-types=basic;digest" https://subversion.mydomain/svn/repo1/ -- Otherwise the semicolon will be treated as a command delimiter.)

To configure this more permanently you can make a servers config file entry for all matching servers. For Win7 that's C:\Users\<User>\AppData\Roaming\Subversion\servers.

[groups]
mydomain = *.mydomain

[mydomain]
http-auth-types=basic;digest
StackzOfZtuff
  • 2,534
  • 1
  • 28
  • 25
Greg
  • 2,549
  • 2
  • 24
  • 30
  • A little notice: after changing "servers" file you have to restart proper app to catch new settings. In my case it was VS2015 (AnkhSvn plug-in). However, IntelliJ Idea catch new setting "on the fly". – Denis Maslov Mar 04 '18 at 11:40
5

Instead of disabling negotiate in client's config, I'd suggest using Windows Credential Manager to store the other account's credentials for Single Sign-On.

The following instruction shows how to put other domain credentials to access VisualSVN Server into Windows Credential Manager:

  1. Start | Control Panel | Credential Manager,

  2. Click 'Add a Windows Credential',

  3. As 'Internet or network address' enter the FQDN of VisualSVN Server's machine,

  4. As 'Username' enter the <DOMAIN>\<username> of user account that exists in domain and has access rights to VisualSVN Server,

  5. Complete the password field and click OK,

  6. Verify that you can authenticate to VisualSVN Server under the selected user account after completing the above steps.

bahrep
  • 29,961
  • 12
  • 103
  • 150
  • Thanks, assuming I needed separate logins for different tasks (eg building different projects) would svn's --username argument be able to be used to differentiate between multiple saved credentials? It seemed to be being ignored. – Greg Nov 07 '13 at 03:26
  • @bahrep is there any workaround in case the credential manager is disabled? – royalTS Aug 22 '17 at 17:07
  • @bahrep unfortunately not... It is stating that I am not allowed to create a new entry – royalTS Aug 24 '17 at 07:02
  • It seems windows does not recognise correctly the FQDN even when the FQDN is used in the svn http URL connection when there is another credential entry for the hostname – paolov Oct 01 '17 at 04:33