Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of lieven.govaerts@gmail.com
 designates 209.85.223.181 as permitted sender)
MIME-Version: 1.0
Sender: lieven.govaerts@gmail.com
In-Reply-To: 
 <CAOg_pRTfWaMAYw=D4Nm36M5Ozuor39-6vb7PveHNgpTe5913iQ@mail.gmail.com>
References: 
 <CAOg_pRTfWaMAYw=D4Nm36M5Ozuor39-6vb7PveHNgpTe5913iQ@mail.gmail.com>
From: Lieven Govaerts <lgo@mobsol.be>
Date: Tue, 8 Jul 2014 21:24:45 +0200
Message-ID: 
 <CANvU9sdrwQsTdU8Wf6YJ_5Bhdwko0BiH0sKU=7qV4OiFxKawwA@mail.gmail.com>
Subject: Re: SVN 1.8 Kerberos Client problems
To: Nicolai Scheer <nicolai.scheer@gmail.com>
Cc: "users@subversion.apache.org" <users@subversion.apache.org>
Content-Type: text/plain; charset=UTF-8

Hi Nico,

On Tue, Jul 8, 2014 at 3:57 PM, Nicolai Scheer <nicolai.scheer@gmail.com> wrote:
> Hi,
>
> I did an update to svn 1.8.9 on our server yesterday and am now
> running into problems whilst updating the corresponding windows
> client.
>
> Server details:
>
> CentOS 6.5 x64
> SVN 1.8.9, compiled on my own
> Apache 2.2.15
> Authentication using mod_auth_kerb to windows domain
>
> Client:
> Windows Server 2008
> TSVN 1.7.13
>
> Everything ran fine so far. I then upgraded to TSVN 1.8.7 which ships
> with svn 1.8.9 binaries.
> Now, on every repository involving action I get kerberos errors in my
> apache log:
>
> [Tue Jul 08 15:08:10 2014] [error] [client 192.168.1.152]
> gss_accept_sec_context() failed: No credentials were supplied, or the
> credentials were unavailable or inaccessible (, Unknown error)
>
> Strange thing is, TSVN works fine from a user perspective (no error
> displayed whatsoever...). I then tried to use the svn command line
> binaries, same result, evrythings works, but apache error log is DOSed
> with these error entries.

That's because you have this directive in your apache config:
     KrbMethodK5Passwd on

With this configuration, mod_auth_kerb will offer both Negotiate and
Basic authentication. Your logs show that Negotiate authentication
fails, but in this case svn will automatically fall back to Basic
authentication, which succeeds.

> I tried to either "prefer" or deny BulkUpdates on the server, nothing changes.

This option has nothing to do with authentication, it specifies how -
after authentication succeeded - svn+serf will communicate with
mod_dav_svn.

> Since subversion 1.8 comes with serf, it might have do to with the way
> serf handles kerberos.

Not unlikely.

> From the linux cmd (on the svn server itself), I can use kerberos
> (kinit + svn command afterwards) just fine, without any errors popping
> up in the apache log.
>

Which GSSAPI implementation are you using on the server? MIT? Heimdal?
Which versions?

> Our browsers (IE, Chrome, FF) worked fine all the time using kerberos,
> before and after upgrading svn on the server.
>
> TSVN 1.7.13 works as well, so do the svn binaries shipped this version.
>
> I'm quite stuck, because I do not know where to start. To my mind
> kerberos is set up correctly because all clients work, except svn 1.8
>

Serf on Windows uses Microsoft's SSPI API to handle Negotiate
authentication. We know this works well with Windows based servers
(e.g. VisualSVN) that also use SSPI on the server side.
Serf on Linux/Mac uses GSSAPI and one of its implementations. This
works well with other *nix servers.

It's likely that the combination client on Windows with
server+mod_auth_kerb on Linux hasn't seen as much testing as the cross
platform combinations, and that certain scenario's are not supported
well.

Debugging this stuff will not be easy. Most likely you'll find some
more information in the Kerberos implementation logging, which is
configured in your krb5.conf file. On my system the log file is
/var/log/krb5.log. Try to increase the log level to get more detailed
error information.

The best alternative is to find out what's going over the wire.
Disable your SSL configuration and set KrbMethodK5Passwd to off  (on a
test server) and use Wireshark to trace all traffic between your
Windows client and svn server. Wireshark on Windows can decode the
SPNego tokens in the Authorization headers (at least for NTLM but I
suppose for Kerberos also). This allows you to see if all info is
correct (domain, username etc). If you want you can send me the
wireshark trace privately and I'll have a look.

> I thought I could solve the problem by falling back to BulkUpdate, but
> it does not seem to help.
>
> Any suggestions are appreciated!
>
> Greetings
>
> Nico
>

hth,

Lieven

> PS:
>
> svn apache config :
>
> SVNInMemoryCacheSize 131072
> SVNCacheTextDeltas On
> SVNCacheFullTexts On
> SVNCompressionLevel 6
> SVNCacheRevProps On
> <Location /repos>
>     SSLRequireSSL
>     DAV svn
>
>     SVNListParentPath On
>     SVNParentPath /var/local/svn/repos
>
>     # Kerberos authentification
>     AuthType Kerberos
>     AuthName "Realm"
>     KrbServiceName HTTP
>     KrbLocalUserMapping on
>     KrbAuthRealms REALM.INTERN
>     KrbMethodNegotiate on
>     KrbMethodK5Passwd on
>     Krb5KeyTab /etc/httpd/kerberos/keytab
>     KrbVerifyKDC on
>
>     require valid-user
>
>     AuthzSVNAccessFile /var/local/svn/auth/svn_authz
>     SVNPathAuthz short_circuit
> </Location>