Sebastian Bathke added a comment - 2015-02-16 10:38 - edited We have loging working for a certain time period after startup of jenkins. But it gets broken some hours later. A restart solves login problems for another period. Other tools work well with the same ldap host (gerrit, sonar). Jenkins v1.598, LDAP-Plugin v1.11

Mark Nejman added a comment - 2015-03-11 21:39 I am also experiencing the same behavior. It works for anywhere from 1 to 24 hours, but then I cannot login until I restart. Could this be an issue with the LDAP using SSL?

Manoj Binjola added a comment - 2015-03-16 06:38 I am also facing the same issue. Jenkins 1.508.2, TOmcat 7, LDAP plugin 1.11 I've created a ticked but found that many people facing the same issue, so I closed it as duplicate. JENKINS-27434

Manoj Binjola added a comment - 2015-03-23 03:09 Hi, is there any update on this issue. Please let us know if its not related to Jenkins, so that we could focus on other aspects.

Mark Nejman added a comment - 2015-03-23 20:05 No updates as far as I can tell. I did add the com.sun.jndi.ldap.connect.timeout and com.sun.jndi.ldap.read.timeout parameters though, with values of 50000 and 100000 respectively. I think it has helped. I'm not experiencing this issue as frequently.

Mark Nejman added a comment - 2015-04-23 12:42 I am still experiencing this issue where after about 3 or 4 hours, I can no longer log in and need to restart. The Jenkins log did not show any errors, but I tried using the Jenkins CLI and got a stack trace. Hopefully this can shed some light on the issue. I should note that our LDAP connection is an SSL connection through an F5 load balancer. Our certificates are signed by a CA, and I do have the trust store set up. org.acegisecurity.AuthenticationServiceException: Unable to connect to LDAP server; nested exception is javax.naming.CommunicationException: <LDAP_VIP>:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors]; nested exception is org.acegisecurity.ldap.LdapDataAccessException: Unable to connect to LDAP server; nested exception is javax. naming.CommunicationException: <LDAP_VIP>:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors] at org.acegisecurity.providers.ldap.LdapAuthenticationProvider.retrieveUser(LdapAuthenticationProvider.java:238) at org.acegisecurity.providers.dao.AbstractUserDetailsAuthenticationProvider.authenticate(AbstractUserDetailsAuthenticationProvider.java:122) at org.acegisecurity.providers.ProviderManager.doAuthentication(ProviderManager.java:200) at org.acegisecurity.AbstractAuthenticationManager.authenticate(AbstractAuthenticationManager.java:47) at hudson.security.LDAPSecurityRealm$LDAPAuthenticationManager.authenticate(LDAPSecurityRealm.java:786) at hudson.security.LDAPSecurityRealm.authenticate(LDAPSecurityRealm.java:663) at hudson.security.AbstractPasswordBasedSecurityRealm.doAuthenticate(AbstractPasswordBasedSecurityRealm.java:114) at hudson.security.AbstractPasswordBasedSecurityRealm.access$100(AbstractPasswordBasedSecurityRealm.java:39) at hudson.security.AbstractPasswordBasedSecurityRealm$1.authenticate(AbstractPasswordBasedSecurityRealm.java:81) at hudson.cli.CLICommand.main(CLICommand.java:231) at hudson.cli.CliManagerImpl.main(CliManagerImpl.java:92) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:326) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:301) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:260) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:325) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at hudson.cli.CliManagerImpl$1.call(CliManagerImpl.java:63) at hudson.remoting.CallableDecoratorAdapter.call(CallableDecoratorAdapter.java:18) at hudson.remoting.CallableDecoratorList$1.call(CallableDecoratorList.java:21) at jenkins.util.ContextResettingExecutorService$2.call(ContextResettingExecutorService.java:46) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang. Thread .run( Thread .java:745) Caused by: org.acegisecurity.ldap.LdapDataAccessException: Unable to connect to LDAP server; nested exception is javax.naming.CommunicationException: <LDAP_VIP>:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors] at org.acegisecurity.ldap.DefaultInitialDirContextFactory.connect(DefaultInitialDirContextFactory.java:189) at org.acegisecurity.ldap.DefaultInitialDirContextFactory.newInitialDirContext(DefaultInitialDirContextFactory.java:247) at org.acegisecurity.ldap.LdapTemplate.execute(LdapTemplate.java:123) 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) ... 29 more Caused by: javax.naming.CommunicationException: <LDAP_VIP>:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors] at com.sun.jndi.ldap.Connection.<init>(Connection.java:226) at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:136) at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1608) at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2698) at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211) at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154) at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84) at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) at javax.naming.InitialContext.init(InitialContext.java:242) at javax.naming.InitialContext.<init>(InitialContext.java:216) at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:101) at org.acegisecurity.ldap.DefaultInitialDirContextFactory.connect(DefaultInitialDirContextFactory.java:180) ... 36 more Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1904) at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:279) at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:273) at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1446) at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:209) at sun.security.ssl.Handshaker.processLoop(Handshaker.java:901) at sun.security.ssl.Handshaker.process_record(Handshaker.java:837) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1023) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1332) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1359) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1343) at com.sun.jndi.ldap.Connection.createSocket(Connection.java:381) at com.sun.jndi.ldap.Connection.<init>(Connection.java:203) ... 50 more Caused by: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors at sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:350) at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:249) at sun.security.validator.Validator.validate(Validator.java:260) at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:326) at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:231) at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:126) at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1428) ... 59 more Caused by: java.security.cert.CertPathValidatorException: Path does not chain with any of the trust anchors at sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:208) at java.security.cert.CertPathValidator.validate(CertPathValidator.java:279) at sun.security.validator.PKIXValidator.doValidate(PKIXValidator.java:345) ... 65 more

Mark Nejman added a comment - 2015-04-24 16:41 I was reading that the "PKIX path validation failed" error was possibly related to a known bug in Java 7 prior to update 59. I didn't think this was the case since I was using OpenJDK 1.7 update 79. I did try upgrading to OpenJDK 1.8 update 45. However, I experienced the same issue, with the exact same stack trace. So I don't think this issue is Java related.

Mark Nejman added a comment - 2015-04-29 14:07 I believe I have found a resolution to this issue, and it is not Jenkins related. In my Jenkins startup script, I had a snippet that would import the current LDAP certificate into my trust store under a specific alias. However, my LDAP is on a load balancer. Once the load balancer switches me over to another LDAP instance, the certificate no longer matches. If I restarted, it re-imported the new certificate to the trust store under the same alias (overwriting the existing one). This would temporarily resolve the issue until the load balancer switched over again. So what I have done is change my Jenkins startup script to keep track of the certificates that I have imported into the trust store. If a restart encounters a new certificate, I import it under a different alias so that it doesn't overwrite the ones I already have. This took a couple restarts before I was able to get all the certificates (it seems we balance across 3 LDAP instances) but it appears to be working. I have now been up and running for over 24 hours without encountering this connection issue. dicke is the author of this issue, so I don't want to close the ticket without his consent.

Sebastian Bathke added a comment - 2015-05-05 14:30 - edited Just an Update, if there are others out there like us, irresponsibily using virtualBox to host a server application: In our case the cause of the ldap connection issues was VirtualBox. The jenkins server runs within a virtualbox vm (just a temporary situation while waiting for new dedicated host ) using a NAT network adapter. The upgrade to VirtualBox 4.3.24 from 4.3.12 solved the ldap issues entirely, there were much changes related to NAT adapter till 4.3.24 https://www.virtualbox.org/wiki/Changelog So for our case => Jenkins can be considered innocent

Michael Dicke added a comment - 2015-07-29 06:08 In the end the problem was solved by changing the network configuration. Now that Jenkins Server and LDAP server are directly connected via a VPN Tunnel, the problem does not occur any more. So for me the issue is solved. Thanks