• Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Critical Critical
    • ldap-plugin
    • None
    • ldap-plugin 1.15 and 1.16

      Our Ldap Configuration for authentication and authorisation was working fine with 1.14 Ldap Plugin but with upgrade to 1.15 Ldap plugin it cannot find groups.

       

      Test Ldap Configuration Results but able to authenticate correctly
      No LDAP group membership reported.
      If the user is a member of some LDAP groups then the group membership settings are probably configured incorrectly.

       

      The Group search base is same , if i rollback the ldap plugin to 1.14 all configuration works fine

       

       

          [JENKINS-44639] LDAP 1.15 plugin doesn't resolve groups

          I love the new test button but I cannot get the ldap group stuff to work with 1.15.  I'm going to try downgrading...

          Christian Höltje added a comment - I love the new test button but I cannot get the ldap group stuff to work with 1.15.  I'm going to try downgrading...

          I've been able to use LDAP 1.15 with LDAP groups.

          My membership has been correctly displayed using the Test button and with case sensitive I'm able to use the role-membership for role / matrix based authorization too.

          Matthias Robert Wiora added a comment - I've been able to use LDAP 1.15 with LDAP groups. My membership has been correctly displayed using the Test button and with case sensitive I'm able to use the role-membership for role / matrix based authorization too.

          Matthew Gregg added a comment -

          1.15 not working here, had to revert to 1.14. Is it documented somewhere any changes that are needed to go from 1.14 to 1.15?

          Matthew Gregg added a comment - 1.15 not working here, had to revert to 1.14. Is it documented somewhere any changes that are needed to go from 1.14 to 1.15?

          I ran into this again today, upgrading to 1.16 is also broken in the same way.

          What can I do to troubleshoot or debug this so that someone can either fix this or document what needs to change?

          Christian Höltje added a comment - I ran into this again today, upgrading to 1.16 is also broken in the same way. What can I do to troubleshoot or debug this so that someone can either fix this or document what needs to change?

          I broke out Wireshark to take a look and I think what's going on (in my case) is that the group membership attribute (allgroups) on the user object is only returned if specified in the request.

          It looks like the requests are not specifying any attributes when requesting the user and is getting the default attributes which doesn't include allgroups

          Either a second request needs to be made with allgroups for the user or a list of attributes needs to be specified in the initial request.

          Christian Höltje added a comment - I broke out Wireshark to take a look and I think what's going on (in my case) is that the group membership attribute ( allgroups ) on the user object is only returned if specified in the request. It looks like the requests are not specifying any attributes when requesting the user and is getting the default attributes which doesn't include allgroups Either a second request needs to be made with allgroups for the user or a list of attributes needs to be specified in the initial request.

          Using git bisect I found the commit that is causing the breakage: https://github.com/jenkinsci/ldap-plugin/commit/7481d91529786c2a52edb787e4456c8af2645c2b

          I was testing by going to /whoAmI and logging in; not using the "Test LDAP settings" button since that didn't exist in v1.14 and in some commits it's results were incorrect.

          Christian Höltje added a comment - Using git bisect I found the commit that is causing the breakage: https://github.com/jenkinsci/ldap-plugin/commit/7481d91529786c2a52edb787e4456c8af2645c2b I was testing by going to /whoAmI and logging in; not using the "Test LDAP settings" button since that didn't exist in v1.14 and in some commits it's results were incorrect.

          On master (commit fae415f0f20b073) I reverted commit 748ad9 and /whoAmI works.

          The "Test LDAP settings" reports that with login (password is included) it works but lookup reported:

          • User lookup: successful
          • No group membership reported
          • User groups inconsistent (login versus lookup)
          • LDAP Group lookup: successful (68 groups)
          • Lockout
          • The user "choltje@us.ibm.com" may be unable to login with API tokens or SSH keys.
            The user will have inconsistent permissions if able to login using API tokens or SSH keys!
            If this is your own account this could mean you may be locked out!
            Are you sure you want to save this configuration?

          I believe there are two problems going on here...

          1. Something is wrong in 748ad9 that breaks group lookups for logins.
          2. Due to the new Jenkins security model, the non-group lookups need to use an explicit attribute list on the user object; otherwise "function" attributes like allgroups won't work.

          Christian Höltje added a comment - On master (commit fae415f0f20b073 ) I reverted commit 748ad9 and /whoAmI works. The "Test LDAP settings" reports that with login (password is included) it works but lookup reported: User lookup: successful No group membership reported User groups inconsistent (login versus lookup) LDAP Group lookup: successful (68 groups) Lockout The user "choltje@us.ibm.com" may be unable to login with API tokens or SSH keys. The user will have inconsistent permissions if able to login using API tokens or SSH keys! If this is your own account this could mean you may be locked out! Are you sure you want to save this configuration? I believe there are two problems going on here... Something is wrong in 748ad9 that breaks group lookups for logins. Due to the new Jenkins security model, the non-group lookups need to use an explicit attribute list on the user object; otherwise "function" attributes like allgroups won't work.

          Matthew Gregg added a comment - - edited

          Any idea when this might get addressed? Currently holding at 1.14 to have working LDAP.

          Matthew Gregg added a comment - - edited Any idea when this might get addressed? Currently holding at 1.14 to have working LDAP.

          Hi! Thanks for the plugin!

          Unfortunately, I have the same issue and it appeared for me in 1.15 and it works for me in 1.14. What makes me worrying is that JumpCloud officially recommends to stay on 1.14 as everything above is known to be not completely working - https://support.jumpcloud.com/customer/en/portal/articles/2440013-configuring-jenkins-to-use-jumpcloud-s-ldap-as-a-service

          Is there something I can help with this particular issue? Do you need any extra info or details? The issue could be easily reproduced when ldap user assigned to a group which has, say, full permissions in Jenkins and when such user log in, it see <user login> is missing the Overall/Read permission.

          Bogdan Padalko added a comment - Hi! Thanks for the plugin! Unfortunately, I have the same issue and it appeared for me in 1.15 and it works for me in 1.14. What makes me worrying is that JumpCloud officially recommends to stay on 1.14 as everything above is known to be not completely working - https://support.jumpcloud.com/customer/en/portal/articles/2440013-configuring-jenkins-to-use-jumpcloud-s-ldap-as-a-service Is there something I can help with this particular issue? Do you need any extra info or details? The issue could be easily reproduced when ldap user assigned to a group which has, say, full permissions in Jenkins and when such user log in, it see <user login> is missing the Overall/Read permission .

          I have this issue too. 

          In the log I see that the bind command for the group lookup attempts to use the resolved user instead of the manager DN. It then fails because the user doesn't have the proper rights on the ldap.

          Making the LDAP plugin use the Manager DN and password when resolving groups would probably help alot.

          Anders Orvedal added a comment - I have this issue too.  In the log I see that the bind command for the group lookup attempts to use the resolved user instead of the manager DN. It then fails because the user doesn't have the proper rights on the ldap. Making the LDAP plugin use the Manager DN and password when resolving groups would probably help alot.

            Unassigned Unassigned
            prabhatofficial Prabhat Singh
            Votes:
            6 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated: