Announcement

Collapse
No announcement yet.

Multiple problems with LDAP and LDAPS

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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.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?

  • #2
    Hi there,

    I've raised this to our dev team for investigations. Thanks for being so thorough

    Comment


    • #3
      Any word from the developers?

      Comment


      • #4
        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.

        Comment


        • #5
          Originally posted by mattvanmater View Post
          Any word from the developers?
          Have the developers had a chance to review my comments?

          Comment


          • #6
            Originally posted by Mand View Post
            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.
            Any updates?

            Comment


            • #7
              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?

              Comment


              • #8
                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?

                Comment

                Working...
                X