Gitea deactivates LDAP users

[aravindhsampath]

• Gitea version (or commit ref): 1.9.1
• Git version: 2.22.0
• Operating system: CentOS 7.6
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:

Description

While using Gitea with FreeIPA as authentication source, Gitea repeatedly deactivates valid user account every time auth source is synchronised. This is rather annoying to the extent that it makes Gitea unusable in a FreeIPA environment.
There are already several issues opened in the past for this very same issue, but they either went stale or have been closed pointing to a hack that does not quite address the root cause of the issue. This is why I am creating this meta-issue referring to previous closed issues. If this issue also gets closed without a solution in sight, I will have to abandon using Gitea and move our stuff over to something else. :-( Making a desperate attempt to keep using Gitea because it is what I want.

Past issues:

1. Gitea deactivates user every day #4067 State = Closed ; Reason = a hack to NOT sync LDAP users was supplied.
2. LDAP user sync does not work (here) #4433 State = Stale & Closed
3. Inconsistent behaviour when LDAP user is not activated #4404 State = Stale & Closed
4. LDAP user synchronization timeout disables all users #4402 State = Stale & Closed
5. SyncExternalUsers is deactivating ldap users #3815 State = Open

Issue # 3815 refers to LDAP call failing leading to users being de-activated. I cannot verify whether this is happening in my case - the logs don't quite show any LDAP activity in the first place.. I tried running in dev instead of prod as well without luck.

Even if LDAP call fails, de-activating users should not be the default activity! Even in good conditions LDAP server may go offline temporarily, which will lead to disruption in Gitea unnecessarily. This feature needs to be modified such that activation/de-activation of users happen only on a successful LDAP call.

Alternatively, a new config option may be added for e.g local_activation = true which skips the activation deactivation field of the SQL query if the config var is set, and allow the Gitea administrator to activate or de-activate all users(local+LDAP) in Gitea admin panel.

Why am I not okay with the hack?
The hack is to supply UPDATE_EXISTING = false for LDAP sync. I have users who changed their passwords in FreeIPA, and Gitea will not take the new password. As an admin, I do not have the ability to sync this owner's LDAP data alone. I end up re-enabling LDAP sync and resort to manually activate all users after that 👎 only for the same to happen the next time a user changes their password.

Happy to provide any information from my installation. Desperately looking for help.
...

Screenshots

[jorgytim]

I see the exact same issue, which is making this unusable for my development team. We have our Gitea instance using Active Directory as our LDAP server, but the exact same thing occurs whenever a directory sync is performed, all existing users lose their activated status. The only fix is to go in and manually edit every account to set them as activated.

We absolutely need to leave existing accounts activated whenever an LDAP sync is performed, it's almost like the sync is overwriting the local user account info entirely, rather than just merging changes.

[lafriks]

Problem is that no one from developers are able to reproduce issue, if there is no clear ways to reproduce that it is hard to fix it also. In company I work for we use microsoft AD and had no such problem ever. I created that functionality so most probably that is my bug but I can't really fix what I have not seen :/

[jorgytim]

I completely understand that a developer may not be able to reproduce this, but with multiple issues being reported, doesn't it at least warrant a code review to see what the ldap synchronization is doing when it creates local user accounts. Of course we all understand we have access to the source code to review this ourselves, but we are just asking for someone to at least give it a review with this concern in mind, as it would be much faster for an existing developer to figure out than the spin up time it would be for us in the community to figure out what is going on.

[aravindhsampath]

It is reproducible with FreeIPA as an auth source(which Gitea has guidance about in its documentation) in the sense that I tried different versions of Gitea in different servers with same FreeIPA. I can understand that it is harder for a dev to fix something they don't even know where is broken. But, I and several others who created the issues above refer to the same problem that LDAP sync is doing something that it should not be doing in the first place - deactivating accounts without formal confirmation that those accounts were de-activated by an admin.

So, IMHO this should be categorised as a logical bug, and solution can be to either 1. ignore the activation/de-activation field altogether from LDAP sync and tell the Gitea admin that it is their responsibility to use the Gitea admin panel to do so, or 2. have a config parameter "local_activation" as I mentioned in the orig. post that prevents this behaviour. or 3. have the Gitea LDAP sync code de-activate accounts if and only if it can see that the account was de-activated in LDAP source and not just because an LDAP query failed or because the user supplied a "Username attribute" that is not aligned with the LDAP data.

[davidsvantesson]

@aravindhsampath I continue discussion in this issue

If receiving an empty list of users from LDAP, they will still be deactivated.

I dont understand this logic. If Gitea receives an empty list from LDAP how can it assume that ALL users are to be de-activated?
Shouldn't Gitea de-activate users ONLY if it is certain that LDAP says that they are infact de-activated? In my mid, an empty list from LDAP should lead to Gitea doing nothing

First: If you manage to make a successful LDAP query, why is the list empty? That sound as a fault in the LDAP service/server, and should rather be an issue towards that than Gitea!? (It could of course also be a "valid" error that Gitea doesn't detect, but an empty list can't be a fault in itself.)
I'm newbie to LDAP, but what I understand there is no standardized way to know if an account was deactivated. But if a user is not longer in the list from the LDAP query, that should normally mean the user shall not have access any longer.

Anyhow, maybe this could be possible features to add to Gitea to solve this:

• Add a setting making it optional to deactivate users that have been removed in the LDAP query. This can also be a security issue, so it should be default off
• Allowing to deactivate users based on another LDAP query, or possibly an attribute. (in addition to first point)

I looked into this because I had some problems with LDAP. But in my case the problem was we had two LDAP sources, and Gitea doesn't automatically move users from one to the other. So the user has to be moved manually to the other LDAP source. I know this is not your issue, but just wanted to mention in case someone else having that issue.

[aravindhsampath]

@davidsvantesson Thanks for taking the time to explain the reasoning behind your work and #7960 .

On a successful query, why is the list empty?
I'm not an LDAP expert either, but I have a case in hand where LDAP connection seems successful (since users totally new to Gitea are able to login because their creds are supplied by LDAP source), but everytime LDAP sync runs, ALL users are de-activated. So, Gitea is possibly receiving an empty list or a malformed list from LDAP source and decides to annoy the Gitea admin - me :-|
So, it is evidently possible to have a working LDAP source but receive a bad response leading to this behavior.

Another corner case is LDAP server going down temporarily(which is more common than not). Gitea cannot assume that all users must be locked out because of this.

Atleast in FreeIPA (my LDAP source), there is a field for activation/de-activation status of an account. Perhaps Gitea could use such a field to justifiably disable an account - or else under a case of lacking evidence of de-activation, relying on Gitea admin would be wise.

I dont know how I can make Gitea write out the results of this LDAP query in the log so that we all can get some data to see. I tried putting Gitea in "dev" mode, which did not do anything to the logs. Is there are log level I can set to get such info? do you know?

I agree that, if not changing the default behaviour, there must be a config option to turn off this "LDAP based de-activation" feature so that users like me can continue to use Gitea for all its awesomeness!

[lafriks]

Can you provide your ldap auth source settings?

[aravindhsampath]

[aravindhsampath]

I tried various options for "Username Attribute" field, all resulting in the same behaviour of de-activation. I tried uid(which I believe is correct according to FreeIPA), and several other options listed in the listed issues.

Going to sleep now as it is late where I am. I will update more info as possible after 10 hours.

[guillep2k]

@aravindhsampath I suggest you try Gitea again when #7960 is released (I'm guessing 1.10.0 or even 1.9.3). From what you describe, it seems that the list was empty because Gitea was not detecting the error that came with it (e.g. a temporary connection problem). I have the feeling that with this fix your problem will be gone.

[lafriks]

Username attribute should be uid in your case

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.