4

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.

G. Ann - SonarSource Team
  • 22,346
  • 4
  • 40
  • 76
Matt
  • 8,367
  • 4
  • 31
  • 61

3 Answers3

6

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

Community
  • 1
  • 1
Nicolas B.
  • 7,245
  • 17
  • 29
  • It hadn't occurred to me that this also applied to a fresh installation i.e. that 5.6 only allows you to use LDAP from the very 1st time you run it, you can not add it later – Matt Jul 27 '16 at 10:37
  • @Matt I didn't quite say so. LDAP Plugin must be there from the very first time if you use an existing database (already used with prior version). Otherwise you can install the LDAP Plugin any time you want, but users created before that will be authenticated locally in such case. – Nicolas B. Jul 27 '16 at 11:34
  • Right I see. This switch from how local users are declared seems a bit flaky though. I have found that users that were previously created locally are assumed to be LDAP users on upgrade hence they have to be recreated post upgrade. Fortunately I only have a few such users. – Matt Jul 28 '16 at 11:35
  • 1
    If you want some users to be stored as local during the upgrade then make sure their userId is set in `sonar.security.localUsers` during the upgrade. All this stuff is getting improved in 6.x series, with the notion of 'authentication provider' which should be transparent from the Users admin page. – Nicolas B. Jul 28 '16 at 12:50
  • I copied LDAP config to 5.6.6, installed LDAP plugin, and still ran into this issue. I think my error was that our old instance (5.1.2) was using 1.4 of the plugin, and I copied 2.1 of the plugin into the new installation prior to starting the server? Otherwise, not sure what I did wrong. – user944849 Mar 31 '17 at 20:24
3

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';
Schakko
  • 154
  • 5
  • damn, was using plsql developer and cursing for not working. finally switched to sqlplus and issued commit statement. dumb me – Shiva Mar 13 '18 at 15:40
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';
Viacheslav
  • 1,325
  • 9
  • 12