Repository fails at authentication

Hello,    I successfully installed ubersvn-64-1302 on Red Hat Enterprise Linux 5.6. I have set up the LDAP connection and successfully imported the users. I have created a test repository, where I granted r/w permission only a particular user; unchecked the anonymous read, so only this user should have read and write access, no further user has no rights.    Authentication is set to use the same LDAP connection, set as authorative, require valid-user. Please note, that the LDAP is an MS AD.    When I try to    svn co --username https://svn.mycorp.com:9880/tst    it asks for password, then client sends:        and after 1-2 mins, got back 500 Internal Server Error in response to OPTIONS.    the client is svn 1.6.3 r38063.    How can I know what happened? I cannot find any useful in the logs. Please advise.    Cheers,    Tamas

Last updated 10 years ago

Hi,   What SVN client are you using?  It might be best to try and setup the repository with basic uberSVN authentication first, just to test that the configuration works before bringing LDAP into the mix.

With internal authentication works like charm: now what should I do to get working the LDAP? I'm very interested in the SVN Access Control, and I'd like to make some progress to evaluate it.

Can you show us your LDAP location settings in uberSVN?

It can be similar to:  ldap://ldap.server:389/dc=tstdc,dc=tstcorp,dc=com?sAMAccountName?sub?(&(!(userAccountControl:1.2.840.113556.1.4.803:=2))(objectClass=person)(employeeType=*)(employeeNumber=*)(memberOf=CN=svn_users,OU=Distribution Groups,OU=_Global,OU=tstou,DC=tstdc,DC=tstcorp,DC=com))  and please note that I was able to import the users from it. Any idea?

OK, what other settings do you have in the LDAP location screen? The above query worked to retrieve users when you first tested this right?

I have attached all details because BB tried to strip and encode a lot of elements.

There doesn't look to be anything wrong with that tbh. The fact that it pulls your test user in shows that the user exists and that the LDAP connection is working.   Can you show us the contents of 50-repositories.conf, and 35-ldap.conf (again, remove any sensitive data, or feel free to PM me the contents)?

The contents of the error log would help too.

Hello,    The configuration is attached (and removed sensitive data).    When I want to svn co:    Running post_send hooks  ah_post_send (#1), code is 500 (want 401), WWW-Authenticate is (none)  Request ends, status 500 class 5xx, error line:  500 Internal Server Error  Running destroy hooks.  Request ends.  svn: Server sent unexpected return value (500 Internal Server Error) in response to OPTIONS request for 'https://ubersvn.tst.com:9880/tst'  sess: Destroying session.  sess: Destroying session.    the only log what can I find here:    tail -f ubersvn/data/logs/*    ==> ubersvn/data/logs/catalina.out <==  [20 Mar 2013 13:38:22] INFO - Fetching tweets from ubersvn    ==> ubersvn/data/logs/ubersvn.log <==  [20 Mar 2013 13:38:22] INFO (?:?) - Fetching tweets from ubersvn    ==> ubersvn/data/logs/catalina.out <==  [Fatal Error] :58:3: The element type "meta" must be terminated by the matching end-tag "".  [20 Mar 2013 13:43:24] INFO - Fetching tweets from ubersvn   [Fatal Error] :58:3: The element type "meta" must be terminated by the matching end-tag "".    ==> ubersvn/data/logs/ubersvn.log <==  [20 Mar 2013 13:43:24] INFO (?:?) - Fetching tweets from ubersvn    ==> ubersvn/data/logs/catalina.out <==  [20 Mar 2013 13:48:24] INFO - Fetching tweets from ubersvn   [Fatal Error] :58:3: The element type "meta" must be terminated by the matching end-tag "".    ==> ubersvn/data/logs/ubersvn.log <==  [20 Mar 2013 13:48:24] INFO (?:?) - Fetching tweets from ubersvn    so this is quite odd, no usable error message,    when I try to:    /usr/bin/ldapsearch -x -H ldap://ldap.tst.com/ -b "dc=xxx,dc=xxx,dc=xxx" -D 'CN=Test\, User,OU=Standard users,OU=Users,OU=xxx,OU=xxx,DC=xxx,DC=xxx,DC=xxx' -W '(&(objectClass=user)(employeeNumber=*)(employeeType=*)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))' samaccountname    It can bind to the LDAP w/o any glitch and gives back the logins correctly; so I don't see any issue with the LDAP connection/bind.    Any idea?

You should have a bunch more logs available, specifically access_log, error_log, svn_logfile.

A couple of further points: - if the apache error logs are not in ubersvn/data/logs its worth checking what the contents of ubersvn/conf/httpd.conf are as you'll find the error log location there.  - we don't sell Access Control as an app in uberSVN anymore, we do sell Access Control as a standalone product though. I can put you in touch with our sales team if you'd like to investigate that more?