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.
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.
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.
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"}]}
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.
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.
@AliRaith- Did you get anywhere with this? I’m having some similar weirdness… Users are correctly being mapped to the sonargroup based on their AD groups, but the permissions refuse to apply… I only have one default permission template, and seems like nothing matters unless i put the user in the sonar-administrators group (thats the only way I can get users the ability to administer issues), despite the permission’s template.
No, I did not get a clear answer. I would normally expect a user with membership of 2 AD groups to get the cumulative permissions assigned by the 2 groups, but it appears that is not how it works in SonarQube.
99% of our users are only in one AD group and they inherit the group permissions correctly from the default template, but this one user was a member of 2 groups and that didn’t behave as I would have expected like every other application that uses groups.