search

go-gitea / gitea

Git with a cup of tea! Painless self-hosted all-in-one software development service, including Git hosting, code review, team collaboration, package registry and CI/CD
https://gitea.com
MIT License
44.55k stars 5.44k forks source link

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

Closed titou10titou10 closed 1 year ago

titou10titou10 commented 5 years ago

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 commented 5 years ago

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

titou10titou10 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

Can you also provide info from gitea.log?

titou10titou10 commented 5 years ago

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

titou10titou10 commented 5 years ago

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 commented 5 years ago

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[bot] commented 5 years ago

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 5 years ago

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

daveh86 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

je-s commented 5 years ago

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 commented 3 years ago

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

lunny commented 1 year ago

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