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.

[daveh86]

Confirmed that this issue as described by je-s still exists when running under 1.8.3.

My reproducer is;
Create AD connection, with an Admin Group.
Login as any user to create its account
Run the "Synchronize external user data" job.
Users who could previously auth via LDAP will be removed

[daveh86]

Okay. Found the cause. Looks like my version of the issue was due to the use of a lowercase entry in the "Username Attribute" field.

Specifically I had "samaccountname" rather than "sAMAccountName". This meant that the case-insensitive match within LDAP would find users initially when searching the LDAP tree, but would not correctly match that existing user on a subsequent search as it could not find the correct "Username" field.

So, the solution here for anyone reading this in the future is to ensure that your "Username Attribute" field is EXACTLY "sAMAccountName" with no trailing space (that got me in testing too).

[zeripath]

Ugh. Do you think we should add an option to allow for a case insensitive match of the LDAP attribute?

[je-s]

In my case this is not a problem coming from differing capitalization of the filters. I've checked this multiple times.
I still couldn't find a solution for this problem though.

[Mazwak]

I had exactly this issue.
Case was correct on sAMAccountName in the query, but incorrect in username.

[lunny]

I think #25278 has resolved the problem. Please feel free to reopen it if your problem hasn't been resolved by #25278