how to disable user in Apache Directory Ldap - apache

Iam using Apache Directory Ldap. I started using it just recently. I had one query:
I had one attribute called 'user-last-date', so as soon as this user end-date reaches, I should be able to disable the user account in ldap and also should send out an automated email to his manager. So, Is that possible to disable the user automatically in ldap as soon as the 'user-last-date' reached?
I already searched in google on this, not finding much info on this.

No, it is not possible by default, however you can write a custom interceptor to achieve this.
Or you can set the value of attribute pwdAccountLockedTime to 000001010000Z to permanently lock the account, but this will be effective only if the passwordpolicy is enabled.

Related

How to delete a user from SonarQube and re-activate?

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.

How to define Watches in Artifactory for LDAP Users

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.

Grafana: Any way to integrate invite users with LDAP login

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.

How to set Authentication in apache bloodhound?

I've just installed Apache Bloodhound in my server. It's working fine. But with the default settings, anyone can view the list of tickets. I want to change this so that only logged in users are able to view the tickets.
Is it possible? How can I do this?
Default Trac ticket permissions are TICKET_VIEW for 'anonymous' sessions (everyone) and editing for 'authenticated' users, yes.
You'll want to remove TICKET_VIEW, so only authenticated users will see (and modify) tickets. To accomplish that, any user with PERMISSION_REVOKE (inherited by TRAC_ADMIN and PERMISSION_ADMIN as well) is allowed to navigate to the permission web admin page, can check and submit the 'remove' action. Alternatively you could use the trac-admin command:
trac-admin <path_to_trac_env> permission remove anonymous TICKET_VIEW
where you need to replace the path with you real one, like /var/www/trac_env/myTrac.

How to deal with logged in user who happens to be deleted?

In MVC 4 project I've deleted user from the system while he happened to be logged in. Now he's getting exception from SimpleMembershipProvider methods (or from Membership/Role helpers) that user does not exists.
The issue is however, that while logged in, instead of any possibility to log off gracefully, he's getting error page, which would not let him use the page till the auth cookie would get outdated. How to intercept such a situation? It looks like I can't hook anywhere to just handle those exceptions. What is a nice way of dealing with it?
If you are using role-based authorization and have authorization setup correctly in your application, then the graceful way to handle this is to not delete the user but to take his roles away so he does not have access to areas you do not want him to.
Another way to do this is to add an enabled flag to the UserProfile by customizing it as described in this article. Then use the enabled flag in your authorization process by customizing the Authorize attribute to fail authorization if enabled is false. Instead of deleting the user you just flip the enabled flag to false.