Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-43994

Test LDAP Settings not binding as the user being tested?

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Trivial
    • Resolution: Fixed
    • Component/s: ldap-plugin
    • Labels:
      None
    • Environment:
      Jenkins 2.46.1
      ldap-plugin 1.15
    • Similar Issues:

      Description

      When I configure the plugin and then use the Test LDAP Settings button and enter my credentials I get the following successful checks:

      Login
      Authentication: successful
      User ID: brian
      User Dn: uid=brian,cn=users,cn=accounts,dc=example,dc=com
      User Display Name: Brian J Murrell
      User email: brian.murrell@example.com
      LDAP Group membership:
      admins
      Replication Administrators
      Add Replication Agreements
      Modify Replication Agreements
      Remove Replication Agreements
      Modify DNA Range
      Read PassSync Managers Configuration
      Modify PassSync Managers Configuration
      Read LDBM Database Configuration
      Add Configuration Sub-Entries
      Read DNA Range
      System: Read Replication Agreements
      Host Enrollment
      System: Add krbPrincipalName to a Host
      System: Enroll a Host
      System: Manage Host Certificates
      System: Manage Host Enrollment Password
      System: Manage Host Keytab
      463232e8-8595-11e6-a87e-00163e3c41db
      ipausers
      477eee16-8595-11e6-bc28-00163e3c41db
      foo-devs
      foo-jenkins-admin
      ROLE_ADMINS
      ROLE_REPLICATION ADMINISTRATORS
      ROLE_ADD REPLICATION AGREEMENTS
      ROLE_MODIFY REPLICATION AGREEMENTS
      ROLE_REMOVE REPLICATION AGREEMENTS
      ROLE_MODIFY DNA RANGE
      ROLE_READ PASSSYNC MANAGERS CONFIGURATION
      ROLE_MODIFY PASSSYNC MANAGERS CONFIGURATION
      ROLE_READ LDBM DATABASE CONFIGURATION
      ROLE_ADD CONFIGURATION SUB-ENTRIES
      ROLE_READ DNA RANGE
      ROLE_SYSTEM: READ REPLICATION AGREEMENTS
      ROLE_HOST ENROLLMENT
      ROLE_SYSTEM: ADD KRBPRINCIPALNAME TO A HOST
      ROLE_SYSTEM: ENROLL A HOST
      ROLE_SYSTEM: MANAGE HOST CERTIFICATES
      ROLE_SYSTEM: MANAGE HOST ENROLLMENT PASSWORD
      ROLE_SYSTEM: MANAGE HOST KEYTAB
      ROLE_463232E8-8595-11E6-A87E-00163E3C41DB
      ROLE_IPAUSERS
      ROLE_477EEE16-8595-11E6-BC28-00163E3C41DB
      ROLE_FOO-DEVS
      ROLE_FOO-JENKINS-ADMIN

      Lookup
      User lookup: successful

      And then things go to hell and I get a bunch of errors:

      No LDAP group membership reported.
      If the user is a member of some LDAP groups then the group membership settings are probably configured incorrectly.
      Email address inconsistent (login brian.murrell@example.com versus lookup null)
      User groups inconsistent (login versus lookup)
      LDAP Group lookup: failed for 42 groups:
      463232e8-8595-11e6-a87e-00163e3c41db
      477eee16-8595-11e6-bc28-00163e3c41db
      Add Configuration Sub-Entries
      Add Replication Agreements
      Host Enrollment
      Modify DNA Range
      Modify PassSync Managers Configuration
      Modify Replication Agreements
      ROLE_463232E8-8595-11E6-A87E-00163E3C41DB
      ROLE_477EEE16-8595-11E6-BC28-00163E3C41DB
      ROLE_ADD CONFIGURATION SUB-ENTRIES
      ROLE_ADD REPLICATION AGREEMENTS
      ROLE_ADMINS
      ROLE_HOST ENROLLMENT
      ROLE_FOO-DEVS
      ROLE_FOO-JENKINS-ADMIN
      ROLE_IPAUSERS
      ROLE_MODIFY DNA RANGE
      ROLE_MODIFY PASSSYNC MANAGERS CONFIGURATION
      ROLE_MODIFY REPLICATION AGREEMENTS
      ROLE_READ DNA RANGE
      ROLE_READ LDBM DATABASE CONFIGURATION
      ROLE_READ PASSSYNC MANAGERS CONFIGURATION
      ROLE_REMOVE REPLICATION AGREEMENTS
      ROLE_REPLICATION ADMINISTRATORS
      ROLE_SYSTEM: ADD KRBPRINCIPALNAME TO A HOST
      ROLE_SYSTEM: ENROLL A HOST
      ROLE_SYSTEM: MANAGE HOST CERTIFICATES
      ROLE_SYSTEM: MANAGE HOST ENROLLMENT PASSWORD
      ROLE_SYSTEM: MANAGE HOST KEYTAB
      ROLE_SYSTEM: READ REPLICATION AGREEMENTS
      Read DNA Range
      Read LDBM Database Configuration
      Read PassSync Managers Configuration
      Remove Replication Agreements
      Replication Administrators
      System: Add krbPrincipalName to a Host
      System: Enroll a Host
      System: Manage Host Certificates
      System: Manage Host Enrollment Password
      System: Manage Host Keytab
      System: Read Replication Agreements
      Does looking up group details require a Manager Dn and password?
      Are the group search base and group search filter settings correct?
      Lockout
      The user "brian" will be unable to login with the supplied password.
      If this is your own account this would mean you would be locked out!
      Are you sure you want to save this configuration?

      Please disregard the warning about the 42 groups that could not be found.  Those are administrative groups within the LDAP server that are not searchable by anyone.

      But what is worth mentioning is that the errors at the top of the Lookup:

      No LDAP group membership reported.
      If the user is a member of some LDAP groups then the group membership settings are probably configured incorrectly.
      Email address inconsistent (login brian.murrell@example.com versus lookup null)
      User groups inconsistent (login versus lookup)

      all go away if I put the very same credentials I was testing above into the Manager DN and Manager Password fields.  This suggests to me that once the login tests is done, the credentials that were used for the login tests are not used to do the lookup tests.  Is that correct?

      If so, that is not going to accurately reflect the LDAP settings in environments where uses have to bind to the LDAP server to do lookups.

        Attachments

          Issue Links

            Activity

            Hide
            rsandell rsandell added a comment -

            Released in 1.16

            Show
            rsandell rsandell added a comment - Released in 1.16
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Stephen Connolly
            Path:
            src/main/java/hudson/security/LDAPSecurityRealm.java
            src/main/resources/jenkins/security/plugins/ldap/Messages.properties
            http://jenkins-ci.org/commit/ldap-plugin/1b657e0fb88b718b9095a5eed43b8107d57c320a
            Log:
            [FIXED JENKINS-43994] When the user can login but lookup fails report this as a potential issue for API tokens and SSH key base authentication of the user

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Stephen Connolly Path: src/main/java/hudson/security/LDAPSecurityRealm.java src/main/resources/jenkins/security/plugins/ldap/Messages.properties http://jenkins-ci.org/commit/ldap-plugin/1b657e0fb88b718b9095a5eed43b8107d57c320a Log: [FIXED JENKINS-43994] When the user can login but lookup fails report this as a potential issue for API tokens and SSH key base authentication of the user
            Hide
            stephenconnolly Stephen Connolly added a comment -

            Downgrading the priority from Critical to Trivial because:

            • The test button correctly identified a configuration issue
            • The warning message is just not correct
            Show
            stephenconnolly Stephen Connolly added a comment - Downgrading the priority from Critical to Trivial because: The test button correctly identified a configuration issue The warning message is just not correct
            Hide
            stephenconnolly Stephen Connolly added a comment -

            PR to correctly attribute the issue as being for API token and SSH key based authentication of users

            Show
            stephenconnolly Stephen Connolly added a comment - PR to correctly attribute the issue as being for API token and SSH key based authentication of users
            Hide
            stephenconnolly Stephen Connolly added a comment -

            This suggests to me that once the login tests is done, the credentials that were used for the login tests are not used to do the lookup tests.  Is that correct?

            So Jenkins needs to do two kinds of validation of login details:

            1. Validation of login details of a user when the user is logging in.
            2. Validation of a user's group membership when the user is being logged in via API token, being logged in via SSH key, being impersonated by a job (Authorize project plugin) and various other situations (such as where some authorization strategy plugins want to show effective permissions of a user to the admin)

            Your LDAP server does not allow anonymous lookup of the user / group details. So while you can login correctly and your permissions work for you while you are logged in... in actuality you have a broken configuration. Your API tokens will not work correctly. Your SSH key login will not work correctly. You will get all sorts of subtle bugs when using e.g. the Jenkins CLI.

            The test button is correctly identifying these issues and giving you a scary warning.

            What is at issue here is that it is claiming a lock-out when you were able to authenticate, it should be saying that:

            The user "brian" may be unable to login with API tokens or SSH keys and will have inconsistent permissions when logging in with these or when jobs are running as this user.

            The solution for your installation can take one of two forms:

            1. Provide a Manager DN & password. This manager DN and password only needs to have permission to lookup users and groups on the LDAP server. It can even be in a DN that is not permitted to login as a regular user (for example this test uses uid=admin,ou=system as the manager DN but only logs in users from ou=people,o=sevenSeas)
            2. Enable anonymous lookup of groups and users (not recommended but this is the other solution)

            Now if you do not care about the API tokens, the SSH keys or having jobs run as users rather than as SYSTEM then you can probably safely ignore the warning, but a warning is the correct behaviour (the warning just needs some minor tweaking to reflect that you were able to authenticate and it is the "internal" authentication within Jenkins that will have issues)

            Show
            stephenconnolly Stephen Connolly added a comment - This suggests to me that once the login tests is done, the credentials that were used for the login tests are not used to do the lookup tests.  Is that correct? So Jenkins needs to do two kinds of validation of login details: Validation of login details of a user when the user is logging in. Validation of a user's group membership when the user is being logged in via API token, being logged in via SSH key, being impersonated by a job ( Authorize project plugin ) and various other situations (such as where some authorization strategy plugins want to show effective permissions of a user to the admin) Your LDAP server does not allow anonymous lookup of the user / group details. So while you can login correctly and your permissions work for you while you are logged in... in actuality you have a broken configuration. Your API tokens will not work correctly. Your SSH key login will not work correctly. You will get all sorts of subtle bugs when using e.g. the Jenkins CLI. The test button is correctly identifying these issues and giving you a scary warning. What is at issue here is that it is claiming a lock-out when you were able to authenticate, it should be saying that: The user "brian" may be unable to login with API tokens or SSH keys and will have inconsistent permissions when logging in with these or when jobs are running as this user. The solution for your installation can take one of two forms: Provide a Manager DN & password. This manager DN and password only needs to have permission to lookup users and groups on the LDAP server. It can even be in a DN that is not permitted to login as a regular user (for example this test  uses uid=admin,ou=system as the manager DN but only logs in users from ou=people,o=sevenSeas ) Enable anonymous lookup of groups and users (not recommended but this is the other solution) Now if you do not care about the API tokens, the SSH keys or having jobs run as users rather than as SYSTEM then you can probably safely ignore the warning, but a warning is the correct behaviour (the warning just needs some minor tweaking to reflect that you were able to authenticate and it is the "internal" authentication within Jenkins that will have issues)
            Hide
            adrianbridgett Adrian Bridgett added a comment -

            Same issue (against OpenLDAP).

            Swapping the Group membership from "Parse user attribute for list of LDAP groups":

            memberOf

            To "Search for LDAP groups containing user":

            (| (member={0}) (uniqueMember={0}) (memberUid={1}))
            Show
            adrianbridgett Adrian Bridgett added a comment - Same issue (against OpenLDAP). Swapping the Group membership from "Parse user attribute for list of LDAP groups": memberOf To "Search for LDAP groups containing user": (| (member={0}) (uniqueMember={0}) (memberUid={1}))

              People

              • Assignee:
                stephenconnolly Stephen Connolly
                Reporter:
                brianjmurrell Brian J Murrell
              • Votes:
                2 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: