SonarQube 7.9.1 docker container, strange LDAP issue

cRaZyT · August 22, 2019, 3:32pm

Hi there,

I have a stange problem with the actual sonarqube 7.9.1 docker container (build at 15.08.2019) and the LDAP 2.2 plugin (build 608).

The config looks like:

sonar.security.realm=LDAP
sonar.authenticator.downcase=true
ldap.url=ldap://ipa.usermanagement.t00ls.de:389
ldap.bindDn=id=admin,cn=users,dc=usermanagement,dc=t00ls,cn=accounts,dc=de
ldap.bindPassword=****
…

If I ran the container on Mac everything is OK and SonarQube connects to my LDAP server.
If I ran the same container with the same configuration on Redhat EL7 I get the following Error:

2019.08.22 14:07:15 INFO  web[][org.sonar.INFO] Security realm: LDAP
2019.08.22 14:07:15 INFO  web[][o.s.p.l.LdapSettingsManager] User mapping: LdapUserMapping{baseDn=cn=users,cn=accounts,dc=usermanagement,dc=t00ls,dc=de, request=(&(objectClass=inetorgperson)(uid={0})(|(memberOf=cn=sonarqube-software-users,cn=groups,cn=accounts,dc=usermanagement,dc=t00ls,dc=de)(memberOf=cn=sonarqube-administrators,cn=groups,cn=accounts,dc=usermanagement,dc=t00ls,dc=de))), realNameAttribute=cn, emailAttribute=mail}
2019.08.22 14:07:15 INFO  web[][o.s.p.l.LdapSettingsManager] Group mapping: LdapGroupMapping{baseDn=cn=groups,cn=accounts,dc=usermanagement,dc=t00ls,dc=de, idAttribute=cn, requiredUserAttributes=[dn], request=(&(objectClass=groupOfNames)(member={0}))}
2019.08.22 14:07:15 INFO  web[][o.s.p.l.LdapContextFactory] Test LDAP connection: FAIL
2019.08.22 14:07:15 ERROR web[][o.s.s.p.Platform] Background initialization failed. Stopping SonarQube
org.sonar.api.utils.SonarException: Security realm fails to start: Unable to open LDAP connection
	at org.sonar.server.user.SecurityRealmFactory.start(SecurityRealmFactory.java:93)
	at org.sonar.core.platform.StartableCloseableSafeLifecyleStrategy.start(StartableCloseableSafeLifecyleStrategy.java:40)
	at org.picocontainer.injectors.AbstractInjectionFactory$LifecycleAdapter.start(AbstractInjectionFactory.java:84)
	at org.picocontainer.behaviors.AbstractBehavior.start(AbstractBehavior.java:169)
	at org.picocontainer.behaviors.Stored$RealComponentLifecycle.start(Stored.java:132)
	at org.picocontainer.behaviors.Stored.start(Stored.java:110)
	at org.picocontainer.DefaultPicoContainer.potentiallyStartAdapter(DefaultPicoContainer.java:1016)
	at org.picocontainer.DefaultPicoContainer.startAdapters(DefaultPicoContainer.java:1009)
	at org.picocontainer.DefaultPicoContainer.start(DefaultPicoContainer.java:767)
	at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:135)
	at org.sonar.server.platform.platformlevel.PlatformLevel.start(PlatformLevel.java:90)
	at org.sonar.server.platform.platformlevel.PlatformLevel4.start(PlatformLevel4.java:545)
	at org.sonar.server.platform.Platform.start(Platform.java:211)
	at org.sonar.server.platform.Platform.startLevel34Containers(Platform.java:185)
	at org.sonar.server.platform.Platform.access$500(Platform.java:46)
	at org.sonar.server.platform.Platform$1.lambda$doRun$0(Platform.java:119)
	at org.sonar.server.platform.Platform$AutoStarterRunnable.runIfNotAborted(Platform.java:371)
	at org.sonar.server.platform.Platform$1.doRun(Platform.java:119)
	at org.sonar.server.platform.Platform$AutoStarterRunnable.run(Platform.java:355)
	at java.base/java.lang.Thread.run(Unknown Source)
Caused by: org.sonar.plugins.ldap.LdapException: Unable to open LDAP connection
	at org.sonar.plugins.ldap.LdapContextFactory.testConnection(LdapContextFactory.java:211)
	at org.sonar.plugins.ldap.LdapRealm.init(LdapRealm.java:63)
	at org.sonar.server.user.SecurityRealmFactory.start(SecurityRealmFactory.java:87)
	... 19 common frames omitted
Caused by: javax.naming.CommunicationException: simple bind failed: ipa.usermanagement.t00ls.de:389
	at java.naming/com.sun.jndi.ldap.LdapClient.authenticate(Unknown Source)
	at java.naming/com.sun.jndi.ldap.LdapCtx.connect(Unknown Source)
	at java.naming/com.sun.jndi.ldap.LdapCtx.<init>(Unknown Source)
	at java.naming/com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(Unknown Source)
	at java.naming/com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(Unknown Source)
	at java.naming/com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(Unknown Source)
	at java.naming/com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(Unknown Source)
	at java.naming/javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
	at java.naming/javax.naming.InitialContext.getDefaultInitCtx(Unknown Source)
	at java.naming/javax.naming.InitialContext.init(Unknown Source)
	at java.naming/javax.naming.ldap.InitialLdapContext.<init>(Unknown Source)
	at org.sonar.plugins.ldap.LdapContextFactory.createInitialDirContext(LdapContextFactory.java:134)
	at org.sonar.plugins.ldap.LdapContextFactory.createBindContext(LdapContextFactory.java:96)
	at org.sonar.plugins.ldap.LdapContextFactory.testConnection(LdapContextFactory.java:207)
	... 21 common frames omitted
Caused by: java.net.SocketException: Connection or outbound has closed
	at java.base/sun.security.ssl.SSLSocketImpl$AppOutputStream.write(Unknown Source)
	at java.base/java.io.BufferedOutputStream.flushBuffer(Unknown Source)
	at java.base/java.io.BufferedOutputStream.flush(Unknown Source)
	at java.naming/com.sun.jndi.ldap.Connection.writeRequest(Unknown Source)
	at java.naming/com.sun.jndi.ldap.Connection.writeRequest(Unknown Source)
	at java.naming/com.sun.jndi.ldap.LdapClient.ldapBind(Unknown Source)
	... 35 common frames omitted
2019.08.22 14:07:16 INFO  web[][o.s.p.ProcessEntryPoint] Hard stopping process
2019.08.22 14:07:17 WARN  web[][o.s.p.ProcessEntryPoint$HardStopperThread] Can not stop in 1000ms
2019.08.22 14:07:17 WARN  web[][o.s.s.a.EmbeddedTomcat] Failed to stop web server
org.apache.catalina.LifecycleException: Failed to stop component [StandardServer[-1]]
	at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:238)
	at org.apache.catalina.startup.Tomcat.stop(Tomcat.java:437)
	at org.sonar.server.app.EmbeddedTomcat.terminate(EmbeddedTomcat.java:104)
	at org.sonar.server.app.WebServer.hardStop(WebServer.java:83)
	at org.sonar.process.ProcessEntryPoint$HardStopperThread.lambda$new$0(ProcessEntryPoint.java:219)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
	at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)
Caused by: org.apache.catalina.LifecycleException: Failed to stop component [StandardService[Tomcat]]
	at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:238)
	at org.apache.catalina.core.StandardServer.stopInternal(StandardServer.java:814)
	at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:226)
	... 9 common frames omitted
Caused by: org.apache.catalina.LifecycleException: Failed to stop component [StandardEngine[Tomcat]]
	at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:238)
	at org.apache.catalina.core.StandardService.stopInternal(StandardService.java:486)
	at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:226)
	... 11 common frames omitted
Caused by: org.apache.catalina.LifecycleException: A child container failed during stop
	at org.apache.catalina.core.ContainerBase.stopInternal(ContainerBase.java:1008)
	at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:226)
	... 13 common frames omitted
2019.08.22 14:07:17 INFO  app[][o.s.a.SchedulerImpl] Process[web] is stopped

To check the LDAP connection, I’ve installed “ldapsearch” in the container and checked the connection:

sonarqube@ef9533682b9d:/opt/sonarqube$ ldapsearch -h ipa.usermanagement.t00ls.de:389 -b “dc=usermanagement,dc=t00ls,cn=accounts,dc=de” -x
# extended LDIF
#
# LDAPv3
# base <dc=usermanagement,dc=t00ls,cn=accounts,dc=de> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 32 No such object

# numResponses: 1

If there would be a connection problem with the command line the output normally looks like:

ldap_sasl_bind(SIMPLE): Can’t contact LDAP server (-1)

The same error occures with:

ldap.url=ldaps://ipa.usermanagement.t00ls.de:389

I have an other container running on Redhat EL7 which connects to my LDAP without any problems.

Has someone an idea how to solve this problem?

Thanks in advanced for any support

Regards
Thorsten

Wouter_Admiraal · August 23, 2019, 9:49am

Hi @cRaZyT,

Thanks for the detailed report.

I see the following error in your stacktrace:

at java.base/sun.security.ssl.SSLSocketImpl$AppOutputStream.write(Unknown Source)

Which looks like an issue with SSL. I see you’re not running with LDAPS, nor using the LDAPS “usual” port (636), but, I know it is possible to run LDAP on the “regular” port, and still have an SSL handshake take place. Is this the case? If so, can you double check your JDK keystore inside the container (see keytool)?

cRaZyT · August 23, 2019, 10:59am

Hi @Wouter_Admiraal,

I tried using LDAPS which lasts in the same error. Regarding the Port, yes we use the regular port.
Inside the offical sonarqube docker container, the keytool is available but no key is stored over there, which is also the case in the functioning container hosted on Mac OS.

Wouter_Admiraal · August 23, 2019, 11:49am

Hi, thanks for the info.

My question was more about how you configured LDAP:

I know it is possible to run LDAP on the “regular” port, and still have an SSL handshake take place. Is this the case?

Sorry if I wasn’t clear: are you “requiring” a SSL/TLS handshake, despite the fact you’re not running on LDAPS/port 636? Are we certain that LDAP is not requesting a SSL handshake (would be weird, but I’m just shooting in the dark here)?

Because it works locally, and you can access from the container using the CLI, only 2 things come to mind:

Your bind credentials are incorrect
IF your LDAP needs a SSL handshake (for whatever strange reason), there could be an issue with the certificates, as your Bash will not necessarily use the same certificates as the JDK.

It’s weird that SonarQube tries to use SSL, but because it works locally, with the exact same setup, I’m leaning towards an issue in the environment rather than with SonarQube itself (for now).

cRaZyT · August 23, 2019, 1:12pm

Hi @Wouter_Admiraal,

sorry for my missunderstanding.

The bind credentials are configured in the sonar.properties file which is identical on both docker instances.
No the LDAP server don’t need an SSL handshake.

It’s really weired because there are other docker containers hosted on the RedHat server which are connecting without any issue to the LDAP server.

cRaZyT · August 26, 2019, 1:10pm

Hi @Wouter_Admiraal,

I found asolution. I could fix this problem by changing the “ldap.bindDn”.
I’ve changed the string from “ldap.bindDn=id=admin” to “ldap.bindDn=uid=admin”.
I don’t understand why there could be a difference between MAC and RedHat but that solved the problem.

Regards
Thorsten

Wouter_Admiraal · August 29, 2019, 6:31am

Hi @cRaZyT,

Great! Happy to see you found a solution. I admit I was a bit stumped by your problem . I started asking around, but to no avail.

Thank you for sharing it here !