LDAP user synchronization timeout disables all users

[leepfrog-ger]

• Gitea version (or commit ref): 1.4.2
• Git version: not relevant
• Operating system: Windows
• 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:

2018/07/08 16:39:05 [T] Doing: SyncExternalUsers
2018/07/08 16:39:06 [T] Doing: SyncExternalUsers[TLD.de LDAP]
2018/07/08 16:39:06 [T] Dialing LDAP with security protocol (1) without verifying: true
2018/07/08 16:39:06 [T] Bound as BindDN CN=svc_gitea1_ldap,OU=[REDACTED],DC=de
2018/07/08 16:39:06 [T] Fetching attributes 'sAMAccountName', 'givenName', 'sn', 'mail' with filter (&(objectClass=person)(memberof:1.2.840.113556.1.4.1941:=CN=sec_gitea_bc-git_users[REDAACTED]DC=de)(sAMAccountname=*)) and base dc=TLD,dc=de
2018/07/08 16:41:06 [...gitea/models/user.go:1388 SyncExternalUsers()] [E] LDAP Search failed unexpectedly! (LDAP Result Code 3 "Time Limit Exceeded": )
2018/07/08 16:41:06 [T] SyncExternalUsers[TLD.de LDAP]: Deactivating user abc
2018/07/08 16:41:06 [T] SyncExternalUsers[TLD.de LDAP]: Deactivating user def
2018/07/08 16:41:06 [T] SyncExternalUsers[TLD.de LDAP]: Deactivating user ghi

Description

I've notcied that if the LDAP user sync runs into a timeout all users tied to that authentication source will be disabled.
While I understand the reasoning from a security perspective it might be sensible to at least do one or two retries because this otherwise might bring down the entire system until this is noticed.
The issue making this worse is that in case users are decativated the behaviour is not consistent. Assume the following:

1. An LDAP query for the scheduled user synchronization runs into a timeout because the LDAP server that was chosen for the sync is temporarily unavailable (e.g. rebooting due to maintenance).
2. All users are subsequently disabled
3. The users can however continue to use Gitea just fine for the most part because when they manually log in the login their account status will be "live" checked against the LDAP during login. This check will return that the account is existing, enabled and the password is correct, meaning they can login and fully use the system. But the "activated" flag of the account remains "false"!
4. When pushing/pulling via HTTPS this works fine as this again triggers a LDAP lookup which will allow the action to happen
5. Pushing/Pulling via SSH does not work because this does not seem to trigger an LDAP lookup but will simply allow or deny based on the "activated" flag of the account

Suggestion

As also in a perfectly working environment there can be a temporary unavailability of the LDAP server that was chosen by Gitea to perform user sync temporary failurs (like Timeout or unable to connect) should not lead to immediate user deactivation but the sync should be retried 2 or 3 times, possibly with a delay of a few minutes

[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.

[huapox]

same problem! help wanted.