I have installed SonarQube 5.2 and the LDAP plugin 1.5 a few hours ago. I am really happy about the easy configuration of the LDAP plugin in an Active Directory domain.
But I experience something which looks like a huge problem.
1) An AD user loads the web page of the SonarQube instance
[behind the scenes] a user is being created (starting up from the headers of the HTTP request and the information present in the Active Directory)
2) An administrator of the platform (e.g. admin, default administrator of the platform) gives her some rights (e.g. add her to the sonar-administrators group)
the web interface shows an updated set of rights for this user
3) The user starts a new session
!!! The user has lost all of its rights. She doesn't belong anymore to the sonar-administrators group
(expected behavior) the user gets an updated interface, with the menus reserved to the sonar-administrators group
Am I missing some important part of the documentation?
You have configured SonarQube to use an external system to manage security, in this particular case Active Directory. So the default (and expected) behaviour is to delegate both the authentication and the authorizations to this system.
In your example, if you want the user to belong to some specific group, you have to configure this in your Active Directory. Next time the user logs in, he will be associated to this(those) group(s).
Note that the groups must exist in SonarQube otherwise this won't work (i.e. you have to manually add them in the "Security > Groups" ).
To elaborate on Fabrice's answer, when you have a user or group in the AD that you want to have administration permissions to the SonarQube instance, go to:
<your sq instance>/roles/global
and add the user or the group to the Administer System global permission.
Related
In our SonarQube instance we have recently enabled LDAP authentication. Prior to LDAP integration the users were manually created. It so happened some of the users were created using the same LDAP user ID and custom password.
Now when LDAP is integrated we want all users use the LDAP ID/pass instead of previously manually created ID/password. SonarQube login works with manually created password rather than LDAP password. So how do remove the manually created users and only activate the LDAP users?
PS: I dont see the option to delete but only to de-activate
As replied by Jeroen Heier in comments, removing users from Administration > Security > Users will allow you to reuse the login of the removed user with an LDAP account.
If it's not the case, please describe what you're doing.
While I'm concerned with the deletion of an account... why can't you re-activate a user if you de-activated them through the UI. This is incredibly painful if a user was accidentally deactivated.
Artifactory allows to set Watches on specific repositories to get notification when changes happen.
When you define an internal user, this works properly.
For LDAP Users, there is no option to set a watch on a repository.
Are special settings needed to enable this feature for LDAP Users or is it imposible without any workarounds?
Thanks a lot!
The issue you are describing is not related to the LDAP users but due to one of the below options:
You are not creating the LDAP users locally on Artifactory, meaning that you are validating the user vs the LDAP server on the fly and not creating the user on Artifactory. If this is the case then the reason for you not to be able to set a watcher is that from Artifactory perspective it doesn't have a user with details (email as an example).
If #1 is not the case and you do create the LDAP users (automatically or not ) in Artifactory then check if those users have email defined upon creation in Artifactory.
I have set the proper LDAP configuration in Sonar 5.6.6 LTS (ldap plugin v2.2.0.608) and I see in logs that the connection is established.
When I first try to login with my LDAP-login, I am able to do so, but my user has of course no permissions - that is okay.
The problem occurs, when I want to first add my user and give him i.e. sonar-administrators group. When it is set and I try to login, Sonar authenticates me not against the external system (LDAP) but uses his own data base.
I am sure it worked with Sonar 4.5 but now I cannot configure it properly.
The problem was that creation of new users adds them by default to the local database of SonarQube. To change this default behavior I found out that the REST API endpoint to create users contains the flag 'local' which defines whether the user should be considered as a local user added to the local database or he should be added as an external user authenticated again an external system like LDAP.
So final answer is to use the following REST API endpoint:
private final String CREATE_USER_API = "/api/users/create?login={login}&name={name}&local=false"
Please note the following property: local=false at the end of the string.
The context:
A client environment: SharePoint Foundation 2010
He wants to have a timerjob to update users profiles with data in active directory. Everything OK, I developed the timerjob that gets a catalog from active directory & updates selected fields for every user in the SharePoint hidden users list, that way I can keep a daily update for every user.
The problem: the client has used (as i should have thought) an active directory group that he have to manage permissions in SharePoint something like "All authenticated users".
Now i have no clue on how to update the profiles inside that group because they don't exist in the list.
Any ideas on where to update those profiles ?
Is it possible that the SP site was upgraded from an earlier flavor - specifically 2007 - and this is an artifact of that- NT Authority All Authenticated Users..... This is a catch-all reference sometimes dropped into a group or a listing pointing towards the SP site admin for user access requests. You can control access on it by having it in one group and then setting the permissions of that group as low as possible. But as for reading anything back into your scheme from Active Directory - there's nothing to grab. It's only a flag that tells SharePoint that an ID authenticated within the windows domain and nothing more. It's a default gateway of sorts to allow domain users into the SharePoint site, usually, for read only access or access to request SharePoint unique permissions, or, on some sites, access at a basic visitor level.
Using the Jenkins OpenID plugin I'm able to configure Jenkins to use my Google Apps OpenID as a provider. Anonymous users are still able to access that application (they have read access only), but I want to have it so that users are forced to login using the Google App domain or they are denied access.
I'm currently using the Jenkins Authorization setting of "Logged in users can do anything", I've tried using the "Matrix based authentication" and denying anonymous users, assuming logged in users would still have permissions, is there a special group value I can use for "logged in users" in matrix based authentication?
It seems like "Matrix-based security" will only work for specific users when using Google Apps OpenID (I don't believe Google apps for domains has support for OpenIDTeam extension
Yes there is a special group you can use to do this but finding the information about how to do it isn't obvious.
If you hover over the 'Overall - Read' column on the Matrix-based security table you'll get the solution.
It states
The read permission is necessary for viewing almost all pages of Jenkins. This permission is useful when you don't want unauthenticated users to see Jenkins pages - revoke this permission from the anonymous user, then add "authenticated" pseudo-user and grant the read access.
I use the following technique in combination with the OpenID plugin which allows me to specify a Google Apps for Business domain to secure Jenkins with
Warning: Make sure you've got a backup of your installation before you start because if you get something wrong you may lock yourself out of your Jenkins. Unpicking the plugins and settings would take longer than just restoring from a backup.
Ensure your choice of OpenID provider is still working ok with your current 'Logged in users can do anything' setting
Select the 'Matrix based-security' mode for Authorization
Add a new 'authenticated' group (lower case 'a') to the Matrix-based security table.
Use the 'check all' icon at the right hand end of the new 'authenticated' row to tick all the permission boxes.
Use the 'check all' icon at the right hand end of the 'Anonymous' row to untick all the permission boxes.
Save the settings
Reload Jenkins
Now each time a user wants to see Jenkins they have to be already signed into their Google Account and no-one can get to see any Job names or views without login.
Hope this helps.