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

TokenGroups-lookup is filtered/limited to user-domain (in Forest/Multi-Domain AD)

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Minor Minor
    • None
    • Windows Server 2008 R2 (x64),
      Active Directory plugin 1.48

      I have tested the tokengroups group-lookup strategy of the (newest) Active Directory Plugin in our AD-environment. Our AD is setup as forest, were some users are located in the root-domain (e.g., root.local), but most user-accounts, security-groups and computers are located in the second resource-domain (e.g., subx.local).

      Therefore, the plugin is currently configured with

      • Domain Name = "subx.local,root.local",
      • Domain controller = "dc1.subx.local:3268,dc2.subx.local:3268"
      • Group Membership Lookup Strategy = "RECURSIVE"

      With this configuration, login "against" a local group of subx.local by using an account of root.local (which is member of the local group) is permitted.

      If I change the the group-lookup strategy to "TOKENGROUPS", the login fails *) ...
      ... and after some tests (with logging 'FINE'), I've determined (or assume), that:

      • Searching for the user-object and login (with credentials) is successful,
      • also getting the tokengroups-list (SIDs) will contain local, universal groups of the subx.local (which DC was asked),
      • But the the name-translation of the tokengroups-SIDs afterwards, is limited to the domain (by Bind-DN) of the user-object. Therefore, the security-groups of our resource-domain (subx.local) were not found!

      *) More concrete:
      Login with an account of the resource-domain (subx.local) is still successful; an much faster.
      The failure/problem occurs only with accounts of the "extra" root-domain.

      Assuming, that my findings/assumptions are correct: It is possible to change the implementation, that groups of "different" (but also configured/permitted domain), are permitted?

      Best regards from Salzburg,
      Markus

          [JENKINS-38225] TokenGroups-lookup is filtered/limited to user-domain (in Forest/Multi-Domain AD)

          Hello, what bindName are you using? Is it in format CN="", ... or you are using the displayedName?

          Félix Belzunce Arcos added a comment - Hello, what bindName are you using? Is it in format CN="", ... or you are using the displayedName?

          Hi!

          We have set bindName "cn=LDAP QUERY,cn=Users,dc=root,dc=local";
          Note: same account (with same pwd) also exists in domain subx.local!

          Best regards,
          Markus

          GMC Software Development B&R Corporate added a comment - Hi! We have set bindName "cn=LDAP QUERY,cn=Users,dc=root,dc=local"; Note: same account (with same pwd) also exists in domain subx.local! Best regards, Markus

          Okay, I've tested some variations of the bind-DN (CN-notation, only display-name, user principal name), and there were no noticeable differences.
          I think, the problem is that in case of an account like CN=user1,OU=_Users,DC=root,DC=local the result of tokengroups-lookup

          Looking up group of CN=user1,OU=_Users,DC=root,DC=local
          

          will contain also the SIDs of groups, which are also located in subx.local.
          But the follow-up query to determine these group-names by

          Sep 19, 2016 9:39:18 AM FINER hudson.plugins.active_directory.LDAPSearchBuilder
          searching (|(objectSid={0})(objectSid={1})(objectSid={2})(objectSid={3})(objectSid={4})(objectSid={5})(objectSid={6})(objectSid={7})(objectSid={8})(objectSid={9})(objectSid={10})(objectSid={11})(objectSid={12})(objectSid={13})(objectSid={14})(objectSid={15})(objectSid={16})(objectSid={17})(objectSid={18})(objectSid={19})(objectSid={20})(objectSid={21})(objectSid={22})(objectSid={23})(objectSid={24})(objectSid={25})(objectSid={26})(objectSid={27})(objectSid={28})(objectSid={29})(objectSid={30})(objectSid={31})(objectSid={32})(objectSid={33})(objectSid={34})(objectSid={35})(objectSid={36})(objectSid={37})(objectSid={38}))[[B@11f25a48, [B@242109d6, [B@40b7621f, [B@10450821, [B@1366307b, [B@3f25e478, [B@44f9de19, [B@7cc5d2a7, [B@5e02d0ac, [B@4e14f930, [B@4497effd, [B@16954d22, [B@5e5a68ec, [B@376ed76e, [B@4cfd3e79, [B@703d9699, [B@7d2d8d7a, [B@3cb9f016, [B@19120f0e, [B@507cbeb, [B@1450d06c, [B@679aabb0, [B@6ef9a232, [B@559a7495, [B@47db0dfa, [B@752ee99a, [B@56e53d3f, [B@50ddd5aa, [B@4ff6b696, [B@4d96f4cb, [B@32e52483, [B@c2bc7f0, [B@761382e5, [B@c591040, [B@1703ec74, [B@4545ad23, [B@2fab1bc4, [B@6bb4d561, [B@635ce42f] in DC=root,DC=local using {java.naming.referral=follow, java.naming.ldap.version=3, java.naming.security.principal=Svc_LDAPQuery@root,local, java.naming.ldap.attributes.binary=tokenGroups objectSid, java.naming.provider.url=ldap://dc1.subx.local:3268/, com.sun.jndi.ldap.read.timeout=60000, java.naming.security.credentials=…} with scope 2 returning [cn]
          Sep 19, 2016 9:39:18 AM FINE hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider
          CN=user1,OU=_Users,DC=root,DC=local is a member of cn: Users
          

          is limited to scope DC=root,DC=local !

          I.e., Login with CN=user1,OU=_Users,DC=root,DC=local is permitted, but groups (which this account is member of) in our resource-domain (subx.local) are not determined, because "only" group-names of the same domain (like the user-account) are found.
          In our case, login or users in DC=root,DC=local and DC=subx,DC=local is permitted, but jenkins permissions are applied, if the account is member
          of the (universal) group "Jenkins-Group" (CN=Jenkins-Group,CN=_Users,DC=subx,DC=local); Recursive lookup is able to determine this setup.

          Best regards,
          Markus

          GMC Software Development B&R Corporate added a comment - - edited Okay, I've tested some variations of the bind-DN (CN-notation, only display-name, user principal name), and there were no noticeable differences. I think, the problem is that in case of an account like CN=user1,OU=_Users,DC=root,DC=local the result of tokengroups-lookup Looking up group of CN=user1,OU=_Users,DC=root,DC=local will contain also the SIDs of groups, which are also located in subx.local. But the follow-up query to determine these group-names by Sep 19, 2016 9:39:18 AM FINER hudson.plugins.active_directory.LDAPSearchBuilder searching (|(objectSid={0})(objectSid={1})(objectSid={2})(objectSid={3})(objectSid={4})(objectSid={5})(objectSid={6})(objectSid={7})(objectSid={8})(objectSid={9})(objectSid={10})(objectSid={11})(objectSid={12})(objectSid={13})(objectSid={14})(objectSid={15})(objectSid={16})(objectSid={17})(objectSid={18})(objectSid={19})(objectSid={20})(objectSid={21})(objectSid={22})(objectSid={23})(objectSid={24})(objectSid={25})(objectSid={26})(objectSid={27})(objectSid={28})(objectSid={29})(objectSid={30})(objectSid={31})(objectSid={32})(objectSid={33})(objectSid={34})(objectSid={35})(objectSid={36})(objectSid={37})(objectSid={38}))[[B@11f25a48, [B@242109d6, [B@40b7621f, [B@10450821, [B@1366307b, [B@3f25e478, [B@44f9de19, [B@7cc5d2a7, [B@5e02d0ac, [B@4e14f930, [B@4497effd, [B@16954d22, [B@5e5a68ec, [B@376ed76e, [B@4cfd3e79, [B@703d9699, [B@7d2d8d7a, [B@3cb9f016, [B@19120f0e, [B@507cbeb, [B@1450d06c, [B@679aabb0, [B@6ef9a232, [B@559a7495, [B@47db0dfa, [B@752ee99a, [B@56e53d3f, [B@50ddd5aa, [B@4ff6b696, [B@4d96f4cb, [B@32e52483, [B@c2bc7f0, [B@761382e5, [B@c591040, [B@1703ec74, [B@4545ad23, [B@2fab1bc4, [B@6bb4d561, [B@635ce42f] in DC=root,DC=local using {java.naming.referral=follow, java.naming.ldap.version=3, java.naming.security.principal=Svc_LDAPQuery@root,local, java.naming.ldap.attributes.binary=tokenGroups objectSid, java.naming.provider.url=ldap://dc1.subx.local:3268/, com.sun.jndi.ldap.read.timeout=60000, java.naming.security.credentials=…} with scope 2 returning [cn] Sep 19, 2016 9:39:18 AM FINE hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider CN=user1,OU=_Users,DC=root,DC=local is a member of cn: Users is limited to scope DC=root,DC=local ! I.e., Login with CN=user1,OU=_Users,DC=root,DC=local is permitted, but groups (which this account is member of) in our resource-domain (subx.local) are not determined, because "only" group-names of the same domain (like the user-account) are found. In our case, login or users in DC=root,DC=local and DC=subx,DC=local is permitted, but jenkins permissions are applied, if the account is member of the (universal) group "Jenkins-Group" (CN=Jenkins-Group,CN=_Users,DC=subx,DC=local); Recursive lookup is able to determine this setup. Best regards, Markus

          Can you try to install active directory 2.0 and add the following configuration.

          Domain Name = "subx.loca",
          Domain controller = "dc1.subx.local:3268,dc2.subx.local:3268"
          Group Membership Lookup Strategy = "tokenSec"

          Domain Name = "root.local",
          Domain controller = <BLANK>
          Group Membership Lookup Strategy = "tokenSec"

          Félix Belzunce Arcos added a comment - Can you try to install active directory 2.0 and add the following configuration. Domain Name = "subx.loca", Domain controller = "dc1.subx.local:3268,dc2.subx.local:3268" Group Membership Lookup Strategy = "tokenSec" Domain Name = "root.local", Domain controller = <BLANK> Group Membership Lookup Strategy = "tokenSec"

          BTW check firstly the release notes as you might be locked.

          Félix Belzunce Arcos added a comment - BTW check firstly the release notes as you might be locked.

          Any update here?

          Félix Belzunce Arcos added a comment - Any update here?

            fbelzunc Félix Belzunce Arcos
            gmc_devel GMC Software Development B&R Corporate
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: