Administrator account password not recognised (Unable to bind LDAP server)

Support
, ,
1

Hello everyone,

First of all, thanks to all the Yunohost team for their incredible work.

yunohost: 11.1.19
yunohost-admin: 11.1.9.4
moulinette: 11.1.4
ssowat: 11.1.4
Virtualization: kvm
OS: Debian 11 (bullseye)
Kernel: 5.10.0-22-amd64

I get stuck after postinstalling yunohost on a VPS using a fresh Debian 11 installation: my admin user credentials (first user created via postinstall) are not recognized.
I did the same installation on a raspberry pi 3 without any problem.
(using of course https://domain.name/yunohost/admin)

I first noticed that the admins group did not exist.

So I followed the recommended procedure on the 11.1.1 announcement to clean everything and then created the admins group:

MAINDOMAIN=$(yunohost domain list --output-as json | jq -r '.main')
yunohost user group add-mailalias admins root@$MAINDOMAIN admin@$MAINDOMAIN admins@$MAINDOMAIN webmaster@$MAINDOMAIN abuse@$MAINDOMAIN postmaster@$MAINDOMAIN
yunohost user group remove-mailalias admins root admin admins abuse webmaster postmaster

Now the admins group exist and my “admin” user (testuser) is a member:

yunohost user group list
groups:
  admins:
    members: testuser
  all_users:
    members: testuser
  visitors:
    members:

Unfortunately the password is still not recognized and changing the password via “yunohost user update testuser -p” does not change anything.
The command gives a warning “Failed to fetch quota info … Command ‘doveadm -f flow quota get -u testuser’ returned non-zero exit status 75”, but I guess it’s kinda expected since the user’s mailbox quota is empty.

doveadm (1:2.3.13+dfsg1-2+deb11u1) and slapd (2.4.57+dfsg-3+deb11u1) are functional.

Does anyone have a clue regarding the problem?

2

Digging deeper the logs indicate that the LDAP service is down:

tail /var/log/yunohost/yunohost-api.log:

- 2023-05-14 13:40:15,173 DEBUG    geventwebsocket.handler (unknown function) - Initializing WebSocket
- 2023-05-14 13:40:15,173 DEBUG    geventwebsocket.handler (unknown function) - Validating WebSocket request
- 2023-05-14 13:40:15,174 DEBUG    geventwebsocket.handler (unknown function) - Can only upgrade connection if using GET method.
- 2023-05-14 13:40:19,694 WARNING  yunohost.authenticators.ldap_admin (unknown function) - Le service LDAP est en panne, essayez de le redémarrer...
- 2023-05-14 13:40:34,322 INFO     geventwebsocket.handler (unknown function) - 127.0.0.1 - - [2023-05-14 13:40:34] "POST /login HTTP/1.1" 401 164 19.148779

But looking at the slapd service status, everything seems in order:

systemctl status slapd.service

Active:  active (running) since Sun 2023-05-14 13:40:19 CEST; 9min ago
Docs:    man:systemd-sysv-generator(8)
Process: 8365 ExecStart=/etc/init.d/slapd start (code=exited, status=0/SUCCESS)

Every login attempt using Web admin UI trigger a shutdown and restart of slapd:

journalctl -u slapd --no-pager --no-hostname

May 14 13:53:26 systemd[1]: Stopping LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)...
May 14 13:53:26 slapd[8373]: daemon: shutdown requested and initiated.
May 14 13:53:26 slapd[8373]: slapd shutdown: waiting for 0 operations/tasks to finish
May 14 13:53:26 slapd[8373]: DIGEST-MD5 common mech free
May 14 13:53:26 slapd[8373]: DIGEST-MD5 common mech free
May 14 13:53:26 slapd[8373]: slapd stopped.
May 14 13:53:26 slapd[12748]: Stopping OpenLDAP: slapd.
May 14 13:53:26 systemd[1]: slapd.service: Succeeded.
May 14 13:53:26 systemd[1]: Stopped LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol).
May 14 13:53:26 systemd[1]: Starting LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)...
May 14 13:53:26 slapd[12761]: @(#) $OpenLDAP: slapd 2.4.57+dfsg-3+deb11u1 (May 14 2022 18:32:57) $
                                      Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>
May 14 13:53:26 slapd[12763]: slapd starting
May 14 13:53:26 slapd[12754]: Starting OpenLDAP: slapd.
May 14 13:53:26 systemd[1]: Started LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol).
3

Syslog indicate that the LDAP server cannot be binded:

postfix/cleanup[116829]: warning: dict_ldap_connect: Unable to bind to server ldap://localhost:389 with dn empty or implicit: -1 (Can't contact LDAP server)

However, port 389 is well used by slapd:

ss -tunlp | grep 389

tcp LISTEN 0 1024 127.0.0.1:389 0.0.0.0:* users:(("slapd",pid=122072,fd=8))

4

Any advice in witch direction I should dig to find the problem?
(malheureusement je sèche là :/)

5

Still digging:

I’m confuse with this one.
The standard connexion to LDAP works and not the TLS one:
Is it something expected? Since .cert and .key are specified within the slapd conf but that we are using port 389 (instead of the default 363 for TLS).

But a connection test result in a “Can’t contact LDAP Server (-1)”

ldapsearch -x -d 1

ldap_create
ldap_extended_operation_s
ldap_extended_operation
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP localhost:389
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying ::1 389
ldap_pvt_connect: fd: 3 tm: -1 async: 0
attempting to connect:
connect errno: 111
ldap_close_socket: 3
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 127.0.0.1:389
ldap_pvt_connect: fd: 3 tm: -1 async: 0
attempting to connect:
connect success
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({) ber:
ber_flush2: 31 bytes to sd 3
ldap_result ld 0x56068babca60 msgid 1
wait4msg ld 0x56068babca60 msgid 1 (infinite timeout)
wait4msg continue ld 0x56068babca60 msgid 1 all 1
** ld 0x56068babca60 Connections:
* host: localhost  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Wed May 17 19:21:55 2023


** ld 0x56068babca60 Outstanding Requests:
 * msgid 1,  origid 1, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x56068babca60 request count 1 (abandoned 0)
** ld 0x56068babca60 Response Queue:
   Empty
  ld 0x56068babca60 response count 0
ldap_chkResponseList ld 0x56068babca60 msgid 1 all 1
ldap_chkResponseList returns ld 0x56068babca60 NULL
ldap_int_select
read1msg: ld 0x56068babca60 msgid 1 all 1
ber_get_next
ldap_err2string
ldap_start_tls: Can't contact LDAP server (-1)
ldap_free_request (origid 1, msgid 1)
ldap_free_connection 1 1
ldap_free_connection: actually freed

ldapwhoami -x -D cn=testuser,dc=yunohost,dc=org -W

ldap_result: Can't contact LDAP server (-1)
6

Problem solved:

I’ve added
slapd:ALL in /etc/hosts.allow.
Then I deleted the main user, did a regen-conf --force, and recreated the main user (= admin).

Explanations:
Slapd could not be contacted (due to the hosts.allow configuration).
As a result the creation of the main user was faulty (the associated system user and thus the /home/user folder could not be created). Even with the slapd connection allowedd, the user was then not recognized.
It was therefore necessary (in addition to authorizing slapd in hosts) to recreate the user.

If a dev or someone in the know could confirm if this is the right thing to do or if I’m just badly working around a problem that’s still there, I’d love to hear from you!

7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.