I am trying to integrate Opensearch with openldap, and currently I am able to login to Opensearch-Dashboard with a user (say john) in ldap. However, after I delete user "john" from ldap, I can still login with user "john" with previously assigned group as if the user is cached by Opensearch once it logs in. The user remains cached until I restart Opensearch. I can no longer login with user "john" as expected after Opensearch is restarted.
Does anyone experience the same thing? or most likely I miss-configured somethinig?
I use Helm chart from https://github.com/opensearch-project/helm-charts (main branch) to deploy Opensearch.
The Docker image used is opensearchproject/opensearch:2.0.0-rc1
After a few testings, it turns out the LDAP data will be cached for around 10 min.
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.
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.
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 have a strange problem with an authentication of users in Grails using Spring Security plugin:
When the user logs into his account, he sees credentials of completely different user (I print out the credentials)
Sometimes the credentials switch to other user when user is already correctly authenticated.
This problem does occur neither on my development machine nor on a test serwer.
The evironment where problem is present:
Students in a school are testing the system on school's computers
Each student registers as a new user
School's computers has some security restrictions (that I don't know)
All computers has one IP assigned (I don't know how internal network is configured yet)
Firstly, I thought it had something to do with cookie storage (j_session_id), but students could log in to Facebook or Gmail, etc. without any unexpected account switches.
It looks as if all cookies on all computers are being overriden when new user logs in - this was my guess but I can't confirm that all consequent users have the same - last logged user's credentials.
Sadly, I can't debug it at school's place, because it's far away.
How can I find out what is going on?
What might be the possible cause of the problem?
Why have users often different credentials when they are logging in?
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.