[FEATURE REQUEST] Ability to disable LDAP users

[cmer]

Motivation
In a small business environment, we occasionally need to disable users after they have departed the company.

Describe the solution you'd like
I'd like to have a way to disable a user at on a specific date in the future, or right now.

Describe alternatives you've considered
Changing their password. But they could just reset it. Removing their email address is also a possibility, but it's kind of dirty and not great in case the person needs to be reactivated in the future.

[nitnelave]

Why can't you delete the user? Why do you need to keep them around? Do you have many cases where a disabled user has to be re-enabled?

I'm a bit skeptical of the use case. If a user leaves the company, their entry should surely be deleted, no? And if they do join again, then you have to consider again which permissions they need, since the business might have evolved and the requirements changed, or even just the group organization.

The closest feature I can think of that could facilitate the bulk addition of permissions is nested/inherited groups. It's planned, but not right now :)

Another thing you can do is to keep their account but remove them from every group: if you have configured your integrations correctly, they won't have access to anything, even though their password is still valid (though that may be a bit riskier).

[nomandera]

In my home lab it is unlikely I would ever use this but at my day job there are many instances where this can and does happen.

Holidays, maternity or paternity leave, sickness, testing related services stop working when user disabled, first line incident response (it is far less impactful to disable with a view to later reactivation if false positive than deleting a user) etc

[lordratner]

I would suggest removing them from groups if they need to be "disabled." Or add them to a "departed" group that is explicitly blocked in any ldap queries.

Just a thought

[wildcart]

We are also interested in this feature. A few month ago a user left the company and we reset the user's password to 'deactivate' the user. The reason why we haven't deleted the user nor removed the user from any groups is that I am not sure how services using (L)LDAP would 'react' if they no longer find the user in the directory. Especially GitLap and OpenProject are critical and any contribution made by the user must remain attributed to that specific user.

Another reason for not deleting the user is: We must never be able to create a user with the same username / email address. Otherwise, attributing contributions to a user becomes difficult because we would always have to consider the date of the contribution and the date a user was active.

[terefang]

there are two widely used attributes for this used by other servers:

• userAccountControl – from Active Directory; 512=active, 514=disabled
• pwdAccountLockedTime – from Sun/iPlanet/OpenLDAP; Timestamp when the account was last locked, where 000001010000Z means the account has been locked permanently.
• nsAccountLock – Netscape/389/FreeIPA; true=locked, false=unlocked

[nitnelave]

Just a small update on my position on this feature: I'm not against, but it's not targeting the core user base of the project, small self-hosted homelabs. The feature seems more targetted at companies. As such, I'm open to pull requests, but I probably won't implement it myself.

If you want to contribute, I'd be happy to guide you, provide you with hints and go over the design with you!

[lllllllillllllillll]

I've been hoping to get this feature as well, but with the ability to set account expiry dates.
I'd like to be able to grant multiple accounts temporary access without having to monitor and disable them manually.