LDAP users with same email


(Carles Perez) #1

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

(Carles Perez) #2

Hello, FYI same behavior with SonarQube 7.2

(G Ann Campbell) #3


It’s simply not possible to have two LDAP/SonarQube users with the same email.

This response is relevant:


(Mark Symons) #4

@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.

(Julien Lancelot) #6

Hi Mark,

You’ll be able to get more info about authentication errors by setting logs to DEBUG.

Julien Lancelot

Unable to login with AD credentials post migration to Sonar 6.7.2 - only admin credentials working
(Mark Symons) #7

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?

(Nicolas Bontoux) #8

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.

(Ian W) #9

(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?