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

AD and LDAP fail due to Referrals

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Component/s: ldap-plugin
    • Labels:
      None
    • Environment:
      Platform: PC, OS: Linux
    • Similar Issues:

      Description

      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

        Attachments

          Activity

          Hide
          ssbarnea 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?

          Show
          ssbarnea 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?
          Hide
          cmcginty 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

          Show
          cmcginty 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
          Hide
          cmcginty 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.

          Show
          cmcginty 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.
          Hide
          leif81 Leif Gruenwoldt added a comment -

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

          Show
          leif81 Leif Gruenwoldt added a comment - We worked around this issue by switching from the Jenkins LDAP Plugin to the Jenkins Active Directory Plugin.
          Hide
          apemberton 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).

          Show
          apemberton 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).
          Hide
          redmumba 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.

          Show
          redmumba 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.
          Hide
          arena_gabriel 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

          Show
          arena_gabriel 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

            People

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

              Dates

              • Created:
                Updated: