Some of this information was first posted to the subversion users mailing list by Michael Kelley and can be read here. Please feel free to add to or correct this information.
I have configured an Apache 2.0.52 server for Subversion 1.1.1 running Windows 2000 Server SP4 as a domain member server. I want to use domain accounts to authenticate users and authorize access into my repositories. After a lot of trial-and-error testing and reading code for various Apache modules, I finally got it working so I thought I'd share what I learned. I have just completed moving our Subversion/Apache installation over to a new server running Windows Server 2003 and all these comments still apply.
I'm using the modified mod_auth_sspi module from http://www.deadbeef.com/index.php/mod_auth_sspi/sspi.html instead of the module distributed with Apache. I'm also loading the mod_authz_svn module that comes with the Windows binaries for Subversion.
My httpd.conf file contains this for my repository location:
<Location "/svn"> dav svn SVNParentPath "d:/svndav/repository" # our user authentication policy AuthName "SVN Server" AuthType SSPI SSPIAuth On SSPIAuthoritative On SSPIDomain MYDOMAINNAME #SSPIOfferBasic on #let non-IE clients authenticate #SSPIOmitDomain On # keep domain name in userid string # passed down to mod_authz_svn #Require valid-user # A Require directive may? prevent userid # strings from being passed down to mod_authz_svn # our access control policy enforced by mod_authz_svn AuthzSVNAccessFile "d:/svndav/svnaccess.conf" </Location>
Be sure that you have also loaded the appropriate modules in the LoadModule section:
LoadModule sspi_auth_module modules/mod_auth_sspi.so LoadModule dav_svn_module modules/mod_dav_svn.so LoadModule authz_svn_module modules/mod_authz_svn.so
I found that the AuthzSVNAccessFile needs to have MYDOMAINNAME\UserId account names in a precise, case-sensitive form. AuthzSVNAccessFile format could be found here. The domain name or machine name (for local user accounts) seems to always come down in all upper case or all lower case. The userid account names are also case sensitive. In my case, some domain accounts were prepared as LastnameFirstname (camel caps) while others were all lower case. Use a single backslash to separate MYDOMAINNAME\UserId. The mod_authz_svn checks are case-sensitive and you need to match character case exactly. If users manually enter their domain/userid information in response to an authentication pop-up dialog box, then the mod_authz_svn module will see the string exactly as entered.
I rebuilt mod_auth_sspi so I could log exactly what it thought the user account names were and was thinking of just forcing all domain and user names to lower case and then just specifying them as lower case only in the AuthzSVNAccessFile. I'd rather change mod_authz_svn so that it does case-insensitive compares under Windows which is how account names are handled and specified to work.
The stock mod_authz_svn also performs case-sensitive comparisons on the repository path names in your AuthzSVNAccessFile. This obviously makes sense for unix/linux clients, but is confusing for those of us brainwashed by Windows where path names are case-insensitive.
I've found that local user accounts on the server itself pass the mod_auth_SSPI authentication.
Additionally, I've observed that the userid strings passed down automatically to mod_authz_svn can have the domain names presented in all upper-case or in all lower-case letters. I don't know what causes this (authenticating against BDC instead of PDC? locally cached logins vs. actual domain authentication?). To work around this, I'm currently putting duplicate entries in my AuthzSVNAccessFile -- one with domain or machine names in all uppercase and another with domain or machine names in lower case.
What would be really nice is to have mod_authz_svn have some additional directives so that username and repository pathname comparisons can be specified to be case-insensitive. If you're in an all-Windows environment, case sensitivity doesn't make sense and confuses the administrators.
Hope this can help anyone else struggling with Windows domain account access control...