# SonarQube 7.9.1 docker container, strange LDAP issue **URL:** \ **Category:** SonarQube Server / Community Build\ **Created:** [August 22, 2019, 3:32pm UTC](https://community.sonarsource.com/t/sonarqube-7-9-1-docker-container-strange-ldap-issue/13460 "2019-08-22T15:32:41Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![cRaZyT](https://avatars.discourse-cdn.com/v4/letter/c/c77e96/32.png) [@cRaZyT](https://community.sonarsource.com/u/cRaZyT)\ **Post date:** [August 22, 2019, 3:32pm UTC](https://community.sonarsource.com/t/sonarqube-7-9-1-docker-container-strange-ldap-issue/13460/1 "2019-08-22T15:32:41Z")
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: ```auto 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.(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.(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](http://ipa.usermanagement.t00ls.de:389) -b “dc=usermanagement,dc=t00ls,cn=accounts,dc=de” -x > # extended LDIF > # > # LDAPv3 > # base \ 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 ---
**Author:** ![Wouter\_Admiraal](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/wouter_admiraal/32/1841_2.png) [@Wouter\_Admiraal](https://community.sonarsource.com/u/Wouter_Admiraal)\ **Post date:** [August 23, 2019, 9:49am UTC](https://community.sonarsource.com/t/sonarqube-7-9-1-docker-container-strange-ldap-issue/13460/3 "2019-08-23T09:49:36Z")
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`](https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html))? ---
**Author:** ![cRaZyT](https://avatars.discourse-cdn.com/v4/letter/c/c77e96/32.png) [@cRaZyT](https://community.sonarsource.com/u/cRaZyT)\ **Post date:** [August 23, 2019, 10:59am UTC](https://community.sonarsource.com/t/sonarqube-7-9-1-docker-container-strange-ldap-issue/13460/4 "2019-08-23T10:59:09Z")
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. ---
**Author:** ![Wouter\_Admiraal](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/wouter_admiraal/32/1841_2.png) [@Wouter\_Admiraal](https://community.sonarsource.com/u/Wouter_Admiraal)\ **Post date:** [August 23, 2019, 11:49am UTC](https://community.sonarsource.com/t/sonarqube-7-9-1-docker-container-strange-ldap-issue/13460/5 "2019-08-23T11:49:59Z")
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: 1. Your bind credentials are incorrect 2. _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). ---
**Author:** ![cRaZyT](https://avatars.discourse-cdn.com/v4/letter/c/c77e96/32.png) [@cRaZyT](https://community.sonarsource.com/u/cRaZyT)\ **Post date:** [August 23, 2019, 1:12pm UTC](https://community.sonarsource.com/t/sonarqube-7-9-1-docker-container-strange-ldap-issue/13460/6 "2019-08-23T13:12:32Z")
Hi @Wouter_Admiraal, sorry for my missunderstanding. 1. The bind credentials are configured in the sonar.properties file which is identical on both docker instances. 2. 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. ---
**Author:** ![cRaZyT](https://avatars.discourse-cdn.com/v4/letter/c/c77e96/32.png) [@cRaZyT](https://community.sonarsource.com/u/cRaZyT)\ **Post date:** [August 26, 2019, 1:10pm UTC](https://community.sonarsource.com/t/sonarqube-7-9-1-docker-container-strange-ldap-issue/13460/7 "2019-08-26T13:10:55Z")
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 ---
**Author:** ![Wouter\_Admiraal](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/wouter_admiraal/32/1841_2.png) [@Wouter\_Admiraal](https://community.sonarsource.com/u/Wouter_Admiraal)\ **Post date:** [August 29, 2019, 6:31am UTC](https://community.sonarsource.com/t/sonarqube-7-9-1-docker-container-strange-ldap-issue/13460/8 "2019-08-29T06:31:17Z")
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 👍!