SonarQube LDAP plugin: a love story

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.


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
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, 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:


Now moving towards the Active Directory plugin you need to change it to look like this:


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\plugins folder.

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.



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. Root node in AD from which to search for groups Same as for the user request but for group search. 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 '' 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.


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.

TFS Job “Reporting Service Path Rename” failing


After migrating our TFS 2015 server to a different AD domain we started seeing in our Job Monitoring page a large number of “Reporting Service Path Rename” job runs failing.


In the job details result message we can see the following, The permissions granted to user 'RABOSVC\prd.TFSService' are insufficient for performing this operation., where 'RABOSVC\prd.TFSService' is the application tier service account.


After a quick check, all the permissions set in the reporting services seemed to be all right. In the ‘Site Settings’ our service account was added in ‘System Administrator’ role, as on the ‘TfsReports’ folder it was set as ‘Team Foundation Content Manager’, and also inside ‘TfsReports’ folder it had also ‘Team Foundation Content Manager’ association on the Team Project Collection folder.


As it turned out this was not sufficient. On the project level folders we also needed to associate our new TFS Service account to ‘Team Foundation Content Manager’ role. Once done, the “Reporting Service Path Rename” job managed to run successfully.


Obviously this needs to be set only once, for the projects created previous to the domain change. Newly created projects will inherit the correct right from the Collection folder.

Although this is not a very common operation/situation, still I hope this can help someone in a similar situation as not many references to “Reporting Service Path Rename” job can be found on Google.

Also I would like to say a big thanks to Microsoft support which helped us diagnosing this issue.