Login failure email 'xxx' is already used (7.9.6->8.9 upgrade)

SonarQube
, ,
1

hi,

i updated sonarqube 7.9.6 to 8.9. the process went smoothly except existing users in sonarqube database (ldap-bound) cannot login with the following error in logs: login failure ‘xxx’ is already used

new users can (and logs indicated ldap connection is ok). previously logged in users cannot since their ldap-linked accounts are already in the sonarqube database.

any advice would be greatly apprecaited.

thank you.
artur314

2

can anyone help please?

3

Hello Arthur,

SonarQube is able to connect to different services to delegate authentication. Therefore, when you start using one for a given account, this is not possible to use another one.

Are you using another tool in addition to LDAP to delegate your SonarQube authentication? It looks like you have used a different system to authenticate your user. This means that the account exists but cannot use LDAP for authentication.

We introduced in 8.7 a new web API to migrate an account from one authentication system to another.

If you need to use LDAP for the authentication of this account, I invite you to read the paragraph “Migrate users to a new authentication method” of this documentation page.

Best,
JD.

4

hi jd,

my configuraton used LDAP and it worked great. as soon as i upgraded from 7.9.6 to 8.9, the LDAP authentication no longer works, giving the error mentioned in the subject of this thread. yet, the logs indicate LDAP connectivity as ok. so there wasn’t a change in authentication type, just an upgrade of sonarqube.

using the local admin credentials works. what also works is new users with LDAP. just existing LDAP users get the error.

please, advise.

thank you.

5

Hi Artur,

I do not question your LDAP configuration. I just mentioned that you cannot use multiple authentication providers for the same account.

FYI SonarQube 7.9 was not doing this validation. Now we are validating the authentication provider, you may have a different behavior between 7.9 and 8.9 using the same LDAP configuration.

To check the authentication provider SonarQube expects for a given user, you should query the webAPI “api/users/search”.

  • If for your user “externalProvider” is set to “sonarqube” it means that you should be able to use LDAP for the authentication.

  • If “externalProvider” is set to “saml”, “github” or “gitLab”, it means that you cannot use LDAP for the authentication of this user without migrating the account on “sonarqube” provider.

If you do not manage to sort this out, thanks for:

  • providing me the result of “api/users/search” on a user you reproduce the authentication issue with
  • restarting SonarQube with debug logs activated for the web-server
  • try to authenticate with the same user than above using LDAP
  • provide the web.log logs in debug that shows your authentication attempt (make sure you removed data you should not disclose publicly)

JD.

6

hi Jean-Denis,

the “externalProvider” is set to saml on both the upgraded server and on the server that is still v7.9.x for the same user. prior to the upgrade and on the 7.9.x instance, if saml is turned off, it reverts to straight AD authentication. both methods work seamlessly.

your second point is that it requires to be migrated. what should it be migrated to and why? it’s a saml id and was never local.

thank you.

artur

10

Hello artur,

prior to the upgrade and on the 7.9.x instance, if saml is turned off, it reverts to straight AD authentication. both methods work seamlessly.

You are right and this behavior is different since version 8.1. SonarQube is now checking which authentication provider. If the authentication provider is not the one that is configured for a given account, the authentication fails.

what should it be migrated to

As mentioned in my first comment, you should use the Web API to change the authentication provider the user can use. The procedure is described in the paragraph “ Migrate users to a new authentication method ” of this documentation page.

and why?

In terms of authentication, we should make sure there is a single source of truth. When different authentication methods are configured, the admin has to choose which one to use.