Users Unable to Authenticate with LDAP

Hello,

We recently had our underlying LDAP service changed from Sun Microsystems to Ping authentication, this did not seem to cause any visible issues at the time of the upgrade, but now some users who have changed their passwords cannot seem to login to our Sonarqube instance, when they try they receive this error:

2020.11.30 15:09:58 DEBUG web[AXYZ3UdoW2PiQKDvAOvd][auth.event] login failure [cause|Email 'NARENDRA.MANNA@LibertyMutual.com' is already used][method|FORM][provider|REALM|LDAP][IP|10.225.33.123|10.235.80.225, 10.235.80.225][login|N0204293]

Additionally I see the Users who are trying to login already exist in Sonar and they report they have had access prior to this change. Based on the below article it seems that during authentication users cannot use an email in use by another user.

I think what is happening is that now that the underlying LDAP has changed and the user’s changed their password, Sonarqube thinks that they are a difference user and denies them due to conflicting email addresses. Does anyone know a way this can be remedied, preferably without an outage? Alternatively does anyone have a query or action that will let me remove and re-sync the users in our Sonarqube instance?

Sonarqube version 8.4.1.

Thanks,
Brandon

Edit: It looks like we do not see this issue for new users, only for users that logged in prior to this LDAP change. Additionally I cannot deactivate users using the UI that are having this authentication issue.

Hello @malceore

The issue you observe is indeed caused by an email conflict. As you changed the LDAP server and you observe the problem only for existing users the most likely cause is that the user logins coming form old and new LDAP do not match. This might be due to change in LDAP configuration on the SonarQube side (e.g. different LDAP user request ldap.user.request or different value for sonar.authenticator.downcase parameter etc.). If that is the case you may either adjust the configuration or update the logins of the existing users to match the new logins. This can be done with api/users/update_login Web API. Once the new login matches the old one SonarQube will be able to log in the user correctly.

You can see the value of the new login in the web.log as in the sample you provided. To determine which existing SonarQube login is associated with the conflicting email address you may run:

api/users/search?q=<conflicting_email>

Best,
Michal

P.S> External users can be deactivated using api/users/deactivate Web API.

Hey Michal, thanks for the reply. I am unable to deactivate these users using the API or the UI, the user still exist and is active afterwards. I also cannot update these users in the UI as the underlying LDAP directory is Read-Only, API doesn’t seem to allow me to either. Is there any other way to purge users? It seems like the behavior is that it will not add the users from LDAP if they have an email matching an existing user.

Hello Brandon

That is unusual. api/users/deactivate and api/users/update_login should give you a detailed message if they fail to deactivate or update the login. If they run successfully the output will tell you the operation succeeded and api/users/search can further help to verify that.

Here is an example:

1< Let’s say we have user LDAP bob who cannot log in because of the email conflict:

2020.12.04 18:52:16 DEBUG web[AXYuzgv8YuAJPV9kAAEE][auth.event] login failure [cause|Email 'robert@company.com' is already used][method|FORM][provider|REALM|LDAP][IP|0:0:0:0:0:0:0:1|][login|bob]

2< We may check which existing account uses the email address with api/users/search:

c:\>curl -w "HTTP CODE: %{http_code}" "http://localhost:9000/api/users/search?q=robert@company.com"
{"paging":{"pageIndex":1,"pageSize":50,"total":1},"users":[{"login":"robert","name":"robert"}]}HTTP CODE: 200

We can see that this is user robert.

3< Once we confirm that it is the same LDAP user whose login changed from robert to bob we may run api/users/update_login to updated the login:

c:\>curl -X POST -u <user>:<pass> -w "HTTP CODE: %{http_code}" "http://localhost:9000/api/users/update_login?login=robert&newLogin=bob"
HTTP CODE: 204

c:\>curl -w "HTTP CODE: %{http_code}" "http://localhost:9000/api/users/search?q=robert@company.com"
{"paging":{"pageIndex":1,"pageSize":50,"total":1},"users":[{"login":"bob","name":"robert"}]}HTTP CODE: 200

which will allow bob to login:

2020.12.04 18:56:25 DEBUG web[AXYuzgv8YuAJPV9kAAEI][auth.event] login success [method|FORM][provider|REALM|LDAP][IP|0:0:0:0:0:0:0:1|][login|bob]

Alternatively we may deactivate robert which will clear email address conflict and allow bob to log in creating a new user entry not linked to robert:

c:\>curl -X POST -u <user>:<pass> -w "HTTP CODE: %{http_code}" "http://localhost:9000/api/users/deactivate?login=robert"
{"user":{"login":"robert","name":"bob","active":false,"local":false,"externalIdentity":"robert","externalProvider":"sonarqube","groups":[],"scmAccounts":[]}}HTTP CODE: 200

By checking the messages returned from the Web APIs and HTTP return codes you should get a good idea of where the problem is.

I hope that helps
Michal

P.S> It is expected that you cannot deactivate external users from the UI.

Thanks, it looks like deactivation works but does not solve the issue. But I think I discovered the root of the issue. It looks like the users having issues have a space in front of their logins.

User having an issue logging in:
{"paging":{"pageIndex":1,"pageSize":50,"total":1},"users":[{"login":" n0136285","name":"DAVE MOTT","active":true,"email":"dave.mott@libertymutual.com","groups":["ci_developer","ci_eclps_developer","cp_clarity","cp_egrc","cp_is_users","ram_ECLPS_IT_SUPPORT","sec_it_only","sonar-users"],"tokensCount":0,"local":false,"externalIdentity":" n0136285","externalProvider":"sonarqube","avatar":"6c5e11fd4a236797aaa36e8e560551da"}]}HTTP CODE: 200{"errors":[{"msg":"User 'n0136285' doesn't exist"}]}HTTP CODE: 404{"paging":{"pageIndex":1,"pageSize":50,"total":1},"users":[{"login":" n0136285","name":"DAVE MOTT","active":true,"email":"dave.mott@libertymutual.com","groups":["ci_developer","ci_eclps_developer","cp_clarity","cp_egrc","cp_is_users","ram_ECLPS_IT_SUPPORT","sec_it_only","sonar-users"],"tokensCount":0,"local":false,"externalIdentity":" n0136285","externalProvider":"sonarqube","avatar":"6c5e11fd4a236797aaa36e8e560551da"}]}HTTP CODE: 200%

My user login, which works and does not start with a Space:
{"paging":{"pageIndex":1,"pageSize":50,"total":1},"users":[{"login":"n0305853","name":"BRANDON WOOD","active":true,"email":"Brandon.Wood01@libertymutual.com","groups":["cp_egrc","cp_is_users","cp_libfrgadm","ets_cloudfoundry_developers","ets_libertyforge_developers","ets_libertyforge_git","hs_Remedy_Reporting_All_Users","sec_it_only","sonar-users"],"tokensCount":0,"local":false,"externalIdentity":"n0305853","externalProvider":"sonarqube","avatar":"03dd1d90e06d944dd6104844e561afcc","lastConnectionDate":"2020-12-07T10:42:41-0500"}]}HTTP CODE: 200

Now I am trying to figure out how to alter their logins with whitespace in the URL. Once I figure that out and can post it I’ll close this out.

Thanks again Michal,
Brandon

Hello Brandon

These logins with spaces might have been introduced in old version of SonarQube and kept during subsequent migrations. The current Web API will filter out any space in the login so you might not be able to update the problematic login via Web API. It might be necessary to manually update login column for the concerned user directly in users table of the SonarQbe database (you would normally never do, but in this specific case this might be the only option). Of course extra caution should be exercised with the operation first rehearsed on test environment and database back-up taken before any update.

Here is an example of the query that could be used to update a user with an unnecessary space to a trimmed version:

update users set login=trim(login) where login='<login_with_an_unwanted_space>'

Once the space is cleared the login coming from LDAP and the one in SonarQube should match and the user should be able to log in.

I hope that helps
Michal

Hey Michal,.

I’ve tried both of these variations to no success, says it cannot find the user:
curl -X POST -u n0305853 -w "HTTP CODE: %{http_code}" 'https://forge.lmig.com/sonar/api/users/update_login?login=%20n0204293&newLogin=n0204293'

curl -X POST -u n0305853 -w "HTTP CODE: %{http_code}" --data-urlencode "login= n0204293" --data-urlencode "newLogin=n0204293" 'https://forge.lmig.com/sonar/api/users/update_login'

Response:
{"errors":[{"msg":"User 'n0204293' doesn't exist"}]}. HTTP CODE: 404

But I was able to change my own login using the same style queries since I do not have a space in my name. I believe I am unable to update the affected using the API, it seems like the API is filtering out my space in my search criteria based on the behavior. If you create a user with a space before it’s name are you able to recreate this? Is this a known issue or am I missing something?

Additionally they do not seem to have a space in their LDAP entries, and this issue does not affect them in our non-prod environment, I believe it only exists within Sonar.

Thanks,
Brandon

Hello Brandon
As I said in my previous post - for entries with space you might have to sanitize them directly in the database (taking all the precautions I mentioned) as api/users/update_login Web API filters out the space.
Best,
Michal