SonarQube does not start after configuring LDAP

I am using sonarqube version (from docker image
I am trying to get users and groups from LDAP but none of the combinations I tried give me a working result:

  1. If I configure LDAP to like this:

I get an instance of SQ that is stuck with “SonarQube is starting” and never proceeds.
My log (with level DEBUG) ends with

2020.08.10 15:15:56 INFO  web[][o.s.a.l.LdapSettingsManager] User mapping: LdapUserMapping{baseDn="cn=users,cn=accounts,dc=intgdc,dc=com", request=(&(objectClass=inetOrgPerson)(uid={0})), realNameAttribute=cn, emailAttribute=mail}
2020.08.10 15:15:56 INFO  web[][o.s.a.l.LdapSettingsManager] Groups will not be synchronized, because property '' is empty.

I tried to debug network with tcpdump but I can only confirm that communication happens (2 packates in one direction, 2 back) but stops pretty early and nothing is happening.

Full DEBUG log:

  1. I also tried this combination (+also imported certificate of the freeipa server and root certificate of the corresponding CA):

In this case I am getting
Caused by: javax.naming.AuthenticationException: [LDAP: error code 49 - Invalid Credentials]

but my ldap.bindPassword in is exactly the same I use with CLI ldapsearch and it works fine from the CLI.

Full DEBUG log:

Any idea what I am doing wrong here? The case (1) looks promising but I don’t know how to debug it further.


Welcome to the community!

Debug-level actually makes this rather difficult to look at. Any time you’re dealing with a startup failure, you should get everything you need at the ERROR level (i.e. by default).

When I plopped your log into a text editor and stripped out all the debug lines, I was able to see that the connection to port 9001 is being refused. That’s significant because it’s the port that SonarQube runs ElasticSearch on by default. My guess is that
a) you’ll find more detail in some of the other server logs
b) you started up SonarQube, configured LDAP and then tried to restart but not all of the processes from the first run shut down & so now your second run is blocked trying to get the ES port.


Hi Ann,
thank you for your reply. The problem with port 9001 is indeed from my various tests where I didn’t shut down the container properly. If I do the same again from scratch (+switch off the DEBUG output) I still get the same result:

  • stuck start with

  • invalid credentials

(btw. I use ldap.authentication=simple and ldap.bindPassword is the same as the password I succesfully use with CLI ldapsearch)


With the help of LDAP logs I was able to find out that the bindDn option was wrong. It was passed on quite literally. So it included double quotes “” I had put around the dn=… string.

After removing those I was able to use ldap(389)+startTLS and also ldaps(636)+no startTLS

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.