[users@httpd] Apache, ActiveDirectory & SVN security config

[Stephen Moretti <st...@gmail.com>]

Hi there,

We've recently changed how we manage users and access to our Trac and SVN
repositories to use ActiveDirectory.
Its working pretty well except that we have two small problems with the SVN
configuration in apache.

I'll start at the beginning and describe the "rule set" and config we have.

Everyone in the company is allowed to check code out of any repository as
long as they have a valid user.
There are two distribution groups in Activity Directory that are used to
check permissions against for a project.
The first is "Tech Leads".  If you a member of the "Tech Leads" group you
have read/write access to every SVN repo regardless of project group
membership.
The second is a [projectname]dev group.  If you are a member of this group
then you have read/write access to the [projectname] repo.
If you aren't logged in you should not have access to read or write to a
repository.

We currently have over 50 repos/trac environments, so I've got a set of
scripts for automating creation of new client/project installations, as well
as some wild card inclusion of config files to help us manage all this
config.

Starting at the top we have a VirtualHost

<VirtualHost *:80>
>     ServerAdmin webmaster@localhost
>     ServerName svn.dev.enigma.lan
>     ServerAlias central
>
>     LoadModule wsgi_module modules/mod_wsgi.so
>     LoadModule dav_svn_module modules/mod_dav_svn.so
>     LoadModule authz_svn_module modules/mod_authz_svn.so
>
>     DocumentRoot d:/SourceControl/wwwroot
>     <Directory d:/SourceControl/wwwroot>
>     Order allow,deny
>     Allow from all
>     </Directory>
>
>     ErrorLog "|D:/SourceControl/logs/rotatelogs.exe
> D:/SourceControl/logs/error.svn.log 86400"
>     CustomLog "|D:/SourceControl/logs/rotatelogs.exe
> D:/SourceControl/logs/access.svn.log 86400" combined
>
>     Include D:/SourceControl/conf/subversion_ad.conf
>     Include D:/SourceControl/conf/trac_ad.conf
> </VirtualHost>
>

Then we have a top level config files for subversion and trac.

The subversion config looks like this :

<Location /svn/>
>
>     AuthType Basic
>      AuthBasicProvider ldap
>     AuthzLDAPAuthoritative off
>     AuthName "Enigma Subversion"
>     AuthLDAPURL
> "ldap://ad.enigma.lan:389/DC=enigma,DC=lan?sAMAccountName?sub?(objectClass=*)"
> NONE
>     AuthLDAPBindDN
> "CN=SVNAuth,OU=SBSUsers,OU=Users,OU=MyBusiness,DC=enigma,DC=lan"
>     AuthLDAPBindPassword "OURPASSWORD"
>
>     Require valid-user
>  </Location>
>
>  Include D:/SourceControl/conf/location/*.conf
>
>  CustomLog D:/SourceControl/logs/svn_logfile.log "%t %u %{SVN-ACTION}e"
> env=SVN-ACTION
>

 The locations folder contains one config file for each repo, so that we can
point and protect each repo based on ldap-groups these look like this :

<Location "/svn/CORE">
>     DAV svn
>     SVNPath D:/SourceControl/svnrepos/CORE
>
>     <LimitExcept GET PROPFIND OPTIONS REPORT>
>     Require ldap-group CN=COREdev,OU=Distribution
> Groups,OU=MyBusiness,DC=enigma,DC=lan
>     Require ldap-group CN=Tech Leads,OU=Distribution
> Groups,OU=MyBusiness,DC=enigma,DC=lan
>     Satisfy any
>     </LimitExcept>
>
> </location>
>

So the problems :

We're finding that developer/designers who use TortoiseSVN are getting a
401  "unauthorised" on PROPFIND, but GET doesn't get denied.  If we switch
GET and PROPFIND they get a 401 on OPTIONS.  This problem doesn't occur
using the web browser or subversive, because they only do a GET or a
PROPFIND at the appropriate times unlike TortioseSVN which seems to "spam"
the server for information when you request a file/directory.

The second issue we're having:
Previously developers had to register and set a password specifically for
subversion and trac, so invariably they set the password as something
different to their normal login (No bad thing really). With the change to
use AD for user validation their stored passwords for repo's are now
incorrect. The problem we've found is that if a developer has an incorrect
password, their login via SVN is denied, but they can still commit into the
repo, but it now comes up as "no author"/anonymous.  Obviously this is
bad....

Myself and a colleague have tried a whole bunch of tweaks that usually end
up with denying access to the repo completely.

Any suggestions anyone might have or if you can see anything that we've
completely looked passed/through would be gratefully received.

Regards

Stephen
PS. The work we've done on this config is based on this article :
http://www.jejik.com/articles/2007/06/apache_and_subversion_authentication_with_microsoft_active_directory/


-- 
Stephen Moretti
Blog : http://nil.checksite.co.uk/
Twitter : http://twitter.com/mr_nil
EE: http://beta.experts-exchange.com/M_1167123.html