LDAP user synchronization timeout disables all users #2029

New Issue

GiteaMirror · 2025-11-02T04:21:41-06:00

GiteaMirror commented

2025-11-02 04:21:41 -06:00

Originally created by @leepfrog-ger on GitHub (Jul 9, 2018).

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:

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).
All users are subsequently disabled
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"!
When pushing/pulling via HTTPS this works fine as this again triggers a LDAP lookup which will allow the action to happen
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

Originally created by @leepfrog-ger on GitHub (Jul 9, 2018). - Gitea version (or commit ref): 1.4.2 - Git version: not relevant - Operating system: Windows - Database (use `[x]`): - [ ] PostgreSQL - [ ] MySQL - [x] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] 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

GiteaMirror added the issue/confirmed topic/authentication type/bug labels 2025-11-02 04:21:41 -06:00

GiteaMirror commented

2025-11-02 04:21:42 -06:00

@stale[bot] commented on GitHub (Jan 19, 2019):

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.

@stale[bot] commented on GitHub (Jan 19, 2019): 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.

GiteaMirror commented

2025-11-02 04:21:42 -06:00

@huapox commented on GitHub (Jan 22, 2019):

same problem! help wanted.

@huapox commented on GitHub (Jan 22, 2019): **same problem! help wanted.**

GiteaMirror referenced this issue

2025-11-02 12:04:17 -06:00

[PR #2030] [MERGED] Display config file path on admin panel #16188

Sign in to join this conversation.