There are rich resources on the Internet to help newbies to setup a SVN repository on Windows within domain:
- Subversionary - Setting Up A Server on Windows and Windows Domain Authentication
- Lifehacker - How to set up a personal home Subversion server
- Subversion Official Doc. - Chapter 6. Server Configuration
However, there is lack of resource to talk about the problems when using domain authentication with Subversion.
There are two common cases those most people have asked on the forum or mailing list:
svn: PROPFIND request failed on '\svn'
svn: PROPFIND of '\svn': authorization failed (http://localhost/)
or
svn: PROPFIND request failed on '\svn'
svn: PROPFIND of '\svn': 403 Forbidden (http://localhost/)
This article will show the common problems may occur when using domain authentication with Subversion. Different settings in httpd.conf and AuthzSVNAccessFile may produce different result by different access clients. I will try to list all the combinations and result with explanation. I hope these can help you to escape from the nightmare error messages above.
Scenario
- Domain Controller
- IP is 192.168.10.1
- To maintain domain "MyDomain"
- Windows 2000 Server with computer name DOMAINSERVER.MyDomain
- SVN Server
- IP is 192.168.10.100
- Member of MyDomain
- Windows XP Pro SP2 running Subversion 1.4.0 and Apache 2.0.59 with mod_auth_sspi module.
- Physical path of SVN repository is E:\SVNRepos and control file location at E:\SVNRepos\svnaccess.conf
- SVN Client
- IP is 192.168.10.111
- Member of MyDomain
- Windows XP Pro SP2 running Subversion 1.4.0 and TortoiseSVN 1.4.0 installed
Assume my httpd.conf file contains this for my repository location:
<Location "/svn">
DAV SVN
SVNPath E:\SVNRepos
# our user authentication policy
AuthName "SVN Server"
AuthType SSPI
SSPIAuth On
SSPIAuthoritative On
SSPIDomain MyDomain
# The below options will be used in testing later
# SSPIOfferBasic On
# SSPIUsernameCase lower
# SSPIOmitDomain On
# our access control policy enforced by mod_authz_svn
AuthzSVNAccessFile "E:\SVNRepos\svnaccess.conf"
# only authenticated users may access the repository
Require valid-user
</Location>
and svnaccess.conf is showed below
# To allow the domain user "michael" to access different projects in the repository
[/Project1]
MyDomain\michael = rw
[/Project2]
mydomain\michael = rw
[/Project3]
michael = rw
Factors
Many user may use one or hybrid of the below options to configure their Subversion.
- To enable SSPIOfferBasic for allowing more type of client application to access the SVN repository.
- To use SSPIUsernameCase to eliminate case-sensitive typos of domain and username.
- To enable SSPIOmitDomain for omitting the domain prefix inputted in username.
However, many newbies are annoying with 403 Forbidden and Authorization Failed issue after applying these tricks.
So result tables of different settings in httpd.conf is generated and provide comparison with different factors showed below:
- Different usernames (i.e. MyDomain\michael, mydomain\michael, michael, etc)
- Different client applications (i.e. IE and non-IE including TortoiseSVN, svn.exe and Firefox)
- Options' setting in httpd.conf (i.e. SSPIOfferBasic, SSPIOmitDomain, SSPIUsernameCase,
and apache directive Require)
These may help the users to know where their problem is and how to change their setting to meet the target.
Methods
Login SVN Client as local administrator and run the following three tests for each project:
-
svn.exe, list command will be used to test, as below
svn list --username <username> --password <password> http://192.168.10.100/svn/ProjectX
-
TortoiseSVN, Repo-browser will be used to test, as below
*According to the documentation of TortoiseSVN. It is same as the list command without any authentication information provided
-
Browser - IE / Firefox, the HTTP authentication prompt may be popup, as below
Then to change the setting in httpd.conf one by one. Result tables will be recorded from the above test method after each change.
Results
-
Default Setting
*Browsers MyDomain\michael mydomain\michael michael Project1 ok 403 Forbidden Authorization Required Project2 403 Forbidden ok Authorization Required Project3 403 Forbidden 403 Forbidden Authorization Required svn.exe MyDomain\michael mydomain\michael michael Project1 Authorization Failed Project2 Project3 TortoiseSVN MyDomain\michael mydomain\michael michael Project1 Authorization Failed
Project2 Project3 To see the result in Browser part. As we know that windows domain authentication is always non case-sensitive. So both MyDomain\michael and mydomain\michael can be recognized as domain user "michael". However, the authentication provided by module mod_authz_svn is case-sensitive. This proves that authorization information provided must follow the setting in svnaccess.conf case-sensitively for successful access.
All the result in svn.exe and TortoiseSVN part are authorization failed. This will be discussed in the next test.
* Please remind that some non-IE browser (i.e. Firefox = FF) may treat URL as case-sensitive. For example, if http://192.168.10.100/svn/project1 is used to test in FF, then it will reply "The requested URL /svn/project1/ was not found on this server".
-
Enable SSPIOfferBasic (Uncommented SSPIOfferBasic On in httpd.conf)
Browsers MyDomain\michael mydomain\michael michael Project1 ok 403 Forbidden Authorization Required Project2 403 Forbidden ok Authorization Required Project3 403 Forbidden 403 Forbidden Authorization Required svn.exe MyDomain\michael mydomain\michael michael Project1 ok 403 Forbidden Authorization Required Project2 403 Forbidden ok Authorization Required Project3 403 Forbidden 403 Forbidden Authorization Required **TortoiseSVN MyDomain\michael mydomain\michael michael Project1 ok 403 Forbidden Authorization Required Project2 403 Forbidden ok Authorization Required Project3 403 Forbidden 403 Forbidden Authorization Required According to the documentation provided by mod_auth_sspi, to set SSPIOfferBasic On will allow the client to authenticate against NT with 'Basic' authentication instead of using the NTLM protocol. i.e. the SVN server will accept the clients (svn.exe and TortoiseSVN) those haven't used NTLM protocol to access the SVN Repository thought 'Basic' authentication.
That means SSPIOfferBasic must be enabled in httpd.conf for non-browser type clients to access the SVN Server thought domain authentication.
All the clients have the same result because of the authorization setting in svnaccess.conf.
** Normally, TortoiseSVN will popup a dialog to ask for username/password. However, you may not ever see that dialog before browsing in the repository. It is because Subversion has Client Credentials Caching. It is a built-in system for caching authentication credentials on disk provided by Subversion. It is annoying when I am doing different user login test. So cache is deleted before every user login test.
-
Set SSPIUsernameCase lower (Uncommented SSPIUsernameCase lower in httpd.conf)
Browsers MyDomain\michael mydomain\michael ***michael Project1 403 Forbidden 403 Forbidden 403 Forbidden Project2 ok ok ok Project3 403 Forbidden 403 Forbidden 403 Forbidden svn.exe MyDomain\michael mydomain\michael michael Project1 403 Forbidden 403 Forbidden 403 Forbidden Project2 ok ok ok Project3 403 Forbidden 403 Forbidden 403 Forbidden TortoiseSVN MyDomain\michael mydomain\michael michael Project1 403 Forbidden 403 Forbidden 403 Forbidden Project2 ok ok ok Project3 403 Forbidden 403 Forbidden 403 Forbidden Both MyDomain\michael and mydomain\michael can access Project2. It is because username (include domain prefix) will be converted to lower case before doing authentication when SSPIUsernameCase lower is set. Then MyDomain\michael will become mydomain\michael after lower case conversion. So MyDomain\michael is authorized to access the Project2 in this case.
SSPIUsernameCase is a useful option to eliminate inconsistent case input of the client users. The client users are also no need to remember different case used in the domain name. Besides SSPIUsernameCase lower, SSPIUsernameCase upper works in the same concept but upper case conversion. However, the case used in svnaccess.conf must keep consistent when SSPIOmitDomain is used.
***Actually, I expect michael can't access any project in the server but the result is unexpected. However, it is true in testing. I am still finding why it behaved in this way. I think that may be the problem of my apache setting. If you have any idea, please update me. Thanks.
-
Enable SSPIOmitDomain (Uncommented SSPIOmitDomain On in httpd.conf)
Browsers MyDomain\michael mydomain\michael michael Project1 403 Forbidden 403 Forbidden 403 Forbidden Project2 403 Forbidden 403 Forbidden 403 Forbidden Project3 ok ok ok svn.exe MyDomain\michael mydomain\michael michael Project1 403 Forbidden 403 Forbidden 403 Forbidden Project2 403 Forbidden 403 Forbidden 403 Forbidden Project3 ok ok ok TortoiseSVN MyDomain\michael mydomain\michael michael Project1 403 Forbidden 403 Forbidden 403 Forbidden Project2 403 Forbidden 403 Forbidden 403 Forbidden Project3 ok ok ok All username can access Project3 but not the other two. The result shows that domain prefix in the username will be omitted when SSPIOmitDomain is enabled. MyDomain\michael, mydomain\michael and michael are treated as user michael in MyDomain (option SSPIDomain in httpd.conf).
According to the authorization setting in svnaccess.conf, michael is allowed to access Project3 but not the other two. Any user has domain prefix in svnaccess.conf will never be matched because domain is omitted before authorization. i.e. michael will not match MyDomain\michael or mydomain\michael.
The reason of same result in all clients has already been explained in Result Table 2.
Conclusion
Please remind that svnaccess.conf didn't have any changed in all tests above. It is because the format of svnaccess.conf is straight forward. It must be properly setup before embedded Subversion access with Apache. Just remind to keep consistent case in svnaccess.conf with option of SSPIUsernameCase used is ok.
It is not a Q&A style article to help you to solve your problem but it may help you to locate where the problem is. If you get the idea about that from the above result table, it is great! I will feel very happy about that.
However, the troubles of using domain authentication in Subversion is not completely listed. You may find that Linux-based SVN client, Domain-login environment and related apache directive haven't discussed here. So it may be useless if the problem is located under a complex environment.
At the beginning, I want to share my experience and do a general summary of cases on domain authentication in Subversion, but I found that the scope is too large for one person to do. I will try my best to update the information in this article after I do more testing later.
Of course. I appreciate you to share your experience with me. Happy sharing, everybody! cheers
