Problems connecting to YunoHost's LDAP database the user cn=admin no longer exists in the new version of YunoHost

[rubensflinco]

My YunoHost server

Hardware: Linode nanode 1gb RAM and 1gb CPU with Debian 11 Disk
YunoHost version: 11.1.19
I have access to my server : SSH
Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : no

Description of my issue

I’m having problems connecting to the LDAP database that YunoHost creates to store mainly users.

Let’s go there previously in an older version of YunoHost I believe that something below version 11.1.0.2 I could perfectly connect to LDAP using this data:

Hostname: localhost
SSL/TLS: false
Bind DN: cn=admin,dc=yunohost,dc=org
Bind Password: (Here I put the password I defined for my YunoHost ADM, in the past we had only 1 main ADM)
Port: 389

This stopped working well in the new versions after they implemented the possibility of having more than 1 ADM for the YunoHost panel.
I have always used the two n8n tools to connect to the LDAP database with the community node called n8n-nodes-ldap and also when I want to do something manually I use phpldapadmin which is an app that I install using YunoHost.
This is the error I come across in the new version of YunoHost trying to use the data I mentioned above:

In the new version, I’ve been looking for solutions to my problem of not being able to connect using the cn=admin user. for min](ldap: re-allow member of the admins group to edit ldap db · YunoHost/yunohost@4f5cc16 · GitHub) says that this tweak was made so that the LDAP database will use Admins group users to have access and be roots in the database more this is not entirely true.
During my research I found a different way to login to the LDAP database which was literally using a YunoHost user to connect so I used this data:

Hostname: localhost
SSL/TLS: false
Bind DN: uid=admin,ou=users,dc=yunohost,dc=org
Bind Password: (Here put the YunoHost admin user password)
Port: 389

Notice that the Bind DN has been changed instead of using cn=admin we are using uid=admin and referencing the users table with ou=users.

And well, it worked well for the login in both n8n and phpldapadmin, however these users do not have the same permissions that the old cn=admin had.

On my n8n I make a modification to the database causing it to edit the value of the “homePostalAddress” field, and when I make this value modification I get the following error when I use the user credentials uid=admin:

"The caller does not have sufficient rights to perform the requested operation. Code: 0x32"

This same permission problem happens not only in n8n but also in the phpldapadmin interface if I try to change any field value but the error is described differently, but implying that it is the same thing follows the pint:

Well, this is where I arrived in my investigations and I understand so far that this is a problem due to the new version of YunoHost that has the functionality of having more than 1 ADM and that consequently this is still not reflecting well on the connections to the database LDAP.

I hope someone can help me this problem is giving me a big headache since I use LDAP as my database for a unified Login on my sites using the Dex app that is in the YunoHost store, and the n8n for Registration in the LDAP database.

Can anyone help me?

[tierce]

Have you tried with the first user of your Yunohost instance, who was automatically raised to an admin level ?

[Aleks]

cf [Solved] Phpldapadmin login as cn=admin,dc=yunohost,dc=org no longer supported? - #4 by oberger

[tituspijean]

Nope, even by logging in with uid=<the_admin>,ou=users,dc=yunohost,dc=org, adding a homePostalAddress attribute to myself ends up with 0x32 (LDAP_INSUFFICIENT_ACCESS) error.

[Aleks]

Hmmokay so the issue not about connecting to the DB, but adding a new specific field …?

[rubensflinco]

@Aleks Yes, but it goes beyond adding a new field at least for me I can’t even change the value of a field that already exists and already had a value.

Oh and answering @tierce question, I’m using the first user, which is admin, the legacy administrator of the old version.

[Aleks]

I don’t have time to dig in, but this is the ACL that supposedly allows member of the admins group to write anything:

YunoHost/yunohost/blob/dev/conf/slapd/config.ldif#L160-L163

[rubensflinco]

Where should I implement these code snippets?

[Aleks]

They are already implemented on your server, the real question is why doesn’t it work as expected

[rubensflinco]

Could someone else help me who has more time at the moment?

[dr41nU]

I’m facing the same issue, as when logged in with my account (in admin group), I get the following message:

||Impossible d'effectuer une opération ldap_modify.|
|---|---|
|LDAP dit ::|Insufficient access|
|Erreur numéro ::|0x32 (LDAP_INSUFFICIENT_ACCESS)|
|Description:|You do not have sufficient permissions to perform that operation.|

I get this message even after having regen my ldap conf with # /usr/share/yunohost/hooks/conf_regen/06-slapd post true

Thus, my ldap conf seems correct:

# slapcat -o ldif-wrap=no -b cn=config | grep olcAccess
olcAccess: {0}to *  by * none
olcAccess: {0}to attrs=userPassword,shadowLastChange   by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" write   by anonymous auth   by self write   by * none
olcAccess: {1}to attrs=cn,gecos,givenName,mail,maildrop,displayName,sn   by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" write   by self write   by * read
olcAccess: {2}to dn.base=""   by * read
olcAccess: {3}to *   by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" write   by group/groupOfNames/member.exact="cn=admins,ou=groups,dc=yunohost,dc=org" write   by * read

[rubensflinco]

How do I install an older version of yunohost on my server?
As an alternative way for me to continue using LDAP the old way when there weren’t several Admin users on YunoHost.

[Aleks]

You don’t : we don’t keep old versions of YunoHost uploaded, and even if we did, using an older version of a software to workaround a bug is not a solution : newer versions include security fixes, etc. One way or another you will have to upgrade someday. TL;DR : you will loose less time investigating the actual issue and finding the root cause rather than trying to workaround the issue by “using and older version”

[rubensflinco]

Unfortunately, I’ve already tried everything I could to manage all the config files related to LDAP and I don’t know exactly how LDAP works or what are the right or wrong settings for it, so what’s left for me is to look for other alternative tools to create what I need to create