• Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Critical Critical
    • ldap-plugin
    • Linux

      Running Jenkins 1.565.1, LDAP plugin 1.10.2.

      I found multiple topics on this subject, but none of them seem to solve my problem.

      I am trying to set up LDAP authentication on my Jenkins in my corporate network. Jenkins is running on Linux.
      Here are my LDAP settings:

      Server: ldap://my_server.abc.corp.company.com
      root DN: dc=abc,dc=corp,dc=company,dc=com
      manager DN: my_name@abc.corp.company.com
      manager password: set

      Other settings are blank/default.
      When I try to login to Jenkins, even using the same "manager" login, I get a failure, and see the following error in the Jenkins log:

      org.acegisecurity.providers.ldap.authenticator.BindAuthenticator2 handleBindException
      WARNING: Failed to bind to LDAP: userDnCN=my_name,OU=UserPersonalities,OU=site,OU=UNIX,OU=A Name With Spaces,OU=Resources,dc=abc,dc=corp,dc=company,dc=com username=my_name
      javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903A8, comment: AcceptSecurityContext error, data 52e, v1db1]

      I found a Groovy script that was supposed to help me debug the issue:
      String[] names = ["my_name","another_name"];
      for (name in names) {
      println("Checking the name '" + name + "'...")
      try

      { println(" It is a USER: " + Jenkins.instance.securityRealm.loadUserByUsername(name)) }

      catch (Exception e)

      { println(" It is NOT a user, reason: " + e.getMessage()) }

      println("");
      }

      However, it can find the username successfully:
      Checking the name 'my_name'...
      It is a USER: org.acegisecurity.userdetails.ldap.LdapUserDetailsImpl@5a26cfb7

      Checking the name 'another_name'...
      It is a USER: org.acegisecurity.userdetails.ldap.LdapUserDetailsImpl@143fee62

      Moreover, I can successfully authenticate using the Active Directory plugin, but its performance is very low (it takes 1-2 minutes to authorize a user), and I don't see any setting to tweak that.

          [JENKINS-24623] LDAP AcceptSecurityContext error

          Daniel Beck added a comment -

          This report does not show that the observed behavior is in fact a bug, therefore resolving as Not A Defect.

          Please direct requests for assistance (e.g. in configuring Jenkins) to the jenkinsci-users mailing list, or #jenkins on Freenode.

          Daniel Beck added a comment - This report does not show that the observed behavior is in fact a bug, therefore resolving as Not A Defect. Please direct requests for assistance (e.g. in configuring Jenkins) to the jenkinsci-users mailing list, or #jenkins on Freenode.

          Alex Vesely added a comment - - edited

          Why is it not a bug? The configuration seems to be correct (tested with the Active Directory plugin), but authentication fails with a nonsensical stack-trace. Authentication is successful from the settings, but the same credentials fail on the Login screen.

          Alex Vesely added a comment - - edited Why is it not a bug? The configuration seems to be correct (tested with the Active Directory plugin), but authentication fails with a nonsensical stack-trace. Authentication is successful from the settings, but the same credentials fail on the Login screen.

          Daniel Beck added a comment -

          A simple web search for the error reveals that error 59, data 0x52e indicates invalid credentials (e.g. this or this), and based on the documentation for manager DN you're entering the value in a wrong format. Don't know about you, but that looks like a configuration error to me.

          Daniel Beck added a comment - A simple web search for the error reveals that error 59, data 0x52e indicates invalid credentials (e.g. this or this ), and based on the documentation for manager DN you're entering the value in a wrong format . Don't know about you, but that looks like a configuration error to me.

          Alex Vesely added a comment -

          After analyzing my LDAP hierarchy, I devised the correct manager DN in the format described in your link:
          CN=My Full Name,OU=Workers,DC=abc,DC=corp,DC=company,DC=com

          However, that did not change the behavior at all.
          The plugin prints no errors on the configuration, thus implying that the configuration is correct and that it can successfully login to the LDAP server. The Groovy script I posted above also confirms that: it can validate user names successfully.

          But when I try to login to Jenkins, I see the following behavior:

          • Logging in with a BAD username: login fails, Jenkins log is clean
          • Logging in with a GOOD username: whether the password is good or bad, I get the same stacktrace in the Jenkins log.

          In summary: the username is identified to be correct, the password is also correct (as it is the manager password), but login is still impossible.

          Alex Vesely added a comment - After analyzing my LDAP hierarchy, I devised the correct manager DN in the format described in your link: CN=My Full Name,OU=Workers,DC=abc,DC=corp,DC=company,DC=com However, that did not change the behavior at all. The plugin prints no errors on the configuration, thus implying that the configuration is correct and that it can successfully login to the LDAP server. The Groovy script I posted above also confirms that: it can validate user names successfully. But when I try to login to Jenkins, I see the following behavior: Logging in with a BAD username: login fails, Jenkins log is clean Logging in with a GOOD username: whether the password is good or bad, I get the same stacktrace in the Jenkins log. In summary: the username is identified to be correct, the password is also correct (as it is the manager password), but login is still impossible.

            Unassigned Unassigned
            alex01ves Alex Vesely
            Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: