Hello everyone
We have the following situation that is working fine with svn clients <=
v1.7 in a windows-environment: Our SVN-Server is a VisualSVN-Server,
with integration of the Windows Authentication: Clients that are within
the windows-domain authenticate automatically using their
windows-credentials. Clients that are not part of the domain fail to
log-in using the windows-credentials (as svn.exe sends the local
user-information, like 'machine\username'), then svn.exe asks the user
to enter a username and password. Clients then enter their
domain-username ('domain\user') and the password, so they can authenticate.
Since svn 1.8.x we experience the following:
Clients that are part of the domain can log in without any problems.
Clients that are not part of the domain try to log-in forever using the
local account. The server rejects those credentials - it only knows
about domain-users, not about local users. The client does not stop to
log in then, but tries forever: At the server we see thousands of
rejected log-in requests, at the client we see that it uses one core of
the cpu 100% and eats more and more memory and never (? - I killed it
when it reached more than one Gigabyte of memory) stops.
Why do I think it is a problem of the svn client:
With svn clients <= 1.7 this scenario works against VisualSVN-Server
2.5.x (using subversion 1.7.11) and against VisualSVNS-Server 2.6.2 and
2.6.3 (using subversion 1.8.1): If log-in using the windows-credentials
fails, the svn-client asks for a username and password.
With svn clients >= 1.8 the problem occurs against VisualSVN-Server
2.5.x (subversion 1.7.11) and VisualSVN-Server 2.6.2/3 (subversion
1.8.1), so I would like to blame the client ;)
My try to test the svn-client was a simple checkout, in the form:
svn.exe --no-auth-cache checkout https://repository/svn/repo c:\tmp
For those who know VisualSVN Server: In the server we've selected 'Use
Windows authentication' and then checked both:
- 'Basis authentication' (Users are requested to enter their username
and password in order to authenticate to the server) and
- 'Integrated Windows Authentication' (Windows credentials are
automatically used to authenticate to the server).
If we remove 'Integrated Windows Authentication' every svn client,
regardless if it is in the domain or not, asks for a username/password
and things work fine with svn.exe v1.8.1
Passing --username and --password to svn.exe does not help: If I test using
svn.exe --no-auth-cache --username user --password pass checkout
https://repository/svn/repo c:\tmp
I see at the server that svn.exe does not send the passed user/pass, but
still tries to log in with the local windows credentials (regardless if
the machine is part of the domain or not - the server receives as
username 'machine\user' or 'domain\user').
Is it possible that something like this is going on:
The client queries the server for supported log-in methods.
The server returns "basic auth" and "windows auth"
The 1.7 client first tries windows auth, fails, and then tries basic auth.
The 1.8 client tries windows auth, and if it fails it just tries again,
and again, and again.. maybe its expecting that windows auth should work
anyway: The user is already logged in, so the credentials must be valid.
But they are not if the client is not part of the domain.
Looking at the stack in process explorer reveals that svn.exe seems to
be looping around somewhere in libapr_tsvn.dll
Thanks for any help, if you need more information I'll be glad to share.
Elias
Received on 2013-08-08 10:19:30 CEST