Jenkins : How to setup Hudson with Subversion and mod_auth_sspi (NTLM)

Created by Unknown User (flm), last modified by Unknown User (mindless) on Jul 29, 2010

This mini HOW-TO is for those who are in the urge of using a Subversion server behind a windows based Apache secured by mod_auth_sspi.

Since it this authentication scheme causes some trouble with Hudson (see hereand here) and I ran into the same trouble too here is my setup and solution to get mod_auth_sspi working with Hudson.

Setup

Suppose you have a similar environment for your Subversion. The Hudson part is irrelevant in this context.

  • Apache 2.2.9 running on a Windows 2008 Server (DAV/2 mod_ssl/2.2.9 OpenSSL0.9.8h SVN/1.5.5 mod_auth_sspi/1.0.4)
  • Subversion mounted to Apache 2.2.9 with webdav
  • Apache Authentication Module: mod_auth_sspi
  • Hudson (Release 1.300) on a different machine (Linux or Windows does not matter), served by Tomcat6 and Sun Java6

Synopsis

When you try to setup your project with Subversion then Hudson refuses to connect to the svn repository declared in your hudson job when the access to the repository is protected by mod_auth_sspi. You get this kind of exception from Hudson (lines wrapped for better readability):

org.tmatesoft.svn.core.SVNAuthenticationException: svn: Authentication failed
for http://geonosis/repos/projects/helloWorld/trunk/printHelloWorld
        at
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:67)
[...]
Caused by: org.tmatesoft.svn.core.SVNAuthenticationException: svn: Authentication failed
for http://geonosis/repos/projects/helloWorld/trunk/printHelloWorld
        at
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.authenticationFailed(SVNErrorManager.java:36)

Cause

My guess is that the mod_auth_sspi (NTLM) does not understand what the svnkit (Basic Authentication) of Hudson says to authenticate. (It is my assumption because I am not a Microsoft-Techie - I prefer open standards and sources.) The credentials you enter in Hudson do not make their way into the mod_auth_sspi. Side note: They get send from Hudson: you will see them when you disable ssl and sniff the packets on the wire.

In your Apache error.log you will see an empty user, even when you provided a user name in Hudson. Note the "user unknown" text in the end of the log entry:

[Thu May 29 09:13:33 2008] [error] [client 192.168.0.15] (OS 1326)Logon failure: unknown user name or
bad password.  : authentication failure for "/repos/projects/helloWorld/trunk/printHelloWorld": user unknown

Lets solve this...

Workaround/Solution

The idea is to enforce the mod_auth_sspi to offer Basic Authentication and to challenge Basic Authentication first and NTLM second. By default the mod_auth_sspi challenges NTLM first and does not offer Basic Authentication at all.

Locate your section for /svn in the httpd.conf (it should look like this): 

<Location /svn>
  DAV svn
  SVNParentPath C:\repo
  AuthName "Subversion"
  AuthType SSPI
  SSPIAuth On
  SSPIAuthoritative On
  SSPIDomain yourWindowsDomain
  require valid-user
</Location>

Then add or change these two switches in the section to:

  SSPIOfferBasic On
  SSPIBasicPreferred On

See here for their meaning. Make sure to edit the httpd.conf as Administrator (Windows UAC is another PITA). Save the file. Restart the Apache service. Connect to Subversion via your Hudson job. Sm:)e.

Remarks

NTLM is awkward, if you can avoid it, don't use it! It may even be a security breach when your Apache with mod_auth_sspi serves the internet behind a proxy. If you (or your sysadmins) can't (or won't) bail out Microsoft products consider to use the mod_authnz_ldap from apache with Microsoft Active Directory, since the mod_auth_sspi discussed here seems to be discontinued by the developer(s) since 2006.