SonarQube LDAP plugin: a love story
Mario Majcica It is been a while, since I struggled more then with the recent changes with the SonarQube LDAP plugin.
As I have already mentioned in my previous post, how to configure LDAP with your SonarQube instance, I’ll share with you what I experienced in the recent changes that affected the LDAP plugin.
Introduction
It all started with my upgrade of SonarQube from version 5.5 to version 5.6. With the version 5.6 the support for the LDAP plugin version 1.5.1 (which I was using) was dropped and based on compatibility matrix, we are forced to used the new 2.0 version of LDAP plugin. But wait, if we are using the Microsoft Active Directory as our LDAP directory (which I do), the documentation is pointing us towards a new, spin off, plugin called Active Directory Plugin. You can get more information about this at the official documentation page of LDAP plugin here http://docs.sonarqube.org/display/PLUG/LDAP+Plugin.
Considering this an advised practice, I decided to abandon the LDAP plugin in favor of the newcomer.
In the next paragraph I’ll show you how did my configuration changed in case you got here with the intention to achieve the same.
Just to conclude my story in regard to the LDAP integration and SonarQube upgrades. My plan went well until I decided to upgrade SonarQube again to the next new version, 6.0 in my case. I was surprised to understand that the new Active Directory Plugin was not compatible with the version 6.0 of SonarQube and that if I was keen to keep LDAP integration in place I would need to turn back to LDAP 2.0 plugin.
Not only, I also came to understand that SSO is not supported anymore. This means that my users from now on will need to type in the username and password. Hopefully the following feature will become available soon, which would solve all of these issues, https://jira.sonarsource.com/browse/SONAR-5430. As soon ready, I will write a blog post about it.
From 5.5 to 5.6
If you were using the LDAP plugin version 1.5.1 on SonarQube version 5.2-5.5 and you followed my guide in this post, your current configuration should look like this:
#----------------------------------------------------------------------
# LDAP
sonar.security.realm=LDAP
sonar.authenticator.downcase=true
Now moving towards the Active Directory plugin you need to change it to look like this:
#----------------------------------------------------------------------
# LDAP
sonar.security.realm=ACTIVE_DIRECTORY
sonar.authenticator.downcase=true
This change is sufficient to keep your LDAP integration working.
Before making this change in your configuration make sure that Active Directory plugin is installed.
You will not find the Active Directory Plugin in the Update Center. You need to download it here and install it manually (by placing the sonar-activedirectory-plugin-1.0.jar file into the
extensions\pluginsfolder.
From 5.6 to 6.0 (and beyond)
Now the hard part. If you upgrade from your 5.6.x version to 6.0, the plugin that we just started using, will not be supported anymore. Also the SSO will not work no matter the plugin you are using. If you are planning to achieve the LDAP integration, you will have no other choice than get using the LDAP plugin version 2.0 again. In that case you LDAP configuration needs to change quite drastically. I’ll show you an example and then I’ll explain the various settings and how you should adapt it for your case.
#----------------------------------------------------------------------
# LDAP
sonar.security.realm=LDAP
sonar.authenticator.downcase=true
ldap.url=ldap://ldap.mydomain.com
ldap.bindDn=myServiceAccount@mydomain.com
ldap.bindPassword=myPwd
ldap.user.baseDn=dc=my,dc=domain,dc=com
ldap.user.request=(&(objectClass=user)(sAMAccountName={login}))
ldap.group.baseDn=ou=Groups,dc=my,dc=domain,dc=com
ldap.group.request=(&(objectClass=group)(member={dn}))
ldap.group.idAttribute=sAMAccountName
Let’s check the different settings and try to explain them.
| Setting | Description |
|---|---|
ldap.url |
URI that should point towards your domain server. |
ldap.bindDn |
A valid domain user account that will be used to query the LDAP. |
ldap.bindPassword |
Password of the above mentioned account |
ldap.user.baseDn |
Distinguished Name of the root node in AD from which to search for users. |
ldap.user.request |
LDAP user search pattern. It should stay as is for AD. |
ldap.group.baseDn |
Root node in AD from which to search for groups |
ldap.group.request |
Same as for the user request but for group search. |
ldap.group.idAttribute |
Property used to specifiy the attribute to be used for returning the list of user groups in the compatibility mode. |
If you now have set the necessary for your domain, you should be able to log in SonarQube. Be aware however that your user id is going to be changed same as for your groups. Probably you will need to use the local admin account to setup the new group names and assign the correct Global Permissions. Check my previous blog post on how to achieve that here, SonarQube on Windows and MS SQL.
This also means that if you have issues assigned to users and other user related information, they would be lost. I tried changing some of these values manually in database, however I was not successful. As soon as I do get more information about migrating user profiles, I will create a separate blog post on that.
After you set up everything as I suggested, you still may encounter some issues. If you can’t log in check your log file and see if you have any similar lines in it:
You can't sign up because email 'Mario.Majcica@mydomain.com' is already used by an existing user.
If this is the case you need to deactivate the previous user from Administration > Security > Users panel (log in as admin) or modify a relevant records in you DB in table users.
Update
Meanwhile writing this blog post, a newer version of SonarQube and LDAP plugin became available (SonarQube 6.1 and LDAP plugin 2.1). There are no braking changes and all of the above should work the same.