• Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • ldap-plugin
    • None
    • Platform: PC, OS: Linux

      In security/LDAPBindSecurityRealm.groovy, the following config option is hard coded:

      extraEnvVars = [(Context.REFERRAL):"follow"];

      Attempting to use Active Directory's LDAP server fails due to the fact that AD
      referrals aren't 100% compatible with LDAP itself. Is it possible for this to
      be implemented as a configurable options?

      Just for reference, the value above can be set to "follow", "ignore", or "throw".

      Andrew

          [JENKINS-4895] AD and LDAP fail due to Referrals

          Sorin Sbarnea added a comment -

          I tried how much time it takes to login while using any of the 3 variants and it takes too much time in all case ~14 seconds.

          Any other ideas?

          Sorin Sbarnea added a comment - I tried how much time it takes to login while using any of the 3 variants and it takes too much time in all case ~14 seconds. Any other ideas?

          Casey McGinty added a comment -

          This bug causes the following exception:

          org.acegisecurity.AuthenticationServiceException: LdapCallback;null; nested exception is javax.naming.PartialResultException [Root exception is javax.naming.CommunicationException: example.com:389 [Root exception is java.net.ConnectException: Connection refused: connect]]; nested exception is org.acegisecurity.ldap.LdapDataAccessException: LdapCallback;null; nested exception is javax.naming.PartialResultException [Root exception is javax.naming.CommunicationException: example.com:389 [Root exception is java.net.ConnectException: Connection refused: connect]]

          It appears that Jenkins still throws an exception when 'Context.REFERRAL' is set to 'ignore'.

          org.acegisecurity.AuthenticationServiceException: LdapCallback;Unprocessed Continuation Reference(s); nested exception is javax.naming.PartialResultException: Unprocessed Continuation Reference(s); remaining name ''; nested exception is org.acegisecurity.ldap.LdapDataAccessException: LdapCallback;Unprocessed Continuation Reference(s); nested exception is javax.naming.PartialResultException: Unprocessed Continuation Reference(s); remaining name ''

          If you set your root DN one level deep, like "OU=Site,DC=example,DC=com" then it will work correctly. This doesn't work if you need to validate from the root level. I think the correct fix is to:

          a) do not throw an exception if the referral connection is refused, just log it as a warning
          b) if Context.REFERRAL is 'ignore', do not follow referrals or throw an exception when referral is hit

          Casey McGinty added a comment - This bug causes the following exception: org.acegisecurity.AuthenticationServiceException: LdapCallback;null; nested exception is javax.naming.PartialResultException [Root exception is javax.naming.CommunicationException: example.com:389 [Root exception is java.net.ConnectException: Connection refused: connect] ]; nested exception is org.acegisecurity.ldap.LdapDataAccessException: LdapCallback;null; nested exception is javax.naming.PartialResultException [Root exception is javax.naming.CommunicationException: example.com:389 [Root exception is java.net.ConnectException: Connection refused: connect] ] It appears that Jenkins still throws an exception when 'Context.REFERRAL' is set to 'ignore'. org.acegisecurity.AuthenticationServiceException: LdapCallback;Unprocessed Continuation Reference(s); nested exception is javax.naming.PartialResultException: Unprocessed Continuation Reference(s); remaining name ''; nested exception is org.acegisecurity.ldap.LdapDataAccessException: LdapCallback;Unprocessed Continuation Reference(s); nested exception is javax.naming.PartialResultException: Unprocessed Continuation Reference(s); remaining name '' If you set your root DN one level deep, like "OU=Site,DC=example,DC=com" then it will work correctly. This doesn't work if you need to validate from the root level. I think the correct fix is to: a) do not throw an exception if the referral connection is refused, just log it as a warning b) if Context.REFERRAL is 'ignore', do not follow referrals or throw an exception when referral is hit

          Casey McGinty added a comment -

          Ok, I found another workaround. The issue is that the referral points to an invalid server. To fix this, all you have to do is edit your HOSTS file to point the DNS entry back to the LDAP server. In my situation I have Jenkins on a Windows box and the referral points to EXAMPLE.COM.

          Edit C:\Windows\System32\drivers\etc\hosts, add the line:

          XX.XX.XX.XX example.com

          where XX.XX.XX.XX is the IP address of your LDAP server.

          Also, unrelated to this bug, but for completeness your LDAP 'User Search Filter' should probably be "SAMAccountName=

          {0}

          " if you are using LDAP over Active Directory.

          Casey McGinty added a comment - Ok, I found another workaround. The issue is that the referral points to an invalid server. To fix this, all you have to do is edit your HOSTS file to point the DNS entry back to the LDAP server. In my situation I have Jenkins on a Windows box and the referral points to EXAMPLE.COM. Edit C:\Windows\System32\drivers\etc\hosts, add the line: XX.XX.XX.XX example.com where XX.XX.XX.XX is the IP address of your LDAP server. Also, unrelated to this bug, but for completeness your LDAP 'User Search Filter' should probably be "SAMAccountName= {0} " if you are using LDAP over Active Directory.

          We worked around this issue by switching from the Jenkins LDAP Plugin to the Jenkins Active Directory Plugin.

          Leif Gruenwoldt added a comment - We worked around this issue by switching from the Jenkins LDAP Plugin to the Jenkins Active Directory Plugin.

          Andy Pemberton added a comment - - edited

          I believe the description of this issue is incorrect (at least it is today). This value can be configured by setting an environment variable:

          java.naming.referral=ignore

          Will cause the referrals to ignored. The trouble is that you will still receive a PartialResultException if AD attempts to return an entry with referrals when referrals are ignored (see here for explanation: http://docs.spring.io/spring-ldap/docs/current/apidocs/org/springframework/ldap/core/LdapTemplate.html).

          I believe the proper fix is to leverage functionality like available in the more recent spring-ldap framework's LdapTemplate.ignorePartialResultException property, perhaps setting that property to true for the Jenkins ldap-plugin's LdapTemplate (or at least set to true if the java.naming.referral property is set to ignore).

          Andy Pemberton added a comment - - edited I believe the description of this issue is incorrect (at least it is today). This value can be configured by setting an environment variable: java.naming.referral=ignore Will cause the referrals to ignored. The trouble is that you will still receive a PartialResultException if AD attempts to return an entry with referrals when referrals are ignored (see here for explanation: http://docs.spring.io/spring-ldap/docs/current/apidocs/org/springframework/ldap/core/LdapTemplate.html ). I believe the proper fix is to leverage functionality like available in the more recent spring-ldap framework's LdapTemplate.ignorePartialResultException property, perhaps setting that property to true for the Jenkins ldap-plugin's LdapTemplate (or at least set to true if the java.naming.referral property is set to ignore).

          redmumba added a comment -

          I'd like to add--I filed this ticket almost 6 years ago, and I no longer work at the company where this was an issue. I'm sure a lot has changed since then, but at the time, the AD plug-in was not very well rounded, so we had to fall back on LDAP.

          redmumba added a comment - I'd like to add--I filed this ticket almost 6 years ago, and I no longer work at the company where this was an issue. I'm sure a lot has changed since then, but at the time, the AD plug-in was not very well rounded, so we had to fall back on LDAP.

          Gabriel Arena added a comment -

          I applied another workaround that works for me :
          Change the port number 3268 (instead of 389)

          A GC (global catalog) server returns referrals on 389 to refer to the greater AD "forest", but acts like a regular LDAP server on 3268 (and 3269 for LDAPS)

          @see : http://stackoverflow.com/questions/16412236/how-to-resolve-javax-naming-partialresultexception

          But maybe you should fight with the admin to open this port

          Gabriel Arena added a comment - I applied another workaround that works for me : Change the port number 3268 (instead of 389) A GC (global catalog) server returns referrals on 389 to refer to the greater AD "forest", but acts like a regular LDAP server on 3268 (and 3269 for LDAPS) @see : http://stackoverflow.com/questions/16412236/how-to-resolve-javax-naming-partialresultexception But maybe you should fight with the admin to open this port

            Unassigned Unassigned
            redmumba redmumba
            Votes:
            7 Vote for this issue
            Watchers:
            11 Start watching this issue

              Created:
              Updated: