sonarqube 5.6 & LDAP 2.0 failing to authenticate

Question

I am testing an upgrade to sonarqube 5.6 and have installed the ldap 2.0 plugin & copied the relevant configuration forward to my test 5.6 setup.

The relevant config is

sonar.security.realm=LDAP
ldap.url=ldaps://xxxx:636
ldap.bindDn=uid=xxxx,ou=xxxx,dc=xxxx,dc=xxxx
ldap.bindPassword=xxxx
ldap.user.baseDn=dc=xxxx,dc=com
ldap.user.request=(&(objectClass=person)(mail={login}))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail

I have the following set in conf/sonar.properties

sonar.log.level=DEBUG

On startup I see

2016.07.26 23:57:29 INFO  web[o.s.p.l.LdapContextFactory] Test LDAP connection on ldaps://xxxx:636: OK
2016.07.26 23:57:29 INFO  web[org.sonar.INFO] Security realm started

If I attempt to login, I get "Authentication failed" on the login screen. The log file says nothing other than

2016.07.26 23:57:47 DEBUG web[http] GET / | time=67ms
2016.07.26 23:57:47 DEBUG web[http] GET / | time=187ms
2016.07.26 23:57:47 DEBUG web[http] GET /sessions/new | time=89ms
2016.07.26 23:57:53 DEBUG web[http] POST /sessions/login | time=71ms

The same configuration works fine with sonarqube 4.5.7 and ldap 1.4

Ideas welcome on how to investigate further.

Answer 1

I fixed it by manually updating the users database table of SonarQube, asumming that all other users are managed by LDAP and just the admin is a local user:

UPDATE sonarqube_production.users SET user_local = 0, external_identity_provider = 'ldap' WHERE id != 'admin';

Answer 2

Little fix to Schakko query above, it should be with login not with id:

UPDATE users SET user_local = 0, external_identity_provider = 'ldap' WHERE login != 'admin';

Answer 3

You're most likely hitting known issue SONAR-7770 - Authentication fails if LDAP configuration has been forgotten during the upgrade . Note that an Upgrade Note was issued for this problem:

Most specifically, don't forget to copy the related SonarQube plugin and its related configuration in "conf/sonar.properties" (including "sonar.security.realm" and "sonar.security.localUsers" if present) into the new SonarQube instance otherwise you will be locked out after migration.

So it's important that this LDAP configuration is there even during the upgrade. If you did miss that then the easiest way forward here is to replay the upgrade with the LDAP-related configuration correctly set.

Context

Keep in mind that during an upgrade SonarQube updates the dataset and also stores new information in database (based on new features). The problem in your case would be that the upgrade was done with a partial config (which didn't set sonar.security.realm and sonar.security.localUsers) , and SonarQube couldn't figure out whether users were local or not, hence treating them as local by default. Local users are not authenticated against external authentication providers but locally, which is indeed what we're seeing in your logs (and it's obviously failing because the password lives in LDAP server, not in SonarQube database).