• Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major Major
    • ldap-plugin
    • None
    • OpenLDAP/slapd

      I have a group in LDAP called "Jira Administrators" and I have a user called test.user.

      If I put test.user directly in the Jira Administrators, then authentication and authorization works fine. The user has full administrator access to Jenkins.

      But if I put test.user into a group called "Administrators" and then put that group as a member of the "Jira Administrators" group, then test.user can log in but gets treated like an anonymous; it has no permission to do anything an administrator should be able to do.

          [JENKINS-18961] LDAP plugin does not support nested groups

          Nicolas De Loof added a comment - Depends on https://jira.springsource.org/browse/SEC-1823

          Bruce Coveny added a comment -

          There has been some chat on the springsource ticket and wondering if this could be investigated to what they said to allow nested groups. My firm only uses nested groups so instead of one or two groups we now have to add 50 different groups to Jenkins security console and maintain them all.

          Jean-Pierre Bergamin added a comment - 17/Jun/14 1:31 AM

          I use this class here: https://gist.github.com/ractive/258dd06c99d2939781c0
          Put it in the package org.springframework.security.ldap.authentication.ad and you should be ready to go...

          Bruce Coveny added a comment - There has been some chat on the springsource ticket and wondering if this could be investigated to what they said to allow nested groups. My firm only uses nested groups so instead of one or two groups we now have to add 50 different groups to Jenkins security console and maintain them all. Jean-Pierre Bergamin added a comment - 17/Jun/14 1:31 AM I use this class here: https://gist.github.com/ractive/258dd06c99d2939781c0 Put it in the package org.springframework.security.ldap.authentication.ad and you should be ready to go...

          Has there been any update on this issue? I have Jenkins 1.636 and i still see this exact issue.
          Please let me know how can this be fixed. I used LDAP plugin and our company use Oracle not Active Directory.

          Thanks

          Abhimanyu Bishnoi added a comment - Has there been any update on this issue? I have Jenkins 1.636 and i still see this exact issue. Please let me know how can this be fixed. I used LDAP plugin and our company use Oracle not Active Directory. Thanks

          LDAP plugin works agains AD server in which users are a member of nested groups. You just need to change the query on the plugin following the section of the wiki "Tips and Tricks".

          Félix Belzunce Arcos added a comment - LDAP plugin works agains AD server in which users are a member of nested groups. You just need to change the query on the plugin following the section of the wiki "Tips and Tricks".

          Emory Penney added a comment -

          Wow, that query is slow.  So slow my login attempts time out when I try to use it.

          Emory Penney added a comment - Wow, that query is slow.  So slow my login attempts time out when I try to use it.

          Oleg Nenashev added a comment -

          In order to set proper expectation, I have unassigned Kohsuke from this tickets.
          Currently there is no Default assignee in the LDAP plugin, any contributions will be appreciated.

          Oleg Nenashev added a comment - In order to set proper expectation, I have unassigned Kohsuke from this tickets. Currently there is no Default assignee in the LDAP plugin, any contributions will be appreciated.

          Thanks fbelzunc for that tip!

          Setting "Group membership" to Search for groups containing user and the "Group membership filter": {{(&(objectCategory=group)(member:1.2.840.113556.1.4.1941:={0})) }}worked for me, but was incredibly slow to the point of making builds with the Authorize Project plugin impossible. Then I found the section under "Performance Tuning" that indicated we should enable caching and :tada: it works!

          Graham McGregor added a comment - Thanks fbelzunc for that tip! Setting "Group membership" to  Search for groups containing user  and the "Group membership filter": {{(&(objectCategory=group)(member:1.2.840.113556.1.4.1941:={0})) }}worked for me, but was incredibly slow to the point of making builds with the Authorize Project plugin impossible. Then I found the section under "Performance Tuning" that indicated we should enable caching and :tada: it works!

          Christian Castor added a comment - - edited

          We found a solution on this. Reason for slowliness is the gathering of all group Information out of AD. You have to reduce the search scope for AD Groups to the Groups you need for authentication in Jenkins, e.g only Permission groups for Jenkins should hand over to Jenkins. This must be adjusted in ADFS.

           

          Rule1:

          c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
           => add(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameDN"), query = ";distinguishedName;{0}", param = c.Value);
           

          Rule 2:

          c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
           && c2:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameDN"]
           => add(store = "Active Directory", types = ("http://schemas.xmlsoap.org/claims/Group/Name"), query = "(member:1.2.840.113556.1.4.1941:={1});samaccountname;{0}", param = c1.Value, param = c2.Value);
           

          Rule 3*:

          c:[Type == "http://schemas.xmlsoap.org/claims/Group/Name", Value =~ "(?i)B_App_Jenkins"]
           => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/role", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

           

          • In our Case we have implemented Role as anchor in Jenkins, if group for you,  you have to check for adjusted Rule description in ADFS, Slowliness was reduced from 30 sec to <1 sec.
          • On TechNet you will find marker as  "(?i)B_App_Jenkins" or  "(?i)B_App_Jenkins*" - this doesn't work with Jenkins.

          Christian Castor added a comment - - edited We found a solution on this. Reason for slowliness is the gathering of all group Information out of AD. You have to reduce the search scope for AD Groups to the Groups you need for authentication in Jenkins, e.g only Permission groups for Jenkins should hand over to Jenkins. This must be adjusted in ADFS.   Rule1: c:[Type == " http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname ", Issuer == "AD AUTHORITY"]  => add(store = "Active Directory", types = (" http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameDN "), query = ";distinguishedName;{0}", param = c.Value);   Rule 2: c1:[Type == " http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname ", Issuer == "AD AUTHORITY"]  && c2:[Type == " http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameDN "]  => add(store = "Active Directory", types = (" http://schemas.xmlsoap.org/claims/Group/Name "), query = "(member:1.2.840.113556.1.4.1941:={1});samaccountname;{0}", param = c1.Value, param = c2.Value);   Rule 3*: c:[Type == " http://schemas.xmlsoap.org/claims/Group/Name ", Value =~ "(?i)B_App_Jenkins"]  => issue(Type = " http://schemas.microsoft.com/ws/2008/06/identity/claims/role ", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);   In our Case we have implemented Role as anchor in Jenkins, if group for you,  you have to check for adjusted Rule description in ADFS, Slowliness was reduced from 30 sec to <1 sec. On TechNet you will find marker as  "(?i) B_App_Jenkins" or  " (?i)B_App_Jenkins*" - this doesn't work with Jenkins.

          On TechNet you will find marker as  "(?i)"^"<YourgroupName> Double Quote added as Jenkins not fit with the roof dash

          Christian Castor added a comment - On TechNet you will find marker as  "(?i)"^"<YourgroupName> Double Quote added as Jenkins not fit with the roof dash

          Hi!

          I'm facing the same issue (as in "LDAP plugin does not support nested groups"), but in my case with OID (Oracle Internet Directory). After countless tests I came to the conclusion that the only command that retrieves the full group membership is this:

          ldapsearch -xLLL -o ldif-wrap=no -h <my host> -p 389 -s sub -b "<full user cn>" memberOf

          Whereas, I believe the plugin is doing something like:

          ldapsearch -xLLL -o ldif-wrap=no -h <my host> -p 389 -s sub -b "dc=emea,dc=eu,dc=int" "(uniquemember=<full user cn>)" displayname mail

           

          Unfortunately, the later only returns direct group memberships (not nested).

          In order to workaround the issue, I have to hard assign entire teams' users to the role groups defined in Jenkins. This is not optimal and very prone to error.

          "LDAP_MATCHING_RULE_IN_CHAIN"/"1.2.840.113556.1.4.1941" workaround also doesn't work. As it seems it should only work with AD.

          Any ideas on how to sort this out?

          Thanks!

          Jhonny Oliveira added a comment - Hi! I'm facing the same issue (as in "LDAP plugin does not support nested groups"), but in my case with OID (Oracle Internet Directory). After countless tests I came to the conclusion that the only command that retrieves the full group membership is this: ldapsearch -xLLL -o ldif-wrap=no -h <my host> -p 389 -s sub -b "<full user cn>" memberOf Whereas, I believe the plugin is doing something like: ldapsearch -xLLL -o ldif-wrap=no -h <my host> -p 389 -s sub -b "dc=emea,dc=eu,dc=int" "(uniquemember=<full user cn>)" displayname mail   Unfortunately, the later only returns direct group memberships (not nested). In order to workaround the issue, I have to hard assign entire teams' users to the role groups defined in Jenkins. This is not optimal and very prone to error. "LDAP_MATCHING_RULE_IN_CHAIN"/"1.2.840.113556.1.4.1941" workaround also doesn't work. As it seems it should only work with AD. Any ideas on how to sort this out? Thanks!

            Unassigned Unassigned
            mehaase Mark Haase
            Votes:
            11 Vote for this issue
            Watchers:
            18 Start watching this issue

              Created:
              Updated: