DGhost's Blog

A sysadmin thoughts about the Internet and technologies…

Setting up a Subversion server on linux with SASL authentication against a LDAP Active Directory database

| 19 Comments

This text has been created for my personnal references. I have spent a lot of time on this and now that I was able to make it work I will document the steps that I have done.  I am assuming that if you follow the steps in this document, you have a pretty good understanding of the basic of Linux.  This is not a “how to” for Linux itself but for configuring Subversion with SASL and LDAP against an Active Directory server.

Some useless background on why I want to do this :

The company I work for is running more than 60 servers (all VM servers) of Subversion, all running on Linux with Apache2 and the authentication is done with the mod_ldap for Apache2 against our Active Directory Server.  The server that host that user’s accounts is a Windows Server 2008 with Active Directory.  So all the accounts are store in a MS LDAP DB, not an OpenLDAP!  It’s a Microsoft server after all, so it’s not the standard LDAP protocol, but the Microsoft LDAP protocol.  This kind of setup is called a Subversion over HTTP (or STUB).  I won’t go into the details of that setup because it is already well documented on the Internet.

This setup has been good for us since the last 3 years, but we are now having a lot of problems where the Apache2 service will crash when too many users are using the SVN server at the same time (we have more than 100 users accessing our SVN servers everyday).  When Apache2 crash/freeze, we are not able to kill and restart the service live, we must reboot the server by doing a cold reboot since the server is waiting after the apache2 process to shutdown before rebooting.  Very annoying!  So I want to use a system for authentication that won’t crash when there is a lot of users.  I need something more… lighter.  But I want to keep our authentication to be done against our Active Directory server because we don’t want to manage a new database of all the accounts just for SVN.  I have to drop the Apache2 part.  Here come SASL.  There is many authentication mechanism  available for SASL and one of them is… LDAP!  Now we are talking.  With this new setup our current SVN protocol will change from http://svnserver to : svn://svnserver  No big deal.  We will lose the option of browsing with a browser (IE, firefox, etc.) in our repository.  Like I care!

So after many research on the Internet I had a lot of trouble to understand if that kind of setup is feasible or not.  Lot of people are saying no, but I guess that’s because of the old version of subversion server (I.E. previous version of 1.6.5).  A lot of people said that they where able to make it work but after following some vague instructions it never worked for me.
After a couple of days of tests and tries, I was able to make it work.

On to the setup itself!

You’ll need a Linux server up and running, I used CentOS 5.5 32 bits.  I installed Subversion server version 1.6.13.  This setup will send the user’s info (login/password) as plain text over the network (that’s because of the LDAP call to the AD server itself).  I read that Subversion will not let authentication go through with clear text before version 1.6.5.  I have not tested it with this specific version.  Only with 1.6.13.  If you want a more secure way of sending the user’s account info on a network (like the Internet), then I suggest you use svn+ssh for the protocol – not documented here!

Everything on the CentOS server has been installed using yum.  Make sure that all these packages are installed, if any of them are missing, it won’t work!

subversion – I used version 1.6.13
db4-utils – I am not sure yet if I need this or not!
cyrus-sasl – The SASL authentication system
cyrus-sasl-ldap – LDAP plugin for SASL
cyrus-sasl-plain – for PLAIN login with SASL

If you want to get the latest version of Subversion you’ll have to use a yum repository that contains it.  By default the Subversion package that ship with CentOS is an old version, 1.4.  Follow the steps in this link to connect your CentOS installation to the RPMForge repository to have the latest version :

http://wiki.centos.org/AdditionalResources/Repositories/RPMForge?action=show&redirect=Repositories%2FRPMForge

After you have connected to the RPMForge repository, let’s install all of that in one shot!  Run the following command :

# yum -y install subversion cyrus-sasl cyrus-sasl-ldap cyrus-sasl-plain db4-utils

There will be other packages that will be installed with these for dependencies, just go ahead and install all of it.  Once these steps have been done, you can check the Subversion version by running the following command, it will give you the version installed and also if it’s installed or not!

# yum info subversion

Output will be :

Installed Packages
Name       : subversion
Arch       : i386
Version    : 1.6.13
Release    : 0.1.el5.rf
Size       : 20 M
Repo       : installed
Summary    : Modern Version Control System designed to replace CVS
URL        : http://subversion.tigris.org/
License    : BSD
Description: Subversion is a concurrent version control system which enables one
: or more users to collaborate in developing and maintaining a
: hierarchy of files and directories while keeping a history of all
: changes.  Subversion only stores the differences between versions,
: instead of every complete file.  Subversion is intended to be a
: compelling replacement for CVS.

Or you can also use this command to check the version :

# svnserve --version
svnserve, version 1.6.13 (r1002816)
compiled Oct  2 2010, 21:05:06

Copyright (C) 2000-2009 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

The following repository back-end (FS) modules are available:

* fs_base : Module for working with a Berkeley DB repository.
* fs_fs : Module for working with a plain file (FSFS) repository.

Cyrus SASL authentication is available.

Now let’s create a repository for your Subversion server with this command :

# svnadmin create /path_to_repo/svn

Now on to the configurations of all these text files!  First let’s tell the Subversion service to use SASL as the authentication mechanism.  Configure the following file /path_to-repo/svn/conf/svnserve.conf  You’ll need to change some lines in it (and make sure to remove the comments – #) which are :

# Disable anonymous access to the repo
anon-access = none
# Force auth for write access
auth-access = write
# For fine tuning your access to the repository
authz-db = authz
# Tell Subversion to use SASL for the authentication mechanism
use-sasl = true
# Make sure that there is no encryption for the authentication mechanism
min-encryption = 0

That’s it for this one, make the changes and save it.  Don’t forget to configure your authz file properly for the access also.

Now let’s configure the option of SASL for the Subversion service specifically.  This file is a kind of mysteries for a lot of people because it’s name and location are not the same depending of which kind of distro of linux you are using.  I think it’s the hardest part to figure out where it’s going and what it’s name.  On CentOS I created the text file under /etc/sasl2 and I named it svn.conf.  The file contains the following configuration :

###################################################################
# For CentOS /etc/sasl2/svn.conf
# For other distro it could be /usr/lib/sasl2/svn.conf
# For other distro filename could also be subversion.conf
#
# Password method, use the sasl authentication deamon.
pwcheck_method: saslauthd
#
## Auxiliary plugin, use ldap
auxprop_plugin: ldap
#
## Mechanism list, plain text only
mech_list: PLAIN
ldapdb_mech: PLAIN
# EOF
###################################################################

Now let’s configure the options for LDAP for SASL itself!  Create a text file here :

# touch /etc/saslauthd.conf

Put the following config in it, make sure that you change the adress of the ldap server to reflect your server with the proper username and password for binding to the AD itself.  There is also the config for the ldap_default_domain to change.

###################################################################
#/etc/saslauthd.conf
#
# Your AD server address
ldap_servers: ldap://server.domain.local
#
# You can specify the default domain name!
ldap_default_domain: domain.local
#
# Where are the users located in the AD?  If you haven't change the
# default tree of your AD it should be under the Users OU.
ldap_search_base: CN=users,DC=domain,DC=local
#
# You need a user account to be able to make the authentication in the
# Active Directory, I suggest you create a user just for that!
ldap_bind_dn: user@domain.local
#
# Of course there is a password associated with this user, put it here :
ldap_bind_pw: user_password
#
# Misc options for LDAP to make it work with Microsoft AD. 
# Nothing to change here, move along...
ldap_deref: never
ldap_restart: yes
ldap_scope: sub
ldap_use_sasl: no
ldap_start_tls: no
ldap_version: 3
ldap_auth_method: bind
ldap_filter: sAMAccountName=%u
ldap_password_attr: userPassword
ldap_timeout: 10
ldap_cache_ttl: 30
ldap_cache_mem: 32768
#EOF
#########################################################################

Next, let’s also configure SASL to use LDAP only for the mechanism, configure the existing file located here (if the file is not there, then SASL is not installed on your server) : /etc/sysconfig/saslauthd. For other distro, this file may be located under /etc/default/saslauthd. Only one line to change and it’s :

MECHANISMS="ldap"

Let’s test it, start the SASL service on the server with :

# /etc/init.d/saslauthd start

# testsaslauthd -u 'a user in the AD tree' -p 'the password for that user'"

If that part is working, you should get the following message :

0: OK "Success."

If not, then you have a problem!  make sure that the SASL service is running and reading the /etc/saslauthd.conf file. The log file of SASL itself are located in /var/log/messages
You can do a # tail -f /var/log/messages in another session to see live what is going on with SASL.

Now start SVN with the following command :

# svnserve -d --config-file /path_to-repo/conf/svnserve.conf --root /path_to-repo --log-file /var/log/svn.log

This command tell the Subversion service to start as a deamon (-d) using this specific config file (–config-file the one you edited earlier), using the repo (–root) located where you created your repo and for sake we want a log (–log-file) to see what is going on with SVN.  I just love log file!

Now if everything is good, you should be able to access your repo using the svn://servername protocol to access the repo.  You will then be prompted with a username and password.
Take a user’s account from the AD and try it!  If you have a firewall enabled on your linux server make sure to put an exception for the SVN protocol which is using the TCP port of 3690 or disable your firewall if necessary.

Now wait a minute, SASL and the Subversion service won’t start automatically when the server boot.  Let’s configure that also.  For SASL the script already exist, we just need to enable it to autostart, under CentOS/Redhat run the 2 following commands, for other distro of Linux it may be different.

# chkconfig --add saslauthd

# chkconfig --level 345 saslauthd on

For Subversion the scripts doesn’t exist, so we’ll need to create it, modify it and then enable it.  I found this script on this blog that does that :

http://blog.webramz.com/tag/subversion-autostart/

Create the empty file for the script with this command : # touch /etc/rc.d/init.d/subversion

Just follow the instructions in the blog, copy and paste the Subversion script and you’ll only need to change one line it which is the OPTIONS=  My configuration for that line is this :
OPTIONS="--config-file /path_to-repo/svn/conf/svnserve.conf --root /path_to-repo/svn --log-file /var/log/svn.log"
Notice that the -d for the daemon option is just below in the script, so no need to put it on the OPTIONS line.  Once the script has been created, let’s activate it for the autostart : # chkconfig --add subversion.

Let’s put the proper permission on it : # chmod 0750 /etc/init.d/subversion

And then activate it!

# chkconfig –-level 345 subversion on

That’s it!

Update : If you are managing multiple repositories, I would strongly suggest that you take a look at my new post : Centralizing and simplifying your SVN administration

Author: DGhost

System Administrator and consultant for more than 23 years. I've always used computers since I was a kid. I' ve specialized in networking, servers and the inner workings of the Internet. My blog is aimed as a personnel point of view on some technologies, the web, sciences and the Internet in general. If you are wondering why this website is in French and English, that's because I'm a french Canadian who also speaks English and sometimes, when I'm drunk, dabble in Spanish.

19 Comments

  1. DGhost says:

    What distro of Linux do you use? What is the version of your SVN service? When are you getting this error message? When you start the svn service or when you commit? What is the content of sasl2/svn.conf? Do you happens to have more than one sasl2 folder on your system?

  2. Calvin says:

    I’m getting the following error…

    svnserve: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: ldapdb

    My confguration has been followed to a T according to your guide. I can’t find anything online.

  3. DGhost says:

    You should start by enabling your log in SVN itself instead of using wireshark to figure out what is going on. It would be much easier. But quickly you can see that SVN doesn’t understand the mechanism of SASL itself. Maybe your svnserve.conf is not using SASL in it? have you removed the comment in svnserve.conf and tell it to use sasl : use-sasl = true

    See my recent post on how to simplify your SVN installation for more details regarding the SVN logs.

  4. dD says:

    hi, i tried to do it on debian os , but without success.
    svnserve, version 1.7.18 (r1615261)
    saslauthd 2.1.25

    testsaslauthd say ” 0: OK “Success.” ” .
    when i try to login into repo , svn-client asks for a login\password , but when i type it, nothing happens .

    I try to sniff network with etheral wireshark and saw

    ( PLAIN ( 25:AGRkZXZpbABzeHdQOFNEaQ==
    ) ) ( failure ( 34:SASL(-4): no mechanism available: ) ) ( LOGIN ( ) ) ( step ( 13:VXNlcm5hbWU6
    ) )

    meybe this is my problem ?

  5. DGhost says:

    I don’t understand from your log that the Subversion server is displaying 2 different version 1.6.17 and 1.6.12, was this installation an upgrade from a previous version?

  6. Any of you had this issue:

    2468 2012-09-27T18:08:56.261827Z 10.3.106.133 jorixine svn open 2 cap=(edit-pipeline svndiff1 absent-entries depth mergeinfo log-revprops) / SVN/1.6.17%20(r1128011) –
    2468 2012-09-27T18:08:56.292677Z 10.3.106.133 jorixine svn get-latest-rev
    2468 2012-09-27T18:08:56.303133Z 10.3.106.133 jorixine svn reparent /
    2468 2012-09-27T18:08:56.314774Z 10.3.106.133 jorixine svn ERR /tmp/buildd/subversion-1.6.12dfsg/subversion/svnserve/serve.c 167 170001 Authorization failed

    Everything is authenticating OK… the tests works, but the problem is when I do a svn list svn://servers-ip

  7. DGhost says:

    @crankyproof : Having your users separated in multiple OU’s in your AD organization may be a little bit more complex to setup the SASL authentication. In the saslauthd.conf, check the following config line ;

    # Where are the users located in the AD? If you haven’t change the default tree of
    # your #AD it should be under the Users OU.
    ldap_search_base: CN=users,DC=domain,DC=local

    The ldap_search_base is the parameter that will tell the SASL service where to search in the AD OU’s for the users account. If you use my current config it will not work with your AD schema. I haven’t tried also if with this current setup it can at least make a look-up in a sub OU of my current user’s OU. Should be. I think the easiest way would be to make sure that all your users OU are all located as a sub OU.

    For defining an authz file I will give you an example based on mine, note that in this example, the user1 is part of the AD schema and the Group1 is not. This Group1 exist only in the authz file of the repository that it sits in. If you have specified a ldap_default_domain in your saslauthd.conf file, you don’t need to write the complete fqdn of the user in the authz file, only the first part. Here are 3 different ways to input the user’s name from the AD in a authz file ;

    user1@domain.local
    DOMAIN\user1
    user1

    # authz file example
    #
    [groups]
    Group1 = user1@domain.local, DOMAIN\user2, user3

    [aliases]
    toto=user1/tata=user2
    # for the fun you can even create and use aliases for your username.

    # Access permission at the root of the current repo
    [/]
    * =
    # the ‘* = ‘ config line say that no one has no access to this repo first.
    @Group1 = r
    # This tell that the Group1 users have only read access to the repo (recursively).
    user1 = rw
    # the user1 from the AD has more privileges than the rest of Group1 members,
    # he can read AND write from the root of the repo.
    [/folder1]
    @Group1 = r
    user2@domain.local = rw
    # a sub folder in the repo where Group1 has still read access,
    # but this time user1 cannot write to it but user2 can.
    # EOF

    I think that sums it up. For more info about the authz file I suggest this link :
    http://stackoverflow.com/questions/81361/how-to-setup-access-control-in-svn

  8. DGhost says:

    @jp, you are right that I didn’t put it in my example, the line of [sasl] is already there by default when I installed Subversion 1.6.13 So I had no need to add it myself. It may have been missing if you did an upgrade of Subversion over a previous version that didn’t supported SASL at that time?

  9. crankyprof says:

    Still having problems controlling access. Great walkthrough, but the authz file is my stumbling block. What is the syntax for giving a specific AD user or group read-only will everyone else has read/write. My users are in multiple OUs based on the business model, by the way.
    Thanks.

  10. jp says:

    in the step configure /path_to-repo/svn/conf/svnserve.conf
    add
    [sasl]
    before sasl configuration

  11. Lissandro says:

    Hey, i did it !

    I keep the changes like this:

    MECHANISMS=”ldap”
    SASLAUTHD_AUTHMECH=ldap

    and a very important but missed step..
    $ service svnserve restart
    yes.. i did all the changes and fight for four or five days, that is the missing step 🙂

    Now my svnserve works fine and authenticanting with sasl in my active directory.

    Now i have a new challenge, do this with apache to authenticate with Active Directory 🙂

    I post my solution because the post was very useful for me, thanks

  12. DGhost says:

    Have you checked the log for SVN? With the startup script of the service you can define your logfile name and location. Make sure to enable it and check the file for what’s going on with your authentication problem.

  13. Lissandro says:

    I saw this template, and i have been working with permissions to groups and users with an authz file, but in this case i cant connect to the repository 🙁

    I´m using tortoise for windows connecting to a linux repository. If i can find the solution i´ll be postin here 🙂

  14. Lissandro says:

    Another thing.. I have a svn server running my subversion repository in the opensuse 11.3 and i was using an internal use of the sasl + md5, but this method its very helpfull to my users manage their passwords, theres no interface to do this like i have been done.

    Following your explanation, theres two diferent things in my enviroment
    cyrus-sasl-ldapauth it is cyrus-sasl-ldap-auxprop in the 64 bits opensuse 11.3 version.

    The other its the change in the file /etc/sysconfig/saslauthd where the MECHANISMS= »ldap » does not work, i already try to put only MECHANISMS= ldap and no success, by the way changing

    SASLAUTHD_AUTHMECH=pam to
    SASLAUTHD_AUTHMECH=ldap
    when i use testsaslauthd -u myuser -p mypass
    the authentication it is ok, but when try to connect my repository theres no sucess 🙁
    I tryed to coment again the authz-db option and use a realm = mydomain but still no sucess…

    If someone face this problem, i will be watching for news, any help would be good.

  15. DGhost says:

    looks like a problem with your authz file. There is a good template inside the file (authz) for managing and refining the access that you want to give to the repository. An example of access file would be ;
    # Root of the repository
    [/]
    # Give read access to everybody
    * = r
    # Give read and write access to a specific user
    username = rw

  16. Lissandro says:

    Hi, would be realy good an example of the authz file for a repository, would help a lot!

    Thank you and congratulations for the wonderfull explanation.

  17. JC says:

    Thank you for your detailed explanation, I was able to enable the authentication in a few minutes!

    I just wanted to share that by following this document http://www.sendmail.org/~ca/email/cyrus2/options.html I was able to reduce the file /etc/sasl2/svn.conf to these two lines:

    pwcheck_method: saslauthd
    mech_list: PLAIN

  18. DGhost says:

    Running a Subversion server on Windows is very different compare to Linux. You’ll have to check what kind of mechanisms you’ll want to use for authentication and the protocol used with Subversion. The most popular configuration for running all of that on a Windows Server is to use Apache as the auhentication server (with mod_ldap). This is a very popular configuration, you can find plenty of tutorial for that on the Internet : http://www.sublimesvn.com/blog/2009/02/configuring-subversion-with-active-directory-authentication/

  19. lovetide says:

    i followed this thread http://www.svnforum.org/2017/viewtopic.php?t=7102 to here.

    i run svnserve.exe on Windows Server 2003, and try to configue windows domain authentication, and searched a lot, and no solution.

    maybe authentication via LDAP is a compromised way (like mediawiki or phpBB installation).

    nice article, thanks!
    谢谢!

Leave a Reply

Required fields are marked *.



 

This site uses Akismet to reduce spam. Learn how your comment data is processed.