Sorry for the long post but think it’s necessary to see the whole picture.
We have had Jenkins here since the Hudson days. I’ve migrated to new servers a few times through the years so I’m familiar with the install process. With Java 17 going out of support, I’ve been working on updating to Java 21. Currently we have a PRD and TST server running on RedHat with CA signed certs, etc. To remove any issues do to complexities I stood up a new bare bones server(s) to work on this specific issue. I see this issue on RedHat and Windows so for simplicity, I’ll explain it on my bare bones Windows instance… I think if I can get LDAP into Active Directory(AD) working there, I can apply the fix to our PRD server or at least know how to stand up a new server to migrate to.
bare bones basic install in a nutshell
- I have a new barebones Windows 2019 server.
- I download/install our company supported OpenJDK : Azul Zulu – Java 17(LTS)
- I install Java to “C:\JAVA” and set environment variable JAVA_HOME to “C:\JAVA” and add that to the system ‘path’.
- I import our ‘root’ and ‘intermediate’ certs into “C:\JAVA\lib\security\cacerts” [note: this for later talking point]
- I then install Jenkins (LTS) off the site and follow ‘vanilla’ install picking defaults and setting up a local ‘admin’ account.
- I’ve added / removed the “KEYSTORE” pathing into the Jenkins config file pointing to the Java’s cacert location… doesn’t seem to impact the outcome.
setting up LDAP (to AD) on Java 17
- I login with local ‘admin’ to Jenkins > Manage > Security > Security Realm > LDAP
I configure the following: - Server = ldaps://ldaps.company.corp.com:636 [note: if I don’t add the root/intermediate certs in ‘cacerts’ I have an SSL issue here; so I know Jenkins is using this for certs.]
- root DN = DC=company,DC=corp,DC=com
- User search filter = sAMAccountName={0}
- Group search filter = (& (cn={0}) (objectclass=group) )
- Manager DN = BINDSERVICEACCOUNT
- Manager Password = PASSWORD
I then click on the “Test LDAP Settings” button and provide a user ID/Password and it replies with all green check marks and shows that user’s AD groups.
Java 17 works
switching to Java 21
- I stop the Jenkins service.
- I remove / rename “C:\JAVA”.
- I download OpenJDK : Azul Zulu – Java 21(LTS) and place it in “C:\JAVA”.
- I can open a CMD prompt and ‘java -version’ returns “21…”; Jenkins info shows 21 too.
- I tried several cert scenarios with same results:
-Import the ‘root’ and ‘intermediate’ into the Java 21’s supplied cacerts.
-I copied Java 17’s cacerts over top of Java 21’s.
-I even copied the directory structure “C:\JAVA-17\lib\security” -and- “C:\JAVA-17\conf\security” over to Java 21’s; thinking there was a cert setting / cipher it didn’t like.
I then launched Jenkins and follow the steps above to setup LDAP.
When I click “Test LDAP Settings” button with same credentials, I get the error(s) :
Login
Authentication: failed for user “user”
Lookup
User lookup: user “user” may or may not exist.
Does the Manager DN have permissions to perform user lookup?
LDAP Group lookup: could not verify.
Please try with a user that is a member of at least one LDAP group.
Lockout
The user “user” will be unable to login with the supplied password.
If this is your own account this would mean you would be locked out!
Are you sure you want to save this configuration?
I know that BINDSERVICEACCOUNT works; it works in Java17 -and- I tried a different account I use in a totally different application that can bind / retrieve AD info.
I setup logging “LDAP_Troubleshooting” for ‘org.springframework.security.ldap’ and ‘org.springframework.ldap’. looking in the logs…
- [date/time] FINE org.springframework.security.ldap.SpringSecurityLdapTemplate searchForSingleEntryInternal
- Found DN: CN=John Doe,OU=Information Systems,OU=Accounts
- [date/time] (Java17 FINE, Java21 FINEST) org.springframework.security.ldap.search.FilterBasedLdapUserSearch searchForUser
Java17 returns all the group info, etc.
Java21 doesn’t / blank.
Thoughts
Is there a difference between Java 17 and 21 regarding LDAP (AD) and is there a setting in Java/Jenkins to revert/by-pass that?
I tried using the Jenkins ActiveDirectory plugin with no success both Java17 and 21. To my knowledge the company has always used LDAP (into AD) for Jenkins authentication / authorization.
We use Azul Zulu – Java (per company policy) but I could go outside that if Jenkins recommends using a different OpenJDK ‘brand’. Is there a ‘supported’ brand of Java for Jenkins?
I really think this is Java using LDAP into AD issue than SSL / cert related but looking for any guidance.