[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Need help troubleshooting user authentication (apache)

From: Cooke, Mark <mark.cooke_at_siemens.com>
Date: Wed, 9 Mar 2011 14:44:31 -0000

Folks,

We use TortoiseSVN from windows XP SP3 clients (required by corporate
policy) to connect to repos on windows server 2003:-

Apache/2.2.17 (Win32) DAV/2 mod_ssl/2.2.17 OpenSSL/0.9.8o mod_wsgi/3.3
Python/2.6.4 SVN/1.6.15

I have one single user (amongst 15 or so) who is experiencing
authentication issues and need help in troubleshooting why he alone
cannot use subversion client...

Background:

My user can access the server and browse the source tree fine (I use the
TortoiseSVN xslt config and each department has their own parentpath set
of repos). However, he cannot access the server using a local client
(either TortoiseSVN or the svn command line that we use on the server
(from alagazam, thanks David Darj!))

My user gets the following error:

Username: svn: OPTIONS of
'https://server.company.net/svn/dept/project/trunk': authorization
failed: Could not authenticate to server: rejected Basic challenge
(https://server.company.net)

The same username/password works against the apache server and we use
the same authz file for path based authentication from both apache and
subversion direct. Note that the same client works if we get someone
else to enter their username & password, but always fails for this one
specific user (we have also tried changing his password).

We have cleared all cached data (using the tortoise settings dialog)
then uninstalled and rebooted before re-installing tortoise. We then
tried the svn cli again (generating the info above) to make sure it was
generic svn and not specific to tortoise.

Here is the (sanitised) authentication section from httpd conf (I know
Basic is plain text but all traffic is redirected to SSL https and the
standard client here was until recently IE6):

<Location />
  Order allow,deny
  Allow from all

  AuthName "Dept Applications server"
  AuthType Basic
  AuthBasicProvider ldap
  AuthzLDAPAuthoritative on

  # The LDAP query URL & credentials to access records (required by AD)
  AuthLDAPURL
"ldap://adserver:3268/DC=blah,DC=blah,DC=blah?sAMAccountName,mail?sub?(o
bjectClass=*)" TLS
  AuthLDAPBindDN <ad-username>
  AuthLDAPBindPassword <ad-password>

  Require valid-user
</Location>

...and the department svn root:

<Location /svn/dept/>
  DAV svn
  SVNIndexXSLT "/subversion/svnindex.xsl"
  SVNParentPath D:/svn/dept/
  SVNListParentPath On
  # restrict access to subversion repository paths...
  AuthzForceUsernameCase Lower
  AuthzSVNAccessFile d:/path-to/svn-users.txt
</Location>

...and the relevant bits of svn-users.txt:

# Give named authenticated users read access to the root
[/]
user_a = rw

Finally, here are sample errors from the apache log file:

[Wed Jan 12 10:06:38 2011] [error] [client ip-address] user user_a:
authentication failure for "/svn/dept/project/trunk": Password Mismatch

I do not understand where the 'Password Mismatch' error is coming from,
why does that only happen when using subversion and not the browser? I
have tried searching for "rejected Basic challenge" (both svn.haxx.se
and the wider net) but I've not found anything that hes helped so far.

From what I have found, this should indicate that the server is
rejecting the cached credentials and so the client is prompting for
updated credentials. However, the user can browse the repos using
IE/https through the server (which applies blanket authorisation through
the <Location /> directive) which makes me suspect svn somehow instead
of apache.

I have also tried disabling the AuthzSVNAccessFile (including bouncing
apache) but that made no difference.

What can I do to try to work out what the problem is? It is only svn
and (currently) for only this one user... I'd really appreciate any
help at this point.

~ mark c
Received on 2011-03-09 15:45:10 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.