AD users &#34;deactivated&#34; after the &#34;branch pruning&#34; process runs since v1.7.3 #3003

@lafriks commented on GitHub (Mar 4, 2019):

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

@lafriks commented on GitHub (Mar 4, 2019): You can enable more verbose logging and check gitea.log for ldap errors

GiteaMirror commented

@titou10titou10 commented on GitHub (Mar 6, 2019):

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

@titou10titou10 commented on GitHub (Mar 6, 2019): 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..

GiteaMirror commented

@nuclearbiscoff commented on GitHub (Mar 6, 2019):

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.

@nuclearbiscoff commented on GitHub (Mar 6, 2019): 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.

GiteaMirror commented

@titou10titou10 commented on GitHub (Mar 6, 2019):

@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 on GitHub (Mar 6, 2019): @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

GiteaMirror commented

@titou10titou10 commented on GitHub (Mar 7, 2019):

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

@titou10titou10 commented on GitHub (Mar 7, 2019): 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](https://github.com/go-gitea/gitea/files/2941205/gitea_6241.txt)

GiteaMirror commented

@lafriks commented on GitHub (Mar 10, 2019):

Can you also provide info from gitea.log?

@lafriks commented on GitHub (Mar 10, 2019): Can you also provide info from gitea.log?

GiteaMirror commented

@titou10titou10 commented on GitHub (Mar 11, 2019):

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

@titou10titou10 commented on GitHub (Mar 11, 2019): The`gitea.log`file corresponding to the suspicious part of the`xorm.log`file. [gitea_log_6241.txt](https://github.com/go-gitea/gitea/files/2951944/gitea_log_6241.txt)

GiteaMirror commented

@titou10titou10 commented on GitHub (Mar 14, 2019):

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")

@titou10titou10 commented on GitHub (Mar 14, 2019): It happend again. This time with DEBUG=TRACE. In the meantime we upgraded to v1.7.4 [xorm_174_6241.log.txt](https://github.com/go-gitea/gitea/files/2966651/xorm_174_6241.log.txt) [gitea_174_6241.log.txt](https://github.com/go-gitea/gitea/files/2966652/gitea_174_6241.log.txt) Ine the log, the filter `(sAMAccountName=*) with base OU=XXXXXXXX,OU=XXXXXXXX,OU=XXXXXXXX,DC=XXXXXXXX,DC=XXXXXXXX,DC=XXXXXXXX`is correct and return (at least) the 3 users defined in gitea that are regularly deactivated (sensitive data have been replaced by "XXXXXXXX")

GiteaMirror commented

@je-s commented on GitHub (Apr 4, 2019):

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.

@je-s commented on GitHub (Apr 4, 2019): 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](https://github.com/go-gitea/gitea/blob/704da08fdc6bae6fdd6bf1b892ebe12afeef5eca/models/user.go#L1716 ).

GiteaMirror commented

@stale[bot] commented on GitHub (Jun 3, 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 (Jun 3, 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

@stale[bot] commented on GitHub (Jun 17, 2019):

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

@stale[bot] commented on GitHub (Jun 17, 2019): This issue has been automatically closed because of inactivity. You can re-open it if needed.

GiteaMirror commented

@daveh86 commented on GitHub (Jun 26, 2019):

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 on GitHub (Jun 26, 2019): 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

GiteaMirror commented

@daveh86 commented on GitHub (Jun 26, 2019):

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

@daveh86 commented on GitHub (Jun 26, 2019): 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).

GiteaMirror commented

@zeripath commented on GitHub (Jun 26, 2019):

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

@zeripath commented on GitHub (Jun 26, 2019): Ugh. Do you think we should add an option to allow for a case insensitive match of the LDAP attribute?

GiteaMirror commented

@je-s commented on GitHub (Jun 28, 2019):

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.

@je-s commented on GitHub (Jun 28, 2019): 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.

GiteaMirror commented

@Mazwak commented on GitHub (Nov 30, 2020):

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

@Mazwak commented on GitHub (Nov 30, 2020): I had exactly this issue. Case was correct on sAMAccountName in the query, but incorrect in username.

GiteaMirror commented