Troubles w/ exactly one account for login into SonarQube (SQ)
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.
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.
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.
[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 'firstname.lastname@example.org' is already used... . This should be handled by the auth. providers as a (new) use case to be allowed.
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.