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.