AD users "deactivated" after the "branch pruning" process runs since v1.7.3

[titou10titou10]

• Gitea version (or commit ref): 1.7.3
• Git version: 1.8.3.1
• Operating system: RHEL v7.5
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • [] Yes (provide example URL)
  • No
  • Not relevant

Description

Our Gitea is configured to authenticate user with Microsoft AD
Since the upgrade to v1.7.3 from v1.7.2, all AD users are set to "inactive" after "some" time.
Everything was working fine with v1.7.2
The "some" time is maximum a few hours. We can't figure a pattern or an exact time

We have to use a "local" gitea admin user to "reactive" them:

    Site Administration > User Account > "Edit" on User > Check "User Account is activated"

[UPDATED 2019-03-07]
After enabling more verbose logging, it apperas that this happens after the "branch pruning" process runs and not after an "undetermined amount of time"

[lafriks]

You can enable more verbose logging and check gitea.log for ldap errors

[titou10titou10]

I set the log level to DEBUG..unfortunately the problem didn't surfaced since then. maybe the restart of gitea get rid of the problem? I'll wait a few days and eventually close this ticket if it does not pop up again..

[jakeshaffer]

I had this same issue, but they were all deactivated because the Gitea server started before my LDAP server finished initialization. A quick restart of Gitea fixed it for me.

[titou10titou10]

@jakeshaffer we are not in this case. Everything was fine after upgrade to 1.7.3. Then at some point all AD users became disabled. We manually reactivated all of them. The next day it happened again. We reactivated them and a few hours later, again.. etc. Our AD server is the corporate server and we are certain it was up all the time, and this did not appera on Gitea startup
Again, it did not appear since I restarted Gitea. If the problem does surface again till tomorrow, I'll close this issue

[titou10titou10]

It happend again yesterday...In the logs there are some lines that may be related to the problem:

UPDATE "user" SET "is_active" = $1, "updated_unix" = $2 WHERE "id"=$3 []interface {}{false, 1551906760, 4}

This appear just after the following:

DELETE FROM "deleted_branch" WHERE (deleted_unix < $1) []interface {}{1551820360}

Could it be related to the branch pruning process?

I attached the relevant part of the logs (I changed the name of the repository to "xxxx") : gitea_6241.txt

[lafriks]

Can you also provide info from gitea.log?

[titou10titou10]

Thegitea.logfile corresponding to the suspicious part of thexorm.logfile.
gitea_log_6241.txt

[titou10titou10]

It happend again. This time with DEBUG=TRACE. In the meantime we upgraded to v1.7.4
xorm_174_6241.log.txt
gitea_174_6241.log.txt
Ine the log, the filter
(sAMAccountName=*) with base OU=XXXXXXXX,OU=XXXXXXXX,OU=XXXXXXXX,DC=XXXXXXXX,DC=XXXXXXXX,DC=XXXXXXXXis correct and return (at least) the 3 users defined in gitea that are regularly deactivated
(sensitive data have been replaced by "XXXXXXXX")

[je-s]

I can confirm this problem using Samba as Gitea's AD/LDAP provider.
Docker-Image version 1.6 worked fine, but after upgrading to 1.7 this problem started to occur on a daily basis.

After some testing I've found out that the "Synchronize external users"-Cronjob seems to deactivate the users; when I'm executing it manually it's also producing the same result, and all AD-Users will be deactivated immediately.

PS: I guess the problem is that for some reason Gitea can't find the Users in LDAP anymore, which is why they're being deactivated. Have a look here.

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

[stale]

This issue has been automatically closed because of inactivity. You can re-open it if needed.