Multiple problems with LDAP and LDAPS
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.SunCertPathBuilderException: 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?(ObjectClass=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?
Hi there, I've raised this to our dev team for investigations. Thanks for being so thorough :)
Any word from the developers?
We're in the midst of prepping a release just now, so it may take a little while. I'll give them a nudge tomorrow though.
mattvanmater;129502Any word from the developers?Have the developers had a chance to review my comments?
Mand;129531We're in the midst of prepping a release just now, so it may take a little while. I'll give them a nudge tomorrow though.Any updates?
I'm experiencing the same thing. Can't login to uberSVN anymore now (though I can in Jenkins, Nexus and Sonar?). Very annoying! Any updates on this issue?
Ok, I've found a way to include the truststore in tomcat: In your setenv.sh (linux) add the following JVM options to JAVA_OPTS -Djavax.net.ssl.trustStore=/appl/sodrep/usr/share/java/jre/lib/security/cacerts -Djavax.net.ssl.trustStorePassword=changeit This instructs tomcat applications to use a trusted keystore. Unfortunately now I run into algorithm issues... I've added our certificate using: #openssl x509 -in ldaps.crt -text -noout openssl x509 -in ldaps.crt -outform der -out ldaps.der #openssl x509 -in ldaps.der -inform der -text -noout keytool -import -alias ldaps -keystore cacerts -file ldaps.der java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: Default, provider: SunJSSE, class: sun.security.ssl.SSLContextImpl$DefaultSSLContext) Suggestions anybody?
1-8 of 8
Reply to this discussion
You cannot edit posts or make replies: You should be logged in before you can post.