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.
Related
RE: https://jfrog.com/knowledge-base/when-do-the-groups-associated-with-an-ldap-user-get-updated-in-artifactory/
The Knowledge Base article above says:
"LDAP user authentication requests using Encrypted password or plain text password will update the LDAP group association changes from the LDAP server."
We've added a user to a group, but that user still can't see the artifacts governed by that group even after he has logged in. How can we cause Artifactory to update its group membership cache?
Please ask the user to logout and log back in after being added to the groups. Artifactory will try to reach to the LDAP server for validating the creds and then get the groups associated with the user which is returned from the LDAP server.
There is a chance that LDAP cache as mentioned in here https://www.jfrog.com/confluence/display/JFROG/LDAP#LDAP-Non-UIAuthenticationCache might take effect the groups to be associated if the user session is not hitting the LDAP server.
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 am trying to configure Grafana for my organization. I was able to configure LDAP and MySQL database pretty easily but when I try to invite a new user to an org in Grafana, it always asks the user to join Grafana.
This would be an OK behavior if at that point Grafana would authenticate against LDAP. Instead, it creates a new user in its own database. This would lead to conflict with LDAP in case the user's AD passwords changes.
This works perfectly when a user had previously logged in to Grafana. An invite sent after would directly take the user to login page.
Is it possible to do the same in case the user is not already registered in Grafana? I really want to avoid saving user credentials in Grafana database.
Any help would be appreciated. Thanks.
I am not a Grafana expert, but looking through the source code on GitHub it certainly seems that new user registration will not go through LDAP. This is obvious in the LDAP related configuration file where you see the read-only credentials needed to look up users in the LDAP directory. A read-only administrator in LDAP will not be able to create new users as this would be necessary during a registration step. The code also indicates that registration creates temporary users in the internal store.
i want to customize login in Liferay 6.2. I've internal liferay users and ldap users. All users have a record in liferay user_ table. The differences are: internal users must change password at first login and see password reminder question.
Ldap users make only login with their password.
Acutally Liferay ask to ldap users to change their password and set password reminder question. These users change password but at next login, login is possible by old ldap password (correct). Liferay must not write in ldap.
How can i remove password change and password reminder question for ldap user?
There's a password policy that you can set per organization. If you introduce a new organization for each of the groups (or just one might suffice as well) you can have individual password policies per organization.
In Password policies you can configure quite a lot of stuff, e.g. should passwords be changed on first login etc. You can also select the "LDAP Password Policy" in the LDAP configuration screen. I'm rarely working with password policies, thus it's hard to give detailed directions - let me know if this is sufficient or if you need more detailed pointers
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.