Multiple problems with LDAP and LDAPS

mattvanmater
mattvanmater
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?

Last updated

Mand
Mand
Hi there,   I've raised this to our dev team for investigations. Thanks for being so thorough :)
mattvanmater
mattvanmater
Any word from the developers?
Mand
Mand
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
mattvanmater
mattvanmater;129502Any word from the developers?
   Have the developers had a chance to review my comments?
mattvanmater
mattvanmater
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?
Pim
Pim
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?
Pim
Pim
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.