LDAP Sync Problems (is_admin, is_restricted and is_active) #13419

lcnittl · 2020-11-03T23:24:23Z

Gitea version (or commit ref): 1.12.4
Git version: 2.20.1
OpenLDAP version: 2.4.47+dfsg-3+deb10u3
Operating system: Debian 10
Downloaded from https://dl.gitea.io/gitea/1.12.4/gitea-1.12.4-linux-amd64
Runs via gitea service (https://github.com/go-gitea/gitea/raw/master/contrib/systemd/gitea.service)
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: https://gist.github.com/lcnittl/60045a167285b50d72f0037f8a37cc2e
- Synchronize external user data: https://gist.github.com/lcnittl/60045a167285b50d72f0037f8a37cc2e#file-gitea-trace-0-log
- Login with user who was changed to admin: https://gist.github.com/lcnittl/60045a167285b50d72f0037f8a37cc2e#file-gitea-trace-1-log
- Login with user that is not admin: https://gist.github.com/lcnittl/60045a167285b50d72f0037f8a37cc2e#file-gitea-trace-2-log
- Login with user that is ext (restricted): https://gist.github.com/lcnittl/60045a167285b50d72f0037f8a37cc2e#file-gitea-trace-3-log

Description

We are encountering 2/3 main issues with LDAP authentication:

is_admin is set correctly on account creation (fist login to Gitea) but is not updated anymore on subsequent logins
is_restricted is not updated anymore on subsequent logins (have not tested on account creation yet, sry)
Although "AllowDeactivateAll": false is set ( Add option to prevent LDAP from deactivating everything on empty search #9879 ) each user's is_active attribute is set to false (cf. https://gist.github.com/lcnittl/60045a167285b50d72f0037f8a37cc2e#file-gitea-trace-0-log-L177-L178 ff.) when using Synchronize external user data in admin/monitor in the web UI (and also on cron started synchronizations).

This is our configuration of the authentication method:

# SELECT * FROM gitea.login_source WHERE id=2;
id: 2
type: 2
name: ldap.our.domain.com
is_actived: 1
is_sync_enabled: 1
cfg:
  Name: ldap.our.domain.com
  Host: ldap.lxc0
  Port: 389
  SecurityProtocol: 0
  SkipVerify: false
  BindDN: ''
  BindPassword: ''
  UserBase: OU=users,DC=our,DC=domain,DC=com
  UserDN: ''
  AttributeUsername: ''
  AttributeName: givenName
  AttributeSurname: sn
  AttributeMail: mail
  AttributesInBind: true
  AttributeSSHPublicKey: ''
  SearchPageSize: 0
  Filter: (&(objectClass=posixAccount)(UID=%s)(!(memberOf=CN=disabled,OU=roles,DC=our,DC=domain,DC=com)))
  AdminFilter: (memberOf=CN=admin,OU=roles,DC=our,DC=domain,DC=com)
  RestrictedFilter: (&(memberOf=CN=ext,OU=roles,DC=our,DC=domain,DC=com)(!(memberOf=CN=gitea,OU=roles,DC=our,DC=domain,DC=com)))
  Enabled: true
  AllowDeactivateAll: false
created_unix: 1603901943
updated_unix: 1604430791

This is the list of our users (probably important for the log gist):

user00: [admin]
user01: [admin]
user02: []
user03: []
user04: []
user05: [ext]
user06: [disabled]
user07: []
user08: [ext]
user09: []
user10: []
user11: []
user12: [ext]
user13: []
user14: []
user15: []
user16: []
user17: [disabled]
user18: []
user19: []
user20: [disabled]
user21: [disabled]
user22: []
user23: []
user24: []
user25: []
user26: [disabled]
user27: [disabled]
user28: [disabled]
user29: [disabled]
user30: [disabled]
user31: [disabled]
user32: [disabled]
user33: []
user34: []
user35: []
user36: [ext]
user37: [disabled, ext]
user38: [ext]
user39: [ext]
user40: [ext]
user41: []
user42: []
user43: []
user44: []
user45: []
user46: []

The values after the user keys are the roles each user has (eg user00 is admin and (memberOf=CN=admin,OU=roles,DC=our,DC=domain,DC=com) evaluates to true).

When the filters are run manually with ldapsearch they return the correct user entries.

Issue 1)

Should theoretically be fixed already (cf. #10538 (comment) ) but is not working for me: Is my admin filter wrong? If yes, why is the attribute correct on creation?

On subsequent login, LDAP seems to correctly filter for admin as it is not logging [T] LDAP Admin Search found no matching entries when the admin role is set:

admin role is set ( https://gist.github.com/lcnittl/60045a167285b50d72f0037f8a37cc2e#file-gitea-trace-1-log-L34-L35 )

2020/11/03 23:38:48 ...es/auth/ldap/ldap.go:161:checkAdmin() [T] Checking admin with filter (memberOf=CN=admin,OU=roles,DC=our,DC=domain,DC=com) and base uid=user08,ou=users,DC=our,DC=domain,DC=com
2020/11/03 23:38:48 ...es/auth/ldap/ldap.go:147:bindUser() [T] Binding with userDN: uid=user08,ou=users,DC=our,DC=domain,DC=com

vs admin role is not set ( https://gist.github.com/lcnittl/60045a167285b50d72f0037f8a37cc2e#file-gitea-trace-2-log-L14-L19 )

2020/11/03 23:56:19 ...es/auth/ldap/ldap.go:161:checkAdmin() [T] Checking admin with filter (memberOf=CN=admin,OU=roles,DC=our,DC=domain,DC=com) and base uid=user08,ou=users,DC=our,DC=domain,DC=com
2020/11/03 23:56:19 ...es/auth/ldap/ldap.go:172:checkAdmin() [T] LDAP Admin Search found no matching entries.
2020/11/03 23:56:19 ...es/auth/ldap/ldap.go:186:checkRestricted() [T] Checking restricted with filter (&(memberOf=CN=ext,OU=roles,DC=our,DC=domain,DC=com)(!(memberOf=CN=gitea,OU=roles,DC=our,DC=domain,DC=com))) and base uid=user08,ou=users,DC=our,DC=domain,DC=com
2020/11/03 23:56:19 ...es/auth/ldap/ldap.go:197:checkRestricted() [T] LDAP Restricted Search found no matching entries.
2020/11/03 23:56:19 ...es/auth/ldap/ldap.go:147:bindUser() [T] Binding with userDN: uid=user08,ou=users,DC=our,DC=domain,DC=com
2020/11/03 23:56:19 ...es/auth/ldap/ldap.go:153:bindUser() [T] Bound successfully with userDN: uid=user08,ou=users,DC=our,DC=domain,DC=com

Yet, the is_admin flag remains unaltered.

Issue 2)

This was tested (for the log) by adding ext role to user08.

Here again, according to the log, LDAP seems to correctly apply the filter (No [T] LDAP Restricted Search found no matching entries login):

ext role is set ( https://gist.github.com/lcnittl/60045a167285b50d72f0037f8a37cc2e#file-gitea-trace-3-log-L16-L17 )

2020/11/04 00:10:27 ...es/auth/ldap/ldap.go:186:checkRestricted() [T] Checking restricted with filter (&(memberOf=CN=ext,OU=roles,DC=our,DC=domain,DC=com)(!(memberOf=CN=gitea,OU=roles,DC=our,DC=domain,DC=com))) and base uid=user08,ou=users,DC=our,DC=domain,DC=com
2020/11/04 00:10:27 ...es/auth/ldap/ldap.go:147:bindUser() [T] Binding with userDN: uid=user08,ou=users,DC=our,DC=domain,DC=com

Is is_restricted supposed to get updated on each login?

Issue 3)

I think this -- deactivation of all users -- should not happen in our case because

The user search filter should, in our setup, not return an empty list for any user (the the best of my knowledge, all users exist in LDAP).
Even if it would, AllowDeactivateAll is set to false (so it should never deactivate all users?)
Only the admin and restricted filters are returning empty lists, for obvious reasons

But probably there is a filter problem here as well?

Any input welcome! If there is further info needed, please let me know!

2020/11/03 23:38:48 ...es/auth/ldap/ldap.go:88:findUserDN() [T] Search for LDAP user: user08
2020/11/03 23:38:48 ...es/auth/ldap/ldap.go:96:findUserDN() [T] Searching for DN using filter (&(objectClass=posixAccount)(UID=user08)(!(memberOf=CN=disabled,OU=roles,DC=our,DC=domain,DC=com))) and base OU=users,DC=our,DC=domain,DC=com
2020/11/03 23:38:48 ...es/auth/ldap/ldap.go:286:SearchEntry() [T] Fetching attributes '', 'givenName', 'sn', 'mail', '' with filter (&(objectClass=posixAccount)(UID=user08)(!(memberOf=CN=disabled,OU=roles,DC=our,DC=domain,DC=com))) and base uid=user08,ou=users,DC=our,DC=domain,DC=com
2020/11/03 23:38:48 ...es/auth/ldap/ldap.go:161:checkAdmin() [T] Checking admin with filter (memberOf=CN=admin,OU=roles,DC=our,DC=domain,DC=com) and base uid=user08,ou=users,DC=our,DC=domain,DC=com
2020/11/03 23:38:48 ...es/auth/ldap/ldap.go:147:bindUser() [T] Binding with userDN: uid=user08,ou=users,DC=our,DC=domain,DC=com

020/11/03 23:56:19 ...es/auth/ldap/ldap.go:161:checkAdmin() [T] Checking admin with filter (memberOf=CN=admin,OU=roles,DC=our,DC=domain,DC=com) and base uid=user08,ou=users,DC=our,DC=domain,DC=com
2020/11/03 23:56:19 ...es/auth/ldap/ldap.go:172:checkAdmin() [T] LDAP Admin Search found no matching entries.

There's something very odd going on here. Is there request limiting? Are we sending some whitespace by accident?

lcnittl · 2020-11-09T10:29:38Z

Maybe I was not very clear, sorry for that:
The different results from the same query are expected, as in the first case the admin role was set (user08 has the memberOf=CN=admin,OU=roles,DC=our,DC=domain,DC=com attribute set) and in the second case that attribute was removed. This was done to rule out that a failed LDAP query is the reason for the is_admin flag being not altered. But indeed, Gitea's LDAP query correctly found whether the user is supposed to be admin or not.

SnailShea · 2020-12-29T02:16:12Z

May be unrelated to the cause of issues others have had (I've seen at least one screenshot showing my fix would not help them on other related issues) but I was having issues with user deactivation after a sync. Turns out if you have, in my example a User Filter of (&(objectClass=posixAccount)(uid=%s)) but leave the Username Attribute field blank, deactivation of any previously signed in users will occur. Adding uid to Username Attribute resolved the issue I was having. It was strange, I was able to sign in just fine but the user list would only populate with that name after signing in, and no other names from the LDAP instance. And, of course, upon sync that account would then be locked. After applying the fix as it pertained to my issue, all users in the LDAP show up in the account list on gitea.

Hoping this helps someone.

SirIntellegence · 2021-03-29T15:44:30Z

This issue is happening for me as well. I don't know if it is related to me leaving the "Username Attribute" field empty since out LDAP apparently doesn't support the UID attribute and the closest thing I can use "userPrincipalName" is effectively their domain email address.

SnailShea · 2021-03-29T15:59:55Z

This issue is happening for me as well. I don't know if it is related to me leaving the "Username Attribute" field empty since out LDAP apparently doesn't support the UID attribute and the closest thing I can use "userPrincipalName" is effectively their domain email address.

Is your user attribute cn instead of uid perhaps? Essentially I think the field should be populated with whatever attribute indicates a unique user entry.

SirIntellegence · 2021-03-29T16:08:02Z

From what I can tell by running queries, cn contains the user's name ("Billy Bob"), not the username ("bbob").

SnailShea · 2021-03-29T16:25:31Z

From what I can tell by running queries, cn contains the user's name ("Billy Bob"), not the username ("bbob").

If you're directly referencing a user object in your LDAP structure how do you do so? For me it would be like uid=mxlinux,cn=Users,dc=domain,dc=tld the part where I have uid might be different for you but I think still an expected part of any LDAP structure.

SirIntellegence · 2021-03-29T16:31:29Z

I am using userPrincipalName for the filter and I haven' gotten the group filter field to work, so I am using (&(&(&(objectClass=person)(memberOf:=CN=Programming,CN=Users,DC=domain,DC=com)(userPrincipalName=%s))))
Also, I am not sure if this is related entirely to the issue and if this discussion should be held here. Don't want to hijack an issue...

youngmit · 2021-05-17T20:56:30Z

May be unrelated to the cause of issues others have had (I've seen at least one screenshot showing my fix would not help them on other related issues) but I was having issues with user deactivation after a sync. Turns out if you have, in my example a User Filter of (&(objectClass=posixAccount)(uid=%s)) but leave the Username Attribute field blank, deactivation of any previously signed in users will occur. Adding uid to Username Attribute resolved the issue I was having. It was strange, I was able to sign in just fine but the user list would only populate with that name after signing in, and no other names from the LDAP instance. And, of course, upon sync that account would then be locked. After applying the fix as it pertained to my issue, all users in the LDAP show up in the account list on gitea.

Hoping this helps someone.

This is extremely helpful! I had left this option blank, because the "Leave empty to use the username entered in Gitea" guidance implies that all it is used for is to determine the Gitea-internal username for the user. Adding sAMAccountName (we use AD) fixed it for me. I'm wondering if just making more explicit that this is also important for the sync operation to work correctly would clear up a lot of confusion for folks?

Alexey-I · 2021-05-31T12:43:14Z

Hi!
I can probably add a bit. We've just experienced the sync issue with Gitea Version: 1.15.0+dev-358-gfb6c6895f (Docker image).
Users who were able to register via LDAP yesterday, became Deactivated today.
After a bit of experimenting I was able to fix this issue by changing Username Attribute = samaccountname to Username Attribute = sAMAccountName on Authentication Source settings.
This is probably my fault, I should have used correct spelling from the very beginning but with user registration it worked. It's synchronization which seems to insist to be case sensitive.

Oasis6604 · 2022-09-27T09:17:59Z

Hi! I can probably add a bit. We've just experienced the sync issue with Gitea Version: 1.15.0+dev-358-gfb6c6895f (Docker image). Users who were able to register via LDAP yesterday, became Deactivated today. After a bit of experimenting I was able to fix this issue by changing Username Attribute = samaccountname to Username Attribute = sAMAccountName on Authentication Source settings. This is probably my fault, I should have used correct spelling from the very beginning but with user registration it worked. It's synchronization which seems to insist to be case sensitive.

Same here!
Login works even with lowercase writing and tools like ldapsearch work aswell. But the issue that my users become disabled is gone since I use the correct writing.

night-gold · 2022-11-15T15:17:10Z

Hello, just find out that there is a solution that works for us here . You have to put a valid value username attribute. CN is an example in the post, I had to put 'uid' as the 'cn' is empty in our ldap.

Samachi · 2024-05-31T01:24:07Z

1.22.0, the issue still exist, while using LDAP (via BindDN) as authentication source, Gitea deactivates LDAP users almost once a day or when you run “Synchronize external user data”.

lcnittl changed the title ~~LDAP Sync Problems (is_admin and is_active)~~ LDAP Sync Problems (is_admin, is_restricted and is_active) Nov 3, 2020

6543 added the type/bug label Nov 5, 2020

lunny added the issue/workaround it is or has a workaround label Nov 21, 2022

lunny added the theme/ldap label Sep 13, 2023

delvh added topic/authentication and removed theme/ldap labels Oct 7, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

LDAP Sync Problems (is_admin, is_restricted and is_active) #13419

LDAP Sync Problems (is_admin, is_restricted and is_active) #13419

lcnittl commented Nov 3, 2020 •

edited

Loading

zeripath commented Nov 8, 2020

lcnittl commented Nov 9, 2020

SnailShea commented Dec 29, 2020 •

edited

Loading

SirIntellegence commented Mar 29, 2021

SnailShea commented Mar 29, 2021 •

edited

Loading

SirIntellegence commented Mar 29, 2021 •

edited

Loading

SnailShea commented Mar 29, 2021

SirIntellegence commented Mar 29, 2021 •

edited

Loading

youngmit commented May 17, 2021

Alexey-I commented May 31, 2021

Oasis6604 commented Sep 27, 2022

night-gold commented Nov 15, 2022 •

edited

Loading

Samachi commented May 31, 2024

LDAP Sync Problems (is_admin, is_restricted and is_active) #13419

LDAP Sync Problems (is_admin, is_restricted and is_active) #13419

Comments

lcnittl commented Nov 3, 2020 • edited Loading

Description

Related

zeripath commented Nov 8, 2020

lcnittl commented Nov 9, 2020

SnailShea commented Dec 29, 2020 • edited Loading

SirIntellegence commented Mar 29, 2021

SnailShea commented Mar 29, 2021 • edited Loading

SirIntellegence commented Mar 29, 2021 • edited Loading

SnailShea commented Mar 29, 2021

SirIntellegence commented Mar 29, 2021 • edited Loading

youngmit commented May 17, 2021

Alexey-I commented May 31, 2021

Oasis6604 commented Sep 27, 2022

night-gold commented Nov 15, 2022 • edited Loading

Samachi commented May 31, 2024

lcnittl commented Nov 3, 2020 •

edited

Loading

SnailShea commented Dec 29, 2020 •

edited

Loading

SnailShea commented Mar 29, 2021 •

edited

Loading

SirIntellegence commented Mar 29, 2021 •

edited

Loading

SirIntellegence commented Mar 29, 2021 •

edited

Loading

night-gold commented Nov 15, 2022 •

edited

Loading