How can I switch an existing set of Subversion repositories to use ActiveDirectory? (svnserve/windows)

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?

Solution 1:

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.

Solution 2:

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://10.11.22.33:389/ou=Users,dc=domainName,dc=companyName,dc=whatever?sAMAccountName?sub?(objectClass=*)
        Require valid-user
        SVNAutoversioning on

        AuthzSVNAccessFile /etc/apache2/svn_authz
</Location>

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:

[groups]
ops=jack.brown,john.smith

[/]
* = rw

[/priv]
* =
@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.

Solution 3:

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:

ntml_server

and optional

ntml_v2

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.