SonarQube does not start after configuring LDAP

Hi,
I am using sonarqube version 8.4.1.35646 (from docker image docker.io/library/sonarqube).
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:

sonar.security.realm=LDAP
ldap.url=ldap://:636
ldap.StartTLS=true

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 'ldap.group.baseDn' 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):

sonar.security.realm=LDAP
ldap.url=ldaps://:636
ldap.StartTLS=false

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

but my ldap.bindPassword in sonar.properties 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.

Hi,

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
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.

 
HTH,
Ann

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
    ldap.StartTLS=true
    ldap.url=ldap://na1-freeipa01.intgdc.com:636

  • invalid credentials
    ldap.StartTLS=false
    ldap.url=ldaps://na1-freeipa01.intgdc.com:636

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

logs: https://gist.github.com/tomaso/1264f9fe5761e1e4c720e141cd092758

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.