HOW-TO svn and LDAP with the subversion svnserve and SASL

This How To offers simple guidance and working examples on how to configure svnserve and Cyrus SASL to authenticate svn and svnserve against OpenLDAP, it may also be helpful in configuring any SASL enabled client to authenticate against LDAP.

Authenticating using svn and svnserve with ldap is straightforward and facilitates single sign on. SASL the Simple Authentication Security Layer is available to svnserve the Subversion version control server and allows authentication and authorization through many mechanisms including LDAP.

Versions tested in compiling this guide are Subversion 1.7 & 1.8, Cyrus SASL 2.1 and Open LDAP 2.4.  The operating system is FreeBSD though any unix/linux system should be able to use this guide by adjusting file locations where necessary.  This guide assumes a working LDAP server, SASL authentication server and Subversion server.

Cyrus SASL

SASL setup is straightforward and for this example requires two configuration files, one in the SASL library with the service name and the second for the saslauthd daemon.

SASL configuration

By default, the Cyrus SASL library reads it's options from /usr/lib/sasl2/App.conf (where "App" is the application defined name of the application).  In our case the application is svnserve and is identified by svn so on FreeBSD the file will be found at /usr/local/lib/sasl2/svn.conf.

This svn.conf configuration contains two lines, pwcheck_method to specify the password checking mechanism, in this case specifying the saslauthd daemon and mech_list to specify the allowed mechanisms allowed and for LDAP the plaintext password is required so either or both of PLAIN and LOGIN can be used.

pwcheck_method: saslauthd
mech_list: PLAIN LOGIN

SASL authentication server configuration

There are three authentication methods available, though in this guide only bind and fastbind are shown.

Binding using fastbind

This is the simplest and fastest of the two and binds using the supplied username and password. The ldap_filter is used to specify the Distinguished Name to bind as the user.

/usr/local/etc/saslauthd.conf
ldap_servers: ldap://example.com/
ldap_auth_method: fastbind
ldap_filter: uid=%U,dc=example,dc=com

Binding using bind

This is more flexible by searching using filters, it is slightly slower as it binds as the search user, searches for the user using the ldap_filter then if found binds for a second time as that user.

This example uses the authorizedService attribute offered by ldapns.schema to check that a user has an attribute 'authorizedService: svn'.

/usr/local/etc/saslauthd.conf
ldap_servers: ldaps://example.com/
ldap_auth_method: bind
ldap_bind_dn: uid=searchuser,dc=example,dc=com
ldap_password: secretpassword
ldap_search_base: dc=example,dc=com
ldap_filter: (&(uid=%U)(authorizedService=%s))

SASL authentication server testing

The SASL authentication server can be tested with testsaslauthd -u igor -p secret and should return one of the following responses

0: OK "Success."

Showing that the user has successfully authenticated.

0: NO "authentication failed"

Showing that the user has successfully connected and the authentication has failed, more information is may be available in /var/log/security.

connect() : No such file or directory
0:

Here there is no connection to the saslauthd daemon, check that the daemon is running and permissions to the socket are readable.

Subversion

Subversion needs to be compiled with --with-sasl and the svnserve configuration file svnserve.conf needs the following sasl entry:

[sasl]
use-sasl = true

Then the Subversion daemon svnserve is run with the --config-file=/path/to/svnserve.conf

Restarting the svnserve daemon and you should now be authenticating against ldap.

Svn issues

If there are E170001 errors such as

svnsync: E170001: Unable to connect to a repository at URL
svnsync: E170001: Authentication error from server: SASL(-1): generic failure: Password verification failed
svn: E170001: Authentication error from server: SASL(-1): generic failure: Password verification failed

Also if your svnserve.log shows 'Network connection closed unexpectedly', this could be an indication that the sasl authentication daemon is running but the socket is not visible.

This means that the svnserve daemon is unable to authenticate against the sasl server, it might be related to permissions of the saslauthd daemon which on FreeBSD the socket is at /var/run/saslauthd/mux where the permissions should be srwxrwxrwx

ls -ld /var/run/saslauthd
drwxr-x--- 2 cyrus cyrus 512 3 Sep 04:27 /var/run/saslauthd

chmod 755 /var/run/saslauthd

ls -ld /var/run/saslauthd
drwxr-xr-x 2 cyrus cyrus 512 3 Sep 04:28 /var/run/saslauthd

The world r-x on /var/run/saslauthd allows the mux socket /var/run/saslauthd/mux to be accessed by the svnserve daemon

If there are any E210007 errors such as

svnsync: E210007: Cannot negotiate authentication mechanism
svn: E210007: Cannot negotiate authentication mechanism

The error could mean that the client has not been built with sasl libraries and so the server and client fails to find a common authentication mechanism and so returns the E210007 error.  Easily fixed by ensuring the client and server are built with the same options.

By Alan Hicks