SyncExternalUsers is deactivating ldap users #1708

@lafriks commented on GitHub (Apr 19, 2018):

It should be (&(objectclass=user)(samaccountname=%s)(memberof=cn=vcs_users,ou=groups,dc=example,dc=com))

@lafriks commented on GitHub (Apr 19, 2018): It should be `(&(objectclass=user)(samaccountname=%s)(memberof=cn=vcs_users,ou=groups,dc=example,dc=com))`

GiteaMirror commented

https://github.com/go-gitea/gitea/blob/master/modules/auth/ldap/ldap.go#L293 ?

@junkb commented on GitHub (Apr 19, 2018):

no asterisk in the actual filter, no [see screen shot] - that's only appearing in the log output

i don't know go really at all, but could that asterisk be coming from

it looks like userFilter might be getting explicitly set with a literal '*'?

@junkb commented on GitHub (Apr 19, 2018): no asterisk in the actual filter, no [see screen shot] - that's only appearing in the log output i don't know go really at all, but could that asterisk be coming from https://github.com/go-gitea/gitea/blob/master/modules/auth/ldap/ldap.go#L293 ? it looks like userFilter might be getting explicitly set with a literal '*'? ![filters](https://user-images.githubusercontent.com/7424193/39021107-702ce26e-43fd-11e8-8f79-22dc6f3ff94b.png)

GiteaMirror commented

@junkb commented on GitHub (Apr 28, 2018):

what else can i do to troubleshoot this further?

@junkb commented on GitHub (Apr 28, 2018): what else can i do to troubleshoot this further?

GiteaMirror commented

@s-hamann commented on GitHub (May 4, 2018):

I experienced similar behaviour until I set the username attribute to sAMAccountName. Does not seem to be as optional as the docs indicate (for AD environments, at least).

@s-hamann commented on GitHub (May 4, 2018): I experienced similar behaviour until I set the username attribute to `sAMAccountName`. Does not seem to be as optional as the docs indicate (for AD environments, at least).

GiteaMirror commented

@hexathos commented on GitHub (May 12, 2018):

setting username to sAMAaccountName didn't help... my gitea installation with active directory backend is still deactivating users... same goes for the instance with openldap backend... ;c(

@hexathos commented on GitHub (May 12, 2018): setting username to sAMAaccountName didn't help... my gitea installation with active directory backend is still deactivating users... same goes for the instance with openldap backend... ;c(

GiteaMirror commented

@lafriks commented on GitHub (May 13, 2018):

I can't seem to reproduce that

@lafriks commented on GitHub (May 13, 2018): I can't seem to reproduce that

GiteaMirror commented

@hexathos commented on GitHub (May 13, 2018):

I am not that fine with go... but
524885dd65 (diff-5b36fdb03ccb6b7625fd57a6c675051dR309)

returned two bools (which i assume was isadmin and isactive) while search result returns just isadmin

@hexathos commented on GitHub (May 13, 2018): I am not that fine with go... but https://github.com/go-gitea/gitea/commit/524885dd6502570dddf5c83f171ee74890dba5c4#diff-5b36fdb03ccb6b7625fd57a6c675051dR309 returned two bools (which i assume was isadmin and isactive) while search result returns just isadmin

GiteaMirror commented

@liquidat commented on GitHub (May 28, 2018):

I can verify the issue - upon each run of SyncExternalUsers the LDAP user is deactivated. However I fail to reproduce the log message mentioned above, even in Debug mode!

My user filter is much simpler: (&(objectclass=person)(uid=%s)) It is running against a freeipa LDAP server.

Gitea version (or commit ref): e6b0a2d
Git version: git version 2.15.0
Operating system: docker container gitea/gitea:latest running on CentOS
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite
Can you reproduce the bug at https://try.gitea.io:
- Yes (provide example URL)
- No
- Not relevant

@liquidat commented on GitHub (May 28, 2018): I can verify the issue - upon each run of `SyncExternalUsers` the LDAP user is deactivated. However I fail to reproduce the log message mentioned above, even in Debug mode! My user filter is much simpler: `(&(objectclass=person)(uid=%s))` It is running against a freeipa LDAP server. - Gitea version (or commit ref): e6b0a2d - Git version: git version 2.15.0 - Operating system: docker container `gitea/gitea:latest` running on CentOS - Database (use `[x]`): - [x] PostgreSQL - [ ] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant

GiteaMirror commented

@okimiko commented on GitHub (May 31, 2018):

I can verfiy the issue, too. I reverted to an older image.

Gitea version (or commit ref): docker -> 6015731584f2
Git version: n/a
Operating system: n/a docker
Database (use [x]):
- PostgreSQL
- MySQL
- MSSQL
- SQLite

@okimiko commented on GitHub (May 31, 2018): I can verfiy the issue, too. I reverted to an older image. - Gitea version (or commit ref): docker -> 6015731584f2 - Git version: n/a - Operating system: n/a docker - Database (use [x]): - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [x] SQLite

GiteaMirror commented

@sapk commented on GitHub (May 31, 2018):

We should maybe raise this issue to kind/bug tag and add to 1.5.0 release ?

@sapk commented on GitHub (May 31, 2018): We should maybe raise this issue to kind/bug tag and add to 1.5.0 release ?

GiteaMirror commented

@lafriks commented on GitHub (May 31, 2018):

I can not seem to reproduce this bug with either MS AD or OpenLDAP :(

@lafriks commented on GitHub (May 31, 2018): I can not seem to reproduce this bug with either MS AD or OpenLDAP :(

GiteaMirror commented

@liquidat commented on GitHub (May 31, 2018):

@lafriks Any idea how we could further debug the problem? I am using the pre-build docker container.

Also, in https://github.com/go-gitea/gitea/issues/3815#issuecomment-382706926 you mentioned that the filter should contain samaccountname and memberof - is this a requirement? As mentioned above I use a rather simple filter, maybe that's the problem?

@liquidat commented on GitHub (May 31, 2018): @lafriks Any idea how we could further debug the problem? I am using the pre-build docker container. Also, in https://github.com/go-gitea/gitea/issues/3815#issuecomment-382706926 you mentioned that the filter should contain `samaccountname` and `memberof` - is this a requirement? As mentioned above I use a rather simple filter, maybe that's the problem?

GiteaMirror commented

@lafriks commented on GitHub (May 31, 2018):

@liquidat I'm testing OpenLDAP with same configuration as in tests: https://github.com/go-gitea/gitea/blob/master/integrations/auth_ldap_test.go#L99

@lafriks commented on GitHub (May 31, 2018): @liquidat I'm testing OpenLDAP with same configuration as in tests: https://github.com/go-gitea/gitea/blob/master/integrations/auth_ldap_test.go#L99

GiteaMirror commented

2025-11-02 04:10:27 -06:00

@liquidat commented on GitHub (Jun 7, 2018):

I realized that even if I add an admin filter which should match my user, the user is not an admin afterwards.
Maybe the ldap sync for some reason does not manage find the users? Is there any way to get more debug output of the sync in the current container build, like how many users were found?

@liquidat commented on GitHub (Jun 7, 2018): I realized that even if I add an admin filter which should match my user, the user is not an admin afterwards. Maybe the ldap sync for some reason does not manage find the users? Is there any way to get more debug output of the sync in the current container build, like how many users were found?

GiteaMirror commented

@yamss commented on GitHub (Jun 7, 2018):

I'm having the same issue. This behavior started maybe a week ago... everything was fine before. I updated my docker image one week before this started to happen.

@yamss commented on GitHub (Jun 7, 2018): I'm having the same issue. This behavior started maybe a week ago... everything was fine before. I updated my docker image one week before this started to happen.

GiteaMirror commented

2025-11-02 04:10:27 -06:00

@lafriks commented on GitHub (Jun 7, 2018):

Can you please give your LDAP source configuration and LDAP server software being used.

@lafriks commented on GitHub (Jun 7, 2018): Can you please give your LDAP source configuration and LDAP server software being used.

GiteaMirror commented

2025-11-02 04:10:27 -06:00

@yamss commented on GitHub (Jun 7, 2018):

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

@yamss commented on GitHub (Jun 7, 2018): - Gitea version (or commit ref): Docker 1.4.2 - Git version: n/a - Operating system: CentOS 7 - Database (use [x]): - [ ] PostgreSQL - [x] 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))

GiteaMirror commented

@liquidat commented on GitHub (Jun 11, 2018):

@lafriks Was this a request to provide feedback meant that everyone with this bug should answer, or only @yamss ?

@liquidat commented on GitHub (Jun 11, 2018): @lafriks Was this a request to provide feedback meant that everyone with this bug should answer, or only @yamss ?

GiteaMirror commented

@lafriks commented on GitHub (Jun 12, 2018):

@liquidat everyone can provide, the more cases are provided the better chances to find where is the problem

@lafriks commented on GitHub (Jun 12, 2018): @liquidat everyone can provide, the more cases are provided the better chances to find where is the problem

GiteaMirror commented

@liquidat commented on GitHub (Jun 13, 2018):

LDAP Source configuration:

Authentication Type: LDAP (via BindDN)
Authentication Name: IDM
Security Protocol: Unencrypted
Host: idm-c
Port: 389
Bind DN: uid=system,cn=sysaccounts,cn=etc,dc=bayz,dc=de
Bind Password: (encrypted)
User Search Base: cn=users,cn=accounts,dc=bayz,dc=de
User Filter: (&(objectClass=inetOrgPerson)(memberOf=cn=users,cn=accounts,dc=bayz,dc=de)(uid=%s))
Admin Filter: (&(objectclass=person)(uid=%s))
Username Attribute: rwo
Email Attribute: mail
Enable User Synchronization
This Authentication Source is Activated

LDAP Server software:

freeipa-server-4.4.4-4.fc26.x86_64

@liquidat commented on GitHub (Jun 13, 2018): LDAP Source configuration: - Authentication Type: LDAP (via BindDN) - Authentication Name: `IDM` - Security Protocol: Unencrypted - Host: `idm-c` - Port: `389` - Bind DN: `uid=system,cn=sysaccounts,cn=etc,dc=bayz,dc=de` - Bind Password: (encrypted) - User Search Base: `cn=users,cn=accounts,dc=bayz,dc=de` - User Filter: `(&(objectClass=inetOrgPerson)(memberOf=cn=users,cn=accounts,dc=bayz,dc=de)(uid=%s))` - Admin Filter: `(&(objectclass=person)(uid=%s))` - Username Attribute: `rwo` - Email Attribute: `mail` - [x] Enable User Synchronization - [x] This Authentication Source is Activated LDAP Server software: - freeipa-server-4.4.4-4.fc26.x86_64

GiteaMirror commented

@junkb commented on GitHub (Jun 14, 2018):

i've just experienced some additional developments wrt to this issue. today, for the first time, i performed a git operation using ssh rather than http, and observed the following symptom:

>git clone --verbose 'vcs:example/foo.git'
Cloning into 'foo'...
Gitea: Your account is not active or has been disabled by Administrator
User jdoe is disabled and have no access to repository example/foo.git
fatal: Could not read from remote repository.

if i activate the user manually [e.g. via the admin panel], the symptom is gone and i'm able to perform operations successfully. after the scheduled task runs and the user gets deactivated, the symptom reappears. git operations via https don't exhibit this symptom. they work even with the user inactive, in the same way i can log into the web ui, even with an inactive user.

@junkb commented on GitHub (Jun 14, 2018): i've just experienced some additional developments wrt to this issue. today, for the first time, i performed a git operation using ssh rather than http, and observed the following symptom: ``` >git clone --verbose 'vcs:example/foo.git' Cloning into 'foo'... Gitea: Your account is not active or has been disabled by Administrator User jdoe is disabled and have no access to repository example/foo.git fatal: Could not read from remote repository. ``` if i activate the user manually [e.g. via the admin panel], the symptom is gone and i'm able to perform operations successfully. after the scheduled task runs and the user gets deactivated, the symptom reappears. git operations via https don't exhibit this symptom. they work even with the user inactive, in the same way i can log into the web ui, even with an inactive user.

GiteaMirror commented

@junkb commented on GitHub (Jun 14, 2018):

here are my configuration details [i'm sorry, i've had to mask some particulars]

authentication type: ldap [via bind dn]
authentication name: example.com
security protocol: unencrypted
host: dsa1.example.com
port: 389
bind dn: vcs01-gitea@example.com
bind password: *************
user search base: ou=users,dc=example,dc=com
user filter: (&(objectclass=user)(samaccountname=%s)(memberof=cn=vcs_users,ou=security_groups,dc=example,dc=com)(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))
admin filter: (memberof=cn=vcs_admins,ou=security_groups,dc=example,dc=com)
username attribute: samaccountname
first name attribute: givenname
surname attribute: cn
email attribute: mail
fetch attributes in bind dn context
enable user synchronization
this authentication is activated

the directory server is microsoft active directory, running on windows server 2008 r2 datacenter 64 bit service pack 1

@junkb commented on GitHub (Jun 14, 2018): here are my configuration details [i'm sorry, i've had to mask some particulars] - authentication type: ldap [via bind dn] - authentication name: example.com - security protocol: unencrypted - host: dsa1.example.com - port: 389 - bind dn: vcs01-gitea@example.com - bind password: ************* - user search base: ou=users,dc=example,dc=com - user filter: (&(objectclass=user)(samaccountname=%s)(memberof=cn=vcs_users,ou=security_groups,dc=example,dc=com)(!(UserAccountControl:1.2.840.113556.1.4.803:=2))) - admin filter: (memberof=cn=vcs_admins,ou=security_groups,dc=example,dc=com) - username attribute: samaccountname - first name attribute: givenname - surname attribute: cn - email attribute: mail - [x] fetch attributes in bind dn context - [x] enable user synchronization - [x] this authentication is activated the directory server is microsoft active directory, running on windows server 2008 r2 datacenter 64 bit service pack 1

GiteaMirror commented

@armin1402 commented on GitHub (Jun 21, 2018):

We got the same issue here with OpenLDAP

Authentication Type: LDAP (via BindDN)
Authentication Name: gitea
Security Protocol: LDAPS
Host: IP (x.x.x.x)
Port: 7636
Bind DN: uid=XXXXXXXX,cn=users,dc=XXXXXX,dc=de
Bind Password: XXXXXXXXX
User Search Base: cn=users,dc=XXXXXXXX,dc=de
User Filter: (uid=%s)
Admin Filter: XXXXXXXX
Username Attribute: empty
Email Attribute: mail

Enable User Synchronization
This Authentication Source is Activated

Logfile


Jun 21 14:29:55 FQDN gitea[740]: 2018/06/21 14:29:55 [T] Bound as BindDN uid=svc_gitea,cn=users,dc=XXXXXXX,dc=de
Jun 21 14:29:55 FQDN gitea[740]: 2018/06/21 14:29:55 [T] Fetching attributes '', '', '', 'mail' with filter (uid=*) and base cn=users,dc=XXXXXX,dc=de
Jun 21 14:29:55 FQDN gitea[740]: 2018/06/21 14:29:55 [T] SyncExternalUsers[svc_gitea]: Deactivating user XXXX.XXXX
Jun 21 14:29:55 FQDN gitea[740]: 2018/06/21 14:29:55 [I] [SQL] UPDATE `user` SET `is_active` = ?, `updated_unix` = ? WHERE `id`=? []interface {}{false, 1529584195, 3}
Jun 21 14:29:55 FQDN gitea[740]: 2018/06/21 14:29:55 [T] SyncExternalUsers[svc_gitea]: Deactivating user XXXX.XXXX
Jun 21 14:29:55 FQDN gitea[740]: 2018/06/21 14:29:55 [I] [SQL] UPDATE `user` SET `is_active` = ?, `updated_unix` = ? WHERE `id`=? []interface {}{false, 1529584195, 6}
Jun 21 14:29:55 FQDN gitea[740]: 2018/06/21 14:29:55 [T] SyncExternalUsers[svc_gitea]: Deactivating user XXXX.XXXX
Jun 21 14:29:55 FQDN gitea[740]: 2018/06/21 14:29:55 [I] [SQL] UPDATE `user` SET `is_active` = ?, `updated_unix` = ? WHERE `id`=? []interface {}{false, 1529584195, 10}
Jun 21 14:29:55 FQDN gitea[740]: 2018/06/21 14:29:55 [T] SyncExternalUsers[svc_gitea]: Deactivating user XXXX.XXXX
Jun 21 14:29:55 FQDN gitea[740]: 2018/06/21 14:29:55 [I] [SQL] UPDATE `user` SET `is_active` = ?, `updated_unix` = ? WHERE `id`=? []interface {}{false, 1529584195, 12}

@armin1402 commented on GitHub (Jun 21, 2018): We got the same issue here with OpenLDAP Authentication Type: LDAP (via BindDN) Authentication Name: gitea Security Protocol: LDAPS Host: IP (x.x.x.x) Port: 7636 Bind DN: uid=XXXXXXXX,cn=users,dc=XXXXXX,dc=de Bind Password: XXXXXXXXX User Search Base: cn=users,dc=XXXXXXXX,dc=de User Filter: (uid=%s) Admin Filter: XXXXXXXX Username Attribute: empty Email Attribute: mail - [x] Enable User Synchronization - [x] This Authentication Source is Activated Logfile ``` Jun 21 14:29:55 FQDN gitea[740]: 2018/06/21 14:29:55 [T] Bound as BindDN uid=svc_gitea,cn=users,dc=XXXXXXX,dc=de Jun 21 14:29:55 FQDN gitea[740]: 2018/06/21 14:29:55 [T] Fetching attributes '', '', '', 'mail' with filter (uid=*) and base cn=users,dc=XXXXXX,dc=de Jun 21 14:29:55 FQDN gitea[740]: 2018/06/21 14:29:55 [T] SyncExternalUsers[svc_gitea]: Deactivating user XXXX.XXXX Jun 21 14:29:55 FQDN gitea[740]: 2018/06/21 14:29:55 [I] [SQL] UPDATE `user` SET `is_active` = ?, `updated_unix` = ? WHERE `id`=? []interface {}{false, 1529584195, 3} Jun 21 14:29:55 FQDN gitea[740]: 2018/06/21 14:29:55 [T] SyncExternalUsers[svc_gitea]: Deactivating user XXXX.XXXX Jun 21 14:29:55 FQDN gitea[740]: 2018/06/21 14:29:55 [I] [SQL] UPDATE `user` SET `is_active` = ?, `updated_unix` = ? WHERE `id`=? []interface {}{false, 1529584195, 6} Jun 21 14:29:55 FQDN gitea[740]: 2018/06/21 14:29:55 [T] SyncExternalUsers[svc_gitea]: Deactivating user XXXX.XXXX Jun 21 14:29:55 FQDN gitea[740]: 2018/06/21 14:29:55 [I] [SQL] UPDATE `user` SET `is_active` = ?, `updated_unix` = ? WHERE `id`=? []interface {}{false, 1529584195, 10} Jun 21 14:29:55 FQDN gitea[740]: 2018/06/21 14:29:55 [T] SyncExternalUsers[svc_gitea]: Deactivating user XXXX.XXXX Jun 21 14:29:55 FQDN gitea[740]: 2018/06/21 14:29:55 [I] [SQL] UPDATE `user` SET `is_active` = ?, `updated_unix` = ? WHERE `id`=? []interface {}{false, 1529584195, 12} ```

GiteaMirror commented

@armin1402 commented on GitHub (Jun 21, 2018):

It seems this isse comes up, if you do the following:

Install gitea
create local users
connect gitea to ldap
use existing accounts

then the userid doesnt match to id.

Maybe it would make more sense, to check in ldap the username (uid, samaccountname) instead of using an id.

@armin1402 commented on GitHub (Jun 21, 2018): It seems this isse comes up, if you do the following: - Install gitea - create local users - connect gitea to ldap - use existing accounts then the userid doesnt match to id. Maybe it would make more sense, to check in ldap the username (uid, samaccountname) instead of using an id.

GiteaMirror commented

@junkb commented on GitHub (Jun 23, 2018):

in my case, the only local account is the administrator account. there are no other local accounts.

@junkb commented on GitHub (Jun 23, 2018): in my case, the only local account is the administrator account. there are no other local accounts.

GiteaMirror commented

@xoxys commented on GitHub (Aug 6, 2018):

@lafriks Any news? The complete notification stack (Gitea/Mail) is broken as a result of this behavior...

@xoxys commented on GitHub (Aug 6, 2018): @lafriks Any news? The complete notification stack (Gitea/Mail) is broken as a result of this behavior...

GiteaMirror commented

@liquidat commented on GitHub (Oct 9, 2018):

As mentioned in bug #4067 a one fix is to fill the appropriate "Username attribute". Depending on the LDAP configuration, this might be "cn" (like described by @ghtyrant in https://github.com/go-gitea/gitea/issues/4067#issuecomment-395530981) or as in my case "uid".

Not sure if that covers all cases mentioned here. But it did for me.

@liquidat commented on GitHub (Oct 9, 2018): As mentioned in bug #4067 a one fix is to fill the appropriate **"Username attribute"**. Depending on the LDAP configuration, this might be "cn" (like described by @ghtyrant in https://github.com/go-gitea/gitea/issues/4067#issuecomment-395530981) or as in my case "uid". Not sure if that covers all cases mentioned here. But it did for me.

GiteaMirror commented

@xoxys commented on GitHub (Oct 9, 2018):

Yes this "fix" works for me also. Downside: All users marching the LDAP filter will be synchronized to the local gitea database. If you have many users this might be a problem. What i would like to see is: User will be created at first login and only these useres will be synced with the ldap

@xoxys commented on GitHub (Oct 9, 2018): Yes this "fix" works for me also. Downside: All users marching the LDAP filter will be synchronized to the local gitea database. If you have many users this might be a problem. What i would like to see is: User will be created at first login and only these useres will be synced with the ldap

GiteaMirror commented

@junkb commented on GitHub (Oct 9, 2018):

above in my earlier comment you can see we have

username attribute: samaccountname

so in our case, this does not avoid the symptom

@junkb commented on GitHub (Oct 9, 2018): above in my earlier comment you can see we have username attribute: samaccountname so in our case, this does not avoid the symptom

GiteaMirror commented

@KimonHoffmann commented on GitHub (Oct 24, 2018):

I have had the same problem even though my configuration already included all the important settings discussed in this his thread.

After further analysis I noticed the "Size Limit Exceeded" error in the log file (see #3675), which wasn't obvious, because most users were synchronized anyway and all relevant user were included by sheer luck.

After fixing this issue by enabling paging, the "Active" flags were also synchronized as expected.

@KimonHoffmann commented on GitHub (Oct 24, 2018): I have had the same problem even though my configuration already included all the important settings discussed in this his thread. After further analysis I noticed the "Size Limit Exceeded" error in the log file (see #3675), which wasn't obvious, because most users were synchronized anyway and all relevant user were included by sheer luck. After fixing this issue by enabling paging, the "Active" flags were also synchronized as expected.

GiteaMirror commented

@liquidat commented on GitHub (Oct 24, 2018):

@junkb Maybe this comment helps?

@liquidat commented on GitHub (Oct 24, 2018): @junkb Maybe [this comment](https://github.com/go-gitea/gitea/issues/4067#issuecomment-432473002) helps?

GiteaMirror commented

@lafriks commented on GitHub (Oct 25, 2018):

@KimonHoffmann you can set in LDAP auth source to use paged search, this would fix size limit exceeded error.

@lafriks commented on GitHub (Oct 25, 2018): @KimonHoffmann you can set in LDAP auth source to use paged search, this would fix size limit exceeded error.

GiteaMirror commented

@KimonHoffmann commented on GitHub (Oct 25, 2018):

@lafriks yes, I know, sorry for not clearly expressing what I was trying to say.

I was trying to give other people who are struggling with this error a hint on what may cause it.

What I meant to say was that in my case the fact that the Active-flags were not synchronized from LDAP was a side effect of the sync job never running to completion, because it aborted prematurely with the "Size limit exceeded" error.

Once I fixed the latter by enabling paging in the LDAP config, the Active flags were synchronized as expected.

@KimonHoffmann commented on GitHub (Oct 25, 2018): @lafriks yes, I know, sorry for not clearly expressing what I was trying to say. I was trying to give other people who are struggling with this error a hint on what may cause it. What I meant to say was that in my case the fact that the Active-flags were not synchronized from LDAP was a side effect of the sync job never running to completion, because it aborted prematurely with the "Size limit exceeded" error. Once I fixed the latter by enabling paging in the LDAP config, the Active flags were synchronized as expected.

GiteaMirror commented

@tonysgi commented on GitHub (Dec 5, 2018):

@KimonHoffmann I set the paging size 1000 and 2000 but I am still getting my users deactivated from Active Directory. What paging size did you use?

@tonysgi commented on GitHub (Dec 5, 2018): @KimonHoffmann I set the paging size 1000 and 2000 but I am still getting my users deactivated from Active Directory. What paging size did you use?

GiteaMirror commented

@KimonHoffmann commented on GitHub (Dec 6, 2018):

@tonysgi: I have the paging set to the rather low value of 200.

Please note that you can easily determine, whether or not the page size is the problem by looking for the "Size limit exceeded" message in the log, while performing a synchronization.

I might be wrong in my assessment, but from what I've learned while investigating this problem on my installation is that the synchronization process appears to first fetch all user records and if that succeeded synchronizes the active flags in a second step. So any error that makes the first step not run to completion causes the active flags to be reset.

Having a look into the logfile while the synchronization is in progress could yield pointers on what your specific problem may be.

@KimonHoffmann commented on GitHub (Dec 6, 2018): @tonysgi: I have the paging set to the rather low value of 200. Please note that you can easily determine, whether or not the page size is the problem by looking for the "Size limit exceeded" message in the log, while performing a synchronization. I might be wrong in my assessment, but from what I've learned while investigating this problem on my installation is that the synchronization process appears to first fetch all user records and if that succeeded synchronizes the active flags in a second step. So *any* error that makes the first step not run to completion causes the active flags to be reset. Having a look into the logfile while the synchronization is in progress could yield pointers on what your specific problem may be.

GiteaMirror commented

@huapox commented on GitHub (Jan 22, 2019):

same problem! help wanted. #4402

@huapox commented on GitHub (Jan 22, 2019): **same problem! help wanted.** #4402

GiteaMirror commented

http://www.kouti.com/tables/userattributes.htm

@HarryHHung commented on GitHub (Feb 26, 2019):

In my case my problem was solved by case-sensitively setting user attributes as in the following list.

@HarryHHung commented on GitHub (Feb 26, 2019): In my case my problem was solved by **case-sensitively** setting user attributes as in the following list. [http://www.kouti.com/tables/userattributes.htm](url)

GiteaMirror commented

@stale[bot] commented on GitHub (Apr 27, 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 (Apr 27, 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 (May 11, 2019):

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

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

GiteaMirror commented

@meskio commented on GitHub (Jun 28, 2019):

We are hitting this same issue. I don't think is solved.

Our log says when it disables all our users:

 [...gitea/models/user.go:1649 SyncExternalUsers()] [E] LDAP Search failed unexpectedly! (LDAP Result Code 4 "Size Limit Exceeded": )

I check and our openldap server is configured with oclSizeLimit = 100, and on the gitea side we have marked it to Use Paged Search with Page Size = 50. Our ldap contains ~550 accounts. We have the Username attribute set to uid.

Any ideas of how I can help to solve this issue? Things to look into? Tests that will be useful for that?

@meskio commented on GitHub (Jun 28, 2019): We are hitting this same issue. I don't think is solved. Our log says when it disables all our users: ``` [...gitea/models/user.go:1649 SyncExternalUsers()] [E] LDAP Search failed unexpectedly! (LDAP Result Code 4 "Size Limit Exceeded": ) ``` I check and our openldap server is configured with oclSizeLimit = 100, and on the gitea side we have marked it to `Use Paged Search` with Page Size = 50. Our ldap contains ~550 accounts. We have the `Username attribute` set to `uid`. Any ideas of how I can help to solve this issue? Things to look into? Tests that will be useful for that?

GiteaMirror commented

@lafriks commented on GitHub (Jun 30, 2019):

What version are you using?

@lafriks commented on GitHub (Jun 30, 2019): What version are you using?

GiteaMirror commented

@meskio commented on GitHub (Jul 1, 2019):

We compiled ourselves gitea using the tag 1.8.3.

@meskio commented on GitHub (Jul 1, 2019): We compiled ourselves gitea using the tag 1.8.3.

GiteaMirror commented

@clawoflight commented on GitHub (Jul 11, 2019):

same problem here, it only works if I manually specify the username attribute.

My guess is that there is a bug in the search code compared to the authentication :)

@clawoflight commented on GitHub (Jul 11, 2019): same problem here, it only works if I manually specify the username attribute. My guess is that there is a bug in the search code compared to the authentication :)

GiteaMirror commented

@IonicEcko commented on GitHub (Aug 7, 2019):

I am also having this issue.

Latest docker, really small MS AD (its a lab), every time the sync runs it deactivates my user. Happy to grab any logs etc needed if you can mention what and where.

@IonicEcko commented on GitHub (Aug 7, 2019): I am also having this issue. Latest docker, really small MS AD (its a lab), every time the sync runs it deactivates my user. Happy to grab any logs etc needed if you can mention what and where.

GiteaMirror commented

@lafriks commented on GitHub (Aug 7, 2019):

please check gitea.log for any errors/warnings related to LDAP sync

@lafriks commented on GitHub (Aug 7, 2019): please check gitea.log for any errors/warnings related to LDAP sync

GiteaMirror commented

@IonicEcko commented on GitHub (Aug 7, 2019):

No errors that I can see but the mess of SQL queries makes it hard to tell. I ran an update though to replicate the issue and the only bit that looked out of place was:

2019/08/07 08:03:20 ...rm/session_update.go:375:Update() [I] [SQL] UPDATE "user" SET "is_active" = ?, "updated_unix" = ? WHERE "id"=? []interface {}{false, 1565165000, 7}

For reference (because I never discount my own stupidity) my settings are below. I ended up having to remove the admin filter because it never seemed to work and the user filter had to be simplified and switched from sAMAccountName to SamAccountName to match AD (with sAM it just didnt work at all).

If thats wrong, my apologies.

LDAP definitely works (my AD password works - even after deleting the account). But it deactives the account on every sync.

@IonicEcko commented on GitHub (Aug 7, 2019): No errors that I can see but the mess of SQL queries makes it hard to tell. I ran an update though to replicate the issue and the only bit that looked out of place was: `2019/08/07 08:03:20 ...rm/session_update.go:375:Update() [I] [SQL] UPDATE "user" SET "is_active" = ?, "updated_unix" = ? WHERE "id"=? []interface {}{false, 1565165000, 7}` For reference (because I never discount my own stupidity) my settings are below. I ended up having to remove the admin filter because it never seemed to work and the user filter had to be simplified and switched from sAMAccountName to SamAccountName to match AD (with sAM it just didnt work at all). If thats wrong, my apologies. LDAP definitely works (my AD password works - even after deleting the account). But it deactives the account on every sync. ![image](https://user-images.githubusercontent.com/6550614/62606049-b9555900-b93e-11e9-94a5-aca6669dd13d.png)

GiteaMirror commented

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

@lafriks commented on GitHub (Oct 6, 2019):

Imho this should be resolved on master branch

@lafriks commented on GitHub (Oct 6, 2019): Imho this should be resolved on master branch

GiteaMirror commented