We are using the SQ v9.5 Developer edition on RHEL8 Linux with Oracle database.
If we turn on the LDAP user Authentication with Group mapping, we cant persist our membership into the sonar-administrators local group bc on every login event we lost all of our local group memberships.
SO If we want to work as a “sonar-administrators” member we either
- Have to use local users >> not really secure
- Dont use the LDAP Group mapping >> not soo enterprise solution
Can you please help us, how can we use LDAP User auth with group mappings and at the same time remain part of the local “sonar-administrators” group ??
The solution here is to create a
sonar-administrators group in LDAP and add the appropriate users there. Group mapping is an all-or-nothing proposition. From the docs:
- membership in synchronized groups will override any membership locally configured in SonarQube at each login
Thanks the answer, is it possible to open a Feature Request for that?
“Ability to set the sonar-administration role for a custom named LDAP group”
best regads L
You’re welcome to create a ‘Product Manager for a Day’ thread (please fully explain your use case and needs), but I have very little confidence it will ever turn into code.
In a big company, there are naming conventions everywehere, especially in the LDAP.
Like every group has to be started with “Gr_” After that the application name like “SonarQube” and the role “Sysadmin” >>> “Gr_SonarQube_Sysadmins”.
or something like that.
If i’m using LDAP with group mapping, i would like to use my own naming conventions, not the application’s. I think it is a normal request
I don’t understand. You can absolutely create this group in SonarQube and give it global admin permissions. Or you can update the name of the existing group. In fact, the only built-in group in SonarQube is
sonar-users. So the
sonar-administrators group was created on your side, and you’re in full control of it.
Or are you saying you don’t want your company’s LDAP naming conventions perpetuated into SonarQube? With that, I can’t help you.
ok here is an example what is the difference, if you’re a member of the “sonar-administrators” group on you have more visible controls on the UI:
Without this membership:
With the membership:
how is it possible ?
In this case the sonar-administrators group is local, and my LDAP Group is that one (sysAdmin)
Your last screenshot shows global permissions. Note that none of the permissions listed is related to project administration. So this is about project permissions, not necessarily about membership in that particular group.
You should start by looking at your default permission template, which probably grants project administration (on newly-created projects) to the
sonar-administrators group, but not to
GR_Sonar_sysAdmins. So edit the template to add
GR_Sonar_sysAdmins. Now its members will have project admin rights on any future projects.
What about catching up the existing projects? Go to Administration → Projects → Management. There you have the ability to select one or more projects and
Bulk Apply Permission Template. So you can reset existing projects to whatever’s in the template now. Note that this is a complete overlay, so if any projects had customized permissions, outside those granted by the template, they’ll be lost. For projects where you don’t want to lose customization, you can just edit them individually (use the cog menu on that page) to add the group.
As a side note: there is no ongoing relationship between a permissions template and the projects it was used on. Just like there’s no ongoing relationship between a cookie cutter and the cookies you’ve cut out with it. Changing a permission template won’t have any affect on existing projects, just like dropping the cookie cutter on the floor and denting it won’t change any existing cookies.
THan you for the long explanation, it works fine, my fault!!!
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.