Gitea: SyncExternalUsers is deactivating ldap users

[junkb]

• Gitea version (or commit ref): 1.4.0
• Git version: n/a
• Operating system: ubuntu 17.10
• Database (use [x]):
  
  
  
  • [ ] PostgreSQL
  
  
  • [x] MySQL
  
  
  • [ ] MSSQL
  
  
  • [ ] SQLite
  
  
• Can you reproduce the bug at https://try.gitea.io:
  
  
  
  • [ ] Yes (provide example URL)
  
  
  • [ ] No
  
  
  • [x] Not relevant
  
  
• Log gist: https://gist.github.com/junkb/63517845b0bfbb110434903137b96fbf

Description

i've set up and am using ldap authentication. this seems to be working fine. users in the specified ldap group are able to log in, and are able to use the system. upon a new user's initial login, they are active, and the user management panel confirms this.

however, once SyncExternalUsers runs, it decides all ldap users need to be deactivated, and does so [see logs referenced above].

once this happens, the user is still able to log in, but is shown in the user management panel as inactive, and cannot be seen by other users [for example, in explore -> users].

users can be manually reactivated, by editing that user's settings in the user management panel, and the user is then again visible, etc., but as soon as SyncExternalUsers runs again, it deactivates everyone.

[lafriks]

Do you have user filter set (&(objectclass=user)(samaccountname=*)(memberof=cn=vcs_users,ou=groups,dc=example,dc=com))?

[lafriks]

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

[junkb]

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 '*'?

[junkb]

what else can i do to troubleshoot this further?

[s-hamann]

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

[hexathos]

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(

[lafriks]

I can't seem to reproduce that

[hexathos]

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

[liquidat]

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
  
  

[okimiko]

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
  
  

[sapk]

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

[lafriks]

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

[liquidat]

@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?

[lafriks]

@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

[liquidat]

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?

[yamss]

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.

[lafriks]

Can you please give your LDAP source configuration and 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
• [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))

[liquidat]

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

[lafriks]

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

[liquidat]

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

[junkb]

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]

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: [email protected]
• 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

[armin1402]

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}

[armin1402]

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.

[junkb]

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

[xoxys]

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

[liquidat]

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.

[xoxys]

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

[junkb]

above in my earlier comment you can see we have

username attribute: samaccountname

so in our case, this does not avoid the symptom

[KimonHoffmann]

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.

[liquidat]

@junkb Maybe this comment helps?

[lafriks]

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

[KimonHoffmann]

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

[tonysgi]

@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?

[KimonHoffmann]

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

[huapox]

same problem! help wanted. #4402

[HarryHHung]

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

[stale[bot]]

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

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

[meskio]

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?

[lafriks]

What version are you using?

[meskio]

We compiled ourselves gitea using the tag 1.8.3.

[clawoflight]

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

[IonicEcko]

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.

[lafriks]

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

[IonicEcko]

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.

[stale[bot]]

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.

[lafriks]

Imho this should be resolved on master branch

[s-hell]

I have the same problem.
Started withe 1.9.3, updated to 1.9.4 and compiled the master branch. All the same error.

We are using gitea with:

ssh=2.16.5
DB=mysql
OS=CentOS7.7

[faekz0r]

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.

Try being case sensitive, like this: sAMAccountName