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

I have configured for ldap connectivity in hudson . login it gets hung up and after few minutes it get logged in.

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Critical Critical
    • None
    • Platform: All, OS: Windows XP

      I have configured for ldap connectivity in hudson . I have given all the
      required parameters But while trying to login it gets hung up and after few
      minutes it get logged in.
      Neither its showing any error in catalina.out. I have no clue.

      Is there anything else I need to configure for ldap in hudson other than the
      required parameters to increase the login speed

          [JENKINS-4948] I have configured for ldap connectivity in hudson . login it gets hung up and after few minutes it get logged in.

          robertredd added a comment -

          I'm having the exact same issue. I configured the LDAP security to work with our Active Directory server and I'm using Matrix-based security. Sometimes the login will take about 3 minutes.

          Anyone have any ideas?

          robertredd added a comment - I'm having the exact same issue. I configured the LDAP security to work with our Active Directory server and I'm using Matrix-based security. Sometimes the login will take about 3 minutes. Anyone have any ideas?

          robertredd added a comment -

          This may help someone else. I was connecting to AD using the LDAP config. We do have actual LDAP servers that are kept in sync, so I switched to using our LDAP servers instead and now I'm not seeing this delay anymore.

          The other thing is that I did not have a user search base when I was configured against AD. Now with LDAP I'm using the standard ou=People.

          Maybe this will help someone else.

          It seemed that the time delay only happened on the first login after a Hudson startup for each person when I was configured against the Active Directory server using the standard LDAP plugin, just using the mappings to Active Directory in it.

          robertredd added a comment - This may help someone else. I was connecting to AD using the LDAP config. We do have actual LDAP servers that are kept in sync, so I switched to using our LDAP servers instead and now I'm not seeing this delay anymore. The other thing is that I did not have a user search base when I was configured against AD. Now with LDAP I'm using the standard ou=People. Maybe this will help someone else. It seemed that the time delay only happened on the first login after a Hudson startup for each person when I was configured against the Active Directory server using the standard LDAP plugin, just using the mappings to Active Directory in it.

          When a hang happens, please obtain the thread dump as per instruction in https://wiki.jenkins-ci.org/display/JENKINS/Build+is+hanging and attach those dumps here. Please be encouraged to do it several times so that we can better understand where the time consuming operation is taking place.

          Kohsuke Kawaguchi added a comment - When a hang happens, please obtain the thread dump as per instruction in https://wiki.jenkins-ci.org/display/JENKINS/Build+is+hanging and attach those dumps here. Please be encouraged to do it several times so that we can better understand where the time consuming operation is taking place.

          Fabrice Daugan added a comment - - edited

          This issue still exists in Jenkins 1.611.
          You can avoid this problem by applying recommanded performance tuning and replacing the default and generic values to the LDAP/AD dependant filter :

          • Group search filter --> (& (cn={0}) (objectclass=groupOfUniqueNames))
          • Group membership filter --> uniqueMember= {0}

          Fabrice Daugan added a comment - - edited This issue still exists in Jenkins 1.611. You can avoid this problem by applying recommanded performance tuning and replacing the default and generic values to the LDAP/AD dependant filter : Group search filter --> (& (cn={0}) (objectclass=groupOfUniqueNames)) Group membership filter --> uniqueMember= {0}

          robertredd added a comment - - edited

          Try switching the port to 3268 for using LDAP protocol with Active Directory. I used to have this problem a few years ago. Microsoft sets up port 3268 to be tuned for LDAP queries against AD. You'll see a huge difference. So, try the server like <server>.com:3268 in your setup.

          Funny, I just saw that I had commented on this thread years ago! And, just as info, when I switched from port 389 to 3268 for Active Directory, my initial login went from minutes, to just a couple seconds. If you search for info on that port there's a lot of technical information on the Microsoft site about how this port is different with Active Directory, but I haven't tried to understand it all. It's just designed for LDAP queries better, something about using the catalog.

          robertredd added a comment - - edited Try switching the port to 3268 for using LDAP protocol with Active Directory. I used to have this problem a few years ago. Microsoft sets up port 3268 to be tuned for LDAP queries against AD. You'll see a huge difference. So, try the server like <server>.com:3268 in your setup . Funny, I just saw that I had commented on this thread years ago! And, just as info, when I switched from port 389 to 3268 for Active Directory, my initial login went from minutes, to just a couple seconds. If you search for info on that port there's a lot of technical information on the Microsoft site about how this port is different with Active Directory, but I haven't tried to understand it all. It's just designed for LDAP queries better, something about using the catalog.

            Unassigned Unassigned
            durgadasd durgadasd
            Votes:
            2 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: