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

Error logging in when using matrix permissions with LDAP groups

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Major Major
    • _unsorted
    • None
    • Platform: All, OS: All

      Hudson ver. 1.285

      1. When I enable "Matrix-based security".
      2. Add group foo.
      3. Grant all permissions to group foo.
      4. Login as a new user in group foo to hudson.
      5. Hudson displays following error

      Access Denied

      org.acegisecurity.providers.UsernamePasswordAuthenticationToken@a67154e0:
      Username: org.acegisecurity.userdetails.ldap.LdapUserDetailsImpl@5d82fe47;
      Password: [PROTECTED]; Authenticated: true; Details:
      org.acegisecurity.ui.WebAuthenticationDetails@166c8: RemoteIpAddress:
      10.2.18.121; SessionId: D4C5C9C3EE392793E8A40B73BE95B733; Granted Authorities:
      is missing Read

      User is definitely in the group
      Group definitely has all permissions

      I didn't test if this also applies to non-LDAP groups.

          [JENKINS-3128] Error logging in when using matrix permissions with LDAP groups

          Alan Harder added a comment -

          any update? let us know if we can close this issue. 1.291 is looking like a
          good build stability-wise, good upgrade candidate.

          Alan Harder added a comment - any update? let us know if we can close this issue. 1.291 is looking like a good build stability-wise, good upgrade candidate.

          smulcahy added a comment -

          Hi,

          Sorry for the delay on getting back to this. I've now gotten around to testing
          this with the latest Hudson (1.292 - there is no changelog for this yet which
          worries me a little - should the problem be fixed there too?

          I did the following. Downloaded 1.292 war and dropped it into
          /var/lib/tomcat6/webapps - Hudson seemed to auto-upgrade (good work on this
          guys, very painless).

          I then did the following. Added a new group to LDAP - ldaptestgrp which resulted
          in the following entry in LDAP:

          dn: cn=ldaptestgrp,ou=Groups,dc=example,dc=net
          objectClass: top
          objectClass: posixGroup
          cn: ldaptestgrp
          gidNumber: 10017
          description: Group account

          I then added a user account with the above as it's default group resulting in
          the following entry:

          dn: uid=ldaptest,ou=People,dc=example,dc=net
          sn: test
          givenName: ldap
          uid: ldaptest
          cn: ldaptest
          homeDirectory: /home/ldaptest
          loginShell: /bin/bash
          uidNumber: 10015
          gidNumber: 10017
          gecos: ldaptest
          objectClass: posixAccount
          objectClass: shadowAccount
          objectClass: top
          objectClass: person
          objectClass: organizationalPerson
          objectClass: inetOrgPerson
          objectClass: gosaAccount
          description: User account

          NOTE: these are associated by gidNumber in the user entry rather than by
          memberUid in the group entry (because this is the user's primary group).

          I then added a second test group to LDAP and made ldaptest a member of it -
          resulting in the following entry,

          dn: cn=ldaptestgrp2,ou=Groups,dc=example,dc=net
          objectClass: top
          objectClass: posixGroup
          cn: ldaptestgrp2
          gidNumber: 10018
          description: Group account
          memberUid: ldaptest

          Note that this time it does use memberUid as Hudson expects.

          I then tried adding first ldaptestgrp and then ldaptestgrp2 to the permissions
          matrix and enabling most permissions (except the admin ones). In both test cases
          (using ldaptestgrp and ldaptestgrp2) - I still get the following error in Hudson
          immediately after logging in

          Access Denied

          ldaptest is missing the Read permission

          There is no additional information in the Hudson logs (Hudson logging is running
          with all defaults, not sure if I need to enable something specific to see
          details of authentication?).

          smulcahy added a comment - Hi, Sorry for the delay on getting back to this. I've now gotten around to testing this with the latest Hudson (1.292 - there is no changelog for this yet which worries me a little - should the problem be fixed there too? I did the following. Downloaded 1.292 war and dropped it into /var/lib/tomcat6/webapps - Hudson seemed to auto-upgrade (good work on this guys, very painless). I then did the following. Added a new group to LDAP - ldaptestgrp which resulted in the following entry in LDAP: dn: cn=ldaptestgrp,ou=Groups,dc=example,dc=net objectClass: top objectClass: posixGroup cn: ldaptestgrp gidNumber: 10017 description: Group account I then added a user account with the above as it's default group resulting in the following entry: dn: uid=ldaptest,ou=People,dc=example,dc=net sn: test givenName: ldap uid: ldaptest cn: ldaptest homeDirectory: /home/ldaptest loginShell: /bin/bash uidNumber: 10015 gidNumber: 10017 gecos: ldaptest objectClass: posixAccount objectClass: shadowAccount objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: gosaAccount description: User account NOTE: these are associated by gidNumber in the user entry rather than by memberUid in the group entry (because this is the user's primary group). I then added a second test group to LDAP and made ldaptest a member of it - resulting in the following entry, dn: cn=ldaptestgrp2,ou=Groups,dc=example,dc=net objectClass: top objectClass: posixGroup cn: ldaptestgrp2 gidNumber: 10018 description: Group account memberUid: ldaptest Note that this time it does use memberUid as Hudson expects. I then tried adding first ldaptestgrp and then ldaptestgrp2 to the permissions matrix and enabling most permissions (except the admin ones). In both test cases (using ldaptestgrp and ldaptestgrp2) - I still get the following error in Hudson immediately after logging in Access Denied ldaptest is missing the Read permission There is no additional information in the Hudson logs (Hudson logging is running with all defaults, not sure if I need to enable something specific to see details of authentication?).

          Alan Harder added a comment -

          what did you enter into Hudson's permissions matrix? try entering
          ROLE_ldaptestgrp / ROLE_ldaptestgrp2 instead of just the group name, and see if
          that makes a difference.

          Alan Harder added a comment - what did you enter into Hudson's permissions matrix? try entering ROLE_ldaptestgrp / ROLE_ldaptestgrp2 instead of just the group name, and see if that makes a difference.

          Alan Harder added a comment -

          any update?

          Alan Harder added a comment - any update?

          smulcahy added a comment -

          Hi,

          Apologies for the delay. I originally used just the group name and Hudson seems
          to recognised that as a valid LDAP group (it puts a little group icon beside it
          in the security matrix).

          I tried adding a new group which is ROLE_ldaptestgroup and it doesn't get
          recognised as a group. Furthermore, when I attempt to login as the ldaptestuser
          (a member of this group), I get the "user no read permission" error.

          Hudson ver. 1.292 (I can't see anything in the Changelog's up to 1.299 that
          indicates any LDAP changes have been made).

          smulcahy added a comment - Hi, Apologies for the delay. I originally used just the group name and Hudson seems to recognised that as a valid LDAP group (it puts a little group icon beside it in the security matrix). I tried adding a new group which is ROLE_ldaptestgroup and it doesn't get recognised as a group. Furthermore, when I attempt to login as the ldaptestuser (a member of this group), I get the "user no read permission" error. Hudson ver. 1.292 (I can't see anything in the Changelog's up to 1.299 that indicates any LDAP changes have been made).

          Alan Harder added a comment -

          the inconsistency between the name-check icon and what is actually used has been
          filed as issue #3459. but I was definitely hoping putting ROLE_ prefix in your
          permission matrix would cause the group permissions to apply.. sorry, not sure
          what to try next without really getting in there to debug and see what LDAP
          queries and results are happening.

          Alan Harder added a comment - the inconsistency between the name-check icon and what is actually used has been filed as issue #3459. but I was definitely hoping putting ROLE_ prefix in your permission matrix would cause the group permissions to apply.. sorry, not sure what to try next without really getting in there to debug and see what LDAP queries and results are happening.

          morlach01 added a comment -

          I bumped into the same problem. After reading a bit more carefully the default
          configuration of acegi that mindless pointed I found the "problem".

          It is in the last 2 properties acegi uses in the default bean config.
          <bean id="ldapAuthoritiesPopulator"
          class="org.acegisecurity.providers.ldap.populator.DefaultLdapAuthoritiesPopulator">
          <constructor-arg><ref local="initialDirContextFactory"/></constructor-arg>
          <constructor-arg><value>ou=groups</value></constructor-arg>
          <property name="groupRoleAttribute"><value>ou</value></property>
          <!-- the following properties are shown with their default values -->
          <property name="searchSubTree"><value>false</value></property>
          <property name="rolePrefix"><value>ROLE_</value></property>
          <property name="convertToUpperCase"><value>true</value></property>
          </bean>

          In other words if your group is:
          dn: cn=ldaptestgrp2,ou=Groups,dc=example,dc=net
          objectClass: top
          objectClass: posixGroup
          cn: ldaptestgrp2
          gidNumber: 10018
          description: Group account
          memberUid: ldaptest

          as for smulcahy's example you have to add the
          ROLE_LDAPTESTGRP2
          and then your user ldaptest will receive the proper authorization.

          It would be helpful however if the group validation and the acegi config use the
          same rules. And even better if those are exposed to the Advanced settings in the
          LDAP section.

          I am sure some people would prefer having Roles enforced in all capitals (they
          jump to attention in bigger companies), but on the other hand I would like to
          use the lower-cased version, since with just a few entries it looks nicer.

          morlach01 added a comment - I bumped into the same problem. After reading a bit more carefully the default configuration of acegi that mindless pointed I found the "problem". It is in the last 2 properties acegi uses in the default bean config. <bean id="ldapAuthoritiesPopulator" class="org.acegisecurity.providers.ldap.populator.DefaultLdapAuthoritiesPopulator"> <constructor-arg><ref local="initialDirContextFactory"/></constructor-arg> <constructor-arg><value>ou=groups</value></constructor-arg> <property name="groupRoleAttribute"><value>ou</value></property> <!-- the following properties are shown with their default values --> <property name="searchSubTree"><value>false</value></property> <property name="rolePrefix"><value>ROLE_</value></property> <property name="convertToUpperCase"><value>true</value></property> </bean> In other words if your group is: dn: cn=ldaptestgrp2,ou=Groups,dc=example,dc=net objectClass: top objectClass: posixGroup cn: ldaptestgrp2 gidNumber: 10018 description: Group account memberUid: ldaptest as for smulcahy's example you have to add the ROLE_LDAPTESTGRP2 and then your user ldaptest will receive the proper authorization. It would be helpful however if the group validation and the acegi config use the same rules. And even better if those are exposed to the Advanced settings in the LDAP section. I am sure some people would prefer having Roles enforced in all capitals (they jump to attention in bigger companies), but on the other hand I would like to use the lower-cased version, since with just a few entries it looks nicer.

          smulcahy added a comment -

          Hi,

          Apologies for the delay in following up - I've only gotten a chance to test
          this. now. Thanks for the detailed feedback. It sounds like you might be on the
          right track with this, but I did a quick test this morning and still got a read
          access denied error. I did the following,

          1. Recreated my LDAP test user ldaptestuser and added it to group ldaptestgroup
          2. Logged into Hudson as admin and added ROLE_LDAPTESTGROUP to the permissions
          matrix.
          3. Logged out of Hudson and attempted to login as ldaptestuser and

          SUCCESS!

          I successfully logged in as that user.

          Might be worth pointing to this bug in the Hudon documentation for those
          configuring up LDAP auth. These default config options in ACEGI are surprising
          (and a bit random) - I imagine it'd be better to default to not using a prefix
          or changing the case and let users customise the behaviour if they have explicit
          requirements.

          Thanks for your assistance in this.

          smulcahy added a comment - Hi, Apologies for the delay in following up - I've only gotten a chance to test this. now. Thanks for the detailed feedback. It sounds like you might be on the right track with this, but I did a quick test this morning and still got a read access denied error. I did the following, 1. Recreated my LDAP test user ldaptestuser and added it to group ldaptestgroup 2. Logged into Hudson as admin and added ROLE_LDAPTESTGROUP to the permissions matrix. 3. Logged out of Hudson and attempted to login as ldaptestuser and SUCCESS! I successfully logged in as that user. Might be worth pointing to this bug in the Hudon documentation for those configuring up LDAP auth. These default config options in ACEGI are surprising (and a bit random) - I imagine it'd be better to default to not using a prefix or changing the case and let users customise the behaviour if they have explicit requirements. Thanks for your assistance in this.

          smulcahy added a comment -

          Hi, just re-read my last comment and to noted that the second sentence is
          incorrect. To clarify, the suggested fix works and my ldaptestuser did login
          without any errors (read or otherwise).

          thanks and apologies for the confusion (not enough coffee).

          smulcahy added a comment - Hi, just re-read my last comment and to noted that the second sentence is incorrect. To clarify, the suggested fix works and my ldaptestuser did login without any errors (read or otherwise). thanks and apologies for the confusion (not enough coffee).

          Alan Harder added a comment -

          ok, going to close this one and use #3459 to track the fix. I'll summarize the
          results of all these comments over there. Thanks morlach01 for the help in
          tracking down the settings causing this problem!

              • This issue has been marked as a duplicate of 3459 ***

          Alan Harder added a comment - ok, going to close this one and use #3459 to track the fix. I'll summarize the results of all these comments over there. Thanks morlach01 for the help in tracking down the settings causing this problem! This issue has been marked as a duplicate of 3459 ***

            Unassigned Unassigned
            smulcahy smulcahy
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: