I have a set of private Subversion repositories on a Windows Server 2003 box which developers access via SVNServe over the svn:// protocol. Currently we have been using the authz and passwd files for each repository to control access however with the growing number of repositories and developers I'm considering switching to using their credentials from ActiveDirectory. We run in an all Microsoft shop and use IIS instead of Apache on all of our web servers so I would prefer to continue to use SVNServe if possible.

Besides it being possible, I'm also concerned about how to migrate our repositories so that the history for the existing users map to the correct ActiveDirectory accounts. Keep in mind also that I'm not the network administrator and I'm not terrible familiar with ActiveDirectory so I'll probably have to go through some other people to get the changes made in ActiveDirectory if necessary.

What are my options?

UPDATE 1: It appears from the SVN documentation that by using SASL I should be able to get SVNServe to authenticate using ActiveDirectory. To clarify, the answer that I'm looking for is how to go about configuring SVNServe (if possible) to use ActiveDirectory for authentication and then how to modify an existing repository to remap existing svn users to their ActiveDirectory domain login accounts.

UPDATE 2: It appears that the SASL support in SVNServe works off of a plugin model and the documentation only shows as an example. Looking at the Cyrus SASL Library it looks like a number of authentication "mechanisms" are supported but I'm not sure which one is to be used for ActiveDirectory support nor can I find any documentation about such matters.

UPDATE 3: Ok, well it looks like in order to communication with ActiveDirectory I'm looking to use saslauthd instead of sasldb for the auxprop_plugin property. Unfortunately it appears that according to some posts (possibly outdated and inaccurate) saslauthd does not build on Windows and such endeavors are considered a work in progress.

UPDATE 4: The lastest post I've found on this topic makes it sound as though the proper binaries () are available through the MIT Kerberos Library but it sounds like the author of this post on Nabble.com is still having issues getting things working.

UPDATE 5: It looks like from the TortoiseSVN discussions and also this post on svn.haxx.se that even if saslgssapi.dll or whatever necessary binaries are available and configured on the Windows server that the clients will also need the same customization in order to work with these repositories. If this is true, we will only be able to get ActiveDirectory support from a windows client only if changes are made in these clients such as TortoiseSVN and CollabNet build of the client binaries to support such authentication schemes. Although thats what these posts suggest, this is contradictory from what I originally assumed from other reading in that being SASL compatible should require no changes on the client but instead only that the server be setup to handle the authentication mechanism. After reading a bit more carefully in the document about Cyrus SASL in Subversion section 5 states "1.5+ clients with Cyrus SASL support will be able to authenticate against 1.5+ servers with SASL enabled, provided at least one of the mechanisms supported by the server is also supported by the client." So clearly GSSAPI support (which I understand is required for Active Directory) must be available within the client and the server.

I have to say, I'm learning way too much about the internals of how Subversion handles authentication than I ever wanted to. And unfortunately I was simply looking for an answer about whether I can have Active Directory authentication support when using SVNServe on a Windows server and accessing this from Windows clients. According to the official documentation it seems that this is possible however you can see that the configuration is non-trivial if even possible at all.

UPDATE: 6: Since development on Subversion 1.7 is wrapping up, could anybody add anything about whether Subversion 1.7 will improve upon the situation of getting SVNServe to authenticate using Active Directory?

  • then look here.. stackoverflow.com/questions/333146 but it seems to me as quite a hack. you can get IIS side-by-side with apache [ by running the second one eg on different port or different ip ]
    – pQd
    Dec 7, 2009 at 19:56
  • 2
    +1 for this question. It's something that I keep wanting to find an answer to and failing. Most people seem find apache acceptable (usually in visualsvn form). But it's a pain if you've already got a lot of svn:// references. And it just feels better to me to run svnserve for repository access rather than apache.
    – Jim T
    Dec 8, 2009 at 8:39
  • 1
    +1 really wanted to do this a long time ago as well, I truly hate having to run apache on a windows box just out of principle when it shouldn't be needed... extra points for combining this with SSL access over IIS ^^ Dec 8, 2009 at 15:41
  • @Oskar - I think it would be great if somebody would create a WAS module for IIS7 and up for hosting both the apache based http protocol as well as the svnserve protocol all within IIS. If I had more time on my hands I would delve into creating something like this in .NET as an open source project.
    – jpierson
    Jan 25, 2011 at 3:55

3 Answers 3


As already mentioned, VisualSVN Server is the tool you want. Its an all-in-one package for Windows that just happens to use Apache inside it- you'd never know unless you went poking around in the dlls it installs though, to everyone its a Windows service that has a mmc snap-in to administer it. You can change the port it runs on if you already have port 80 taken.

I understand sasl support through svnserve is being worked on at the moment.

  • If there were a way to get the Apache service to work through IIS or have them both use port 80 then that would be great. Unfortunately for those who want to stick with svnserve or use IIS there doesn't seem to be many options other than to wait to see if the work on sasl support for svnserve comes to fruition. If it's not too much trouble could you please link to some place where we can get up-to-date information on this feature? The SVN project, although better recent, seems not to communicate their efforts and progress very well to the community trough their bug tracker.
    – jpierson
    Jan 17, 2011 at 18:24
  • I'm curious whether you might have any input on whether the sasl support that is/was being worked on for svnserve has come to any fruition. Can we expect to see any improvements in Subversion 1.7?
    – jpierson
    Apr 27, 2011 at 2:26

i'm using apache with svn running on debian linux authorizing againsta active directory server. clients connect to the repository over http protocol. if this setup is acceptable for you - continue reading.

this should also work under apache for windows but i never tried it. what follows is debian specific but should work similarly under windows / other distros; you'll not loose your svn history while migrating...

install required software:

apt-get install libapache2-svn subversion apache2

in configuration for apache's vhost [ symlinks to them can be found in /etc/apache2/sites-enabled ]. inside VirtualHost add:

<Location /svn>
        DAV svn
        #change this to actual path
        SVNPath /full/path/to/your/current/svn/directory

        AuthType Basic
        AuthName "SVN Server"
        AuthBasicProvider ldap
        AuthzLDAPAuthoritative Off

        # provide here credentials for existing domain user. 
        # in my case domain is called domainName and user - user
        AuthLDAPBindDN "domainName\user"
        AuthLDAPBindPassword usersPassword
        # put here ip of the domain controler and full path to OU containing accounts
        AuthLDAPURL ldap://,dc=domainName,dc=companyName,dc=whatever?sAMAccountName?sub?(objectClass=*)
        Require valid-user
        SVNAutoversioning on

        AuthzSVNAccessFile /etc/apache2/svn_authz

make sure that apache loads ldap module:

cd /etc/apache2/mods-enabled
ln -s ../mods-available/authnz_ldap.load
ln -s ../mods-available/ldap.load
/etc/init.d/apache2 reload

make sure that apache can modify files in svn repository:

chown www-data:www-data -R /full/path/to/your/current/svn/directory

your svn_authz should contain rules telling who can access what. in my case:


* = rw

* =
@ops = rw

you can find out more about syntax for that file here.

if you reached that far - your users can check out from http://server.address/svn/ using any svn client [ tortoise/cmdline/visual svn ], they'll see all the history and continue reading/writing to it.

  • 1
    Using Apache may be acceptable if there are no other alternatives but as of right now we already have several svn:// URLs referenced throughout our internal forums and bugtracking software and would rather to contiue using those URLs. Also we've already opened up the associated ports for SVNServe in our firewall. If there was a way to run Appache along with IIS on my Windows Server 2003 box then this may be a realistic method to try although right now I'm more interested in how to get SVNServe to authenticate using ActiveDirectory.
    – jpierson
    Dec 7, 2009 at 19:16

You could use saslNTML instead of GSSAPI. The saslNTML dll is installed with TSVN by default, and I think it's also included in the svn client from collab.net.

there are two options you have to set in your sasl config file:


and optional


and of course you have to set the mech list in your config file to include NTML.

I've only tried this once with TSVN when I implemented the whole thing. But I had someone else set up a test server for me so I have no idea what the exact config options are.

  • Excellent, I'll try this out soon and see where I can get.
    – jpierson
    Dec 8, 2009 at 20:24
  • I've tried a number of things but I always get the following error within when trying to Check Out using TortoiseSVN. Error: Authentication error from server: SASL(-13): user not found: Unable to find a Error: callback: 2
    – jpierson
    Dec 10, 2009 at 17:26
  • "user not found" either means that the computer is not part of the domain you're trying to authenticate to or the user is not know on the domain. Maybe you can try to capture the network traffic and try to find out what's happening?
    – Stefan
    Dec 15, 2009 at 15:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .