Sonarqube 6.2 LDAP configuartion

477 views
Skip to first unread message

rpet...@gmail.com

unread,
Jul 25, 2017, 1:34:59 PM7/25/17
to SonarQube
Hi There,

We have a Sonarqube 6.2 running with the LDAP plugin 2.2.0.608. In the web.log I see an message like:
2017.07.25 19:03:28 INFO  web[][o.s.p.l.LdapSettingsManager] User mapping: LdapUserMapping{baseDn=OU=Users,OU=User Accounts,DC=xxxx,DC=xxxxx, request=(&(objectClass=user)(sAMAccountName={0})), realNameAttribute=cn, emailAttribute=mail}
2017.07.25 19:03:28 INFO  web[][o.s.p.l.LdapSettingsManager] Groups will not be synchronized, because property 'ldap.group.baseDn' is empty.
2017.07.25 19:03:28 INFO  web[][o.s.p.l.LdapContextFactory] Test LDAP connection on ldap://ldap.xxxx.xxxx: OK

And also when I set a wrong password for the ldap.bindPassword parameter Sonarqube will not start anymore.
I conclude that my LDAP properties are correct.

But my question is how does sonarqube know which user to authenticate with the our AD via the LDAP plugin and which users to th elocal database?
When I try to login with an user from LDAP, which doesn't exist in sonaqube I get an 'Authentication failed'.
Also when authentication succeed ho to give them the proper permissions...?
For some reason I have 2 users that can login via LDAP, but I have no idea how they got in there.

I found the users table in the database, but normally you should not be messing around here.

Could someone help me a bit?

Thanks



nicolas...@sonarsource.com

unread,
Jul 26, 2017, 2:58:26 AM7/26/17
to SonarQube, rpet...@gmail.com
Hi there,

The behaviour to remember is the following: any user created in SonarQube is considered local and will always be logged against SonarQube. Contrary to unexisting users that first get logged via LDAP Plugin, and are then considered as non local by SonarQube (i.e. all further authentication attempts will be made against the LDAP/AD server).

About permissions: the above behaviour does mean that LDAP/AD users can only be given permissions (through SonarQube permission settings) once they first logged-in. A solution to that problem is to leverage the Group Mapping feature of the LDAP Plugin. It allows you to allows you to centrally manage group membership in your LDAP/AD server (where your full set of users is also visible) and that info is then synched-down to your SonarQube server. Note that only groups that have been created in SonarQube are used for group mapping. All in all: add user foo to group bar in LDAP ; create group bar in SonarQube and give it the appropriate permissions ; the first time foo logs in, he will automatically inherit these permissions :)

About provisioning LDAP users: starting from the latest version of SonarQube (v6.3), it is now possible to pre-provision LDAP users in SonarQube (i.e. create LDAP users and manage their permissions before they did their first log-in). This capability is only exposed via WebAPI, as it remains a specific use-case which is anyhow better managed programmatically. For more details you can review the api/users/create documentation, notice the local parameter there !

About debugging a failed authentication attempt: switch SonarQube logs to DEBUG , and get the user to attempt to log-in. If it fails then the logs should give you further details, potentially with error codes coming from LDAP/AD side, which must be followed-up with the respective infra teams.

That covers it pretty much.

Best regards,
Nicolas

nicolas...@sonarsource.com

unread,
Jul 26, 2017, 9:47:04 AM7/26/17
to SonarQube, rpet...@gmail.com
Hi Remko,

Please make sure to include the SonarQube group in your responses so that the overall community can benefit from the guidance and help provided here.

About your certificate-related questions: certificate trust mechanics are fully handled at the Java layer, nothing specific to SonarQube nor to the LDAP Plugin on this front. If your default Java truststore does not trust the server certificate then you'll get a 'classic' Java error like: PKIX path building failed (example). It comes from the Java stack, and so does the resolution: updating the Java truststore.

Best regards,
Nicolas


On Wed, 26 Jul 2017 at 14:56 Remko <r...@gmail.com> wrote:
Hi,

Got one more question were to store our CA or LDAP ceritificate. Do these go in the cacerts keystore or can I configure a Sonarqube specific trust (and indentity; for SSL) keystore?
Thanks for your time.

Best regards,
Remko

2017-07-26 13:13 GMT+02:00 Remko <r...@gmail.com>:
Hi Nicolas,

Thanks for the helpful information.
This is clear now. I will play with further.

Best regards,
Remko
Reply all
Reply to author
Forward
0 new messages