Here’s a writeup of how I managed to persuade Subversion‘s svnserve running on FreeBSD to authenticate using SASL, Cyrus’ saslauthd, and LDAP on Novell eDirectory.

I want to run Subversion’s svnserve from inetd. svnserve shall run as the svn user. All normal Subversion access is done through the svnserve programme. All files in all repositories are thus owned by the svn user. I want to authenticate the users of Subversion by using their existing user accounts stored in Novell eDirectory.

First, you’ll need to install these ports:

  1. devel/subversion
    • Make sure you enable the SASL option during make config.
  2. security/cyrus-sasl2
    • Make sure you enable these options during make config:
      • AUTHDAEMOND,
      • OBSOLETE_CRAM_ATTR,
      • CRAM,
      • DIGEST,
      • LOGIN,
      • NTLM,
      • OTP,
      • PLAIN, and
      • SCRAM
  3. security/cyrus-sasl2-saslauthd
    • Make sure you enable the OPENLDAP option during make config.

Create and edit the /usr/local/lib/sasl2/svn.conf file, and give it this contents:

pwcheck_method: saslauthd
auxprop_plugin: ldap
mech_list: PLAIN LOGIN

Create and edit the /usr/local/etc/saslauthd.conf file, and give it this contents:

ldap_servers: ldaps://ldap01.example.net ldaps://ldap02.example.net
ldap_version: 3
ldap_scope: sub
ldap_search_base: OU=some,OU=domain
ldap_filter: (uid=%u)
ldap_bind_dn: CN=someproxyuser,OU=some,OU=domain
ldap_bind_pw: someproxyuserspassword
ldap_auth_method: bind
ldap_timeout: 90

Create and edit the /usr/local/etc/openldap/ldap.conf file, and give it this contents:

uri                     ldaps://ldap01.example.net/ ldaps://ldap02.example.net/
base                    OU=some,OU=domain
scope                   sub
tls_cacert              /etc/ssl/certs/rootcertificate.cer
ssl                     on
ldap_version            3
binddn                  CN=someproxyuser,OU=some,OU=domain
bindpw                  someproxyuserspassword
rootbinddn              CN=administrator,OU=Administrators,OU=some,OU=domain
timeout                 90
network_timeout         90
pam_login_attribute     uid
pam_password            nds
nss_base_passwd         OU=some,OU=domain
nss_base_shadow         OU=some,OU=domain
nss_base_groups         OU=unixgroups,OU=some,OU=domain

Create the /usr/local/etc/openldap/ldap.secret file, and set the file’s mode to 0400:

touch /usr/local/etc/openldap/ldap.secret
chmod 0400 /usr/local/etc/openldap/ldap.secret

This is important as this file contains sensitive information! Give the file one line consisting of the administrator user’s password:

administratorspassword

For sake of compatibility with older and other LDAP software, and in preparation of future use of PAM and NSS, create these symlinks:

ln -s ldap.conf /usr/local/etc/nss_ldap.conf
ln -s openldap/ldap.conf /usr/local/etc/ldap.conf
ln -s openldap/ldap.secret /usr/local/etc/ldap.secret

Copy the root certificate from the PUBLIC directory on the SYS volume on the NetWare server running as the master replica to the /etc/ssl/certs directory on the Subversion server.

Edit the /etc/rc.conf file, and insert these two lines:

saslauthd_enable="YES"
saslauthd_flags="-a ldap"

Fire up saslauthd by running:

/usr/local/etc/rc.d/saslauthd start

Test the connection between saslauthd and the LDAP servers by running:

sh
testsaslauthd -u username -p password
exit

The testsaslauthd program should spit out this line:

0: OK "Success."

If not, check all files pertaining to saslauthd and OpenLDAP. The sole reason for running testsaslauthd inside a secondary Bourne shell, is to avoid storing the password in any command history file.

Make sure the svn group has access to the /var/run/saslauthd directory.

chgrp svn /var/run/saslauthd
chgrp svn /var/run/saslauthd/mux

Otherwise, the svnserve program will be unable to talk to saslauthd when running as the svn user.

Create the directory for storing the Subversion repositories, e.g. /home/svn/svnroot:

mkdir -p /home/svn/svnroot

Set the appropriate ownership and access modes:

chown -R svn:svn /home/svn
chmod 0660 /home/svn/svnroot

Log in as the svn user and create a test repository:

su -l svn
svnadmin create /home/svn/svnroot/testrepo

Edit the /home/svn/svnroot/testrepo/conf/svnserve.conf file and give it this contents:

[general]
anon-access = none
auth-access = write
authz-db = authz

[sasl]
use-sasl = true

Edit the /home/svn/svnroot/testrepo/conf/authz file and give it this contents:

[/]
larry = rw
moe = rw
curly = r
* =

The last line is important and ensures no one else has access to the repository.

Back as the root user, edit the /etc/inetd.conf file, and insert this line:

svn             stream  tcp46   nowait  svn     /usr/local/bin/svnserve svnserve --inetd --root=/home/svn/svnroot --compression 9

Remember, it is expected that the /etc/inetd.conf file contains one or more tabs between each field!

Edit the /etc/rc.conf file, and if necessary insert these two lines:

inetd_enable="YES"
inetd_flags="-lwW -C 60"

You may need to adjust the settings for the svnserve service in the /etc/hosts.allow file.

svnserve : ALL : allow

Start, or possibly restart, the inetd dæmon:

/etc/rc.d/inetd restart

As a regular user, try to check out the testrepo:

svn co svn://svn.example.net/testrepo testrepo

You should be asked to provide the password for the regular user:

Authentication realm: <svn://svn.example.net:3690> testrepo
Password for 'someuser': **********************************

You might be asked if you want to store this password unencrypted. Answer appropriately.

-----------------------------------------------------------------------
ATTENTION!  Your password for authentication realm:

   <svn://svn.example.net:3690> testrepo

can only be stored to disk unencrypted!  You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible.  See the documentation for details.

You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
'/home/someuser/.subversion/servers'.
-----------------------------------------------------------------------
Store password unencrypted (yes/no)? no
Checked out revision 0.

Finally, you might want to commit the edited files to the SCM system you use for configuration management.