ubersvn version: #12.11-2086 SVN - 1.7, fully patched
OS: Ubuntu Server x64 10.0.4.4 LTS, fully patched
Browser: Chrome, fully patched
We are running Active Directory on Windows Server 2008, and have both LDAP and LDAPS (self-signed cert) enabled and working with other applications. I have spent several hours on this problem and am confident the problem lies with UberSVN and not my configuration parameters.
I have identified multiple problems with LDAP integration in UberSVN...
Problem 1 - LDAPS
Simply put, LDAPS integration does not work. If I configure the following parameters
LDAP URL: ldaps://10.0.0.2:636/OU=Office,DC=MYDOMAIN,DC=COM
LDAP Settings --> Apache Encryption Settings
LDAP Encryption Mode = SSL
Verify Server Certificate = No
Save, apply configuration changes
Click Retrieve Users button
Error message: Test LDAP Connection has failed - see log for details
It is unclear which log exactly the error message is referring to (recommend you clarify the error message), but the ubersvn.log file has messages implying the certificate isn't trusted... which I interpret as the server setup not honoring the "Verify Server Certificate = No" setting described above (even though I have confirmed it exists in the underlying configuration file). An excerpt is below:
[17 Jan 2013 09:59:05] INFO (?:?) - Updating httpd ldap conf file /opt/ubersvn/conf/conf.d/35-ldap.conf
[17 Jan 2013 09:59:05] INFO (?:?) - Updating httpd repo location conf file /opt/ubersvn/conf/conf.d/50-repositories.conf
[17 Jan 2013 10:00:45] INFO (?:?) - sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderE xception: unable to find valid certification path to requested target
[17 Jan 2013 10:00:45] INFO (?:?) - Unable to establish connection to LDAP server.
I beleive the "Verify Server Certificate = No" setting above is intended for use in BOTH LDAP as well as Java / Tomcat but that doesn't seem to be the case.
Problem 2- Buggy LDAP setup, makes it unusable
If I use the configuration below, I am able to retreive user attributes as expected from our directory. If I "Use LDAP for uber login authentication", I can log in to the UberSVN administration using the sAMAccountName and my password. However, if I configure a repository for LDAP / Active Directory Authentication, login attempts to that repo result in a 500 Internal Server Error. Switching back to Authentication = "uberSVN Internally Managed" allows the repo to load in a browser and local user to authenticate just fine.
ldap://10.0.0.2:389/OU=Office,DC=MYDOMAIN,DC=COM?sAMAccountName?sub?(O bjectClass=User)
Bind User DN: CN=UberSVN Service Account,CN=Users,DC=MYDOMAIN,DC=com
First Name Attribute: gn
Last Name Attribute: sn
Email Address Attribute: mail
As a bit of crazy luck, I had a typo and tried with the following setting
LDAP URL: ldap://10.0.0.2:389/OU=Office,DC=MYDOMAIN,DC=COM?sn
and after testing the connection ubersvn shows the username is the user's surname attribute that is fetched from AD (i.e. the user's last name, case sensitive), and I am able to log in to the repo!
Perhaps UberSVN's underlying configuration doesn't like usernames that have a period character such as "firstname.lastname"? Feature request: it would be nice to be able to explicitly specify that the username = sAMAccountName. UberSVN seems to be doing something funky to derive the username used for login, so that may be related to this problem.
Is there any other information you need to reproduce this in your lab?
OS: Ubuntu Server x64 10.0.4.4 LTS, fully patched
Browser: Chrome, fully patched
We are running Active Directory on Windows Server 2008, and have both LDAP and LDAPS (self-signed cert) enabled and working with other applications. I have spent several hours on this problem and am confident the problem lies with UberSVN and not my configuration parameters.
I have identified multiple problems with LDAP integration in UberSVN...
Problem 1 - LDAPS
Simply put, LDAPS integration does not work. If I configure the following parameters
LDAP URL: ldaps://10.0.0.2:636/OU=Office,DC=MYDOMAIN,DC=COM
LDAP Settings --> Apache Encryption Settings
LDAP Encryption Mode = SSL
Verify Server Certificate = No
Save, apply configuration changes
Click Retrieve Users button
Error message: Test LDAP Connection has failed - see log for details
It is unclear which log exactly the error message is referring to (recommend you clarify the error message), but the ubersvn.log file has messages implying the certificate isn't trusted... which I interpret as the server setup not honoring the "Verify Server Certificate = No" setting described above (even though I have confirmed it exists in the underlying configuration file). An excerpt is below:
[17 Jan 2013 09:59:05] INFO (?:?) - Updating httpd ldap conf file /opt/ubersvn/conf/conf.d/35-ldap.conf
[17 Jan 2013 09:59:05] INFO (?:?) - Updating httpd repo location conf file /opt/ubersvn/conf/conf.d/50-repositories.conf
[17 Jan 2013 10:00:45] INFO (?:?) - sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderE xception: unable to find valid certification path to requested target
[17 Jan 2013 10:00:45] INFO (?:?) - Unable to establish connection to LDAP server.
I beleive the "Verify Server Certificate = No" setting above is intended for use in BOTH LDAP as well as Java / Tomcat but that doesn't seem to be the case.
Problem 2- Buggy LDAP setup, makes it unusable
If I use the configuration below, I am able to retreive user attributes as expected from our directory. If I "Use LDAP for uber login authentication", I can log in to the UberSVN administration using the sAMAccountName and my password. However, if I configure a repository for LDAP / Active Directory Authentication, login attempts to that repo result in a 500 Internal Server Error. Switching back to Authentication = "uberSVN Internally Managed" allows the repo to load in a browser and local user to authenticate just fine.
ldap://10.0.0.2:389/OU=Office,DC=MYDOMAIN,DC=COM?sAMAccountName?sub?(O bjectClass=User)
Bind User DN: CN=UberSVN Service Account,CN=Users,DC=MYDOMAIN,DC=com
First Name Attribute: gn
Last Name Attribute: sn
Email Address Attribute: mail
As a bit of crazy luck, I had a typo and tried with the following setting
LDAP URL: ldap://10.0.0.2:389/OU=Office,DC=MYDOMAIN,DC=COM?sn
and after testing the connection ubersvn shows the username is the user's surname attribute that is fetched from AD (i.e. the user's last name, case sensitive), and I am able to log in to the repo!
Perhaps UberSVN's underlying configuration doesn't like usernames that have a period character such as "firstname.lastname"? Feature request: it would be nice to be able to explicitly specify that the username = sAMAccountName. UberSVN seems to be doing something funky to derive the username used for login, so that may be related to this problem.
Is there any other information you need to reproduce this in your lab?