Must-share information (formatted with Markdown):
which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
SonarQube Version 7.1 (build 11001)
LDAP 2.2 (build 608)
what are you trying to achieve
To have users from LDAP sharing the same email
what have you tried so far to achieve this
Just the first user logged can access, if a second one with the same email tries it, it can’t. I think that with 2 local users i’ts possible, but no with 2 users created from LDAP
Hello, FYI same behavior with SonarQube 7.2
Hi,
It’s simply not possible to have two LDAP/SonarQube users with the same email.
This response is relevant:
https://community.sonarsource.com/t/allow-plugin-to-define-existing-email-strategy/708/4
Ann
@ganncamp, I do think that there are a couple of bugs (or “sub-optimal behaviour”) here:
The SonarQube v7.2 UI does not give a warning when a technical user is created/edited using an email that matches one that comes from LDAP. Thus, its possible to login as an LDAP user (and a valid member of sonar-administrators), make an email address change to said technical user to use your own email, and then log out. After which, it is no longer possible to login again as oneself (“Authentication Failure”).
“Authentication Failure” is correct as a UI error - but the only log entry (using default loglevel) is an HTTP 401 event in access.log. I think that there should be a log entry somewhere to report the duplicate email.as the cause of the problem.
Such a log event is still needed even if the UI prevents the creation of dupes. This is because older versions of SonarQube do seem to allow users with duplicate emails. I am running v5.6.7 with LDAP working correctly and with duplicate emails. I imagine that login will break as soon as the instance is upgraded. I am forewarned and will clean things up prior to upgrade - but that would not help others.
Hi Mark,
You’ll be able to get more info about authentication errors by setting logs to DEBUG.
Regards,
Julien Lancelot
At DEBUG level, the web.log file does indeed contain sufficient info to help diagnose authentication errors. Testing with v7.2:
2018.10.11 11:14:50 DEBUG web[AWZinyfbgxvsivMDAAAA][auth.event] login failure [cause|User must be authenticated][method|BASIC][provider|LOCAL|local][IP|xxxx|][login|]
2018.10.11 11:14:51 DEBUG web[AWZinyfbgxvsivMDAAAF][auth.event] login failure [cause|User must be authenticated][method|BASIC][provider|LOCAL|local][IP|xxxx|][login|]
2018.10.11 11:14:54 DEBUG web[AWZinyfbgxvsivMDAAAH][o.s.p.l.LdapUsersProvider] Requesting details for user zzzz
... (10 events for LdapSearch,LdapContextFactory,LdapGroupsProvider)
2018.10.11 11:14:54 DEBUG web[AWZinyfbgxvsivMDAAAH][auth.event] login failure [cause|Email 'zzzz@foo.bar.com' is already used][method|FORM][provider|REALM|LDAP][IP|xxxx|][login|zzzz]
I believe that this last event should be INFO or higher.
Bear in mind that the alternative is TWO server restarts (one to turn DEBUG on and then another to turn DEBUG off again once the problem is solved). Additionally, it’s possible that a support person might have sufficient permissions to view logs but not configure what goes into them.
Thoughts on the rest of my post? eg, should not SQ UI prevent configuration of a duplicate email?
Just a quick note on this:
You should be able to dynamically change the logging level from the admin. System Info page, without any server restart.
(pls advise if a separate bug report is req’d …)
We have a scenario where contractors are often rehired. They end up with a new login-id (AD Authentication) but are reassigned the same email. When the user attempts to connect to SQ, the simple error “Authentication failed” is given in the UI.
The user should be provided more accurate information like shown in the logs:
login failure [[cause|Email 'zzzz@foo.bar.com' is already used][method|FORM][provider|REALM|LDAP][IP|xxxx|][login|zzzz]
Email is not even a mandatory field in the UI. Very misleading.
A workaround is to delete the user’s SQ account (or I suppose rename the email on the existing id).
What happens to the existing issues, items, etc. upon deleting the id? What is the best resolution?
Hello, just a question:
a year later, is it still not possible? in my personal case it is a blocking impediment to update my sonar qube server … in previous versions it did not happen and I cannot modify the enormous structure of the ldap of my company in which many emails are shared between users…
Here is a log from today with the same issue:
2019.11.12 12:36:22 DEBUG web[AW5fYXWb9vTLYa9BAACd][auth.event] login failure [cause|Email ‘----------’ is already used][method|FORM][provider|REALM|LDAP][IP|192.168.153.173|][login|-------]
SQ version: SonarQube 7.9.1.27448
java.runtime.version: 11.0.4+10-LTS
Thanks!