[JENKINS-75882] JDK LDAP environment settings don't work any more

[jenkins-infra-bot]

I migrated my jenkins from an old server with JDK 1.8 and jenkins 2.236 to a new server with JDK 17 and 2.504.3. Now I got LDAP login issue. If no one tries to login to jenkins, after a while, the login try will report login error. I checked log, the log shows LDAP read timeout:

"javax.naming.NamingException: LDAP response read timed out, timeout used: 60000 ms.; remaining name 'ou=employee'".  I have 2 ways to recover the login:

1. Restart jenkins
2. Just try a few times the failed login

I reminder this phenominon and I handled before. It was caused by the LDAP pool. Disabling the LDAP pool resolved this issue on my old jenkins server. I checked the setting in LDAP/Server/Advanced Server Configuration/Environment Properties, it was migrated correctly and still there. In config.xml too:

   
         
            com.sun.jndi.ldap.connect.pool
            false
         

 

I don't know why it doesn't work any more. So I tried to set the time out settings: com.sun.jndi.ldap.connect.timeout and com.sun.jndi.ldap.read.timeout to 10 seconds from default 60 seconds. But when the login problem occurs, the log message still shows the time out is 60 seconds. So I believe the LDAP environment settings now don't take effective any more. Is there somthing changed this behavior with Jenkins or the LDAP plugin or JDK?

---

Originally reported by ruralhunter, imported from: JDK LDAP environment settings don't work any more

• status: Open
• priority: Minor
• component(s): ldap-plugin
• resolution: Unresolved
• votes: 0
• watchers: 2
• imported: 2025-12-09

Raw content of original issue

I migrated my jenkins from an old server with JDK 1.8 and jenkins 2.236 to a new server with JDK 17 and 2.504.3. Now I got LDAP login issue. If no one tries to login to jenkins, after a while, the login try will report login error. I checked log, the log shows LDAP read timeout:

"javax.naming.NamingException: LDAP response read timed out, timeout used: 60000 ms.; remaining name 'ou=employee'".  I have 2 ways to recover the login:

	
Restart jenkins
	
Just try a few times the failed login



I reminder this phenominon and I handled before. It was caused by the LDAP pool. Disabling the LDAP pool resolved this issue on my old jenkins server. I checked the setting in LDAP/Server/Advanced Server Configuration/Environment Properties, it was migrated correctly and still there. In config.xml too:

<jenkins.security.plugins.ldap.LDAPConfiguration>

    <extraEnvVars class="linked-hash-map">
          <entry>
            <string>com.sun.jndi.ldap.connect.pool</string>
            <string>false</string>
          </entry>

  </extraEnvVars>
</jenkins.security.plugins.ldap.LDAPConfiguration>

I don't know why it doesn't work any more. So I tried to set the time out settings: com.sun.jndi.ldap.connect.timeout and com.sun.jndi.ldap.read.timeout to 10 seconds from default 60 seconds. But when the login problem occurs, the log message still shows the time out is 60 seconds. So I believe the LDAP environment settings now don't take effective any more. Is there somthing changed this behavior with Jenkins or the LDAP plugin or JDK?

[jenkins-infra-bot]

markewaite:

• Original comment link
• Raw content of original comment:

  This seems like you're asking for help to diagnose an issue rather than reporting a bug.  We use https://community.jenkins.io for help.  More people read that location and you're more likely to find others with a similar issue.
  
  If that doesn't provide enough help and you think that this is a bug, then please provide enough details so that others can duplicate the issue.  "How to report an issue" includes a checklist of the type of information that is needed.
  

This seems like you're asking for help to diagnose an issue rather than reporting a bug.  We use https://community.jenkins.io for help. More people read that location and you're more likely to find others with a similar issue.

If that doesn't provide enough help and you think that this is a bug, then please provide enough details so that others can duplicate the issue. "How to report an issue" includes a checklist of the type of information that is needed.

[jenkins-infra-bot]

ruralhunter:

• Original comment link
• Raw content of original comment:

  No, I don't think so. I think the bug is clearly stated in the subject: the ldap environment variables do not work. I also provided the reproduce step:
  
  	
  Change the ldap timeout environment variables
  	
  Login with ldap account and wait for the timeout
  	
  Check the error log and you will find the timeout is still at default value. the change didn't work.
  
  
  

No, I don't think so. I think the bug is clearly stated in the subject: the ldap environment variables do not work. I also provided the reproduce step:

1. Change the ldap timeout environment variables
2. Login with ldap account and wait for the timeout
3. Check the error log and you will find the timeout is still at default value. the change didn't work.

[jenkins-infra-bot]

ruralhunter:

• Original comment link
• Raw content of original comment:

  I just checked the source code of the plugin. Here the pool option seems always set to true.  The 2 timeout environment variable names sees also not correct. Is this the cause of the probelm?
  

I just checked the source code of the plugin. Here the pool option seems always set to true.  The 2 timeout environment variable names sees also not correct. Is this the cause of the probelm?

[jenkins-infra-bot]

markewaite:

• Original comment link
• Raw content of original comment:

  Thanks for the detailed analysis.  Would you be willing to submit a pull request proposing the change, preferably with tests that show the problem and show how your change fixes the problem?
  

Thanks for the detailed analysis. Would you be willing to submit a pull request proposing the change, preferably with tests that show the problem and show how your change fixes the problem?

[jenkins-infra-bot]

ruralhunter:

• Original comment link
• Raw content of original comment:

  Sorry I don't think my knowledge is enough to implement the change. I think it's better to have the owner of this pull request to check if my analysis is correct or not: simplify connectivity check #102
  

Sorry I don't think my knowledge is enough to implement the change. I think it's better to have the owner of this pull request to check if my analysis is correct or not: #102

[jenkins-infra-bot]

ruralhunter:

• Original comment link
• Raw content of original comment:

  OK, I added some debug log in the code above. Some of my previous statement was wrong. The default value of environment variables was overridden by the settings in jenkins UI. My ldap read timeout setting didn't work was caused by an invisible space before my environment name. It should be "com.sun.jndi.ldap.read.timeout" while my setting was " com.sun.jndi.ldap.read.timeout". I didn't find it until I logged all the environment variables and found duplicate variables. 
  
  However, the problem still exists after I fixed the environment variable name. Now I suspect it is caused by the default setting of pooling of DefaultSpringSecurityContextSource. It is set to true by default. I logged "contextSouce.isPooled()" and indeed it is true. Setting ldap environment variables doesn't change that value. I will ask the author of the PR.
  

OK, I added some debug log in the code above. Some of my previous statement was wrong. The default value of environment variables was overridden by the settings in jenkins UI. My ldap read timeout setting didn't work was caused by an invisible space before my environment name. It should be "com.sun.jndi.ldap.read.timeout" while my setting was " com.sun.jndi.ldap.read.timeout". I didn't find it until I logged all the environment variables and found duplicate variables. 

However, the problem still exists after I fixed the environment variable name. Now I suspect it is caused by the default setting of pooling of DefaultSpringSecurityContextSource. It is set to true by default. I logged "contextSouce.isPooled()" and indeed it is true. Setting ldap environment variables doesn't change that value. I will ask the author of the PR.