I changed the configuration in tomcat and I am no longer seeing the problem.
Probably not a solution, but it does seem to be a workaround.

The key was setting the session-timeout to 0.

when 1.289 (or newer) comes out can you retest (set a small/nonzero session
timeout for quicker testing) and let us know if this is still an issue, or can
we close it? thanks!

will close soon without further input, thanks..

.

Hello,

the problem is still present in Hudson 1.299, Tomcat 6.0.18 with a timeout value
of 5.
15-Apr-2009 18:43:56 hudson.security.LDAPSecurityRealm$1 loadUserByUsername
WARNING: Failed to search LDAP for username=anotherUser
org.acegisecurity.ldap.LdapDataAccessException: LdapCallback;null; nested
exception is javax.naming.PartialResultException [Root exception is
javax.naming.ServiceUnavailableException: MYCOMPANY.COM:389; socket closed [Root
exception is com.sun.jndi.ldap.LdapReferralException: Continuation Reference;
remaining name '']; remaining name '']
at
org.acegisecurity.ldap.LdapTemplate$LdapExceptionTranslator.translate(LdapTemplate.java:295)
at org.acegisecurity.ldap.LdapTemplate.execute(LdapTemplate.java:128)
at org.acegisecurity.ldap.LdapTemplate.searchForSingleEntry(LdapTemplate.java:246)
at
org.acegisecurity.ldap.search.FilterBasedLdapUserSearch.searchForUser(FilterBasedLdapUserSearch.java:119)
at
hudson.security.LDAPSecurityRealm$1.loadUserByUsername(LDAPSecurityRealm.java:348)
at
hudson.security.LDAPSecurityRealm$MailAdressResolverImpl.findMailAddressFor(LDAPSecurityRealm.java:396)
at hudson.tasks.MailAddressResolver.resolve(MailAddressResolver.java:87)
at hudson.tasks.Mailer$UserProperty.getAddress(Mailer.java:429)
at
hudson.plugins.emailext.ExtendedEmailPublisher.createMail(ExtendedEmailPublisher.java:303)
at
hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:249)
at
hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:241)
at
hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:199)
at
hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:372)
at
hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:360)
at hudson.model.Build$RunnerImpl.cleanUp(Build.java:188)
at hudson.model.Run.run(Run.java:962)
at hudson.model.Build.run(Build.java:112)
at hudson.model.ResourceController.execute(ResourceController.java:93)
at hudson.model.Executor.run(Executor.java:119)

many thanks.

any further possibility to have this issue being looked at?

with Hudson v1.311, tomcat 6.0.20 (with or without tcnative support) this is the
error entry generated in catalina log file:
20-Jun-2009 10:52:18 hudson.security.LDAPSecurityRealm$1 loadUserByUsername
WARNING: Failed to search LDAP for username=example
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 timed out: connect]]
at
org.acegisecurity.ldap.LdapTemplate$LdapExceptionTranslator.translate(LdapTemplate.java:295)
at org.acegisecurity.ldap.LdapTemplate.execute(LdapTemplate.java:128)
at org.acegisecurity.ldap.LdapTemplate.searchForSingleEntry(LdapTemplate.java:246)
at
org.acegisecurity.ldap.search.FilterBasedLdapUserSearch.searchForUser(FilterBasedLdapUserSearch.java:119)
at
hudson.security.LDAPSecurityRealm$1.loadUserByUsername(LDAPSecurityRealm.java:348)
at
org.acegisecurity.ui.rememberme.TokenBasedRememberMeServices.loadUserDetails(TokenBasedRememberMeServices.java:308)
at
org.acegisecurity.ui.rememberme.TokenBasedRememberMeServices.autoLogin(TokenBasedRememberMeServices.java:218)
at
org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:104)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at
org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at
org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at
org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249)
at
hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:66)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:155)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.jstripe.tomcat.probe.Tomcat55AgentValve.invoke(Tomcat55AgentValve.java:20)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
at java.lang.Thread.run(Unknown Source)
Caused by: javax.naming.PartialResultException [Root exception is
javax.naming.CommunicationException: EXAMPLE.COM:389 [Root exception is
java.net.ConnectException: Connection timed out: connect]]
at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl(Unknown Source)
at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreReferrals(Unknown Source)
at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl(Unknown Source)
at com.sun.jndi.ldap.LdapNamingEnumeration.hasMore(Unknown Source)
at org.acegisecurity.ldap.LdapTemplate$3.doInDirContext(LdapTemplate.java:257)
at org.acegisecurity.ldap.LdapTemplate.execute(LdapTemplate.java:126)
... 32 more
Caused by: javax.naming.CommunicationException: EXAMPLE.COM:389 [Root exception
is java.net.ConnectException: Connection timed out: connect]
at com.sun.jndi.ldap.LdapReferralContext.<init>(Unknown Source)
at com.sun.jndi.ldap.LdapReferralException.getReferralContext(Unknown Source)
at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreReferrals(Unknown Source)
... 38 more
Caused by: java.net.ConnectException: Connection timed out: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.<init>(Unknown Source)
at java.net.Socket.<init>(Unknown Source)
at com.sun.jndi.ldap.Connection.createSocket(Unknown Source)
at com.sun.jndi.ldap.Connection.<init>(Unknown Source)
at com.sun.jndi.ldap.LdapClient.<init>(Unknown Source)
at com.sun.jndi.ldap.LdapClientFactory.createPooledConnection(Unknown Source)
at com.sun.jndi.ldap.pool.Connections.getOrCreateConnection(Unknown Source)
at com.sun.jndi.ldap.pool.Connections.get(Unknown Source)
at com.sun.jndi.ldap.pool.Pool.getPooledConnection(Unknown Source)
at com.sun.jndi.ldap.LdapPoolManager.getLdapClient(Unknown Source)
at com.sun.jndi.ldap.LdapClient.getInstance(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.connect(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.<init>(Unknown Source)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(Unknown Source)
at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(Unknown Source)
at com.sun.jndi.url.ldap.ldapURLContextFactory.getObjectInstance(Unknown Source)
at javax.naming.spi.NamingManager.getURLObject(Unknown Source)
at javax.naming.spi.NamingManager.processURL(Unknown Source)
at javax.naming.spi.NamingManager.processURLAddrs(Unknown Source)
at javax.naming.spi.NamingManager.getObjectInstance(Unknown Source)
... 41 more

when I perform on the server hosting Tomcat and Hudson the exact same query (as
configured in Hudson config.xml) using ldapsearch the outcome is a valid
response from the LDAP service.

not clear why though the error log is reporting EXAMPLE.COM:389 (i.e. using the
rootDN) rather than the actual host address specified in the config settings.

can you describe in more detail the exact steps you perform to see this problem?
I gather that you login just fine, then let your tomcat session expire, then
visit any hudson page again? Hudson is now trying to login a new session with
the "remember-me" cookie, and you get this exception? Are you in fact logged in
now, even though the exception occurred, or did it fail and you are a guest? If
you try to login now are you able to? Or are you not able to see any pages now
because the exception occurs every time?
I didn't follow your EXAMPLE.COM vs config settings thing.. what are your LDAP
settings in Hudson?

Discrepancy between what the log reports and what the configuration contains in
LDAP security mode.

• the log reports EXAMPLE.COM:389
• the config 'server' param is set to 192.168.1.1:389
  the config 'rootDN' param is set to DC=EXAMPLE,DC=COM

the log should report:
javax.naming.CommunicationException: 192.168.1.1:389 [Root exception is
java.net.ConnectException: Connection timed out: connect]]

and not:
javax.naming.CommunicationException: EXAMPLE.COM:389 [Root exception is
java.net.ConnectException: Connection timed out: connect]]

this happens for every failed login attempt (back to the retry login page as guest).

my current work-around is to set the global tomcat session-timeout parameter to 0

> I gather that you login just fine, then let your tomcat session expire, then
visit any hudson page again?

without the session-timeout change I can't even login with LDAP authorization
immediately after a tomcat start.

with the session-timeout change I can login with LDAP authentication. Now I let
the tomcat/hudson session expire....

> Hudson is now trying to login a new session with the "remember-me" cookie, and
you get this exception?

yes.

> Are you in fact logged in now, even though the exception occurred, or did it
fail and you are a guest?

exception occurs, authorization fails and back as guest.

> If you try to login now are you able to?

no unless I change the session-timeout global param

> Or are you not able to see any pages now because the exception occurs every time?

without changing the session-timeout param only the guest account works.

I noticed this change of behaviour when using Tomcat 6.0.20 and recent Hudson
versions.

this change is in the LDAP socket error. before it was 'socket closed' now it is
'Connection timed out'.

With the current socket error (Connection timed out) it is impossible to login
with a valid LDAP account unless session-timeout is set to 0.

<useSecurity>true</useSecurity>
<authorizationStrategy
class="hudson.security.FullControlOnceLoggedInAuthorizationStrategy"/>
<securityRealm class="hudson.security.LDAPSecurityRealm">
<server>192.168.1.1:389</server>
<rootDN>DC=EXAMPLE,DC=COM</rootDN>
<userSearchBase></userSearchBase>
<userSearch>(&(sAMAccountName=

)(memberOf=CN=Hudson
Access;OU=Services;DC=EXAMPLE;DC=COM))</userSearch>
<managerDN>CN=apache,OU=Apache,OU=Services,DC=EXAMPLE,DC=COM</managerDN>
<managerPassword>XXXXXXX</managerPassword>
</securityRealm>

Hello,

I have experimented using the same LDAP security configuration without Tomcat,
just Hudson standalone (using Winstone), and the same issue arises. I believe it
is purely now an issue within Hudson.

thanks for the attention

Re-prioritizing.

I have done a simple test with Hudson release 301, 310, 318, 320, 323. Just
downloaded the hudson.war, installed it, set the ldap authentication with my
ldap login and tried to login. Oops! I could not able to login.

Definitely its a hudson problem.

I am struggling for many releases.

abarbieri/kajays: can you try replacing WEB-INF/lib/acegisecurity-1.0.5.jar with
the 1.0.7 jar from http://sourceforge.net/projects/acegisecurity/files/ ?
Let us know if the problem persists even with this version.. with luck, a simple
upgrade of this library will help.

I have tried after copying acegi-security-1.0.7.jar but this also not working.

seems issue 3460 having same issue.

http://sourceforge.net/project/shownotes.php?release_id=592318

File Release Notes and Changelog

Release Name: acegisecurity-1.0.7

Notes: WARNING: Acegi Security is now a DEPRECATED PRODUCT. We strongly
recommend you transition to the Spring Security product, which is built on top
of Acegi Security and features substantial new features, improvements and
simplifications. You can access Spring Security at
http://springframework.org/security.

Changes: WARNING: Acegi Security is now a DEPRECATED PRODUCT. We strongly
recommend you transition to the Spring Security product, which is built on top
of Acegi Security and features substantial new features, improvements and
simplifications. You can access Spring Security at
http://springframework.org/security.

maybe if possible thinking to switch to Spring Security (stable is 2.0.5) would
be a better plan?

but how can we switch to spring security?

I think there is some changes after 1.286 release that make the ldap
authentication fail. It would be very great if someone can fix it.

but how can we switch to spring security?

I think there is some changes after 1.286 release that make the ldap
authentication fail. It would be very great if someone can fix it.

abarbieri- yes, spring security 2 might help as well, but that would likely
require code changes.. I thought a good first test would be simply dropping in
the latest 1.x jar. Thanks kajays for trying that.

kajays, so you think a change in Hudson made something stop working? It sounds
like it works for you on 1.286 but not on 1.301 or several later versions? Can
we narrow this down further? There were a couple ldap changes in 1.289, so
please try 1.288 and 1.289 to see if that was the breaking point. There was a
refactor in form validation in 1.294, but I wouldn't expect that to affect the
actual ldap authentication.

It hasn't worked for me since I first reported the bug [v1.255]. I played
around with a few different settings and I mistakenly thought I configured
around the problem but the issue has been present since at least then.

kajays, also can you post the stack trace you get when attempting to login?

Starting from Hudson version 1.289 the ldap authentication stop working. Upto
1.288 its working fine.

after pressing login button it keep on "waiting for
http://localhost:8080/j_acegi_security_check..."

stack trace is:

INFO: JNLP slave agent listener started on TCP port 4592
Sep 17, 2009 12:12:13 PM hudson.security.AuthenticationProcessingFilter2 onUnsuc
cessfulAuthentication
INFO: Login attempt failed
org.acegisecurity.AuthenticationServiceException: LdapCallback;[LDAP: error code
3 - Timelimit Exceeded]; nested exception is javax.naming.TimeLimitExceededExce
ption: [LDAP: error code 3 - Timelimit Exceeded]; remaining name ''; nested exce
ption is org.acegisecurity.ldap.LdapDataAccessException: LdapCallback;[LDAP: err
or code 3 - Timelimit Exceeded]; nested exception is javax.naming.TimeLimitExcee
dedException: [LDAP: error code 3 - Timelimit Exceeded]; remaining name ''
at org.acegisecurity.providers.ldap.LdapAuthenticationProvider.retrieveU
ser(LdapAuthenticationProvider.java:238)
at org.acegisecurity.providers.dao.AbstractUserDetailsAuthenticationProv
ider.authenticate(AbstractUserDetailsAuthenticationProvider.java:119)
at org.acegisecurity.providers.ProviderManager.doAuthentication(Provider
Manager.java:195)
at org.acegisecurity.AbstractAuthenticationManager.authenticate(Abstract
AuthenticationManager.java:45)
at org.acegisecurity.ui.webapp.AuthenticationProcessingFilter.attemptAut
hentication(AuthenticationProcessingFilter.java:71)
at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProces
singFilter.java:252)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.
java:78)
at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicPr
ocessingFilter.java:173)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.
java:78)
at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilte
r(HttpSessionContextIntegrationFilter.java:249)
at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSes
sionContextIntegrationFilter2.java:66)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.
java:78)
at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.ja
va:67)
at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:133)
at winstone.FilterConfiguration.execute(FilterConfiguration.java:195)
at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:368)
at winstone.RequestDispatcher.forward(RequestDispatcher.java:333)
at winstone.RequestHandlerThread.processRequest(RequestHandlerThread.jav
a:244)
at winstone.RequestHandlerThread.run(RequestHandlerThread.java:150)
at java.lang.Thread.run(Unknown Source)
Caused by: org.acegisecurity.ldap.LdapDataAccessException: LdapCallback;[LDAP: e
rror code 3 - Timelimit Exceeded]; nested exception is javax.naming.TimeLimitExc
eededException: [LDAP: error code 3 - Timelimit Exceeded]; remaining name ''
at org.acegisecurity.ldap.LdapTemplate$LdapExceptionTranslator.translate
(LdapTemplate.java:295)
at org.acegisecurity.ldap.LdapTemplate.execute(LdapTemplate.java:128)
at org.acegisecurity.ldap.LdapTemplate.searchForSingleAttributeValues(Ld
apTemplate.java:227)
at org.acegisecurity.providers.ldap.populator.DefaultLdapAuthoritiesPopu
lator.getGroupMembershipRoles(DefaultLdapAuthoritiesPopulator.java:228)
at org.acegisecurity.providers.ldap.populator.DefaultLdapAuthoritiesPopu
lator.getGrantedAuthorities(DefaultLdapAuthoritiesPopulator.java:181)
at org.acegisecurity.providers.ldap.LdapAuthenticationProvider.createUse
rDetails(LdapAuthenticationProvider.java:203)
at org.acegisecurity.providers.ldap.LdapAuthenticationProvider.retrieveU
ser(LdapAuthenticationProvider.java:235)
... 19 more
Caused by: javax.naming.TimeLimitExceededException: [LDAP: error code 3 - Timeli
mit Exceeded]; remaining name ''
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.searchAux(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.c_search(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.c_search(Unknown Source)
at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(Unknown Source)

at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown So
urce)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown So
urce)
at javax.naming.directory.InitialDirContext.search(Unknown Source)
at org.acegisecurity.ldap.LdapTemplate$1SingleAttributeSearchCallback.do
InDirContext(LdapTemplate.java:202)
at org.acegisecurity.ldap.LdapTemplate.execute(LdapTemplate.java:126)
... 24 more

There seem to be multiple issues and kajays is experiencing a different problem.
I would like to suggest we split this ticket so that we're only dealing with
one issue in each.

Below is a stack trace for the original problem (reproduced using v1.317):

Sep 17, 2009 8:01:36 AM hudson.security.AuthenticationProcessingFilter2
onUnsuccessfulAuthentication
INFO: Login attempt failed
org.acegisecurity.AuthenticationServiceException:
LdapCallback;directory.mycompany.com:389; socket closed; nested exception is
javax.naming.ServiceUnavailableException: directory.mycompany.com:389; socket
closed; remaining name ''; nested exception is
org.acegisecurity.ldap.LdapDataAccessException:
LdapCallback;directory.mycompany.com:389; socket closed; nested exception is
javax.naming.ServiceUnavailableException: directory.mycompany.com:389; socket
closed; remaining name ''
at
org.acegisecurity.providers.ldap.LdapAuthenticationProvider.retrieveUser(LdapAuthenticationProvider.java:238)
at
org.acegisecurity.providers.dao.AbstractUserDetailsAuthenticationProvider.authenticate(AbstractUserDetailsAuthenticationProvider.java:119)
at
org.acegisecurity.providers.ProviderManager.doAuthentication(ProviderManager.java:195)
at
org.acegisecurity.AbstractAuthenticationManager.authenticate(AbstractAuthenticationManager.java:45)
at
org.acegisecurity.ui.webapp.AuthenticationProcessingFilter.attemptAuthentication(AuthenticationProcessingFilter.java:71)
at
org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:252)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at
org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at
org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249)
at
hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:66)
at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:155)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
Caused by: org.acegisecurity.ldap.LdapDataAccessException:
LdapCallback;directory.mycompany.com:389; socket closed; nested exception is
javax.naming.ServiceUnavailableException: directory.mycompany.com:389; socket
closed; remaining name ''
at
org.acegisecurity.ldap.LdapTemplate$LdapExceptionTranslator.translate(LdapTemplate.java:295)
at org.acegisecurity.ldap.LdapTemplate.execute(LdapTemplate.java:128)
at org.acegisecurity.ldap.LdapTemplate.searchForSingleEntry(LdapTemplate.java:246)
at
org.acegisecurity.ldap.search.FilterBasedLdapUserSearch.searchForUser(FilterBasedLdapUserSearch.java:119)
at
org.acegisecurity.providers.ldap.authenticator.BindAuthenticator.authenticate(BindAuthenticator.java:71)
at
org.acegisecurity.providers.ldap.authenticator.BindAuthenticator2.authenticate(BindAuthenticator2.java:49)
at
org.acegisecurity.providers.ldap.LdapAuthenticationProvider.retrieveUser(LdapAuthenticationProvider.java:233)
... 26 more
Caused by: javax.naming.ServiceUnavailableException:
directory.mycompany.com:389; socket closed; remaining name ''
at com.sun.jndi.ldap.Connection.readReply(Connection.java:416)
at com.sun.jndi.ldap.LdapClient.getSearchReply(LdapClient.java:611)
at com.sun.jndi.ldap.LdapClient.search(LdapClient.java:534)
at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:1962)
at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1824)
at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1749)
at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1766)
at
com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:394)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:376)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:358)
at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:267)
at org.acegisecurity.ldap.LdapTemplate$3.doInDirContext(LdapTemplate.java:249)
at org.acegisecurity.ldap.LdapTemplate.execute(LdapTemplate.java:126)
... 31 more

I can usually connect on the second attempt.

kajays, I have some info for you.. if you need more assistance after this,
please open a new ticket as suggested (you can add me in the CC list).

I think your problem is as the exception suggests.. LDAP query is taking too
long and timing out. The change in 1.289 that "broke" things for you was adding
back the LDAP group query that was inadvertently removed in 1.280. Here is the
change:

— war/resources/WEB-INF/security/LDAPBindSecurityRealm.groovy (revision 15955)
+++ war/resources/WEB-INF/security/LDAPBindSecurityRealm.groovy (revision 16034)
@@ -64,4 +64,5 @@
authoritiesPopulator(AuthoritiesPopulatorImpl, initialDirContextFactory,
Util.fixNull(instance.groupSearchBase)) {
// see DefaultLdapAuthoritiesPopulator for other possible configurations
searchSubtree = true;
+ groupSearchFilter = "(| (member=

) (memberUid=

))";
}

I think you should customize your LDAPBindSecurityRealm.groovy file, and either
remove that line or change it to just the query you need for your LDAP, such as:
groupSearchFilter = "(uniqueMember=

)";
You might also set a groups base DN in your Hudson config.. this reduces the
scope of the group query, which can also avoid this timeout.
Hope this helps.

Thanks a lot. It solved my problem.

jonathan_w_brown, not sure what else we can do.. you can try acegi 1.0.7 as
suggested above, or tinker with the settings in LDAPSecurityRealm.groovy.
Perhaps you can find an LDAP-experts forum to help with intermittent connection
problems. I have actually seen intermittent failures with my own corporate LDAP
in a little webapp I wrote, and was able to resolve it by switching from the
C-based LDAP implementation in Sun Java System Web Server 7 to the java based
one.. so I know at least in one case changing client library has helped, but
clearly the server and its configuration are involved too.

We now have a test build using Spring Security 2.0.5, you can get it here: http://moshpit.org/hudson.war

Please let me know if you can try a new install using this build and test it with your LDAP server.. otherwise let me know if we should just close this issue, thanks.

Is anyone able to try the above hudson.war?

anyone still watching this?

Just found this issue, and I'm having the same problem (socket closed). I was not able to download the hudson.war from moshpit (HTTP 403: Forbidden).

Hudson: 1.337 (purposefully)
Tomcat: 5.5.27
LDAP: Active Directory on Windows Server 2008

I also had this issue using Active Directory on Windows Server 2003. The Active Directory plugin doesn't work for me, which is why I'm using LDAP instead.

Ooops, thanks.. download link fixed: http://moshpit.org/hudson.war

Hope someone will try it..

Test build with spring framework 2.0.5 now updated for near-Hudson-1.350. Kohsuke is against upgrading (due to plugin compatibility issues), so it only has a chance to happen if several people tell us it makes things work in an environment where 1.0.5 fails. Will close this issue soon if there are no responses.

We definitely have EXACTLY the same problem. After session timeouts we get...

Caused by: javax.naming.ServiceUnavailableException: ldap:389; socket closed; remaining name 'ou=lvmuser'
at com.sun.jndi.ldap.Connection.readReply(Connection.java:419)
at com.sun.jndi.ldap.LdapClient.getSearchReply(LdapClient.java:611)
at com.sun.jndi.ldap.LdapClient.search(LdapClient.java:534)
at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:1962)
at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1824)
at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1749)
at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1766)
at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:394)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:376)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:358)
at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:267)
at org.acegisecurity.ldap.LdapTemplate$3.doInDirContext(LdapTemplate.java:249)
at org.acegisecurity.ldap.LdapTemplate.execute(LdapTemplate.java:126)
... 33 more

Nothing works. Neither hacking LDAPSecurityRealm.groovy nor setting Connection-Pool parameters. Without a solid bugfix we are LOST. (Maybe we have a chance to meet Evangeline Lilly now

Furthermore we discovered this (catalina.out):

Caused by: java.io.NotSerializableException: com.sun.jndi.ldap.LdapCtx
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:416)
at java.lang.Throwable.writeObject(Throwable.java:648)
at sun.reflect.GeneratedMethodAccessor359.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1461)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:416)
at java.lang.Throwable.writeObject(Throwable.java:648)
at sun.reflect.GeneratedMethodAccessor359.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1461)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
at org.apache.catalina.session.StandardSession.writeObject(StandardSession.java:1478)
at org.apache.catalina.session.StandardSession.writeObjectData(StandardSession.java:948)
at org.apache.catalina.session.StandardManager.doUnload(StandardManager.java:517)
at org.apache.catalina.session.StandardManager.unload(StandardManager.java:463)
at org.apache.catalina.session.StandardManager.stop(StandardManager.java:667)
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4363)
at org.apache.catalina.manager.ManagerServlet.stop(ManagerServlet.java:1227)
at org.apache.catalina.manager.HTMLManagerServlet.stop(HTMLManagerServlet.java:563)
at org.apache.catalina.manager.HTMLManagerServlet.doGet(HTMLManagerServlet.java:107)

What we ALSO discovered analysing some DIFFERENT LDAP-Implementations (Netscape...) we saw strange ServiceUnavailableException handlings:

=> Get Connection from pool
=> Perform a LDAP search
=> catch ServiceUnavailableException
=> Try LDAP search AGAIN

I suppose those paranoia hacks aren't programmed in the org.acegisecurity.ldap implementation...

chrisabit, what behavior did you see with the spring 2.0.5 test build?

You mean that http://moshpit.org/hudson.war ? Same problem !

Ok - we gave up. Pity. Hudson-LDAP simply doesn't work in our environment. We've created an tomcat valve for authentification & SSO instead. By the way... Nexus LDAP-Auth works on the SAME SYSTEM !!!

I have the same problem. Not sure what is causing it, but randomly I'll get this in the log files, and then either I wait a while or restart Hudson to be able to log back in:

Also, I'm just starting hudson up with java -jar hudson.war, so this is not inside of Tomcat.

Jun 22, 2010 12:43:11 PM hudson.security.LDAPSecurityRealm$LDAPUserDetailsService loadUserByUsername
WARNING: Failed to search LDAP for username=lshatzer
org.acegisecurity.ldap.LdapDataAccessException: LdapCallback;ldap.company.com:389; socket closed; nested exception is javax.naming.ServiceUnavailableException: ldap.company.com.com:389; socket closed; remaining name 'ou=People,o=company.com'
        at org.acegisecurity.ldap.LdapTemplate$LdapExceptionTranslator.translate(LdapTemplate.java:295)
        at org.acegisecurity.ldap.LdapTemplate.execute(LdapTemplate.java:128)
        at org.acegisecurity.ldap.LdapTemplate.searchForSingleEntry(LdapTemplate.java:246)
        at org.acegisecurity.ldap.search.FilterBasedLdapUserSearch.searchForUser(FilterBasedLdapUserSearch.java:119)
        at hudson.security.LDAPSecurityRealm$LDAPUserDetailsService.loadUserByUsername(LDAPSecurityRealm.java:396)
        at org.acegisecurity.ui.rememberme.TokenBasedRememberMeServices.loadUserDetails(TokenBasedRememberMeServices.java:308)
        at org.acegisecurity.ui.rememberme.TokenBasedRememberMeServices.autoLogin(TokenBasedRememberMeServices.java:218)
        at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:104)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
        at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
        at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
        at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249)
        at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:66)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
        at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
        at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
        at winstone.FilterConfiguration.execute(FilterConfiguration.java:195)
        at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:368)
        at winstone.RequestDispatcher.forward(RequestDispatcher.java:333)
        at winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:244)
        at winstone.RequestHandlerThread.run(RequestHandlerThread.java:150)
        at java.lang.Thread.run(Thread.java:619)
Caused by: javax.naming.ServiceUnavailableException: ds.company.com:389; socket closed; remaining name 'ou=People,o=company.com'
        at com.sun.jndi.ldap.Connection.readReply(Connection.java:416)
        at com.sun.jndi.ldap.LdapClient.getSearchReply(LdapClient.java:611)
        at com.sun.jndi.ldap.LdapClient.search(LdapClient.java:534)
        at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:1962)
        at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1824)
        at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1749)
        at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1766)
        at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:394)
        at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:376)
        at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:358)
        at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:267)
        at org.acegisecurity.ldap.LdapTemplate$3.doInDirContext(LdapTemplate.java:249)
        at org.acegisecurity.ldap.LdapTemplate.execute(LdapTemplate.java:126)
        ... 22 more

When I try to log in:

Jun 22, 2010 12:52:44 PM hudson.security.AuthenticationProcessingFilter2 onUnsuccessfulAuthentication
INFO: Login attempt failed
org.acegisecurity.AuthenticationServiceException: LdapCallback;ldap.company.com:389; socket closed; nested exception is javax.naming.ServiceUnavailableException: ldap.company.com:389; socket closed; remaining name 'ou=People,o=company.com'; nested exception is org.acegisecurity.ldap.LdapDataAccessException: LdapCallback;ldap.company.com:389; socket closed; nested exception is javax.naming.ServiceUnavailableException: ldap.company.com:389; socket closed; remaining name 'ou=People,o=company.com'
        at org.acegisecurity.providers.ldap.LdapAuthenticationProvider.retrieveUser(LdapAuthenticationProvider.java:238)
        at org.acegisecurity.providers.dao.AbstractUserDetailsAuthenticationProvider.authenticate(AbstractUserDetailsAuthenticationProvider.java:119)
        at org.acegisecurity.providers.ProviderManager.doAuthentication(ProviderManager.java:195)
        at org.acegisecurity.AbstractAuthenticationManager.authenticate(AbstractAuthenticationManager.java:45)
        at org.acegisecurity.ui.webapp.AuthenticationProcessingFilter.attemptAuthentication(AuthenticationProcessingFilter.java:71)
        at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:252)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
        at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
        at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249)
        at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:66)
        at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
        at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
        at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
        at winstone.FilterConfiguration.execute(FilterConfiguration.java:195)
        at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:368)
        at winstone.RequestDispatcher.forward(RequestDispatcher.java:333)
        at winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:244)
        at winstone.RequestHandlerThread.run(RequestHandlerThread.java:150)
        at java.lang.Thread.run(Thread.java:619)
Caused by: org.acegisecurity.ldap.LdapDataAccessException: LdapCallback;ldap.company.com:389; socket closed; nested exception is javax.naming.ServiceUnavailableException: ldap.company.com:389; socket closed; remaining name 'ou=People,o=company.com'
        at org.acegisecurity.ldap.LdapTemplate$LdapExceptionTranslator.translate(LdapTemplate.java:295)
        at org.acegisecurity.ldap.LdapTemplate.execute(LdapTemplate.java:128)
        at org.acegisecurity.ldap.LdapTemplate.searchForSingleEntry(LdapTemplate.java:246)
        at org.acegisecurity.ldap.search.FilterBasedLdapUserSearch.searchForUser(FilterBasedLdapUserSearch.java:119)
        at org.acegisecurity.providers.ldap.authenticator.BindAuthenticator.authenticate(BindAuthenticator.java:71)
        at org.acegisecurity.providers.ldap.authenticator.BindAuthenticator2.authenticate(BindAuthenticator2.java:49)
        at org.acegisecurity.providers.ldap.LdapAuthenticationProvider.retrieveUser(LdapAuthenticationProvider.java:233)
        ... 19 more
Caused by: javax.naming.ServiceUnavailableException: ldap.company.com:389; socket closed; remaining name 'ou=People,o=company.com'
        at com.sun.jndi.ldap.Connection.readReply(Connection.java:416)
        at com.sun.jndi.ldap.LdapClient.getSearchReply(LdapClient.java:611)
        at com.sun.jndi.ldap.LdapClient.search(LdapClient.java:534)
        at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:1962)
        at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1824)
        at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1749)
        at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1766)
        at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:394)
        at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:376)
        at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:358)
        at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:267)
        at org.acegisecurity.ldap.LdapTemplate$3.doInDirContext(LdapTemplate.java:249)
        at org.acegisecurity.ldap.LdapTemplate.execute(LdapTemplate.java:126)
        ... 24 more

Still not working with Jenkins 1.398 (Standalone).

Same problem ...

 
23 févr. 2011 11:44:30 hudson.security.AuthenticationProcessingFilter2 onUnsuccessfulAuthentication
INFO: Login attempt failed
org.acegisecurity.AuthenticationServiceException: LdapCallback;null; nested exception is javax.naming.PartialResultException [Root exception is javax.naming.CommunicationException: *****:389 [Root exception is java.net.ConnectException: connect: Address is invalid on local machine, or port is not valid on remote machine]]; nested exception is org.acegisecurity.ldap.LdapDataAccessException: LdapCallback;null; nested exception is javax.naming.PartialResultException [Root exception is javax.naming.CommunicationException: *****:389 [Root exception is java.net.ConnectException: connect: Address is invalid on local machine, or port is not valid on remote machine]]
        at ...

We have the same issue with Jenkins 1.410 running under Tomcat7 on Server 2008 R2. It seems that Jenkins periodically stops trying to authenticate to the specified server, e.g. derp.mycompany.com, and starts trying to authenticate to mycompany.com.

If 1.289 changed things, JENKINS-2256 or JENKINS-1475 would be related.