Gitea deactivates user every day

[ghtyrant]

• Gitea version (or commit ref): 1.4.1 built with: bindata, sqlite
• Git version: 2.11.0
• Operating system: Debian 9.4
• 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:

Description

Every day at 10:15, gitea deactivates my user. I have to navigate to the web interface (where I'm still logged in and have administrative permissions) and manually reactivate myself, otherwise I can't push to repositories. All I see in log files are the following queries being run in xorm.log:

root@git:/var/lib/gitea/log# grep -rn "UPDATE \"user"
xorm.log.2018-05-23.001:69:2018/05/22 10:15:56 [I] [SQL] UPDATE "user" SET "is_active" = $1, "updated_unix" = $2 WHERE "id"=$3 []interface {}{false, 1526976956, 3}
xorm.log.2018-05-28.001:111:2018/05/27 10:15:56 [I] [SQL] UPDATE "user" SET "is_active" = $1, "updated_unix" = $2 WHERE "id"=$3 []interface {}{false, 1527408956, 3}
xorm.log.2018-05-22.001:82:2018/05/21 10:15:56 [I] [SQL] UPDATE "user" SET "is_active" = $1, "updated_unix" = $2 WHERE "id"=$3 []interface {}{false, 1526890556, 3}
xorm.log.2018-05-27.001:69:2018/05/26 10:15:56 [I] [SQL] UPDATE "user" SET "is_active" = $1, "updated_unix" = $2 WHERE "id"=$3 []interface {}{false, 1527322556, 3}
xorm.log.2018-05-26.001:73:2018/05/25 10:15:56 [I] [SQL] UPDATE "user" SET "is_active" = $1, "updated_unix" = $2 WHERE "id"=$3 []interface {}{false, 1527236156, 3}
xorm.log.2018-05-25.001:69:2018/05/24 10:15:56 [I] [SQL] UPDATE "user" SET "is_active" = $1, "updated_unix" = $2 WHERE "id"=$3 []interface {}{false, 1527149756, 3}
xorm.log.2018-05-24.001:69:2018/05/23 10:15:56 [I] [SQL] UPDATE "user" SET "is_active" = $1, "updated_unix" = $2 WHERE "id"=$3 []interface {}{false, 1527063356, 3}

The other log files contain nothing that would suggest what is going on. I'm using LDAP authentication (Bind DN).

[harryxu]

I have same issue.

And my solution is set UPDATE_EXISTING = false in cron.sync_external_users

/home/git/gitea/custom/conf/app.ini

; Synchronize external user data (only LDAP user synchronization is supported)
[cron.sync_external_users]
; Synchronize external user data when starting server (default false)
RUN_AT_START = false
SCHEDULE = @every 24h
UPDATE_EXISTING = false

[ghtyrant]

Thanks for this workaround! edit: Just confirming that it worked for me, thanks again.

I will leave this issue open as I believe this to be something that needs fixing.

[yamss]

Hello harryxu, im using docker to host my gitea... how can I change this setting? All my accounts are getting deactivated every day.

[lafriks]

Please specify your LDAP source configuration & LDAP server software being used

[yamss]

• Gitea version (or commit ref): Docker 1.4.2
• Git version: n/a
• Operating system: CentOS 7
• Database (use [x]):
• PostgreSQL
• MySQL
• MSSQL
• SQLite

Using MS Active Directory:

User Filter= (sAMAccountName=%s)
Admin Filter= (&(objectCategory=Person)(memberOf=CN=GU_TSC,OU=Grupos,DC=lc,DC=gc,DC=local))

[harryxu]

@yamss https://docs.gitea.io/en-us/install-with-docker/#customization

May be you can mount your custom folder to docker container?

[ghtyrant]

@lafriks

Ah, while checking my configuration I think I found the culprit: I've skipped the Admin Filter.
Never mind, it's been a long day for me.

LDAP (via BindDN), Unencrypted.
Bind DN: cn=gitea,ou=users,dc=mydomain,dc=tld
Search Base: ou=users,dc=mydomain,dc=tld
User Filter: (&(cn=%s)(memberOf=cn=git,ou=groups,dc=mydomain,dc=tld))

I'm using OpenLDAP (slapd) 2.4.44+dfsg-5+deb9u1

[ghtyrant]

Looks like I got it to work by setting "cn" (username, in my case) as value of "Username attribute" - it was empty before.

Logs before this change:

2018/06/07 21:00:03 [T] Doing: SyncExternalUsers
2018/06/07 21:00:03 [T] Doing: SyncExternalUsers[LDAP]
2018/06/07 21:00:03 [T] Dialing LDAP with security protocol (0) without verifying: false
2018/06/07 21:00:03 [T] Bound as BindDN cn=gitea,ou=users,dc=mydomain,dc=tld
2018/06/07 21:00:03 [T] Fetching attributes '', '', '', 'mail' with filter (&(cn=*)(memberOf=cn=git,ou=groups,dc=mydomain,dc=tld)) and base ou=users,dc=mydomain,dc=tld
2018/06/07 21:00:03 [T] Checking admin with filter (&(memberOf=cn=git,ou=groups,dc=mydomain,dc=tld)(memberOf=cn=admin,ou=groups,dc=mydomain,dc=tld)) and base cn=myuser,ou=users,dc=mydomain,dc=tld
2018/06/07 21:00:03 [T] SyncExternalUsers[LDAP]: Deactivating user myuser

Logs after this change:

2018/06/07 21:02:03 [T] Doing: SyncExternalUsers
2018/06/07 21:02:03 [T] Doing: SyncExternalUsers[LDAP]
2018/06/07 21:02:03 [T] Dialing LDAP with security protocol (0) without verifying: false
2018/06/07 21:02:03 [T] Bound as BindDN cn=gitea,ou=users,dc=mydomain,dc=tld
2018/06/07 21:02:03 [T] Fetching attributes 'cn', 'givenName', '', 'mail' with filter (&(cn=*)(memberOf=cn=git,ou=groups,dc=mydomain,dc=tld)) and base ou=users,dc=mydomain,dc=tld
2018/06/07 21:02:03 [T] Checking admin with filter (&(memberOf=cn=git,ou=groups,dc=mydomain,dc=tld)(memberOf=cn=admin,ou=groups,dc=mydomain,dc=tld)) and base cn=myuser,ou=users,dc=mydomain,dc=tld
2018/06/07 21:02:03 [T] SyncExternalUsers[LDAP]: Updating user myuser

[yamss]

@harryxu added the parameters for the app.ini file in /var/lib/docker/volumes/gitea_data/_data/gitea/conf and restarted the docker, but that didn't work.

Setting 'cn' in "Username attribute" as described by @ghtyrant also didn't work for me.

[henryk]

@ghtyrant I had the same problem (well, different parameter names and values, OpenLDAP) and indeed, setting the "Username attribute" field fixed the problem. So, I'll call this a documentation problem. The documentation makes it seem that it's safe to leave the username attribute field empty, because it would just do the right thing then.

[daviian]

Related to: #4689, #3815, #4402 and #4433

[liquidat]

@ghtyrant That fixed it for me! Thanks so much!
For future reference: the proper attribute seems to depend on your actual configuration. In my case I had to enter "uid".

[LarrysGIT]

Looks like I got it to work by setting "cn" (username, in my case) as value of "Username attribute" - it was empty before.

Logs before this change:

2018/06/07 21:00:03 [T] Doing: SyncExternalUsers
2018/06/07 21:00:03 [T] Doing: SyncExternalUsers[LDAP]
2018/06/07 21:00:03 [T] Dialing LDAP with security protocol (0) without verifying: false
2018/06/07 21:00:03 [T] Bound as BindDN cn=gitea,ou=users,dc=mydomain,dc=tld
2018/06/07 21:00:03 [T] Fetching attributes '', '', '', 'mail' with filter (&(cn=*)(memberOf=cn=git,ou=groups,dc=mydomain,dc=tld)) and base ou=users,dc=mydomain,dc=tld
2018/06/07 21:00:03 [T] Checking admin with filter (&(memberOf=cn=git,ou=groups,dc=mydomain,dc=tld)(memberOf=cn=admin,ou=groups,dc=mydomain,dc=tld)) and base cn=myuser,ou=users,dc=mydomain,dc=tld
2018/06/07 21:00:03 [T] SyncExternalUsers[LDAP]: Deactivating user myuser

Logs after this change:

2018/06/07 21:02:03 [T] Doing: SyncExternalUsers
2018/06/07 21:02:03 [T] Doing: SyncExternalUsers[LDAP]
2018/06/07 21:02:03 [T] Dialing LDAP with security protocol (0) without verifying: false
2018/06/07 21:02:03 [T] Bound as BindDN cn=gitea,ou=users,dc=mydomain,dc=tld
2018/06/07 21:02:03 [T] Fetching attributes 'cn', 'givenName', '', 'mail' with filter (&(cn=*)(memberOf=cn=git,ou=groups,dc=mydomain,dc=tld)) and base ou=users,dc=mydomain,dc=tld
2018/06/07 21:02:03 [T] Checking admin with filter (&(memberOf=cn=git,ou=groups,dc=mydomain,dc=tld)(memberOf=cn=admin,ou=groups,dc=mydomain,dc=tld)) and base cn=myuser,ou=users,dc=mydomain,dc=tld
2018/06/07 21:02:03 [T] SyncExternalUsers[LDAP]: Updating user myuser

This is the right answer, change "Username Attribute" to "cn" makes it working, but but but, there is new trouble coming later because gitea seems to like "sAMAccountName" equals "cn", if they 2 attribute values not equal each other, there is trouble.

update,

my final configs following, start working now
case sensitive, be careful

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