Wednesday, October 1, 2008

Subversion and NTLM with a Little Active Directory on Top

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.

Diagram of NTLM authentication via the domain for internal users and non AD NTLM authentication for external users.

The Setup

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.

<Location /SVN>
DAV svn
SVNParentPath "C:/SVN"
AuthName "SVN Server"
AuthType SSPI
SSPIAuth On
SSPIAuthoritative On
SSPIDomain [LocalMachine]
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.
#AuthzSVNAccessFile "C:/SVN/svnaccess.conf"
<LimitExcept GET PROPFIND OPTIONS REPORT>
Require group [LocalMachine]\SVNAccess
</LimitExcept>
</Location>

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.Local group on the Subversion/Apache machine that contains all the users/groups that have access to a particular virtual directory (the SVN root in this case).

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.

Of Note

  • 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.

God speed,
Tyler Holmes

6 comments:

Marc Gravell said...

For info, VisualSVN Server is free an offers NTML integrated via Apache out of the box, along with a management console (MMC) for setting ACLs etc.

Tyler Holmes said...

Great heads up Marc. I downloaded and played with VisualSVN Server in addition to watching a demo. It does a fantastic job of abstracting away all the Apache/SVN knowledge into a dead simple wizard.

I sure wish we'd known about it a couple years ago (were they around?) when we initially set up our subversion repository.

Anonymous said...

"Apache on the other hand can handle NTLM quite well so long as you install the SSPI Authentication module."


This sentence seems to be along the lines of the common misunderstanding that only Apache on Windows can authenticate seamlessly against Active Directory using NTLM. This is of course not true. On Unix/Linux you would use mod_ntlm which would give same result. It is quite old but battle proven. You could even use mod_ntlm on Windows if you wanted to.

Tyler Holmes said...

Thanks for the comment, and clearing up that Apache on Unix/Linux can also authenticate with NTLM. I didn't mean to imply that you're w/out options if you're not using a windows machine. The machine that was running SVN in this scenario just happened to be a windows box.

Thanks for commenting!

Anonymous said...

You write:
"Subversion itself is quite unaware of Active Directory and is unable to authenticate through NTLM"

Not anymore, as far as I understand. As of v1.5 of Subversion it uses the Cyrus SASL library to support various authentication methods natively ... among these are NTLM. This will provide NTML authenticatopn to not only the http/https transport (as is already possible today) but also to SVN's native transport (much faster).

J (Encrypted Flash Drive Guy) said...

Diagram helps me to understand the scenario in details. And it's a great idea to have reverse proxy use https and encrypt the channel. Tools like Apache and Subversion definitely allow happening even with constantly shrinking budgets.