LDAP "Admin Filter" stopped working

[palto42]

Description

After upgrading to Gitea 1.20.0 the LDAP Admin Filter stopped working and removed all LDAP based admin permissions.

The admin filter used is:

(memberOf=cn=git-admin,ou=group,o=company,ou=customers,dc=company,dc=net)

It worked in all previous Gitea versions and there hasn't been any change on the LDAP server used.

Gitea Version

1.20.0 - 1.20.4

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

nothing visible in the logs

Screenshots

No response

Git Version

2.40.1

Operating System

RHEL 7.9

How are you running Gitea?

Docker based Gitea.
Docker version 24.0.6

Database

MariaDB
mariadb Ver 15.1 Distrib 10.5.11-MariaDB,

[cschuber]

I'm seeing ssh keys stopped working. I'm not sure if the issue reported here is specifically LDAP or a larger issue.

[palto42]

I re-tested with latest 1.20.2, still the admin filter isn't working anymore.
Isn't there anyone else with this problem or can anyone confirm that it's working in 1.20.x ?

[arcoast]

I re-tested with latest 1.20.2, still the admin filter isn't working anymore. Isn't there anyone else with this problem or can anyone confirm that it's working in 1.20.x ?

I've also lost admin access fwiw.

[arcoast]

I'm not sure on reflection my issue is quite the same, my admin user is a local account and it was marked as inactive (this may have been user error as I rarely have to use it)

I did gain access again by creating a new admin user:

docker exec -it gitea bash

su git
gitea admin user create --username new_admin --email admin@server.com --admin --random-password

[CaiCandong]

(memberOf=cn=git-admin,ou=group,o=company,ou=customers,dc=company,dc=net)

Although you said that your LDAP service has not been changed, I still want to confirm that your LDAP service starts the member of function.

[palto42]

Although you said that your LDAP service has not been changed, I still want to confirm that your LDAP service starts the member of function.

@CaiCandong Not sure what you mean by "your LDAP service starts the memberOf function", but I can run this query on CLI using ldapsearch with the same search string.

[CaiCandong]

This is the user information I used for testing, and was able to successfully get administrator rights. Can you provide some data to help me replicate your test environment?

---

dn: uid=xiaomei,ou=north,dc=deldap,dc=com
cn: xiaomei
displayname: xiaomei
employeenumber: cn=git-admin,ou=north,dc=deldap,dc=com
givenname: xiaomei
mail: xiaomei@esgyn.local
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: top
ou: north
sn:: 5bCP576O
uid: xiaomei
userpassword: 123456

[CaiCandong]

@palto42 Can you show us the LDAP configuration of your Gitea?

[palto42]

@CaiCandong Please find below the sanitized Gitea LDAP config we used:

One difference I spotted in the user filter is that you used %[1]s while I have just %s. I tried with this change, but as expected it has no impact and the admin filer is still not working for me.

In my user record I have this entry which should be matched for the admin filter:

memberOf: cn=git-admin,ou=group,o=company,ou=customers,dc=company,dc=net

[palto42]

I tried with (uid=palto42) as admin filter and it also doesn't work.
As I tried some other group filter, I got one user as admin, but this use was not even a member of the specified group!
No idea what's going on here, in previous releases all worked fine and our LDAP server works fine with other systems.

[CaiCandong]

Can you create a new user and hopefully the result will be that he'll be an administrator the first time he logs in?

I found bug #27051 while checking the related code, but I'm unsure if this relates to your question.

[palto42]

@CaiCandong Can't create easily a new user (managed by different department with long approval process), I was testing the changes by running the "Synchronize external user data" from the dashboard. I have a non-LDAP admin account to ensure that I don't lose access.
Do you think there is any difference for a new user vs, running a sync? In the past it was always working with the sync if I had to change any LDAP settings.

[palto42]

I found bug #27051 while checking the related code, but I'm unsure if this relates to your question.

Since I'm setting the user name as uid, I don't think that this bug applies.

[CaiCandong]

Do you think there is any difference for a new user vs, running a sync? In the past it was always working with the sync if I had to change any LDAP settings.

Yes, I found that issue with one that has to do with user synchronization... wait, did you not set up a user name selection rule?

[CaiCandong]

I would like to know more about this, can I contact you via Discord?

[palto42]

I have set "Username Attribute" as uid, but also tried w/o setting it - no success either way.

[gd197]

hello, same issue here after upgrading from 1.19.x to 1.20.4. Admins who were already identified did not lost their admin privilege, but new ones did not get them.
Username attribute is not set in our configuration due to another issue with LDAP ( #20422 )

[palto42]

still not working in release 1.21.0

[Josue-T]

Maybe #18452 will fix the issue in some cases. cf YunoHost-Apps/gitea_ynh#76 (comment)

[ShayArtzi]

FWIW, I'm also seeing an issue with the LDAP admin filter (using gitea 1.21.11).

It seems that the filter is being checked only upon user creation (first login). Then if the user is added to the admin group, they won't be promoted to admin and vice versa (if the user was an admin on first logon and then removed from the LDAP admin group, the admin privilege won't be revoked)

[palto42]

I just upgraded to latest version 1.22.0 and the LDAP admin filter started working again :-)
Closing this issue as it is solved for me.