Effective permissions from 2 AD groups in the permissions template

We have a SonarQube 7.4 install linked to Active Directory and have added AD groups to the Permissions default template.

We have a couple of users that are members of 2 of the AD groups that have different permissions applied in the default template. One AD group has Administer Issues and Administer Security Hotspots and the other AD group doesn’t.

It appears that the users effectively inherit the least permissions, is this the expected outcome from being a member of multiple groups? I couldn’t find a definitive answer in the online help.

Many Thanks

Hi Ali,

Could you clarify whether you’re connecting to AD via the LDAP plugin or the Azure Active Directory Auth plugin?


It is using the LDAP plugin. And that all appears to be working, the groups in SonarQube are getting populated with users when they login.


Hi Ali,

Just to be sure, your user is added to both groups in SonarQube? (I’m guessing the answer is ‘no’.) And if not, is the missing group spelled exactly the same in both places (capitalization, spacing…)?


Yes the user is appearing in both groups, the problem is not with the LDAP integration per se, but that one group gives more permissions than the other. It appears that SonarQube assumes that the least permission is applied for the user, and the permissions are not cumulative.

Is that the expected result?

Hi @AliRaith,

In order to be sure that I understand correctly, could you clarify what do you mean by

Does it means that for some projects the permissions of the user are correct ?

Julien Lancelot

No, the default permissions template has 2 AD groups specified with different permissions and has been applied across all the projects successfully. The user in question has been added to 2 AD groups (I think mistakenly, they should only be in one of the AD groups) which have conflicting permissions. I would have expected that they would inherit the Administer Issues and Administer Security Hotspots from the first AD group which has those permissions, but it appears that the second AD group that removes those permissions takes precedence.

Is that what we should expect? The online docs are not clear on this issue.


What do you mean by

In AD, in which group does this user belong to ?

The user is a member of 2 groups in AD. Group 1 has been given Administer Issues and Administer Security Hotspots in the default permissions template. Group 2 does not have those permissions in the template. I would have expected that the effective permissions for the user that is a member of both groups to be cumulative, i.e. they should have the Administer Issues and Administer Security Hotspots permissions, but that does not appear to be the case.

I suspect that the user should not have been added to the second AD group that does not have permission, but SonarQube does not appear to behave in a way I would normally expect, and I wanted to check that this is how SonarQube treats the conflict in permissions groups.

If the user is member of the 2 groups in AD, why do you expect that the user is not member of the 2 groups in SonarQube ?
Are the 2 groups correctly created in SonarQube ?

Please execute the following web service in order to check on which group the user belong to :


When I try the web service page you suggested I get a 404 error.

The user is correctly a member of both groups in AD.
The user is listed in SonarQube as a member of both groups (and sonar-users) as I would expect.
The 2 groups in SonarQube have conflicting permissions in the default permissions template.

There isn’t a problem with the AD group mapping into SonarQube, but I would normally expect the effective permissions to be cumulative across all groups that the user is a member of. My question is whether this is what I should expect, as the online documentation isn’t clear?

If the user is member of the 2 groups, the user should indeed have permissions from both groups.

In order to be suer the user is correctly members if the groups, I need to get the answer from the web service I gave you. I forgot to mention that is should be executed as an administrator.

I ran it again as the inbuilt admin user (although I have admin access) and got the following output for the user’s login id:
{"errors":[{"msg":"Unknown url : /api/users/group"}]}


Taking a step back from API calls, etc…

Can you confirm what you see on your instance that shows the user in question has reduced permissions? Is it that the user is unable to take certain actions (annotated screenshots appreciated just to check a few things!), is it that permissions that you are seeing in the project Administration > Permissions don’t align with your expectations?

I’m asking because if you’re looking for the specific user’s permissions, and those permissions are applied via a group – you won’t. You’ll only see what permissions the groups have.

Put another way – we don’t display the effective permissions for a user when they are permissions granted via a group.

Best regards,


1 Like

Yes, the user was complaining that they did not have the permission to assign issues even though they were in the AD group that gave them the permission. That was when I discovered that they were also a member of a team that did not have the permission. I added the users individually to the permission template with explicit Administer Issues permission and that solved their problem, but it is not what I would expect from being a member of 2 teams.