LDAP: exactly one account cannot login

Troubles w/ exactly one account for login into SonarQube (SQ)

  • version: SonarQube,10.2.0.77647

  • deployed as/to: docker

  • goal: allow ALL users to log in, authenticated by LDAP; it does work for all accounts, except exactly one (my pers. account, used before switching to LDAP as a locally created account on SonarQube).

  • My pers. account is active and can be used for other LDAP-based resources of my organization.

  • tried so far: I looked at the Postgres DB, table users, and sometimes I see an account with my username and a numeric suffix (as it should be, compared w/ other LDAP user accounts) but w/ the state disabled.

It looks to me as if my (local) account is still registered somehow/somewhere in the depths of SonarQube or its database. The message on the login screen Authentication failed.

Hi,

Welcome to the community!

We generally tell people to treat the DB as a black box, but leaving that aside…

Did you try to delete your native account? Accounts are never actually deleted (referential integrity…); they’re just set - as you’ve discovered - to disabled. Probably you need to re-add your username through the UI. My foggy memories of long-ago experimentation tell me that will reactivate the account. Then if it doesn’t just work, you should be able to migrate it.

 
HTH,
Ann

Hi

Merci for your welcome message!

And thank you for your feedback.

My local account does not exist (anymore). I will add a local account w/ the same login name,
and see what happens. The migration guide assumes that the (local) account exists which is to be migrated.

Is there a way to see logs of the login procedure/mechanism? In the sonar.properties I set wrapper.console.loglevel=DEBUG;
is there more one can do to see logs (what is going on)? And where?

As soon as I have results, I will update my post.

Best wishes,
Peter

I added my user manually, and then did the migration as given by the migration guide. Still unable to login: no authentication possible. User shows up as being managed by LDAP (just like the other users with working accounts). My other LDAP user (unrelated to the non-working one) works as intended…

What I observe in the DB table users is the hash_method. For local accounts this is (still) set to PBKDF2.

Hi,

You mean via direct DB manipulation, you inserted a user record? If so, please delete it, and try - via the UI - re-adding the same user name.

If my understanding is wrong, then please turn on debug server logging (briefly! it gets big, fast), and post the web.log lines you get when you try to log in.

 
Thx,
Ann

I added my user (same name) via the UI (in contrast to LDAP users which get added by the LDAP provider automagically). Let’s see whether I find the switch to enable server debug logging. …

1 Like

[BUG] Problem solved: I added my personal e-mail address to the default local SQ admin account (instead of the default example.org e-mail address); if this now new e-mail address appears also in an LDAP query (for loading the details of the new (?) LDAP user) then [auth.event] login failure [cause|Email 'user@my-domain.org' is already used... . This should be handled by the auth. providers as a (new) use case to be allowed.

Thank you “AT ganncamp” for pointing me in the right direction (to study the DEBUG level web log).

1 Like

Hi,
I upgraded sonarqube from 9.9.2–>10.2.0
I updated sonar.properties. I checked Ldap configuration. But I can’t login with Ldap. I get authentication failed error.

Hi @Pinar,

I know this thread seems related to your problem, but your problem deserves is own thread. However, before you create one, I urge you to troubleshoot your LDAP problem with a dedicated LDAP client. We aren’t LDAP experts and won’t be able to help you tune your LDAP settings.

 
Ann

Speaking of my particular (LDAP) issue: is there a way to report or handle that bug?

Hi @bsdooby,

What do you consider the bug to be? That you can’t have the same email address associated with two different accounts? That’s by design.

 
Ann

Yes. However, I do not quite get that design decision. But so be it…