When Different Tools Fit in the Same Belt
I'm a big fan of Subversion when it comes to source control. It's feature rich, the price is the best kind (free as in freedom), and it has some great UI options which help developers learn/explore the repository without too steep a learning curve.
I currently work in a (mostly) .NET shop which means we have precious few BSD/Linux distros kicking around, and we also do pretty much all of our authentication via NTLM and Active Directory. Here's a story of some unlikely tools working unexpectedly well together.
Eclectic Authentication Scenario
We wanted to do the following:
- Allow certain NT Users in given Active Directory groups to access the repository.
- Allow certain outside (non company employees) users to access the repository. These users would not have an AD account and get in via a proxy pass.
- Disallow all other users.
The diagram below tries to summarize the scenario. It's worth mentioning that I'm only going to go over the steps for setting up Subversion/Apache to work with NTLM for domain and local accounts. The whole Apache/ISA reverse proxy is a little big for me to get into in this post. That, and I'd probably end up messing it up anyway. Onward.
This is a potential solution to the problem (a.k.a. what we did). I'm positive there are some Subversion experts out there that are deeper with the tool and could come up with a cleaner solution. That being said, I couldn't find any of their blogs.
It's worth mentioning that in this solution all the authentication needs to be done through Apache, Subversion itself is quite unaware of Active Directory and is unable to authenticate through NTLM. Apache on the other hand can handle NTLM quite well so long as you install the SSPI Authentication module.
Ok. Lets get to it.
1. On some Win2k3 machine download and install Apache/Subversion, a good walkthrough for this can be found here. This includes installing the SSPI Apache mod.
2. Backup and then change the <Location> element in your Apache httpd.conf file.
AuthName "SVN Server"
SSPIOmitDomain Off #Require users to use [domain]\username
SSPIOfferBasic On #Required for TortoiseSVN to get at repository
#it does't support NTLM.
SSPIUsernameCase lower #Allows you to give username in lower case.
#SSLRequireSSL (Not a bad idea, if interested read this)
#We limit access by virtual directory instead of svn access file.
<LimitExcept GET PROPFIND OPTIONS REPORT>
Require group [LocalMachine]\SVNAccess
3. Define a local group on the subversion machine (SVNAccess in this case) that allows both domain groups and local users to access the repository. All internal users will get authorized because of their AD Group membership, all external users will get authorized because of their local group membership.
That's it you're done! Users will now be logging in with either their domain\username credential (if they have one) or a [machinename]\username if they're an external user.
- It's a darn good idea to have your reverse proxy use https and encrypt the channel, especially if our Tortoise SVN client is using basic authentication (read username/passwords sent in clear text).
- If you don't have all this internal/external user business then you can just omit step number 3 and potentially add one or more domain groups setting the SSPI Domain [DOMAINNAME] and then adding multiple Require group entries like so.
Especially these days IT departments are being asked to do more with less. Tools like Apache and Subversion definitely allow that to happen even with constantly shrinking budgets. Hopefully your creativeness an ingenuity continue to grow as your budget shrinks.