Logging in on version 1.37 of the Active Directory plugin takes too long and I think it is causing occasional proxy timeouts. At first I had blamed it on having too many groups in Active Directory. Then I took a look at the release notes and saw that version 1.37 add some extra group specific logic. I decided to try downgrading the plugin and sure enough I was able to log in almost immediately. Which made me very very happy!

      Version 1.37 (I've seen this take up to a minute)

      Apr 30, 2014 7:38:17 PM FINE hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider
      Stage 2: looking up via memberOf
      Apr 30, 2014 7:38:44 PM FINE hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider

      Version 1.36

      Apr 30, 2014 7:53:34 PM FINE hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider
      Stage 2: looking up via memberOf
      Apr 30, 2014 7:53:34 PM FINER hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider

          [JENKINS-22830] Slow login w/ Active directory plugin

          Lawrence Ong added a comment -

          The LDAP_MATCHING_RULE_IN_CHAIN mechanism can be very intensive on large servers. The reference to this on Microsoft's site is:

          http://msdn.microsoft.com/en-us/library/aa746475%28v=vs.85%29.aspx

          It mentioned this specifically:

          "Note that when using LDAP_MATCHING_RULE_IN_CHAIN, scope is not limited—it can be base, one-level, or subtree. Some such queries on subtrees may be more processor intensive, such as chasing links with a high fan-out; that is, listing all the groups that a user is a member of. Inefficient searches will log appropriate event log messages, as with any other type of query."

          From what I can see, the search via the chain lookup in the plugin is only using the subtree scope, so it is unlikely that any developer with access to a large AD deployment would want this at all as it can easily kill the AD if there are sufficient queries to accounts with large number of group memberships.

          Lawrence Ong added a comment - The LDAP_MATCHING_RULE_IN_CHAIN mechanism can be very intensive on large servers. The reference to this on Microsoft's site is: http://msdn.microsoft.com/en-us/library/aa746475%28v=vs.85%29.aspx It mentioned this specifically: "Note that when using LDAP_MATCHING_RULE_IN_CHAIN, scope is not limited—it can be base, one-level, or subtree. Some such queries on subtrees may be more processor intensive, such as chasing links with a high fan-out; that is, listing all the groups that a user is a member of. Inefficient searches will log appropriate event log messages, as with any other type of query." From what I can see, the search via the chain lookup in the plugin is only using the subtree scope, so it is unlikely that any developer with access to a large AD deployment would want this at all as it can easily kill the AD if there are sufficient queries to accounts with large number of group memberships.

          Daniel Beck added a comment -

          queries to accounts with large number of group memberships.

          I tried this a while ago in an LDAP tool against AD global catalog. The request timed out for me with an account with only (recursively) two group memberships. One of them was "All Employees Worldwide" though, with 10k+ accounts in it. So it seems the support article doesn't have the full story.

          Daniel Beck added a comment - queries to accounts with large number of group memberships. I tried this a while ago in an LDAP tool against AD global catalog. The request timed out for me with an account with only (recursively) two group memberships. One of them was "All Employees Worldwide" though, with 10k+ accounts in it. So it seems the support article doesn't have the full story.

          Lawrence Ong added a comment - - edited

          This is the timed out query for us:

          member<==>CN=myid,OU=People,OU=eProfile,DC=core,DC=dir,DC=domain,DC=com

          Lawrence Ong added a comment - - edited This is the timed out query for us: member<==>CN=myid,OU=People,OU=eProfile,DC=core,DC=dir,DC=domain,DC=com

          Russ Frisch added a comment -

          I have just installed version 1.38 of this extension on a new Jenkins instance and I'm running into the issue of AD authentication taking a very long time. I have tried to follow the instructions KohSuke provided here a few comments up (https://issues.jenkins-ci.org/browse/JENKINS-22830?focusedCommentId=203052&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-203052) but I'm only seeing the Domain Name and Domain Controller text fields under advanced. I'm not seeing the Group Membership Lookup Strategy. Can anyone else see this option in their install?

          Russ Frisch added a comment - I have just installed version 1.38 of this extension on a new Jenkins instance and I'm running into the issue of AD authentication taking a very long time. I have tried to follow the instructions KohSuke provided here a few comments up ( https://issues.jenkins-ci.org/browse/JENKINS-22830?focusedCommentId=203052&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-203052 ) but I'm only seeing the Domain Name and Domain Controller text fields under advanced. I'm not seeing the Group Membership Lookup Strategy. Can anyone else see this option in their install?

          Daniel Beck added a comment -

          Russ: This option is only available if your Jenkins master doesn't run on Windows, or com4j isn't working.

          Daniel Beck added a comment - Russ: This option is only available if your Jenkins master doesn't run on Windows, or com4j isn't working.

          Russ Frisch added a comment -

          Daniel,

          Thanks for the response. I looked at the commit and was able to determine that the value is stored in the config file as <groupLookupStrategy> and updated my config.xml to include <groupLookupStrategy>Recursive</groupLookupStrategy> which fixes my slow login issue.

          Is there a technical reason why displaying this option in the Jenkins Global Security configuration will not work if Jenkins is running on Windows? Curious why the other advance settings for the AD plugin work but not this one?

          Russ Frisch added a comment - Daniel, Thanks for the response. I looked at the commit and was able to determine that the value is stored in the config file as <groupLookupStrategy> and updated my config.xml to include <groupLookupStrategy>Recursive</groupLookupStrategy> which fixes my slow login issue. Is there a technical reason why displaying this option in the Jenkins Global Security configuration will not work if Jenkins is running on Windows? Curious why the other advance settings for the AD plugin work but not this one?

          Dennys Hsieh added a comment - - edited

          I use 1.38 and I got this error "AD chain lookup is taking too long (41ms). Falling back to recursive lookup". But I input the domain name in the configuration, I'm not sure will it impact the performance. But in 1.36 it only takes < 1 second.

          Dennys Hsieh added a comment - - edited I use 1.38 and I got this error "AD chain lookup is taking too long (41ms). Falling back to recursive lookup". But I input the domain name in the configuration, I'm not sure will it impact the performance. But in 1.36 it only takes < 1 second.

          podskalsky added a comment -

          the workaround "<groupLookupStrategy>Recursive</groupLookupStrategy>" is ok for me

          podskalsky added a comment - the workaround "<groupLookupStrategy>Recursive</groupLookupStrategy>" is ok for me

          The problem has been fixed at least since 2.4 of the plugin.

          Niels Kristian Jensen added a comment - The problem has been fixed at least since 2.4 of the plugin.

          I'm experiencing slow lookups with version 2.6:

          Aug 09, 2017 1:48:23 PM hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider resolveGroups
          WARNING: Group lookup via Active Directorys LDAP_MATCHING_RULE_IN_CHAIN extension matched users groups but took 24 seconds to run. Switching to recursive lookup for future group lookup queries

          I was configuring Active Directory as follows:

          import jenkins.model.*
          import hudson.security.*
          import hudson.plugins.active_directory.*
             
          String domain = 'ad.example.com'
          String site = 'FOO'
          String server = 'bar.ad.example.com'
          String bindName = 'service-jenkins@ad.example.com'
          String bindPassword = 'password'
          
          // Set the security realm to AD, so users can log in with their windows credentials.
          realm = new ActiveDirectorySecurityRealm(domain, site, bindName, bindPassword, server)
          def instance = Jenkins.getInstance()
          instance.setSecurityRealm(realm)
          

          I worked around this by setting Token Groups as my lookup strategy:

          import jenkins.model.*
          import hudson.security.*
          import hudson.plugins.active_directory.*
             
          String domain = 'ad.example.com'
          String site = 'FOO'
          String server = 'bar.ad.example.com'
          String bindName = 'service-jenkins@ad.example.com'
          String bindPassword = 'password'
          
          // AD lookups can be little slow due to looking up groups. Use Token
          // Groups, which is the fastest way of looking groups, although it
          // returns fewer groups.
          def lookupStrategy = GroupLookupStrategy.TOKENGROUPS
          
          // Set the security realm to AD, so users can log in with their windows credentials.
          realm = new ActiveDirectorySecurityRealm(domain, site, bindName, bindPassword, server, lookupStrategy)
          def instance = Jenkins.getInstance()
          instance.setSecurityRealm(realm)
          

          Wilfred Hughes added a comment - I'm experiencing slow lookups with version 2.6: Aug 09, 2017 1:48:23 PM hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider resolveGroups WARNING: Group lookup via Active Directorys LDAP_MATCHING_RULE_IN_CHAIN extension matched users groups but took 24 seconds to run. Switching to recursive lookup for future group lookup queries I was configuring Active Directory as follows: import jenkins.model.* import hudson.security.* import hudson.plugins.active_directory.*     String domain = 'ad.example.com' String site = 'FOO' String server = 'bar.ad.example.com' String bindName = 'service-jenkins@ad.example.com' String bindPassword = 'password' // Set the security realm to AD, so users can log in with their windows credentials. realm = new ActiveDirectorySecurityRealm(domain, site, bindName, bindPassword, server) def instance = Jenkins.getInstance() instance.setSecurityRealm(realm) I worked around this by setting Token Groups as my lookup strategy: import jenkins.model.* import hudson.security.* import hudson.plugins.active_directory.*     String domain = 'ad.example.com' String site = 'FOO' String server = 'bar.ad.example.com' String bindName = 'service-jenkins@ad.example.com' String bindPassword = 'password' // AD lookups can be little slow due to looking up groups. Use Token // Groups, which is the fastest way of looking groups, although it // returns fewer groups. def lookupStrategy = GroupLookupStrategy.TOKENGROUPS // Set the security realm to AD, so users can log in with their windows credentials. realm = new ActiveDirectorySecurityRealm(domain, site, bindName, bindPassword, server, lookupStrategy) def instance = Jenkins.getInstance() instance.setSecurityRealm(realm)

            Unassigned Unassigned
            mrose Michael Rose
            Votes:
            5 Vote for this issue
            Watchers:
            15 Start watching this issue

              Created:
              Updated:
              Resolved: