UCS keine Anmeldung mehr möglich LDAP Problem

UCS - Univention Corporate Server
, ,
#1

Hallo,

wir benutzen UCS nur in Verbindung mit Kopano hausintern und seit heute morgen kann sich kein Benutzer mehr an dem UCS Server oder kopano anmelden. SSH als root funktioniert, mysql, apache2 und die kopano dienste laufen, ldap nicht. Ldap lässt sich auch nicht manuell starten, journalctl -xe bringt u.a. den Fehler error: dict_ldap_connect: Unable to set STARTTLS: -1: Can’t contact LDAP server

Zertifikate sind selbstsigniert, habe die kontrolliert, sind noch gültig, habe dennoch neue ausgestellt und geschaut ob diese auch ldap benutzt werden: ja sind die richtigen.

journalctl -xe Log u.a.:

Sep 09 10:25:29 maila nscd[704]: nss-ldap: do_open: do_start_tls failed:stat=-1
Sep 09 10:25:29 maila nscd[704]: nss_ldap: reconnecting to LDAP server...
Sep 09 10:25:29 maila nscd[704]: nss-ldap: do_open: do_start_tls failed:stat=-1
Sep 09 10:25:29 maila nscd[704]: nss_ldap: reconnecting to LDAP server (sleeping 1 seconds)...
Sep 09 10:25:29 maila systemd[1]: Starting LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)...
-- Subject: Unit slapd.service has begun start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit slapd.service has begun starting up.
Sep 09 10:25:30 maila nscd[704]: nss-ldap: do_open: do_start_tls failed:stat=-1
Sep 09 10:25:30 maila nscd[704]: nss_ldap: could not search LDAP server - Server is unavailable
Sep 09 10:25:30 maila nscd[704]: nss-ldap: do_open: do_start_tls failed:stat=-1
Sep 09 10:25:30 maila nscd[704]: nss_ldap: reconnecting to LDAP server...
Sep 09 10:25:30 maila nscd[704]: nss-ldap: do_open: do_start_tls failed:stat=-1
Sep 09 10:25:30 maila nscd[704]: nss_ldap: reconnecting to LDAP server (sleeping 1 seconds)...
Sep 09 10:25:31 maila nscd[704]: nss-ldap: do_open: do_start_tls failed:stat=-1
Sep 09 10:25:31 maila nscd[704]: nss_ldap: could not search LDAP server - Server is unavailable
Sep 09 10:25:31 maila root[16516]: /etc/init.d/slapd start (pid: 16505, ppid:    1 systemd)
Sep 09 10:25:31 maila slapd[16517]: @(#) $OpenLDAP: slapd  (Jul 29 2019 12:44:50) $
                                            Debian OpenLDAP Maintainers <pkg-openldap-devel@lists.alioth.debian.org>
Sep 09 10:25:31 maila slapd[16517]: Loaded metadata from "/usr/share/univention-management-console/saml/idp/ucs-sso.XXXXXXXXXXXXXX.de.xml"
Sep 09 10:25:31 maila slapd[16517]: /etc/ldap/slapd.conf: line 169: rootdn is always granted unlimited privileges.
Sep 09 10:25:31 maila slapd[16517]: main: TLS init def ctx failed: -1
Sep 09 10:25:31 maila slapd[16517]: DIGEST-MD5 common mech free
Sep 09 10:25:31 maila slapd[16517]: DIGEST-MD5 common mech free
Sep 09 10:25:31 maila slapd[16517]: slapd stopped.
Sep 09 10:25:31 maila slapd[16517]: connections_destroy: nothing to destroy.
Sep 09 10:25:31 maila slapd[16505]: Starting ldap server(s): slapd ...failed.
Sep 09 10:25:31 maila slapschema[16520]: Loaded metadata from "/usr/share/univention-management-console/saml/idp/ucs-sso.XXXXXXXXXXXXXX.de.xml"
Sep 09 10:25:31 maila slapschema[16520]: DIGEST-MD5 common mech free
Sep 09 10:25:31 maila slapd[16505]: 5d760c7b /etc/ldap/slapd.conf: line 169: rootdn is always granted unlimited privileges..
Sep 09 10:25:31 maila systemd[1]: slapd.service: Control process exited, code=exited status=1
Sep 09 10:25:31 maila systemd[1]: Failed to start LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol).

Hat jemand eine Idee wie ich die verfahrene Kiste wieder zum laufen bekomme / wo ich weiter mit der Suche ansetzen kann?

Danke im Voraus

#2

Hallo,
du scheinst ein Zertifikatsproblem zu haben.

main: TLS init def ctx failed: -1

Möglicherweise kann die dieser Foreneintrag helfen Renew Certs
Beste Grüße
pider

#3

Das war auch einer meiner ersten Gedanken. Das hatte ich ja schon gemacht und auch überprüft. Auch mittels der Suchmaschine meines Vertrauens bin ich da nicht weiter gekommen. Hier der akt. Output:

univention-certificate dump -name XXX.XXXXXXXXXXXXXX.de |grep "Not "
            Not Before: Aug  8 21:25:51 2018 GMT
            Not After : Aug  7 21:25:51 2023 GMT
            Not Before: Sep  9 07:34:30 2019 GMT
            Not After : Sep  7 07:34:30 2024 GMT


ls -ahl /etc/univention/ssl
insgesamt 32K
drwxr-xr-x  6 root DC Backup Hosts 4,0K Sep  9 09:59 .
drwxr-xr-x 11 root root            4,0K Sep  9 11:11 ..
lrwxrwxrwx  1 root DC Backup Hosts   44 Aug  8  2018 XXX -> /etc/univention/ssl/XXX.XXXXXXXXXXXXXX.de   <- korrekt
drwxr-x---  2 2001 DC Backup Hosts 4,0K Sep  9 09:34 XXX.XXXXXXXXXXXXXX.de <- korrekt
drwxr-x---  2 root DC Backup Hosts 4,0K Sep  9 09:59 XXX.XXXXXXXXXXXXX.de <- keine ahnung, taucht sonst nirgends auf, tippfehler
-rw-rw----  1 root DC Backup Hosts 2,8K Mär 24 20:39 openssl.cnf
-rw-rw----  1 root DC Backup Hosts   20 Aug  8  2018 password
drwxrwxr-x  6 root DC Backup Hosts 4,0K Sep  9 09:59 ucsCA
drwxr-x---  2 root DC Backup Hosts 4,0K Aug  8  2018 ucs-sso.XXXXXXXXXXXXX.de <- korrekt
#4

Was steht denn in deiner slapd.conf . Passen die Zertifikatspfade ?

#5

Ja, hatte ich schon kontrolliert, passt.

#6

Auslöser könnte gewesen sein dass root nach dem nächtlichem Backup vollgelaufen war. Das Backup erfolgt auf eine Freigabe, die wurde wohl nicht gemountet und so lag eine große fette Datei unter /mnt/… .

Backup Datei gelöscht, Neustart, mysql äuft nicht, tc.cnf gelöscht, mysql startet, ok. Das hatte ich die letzten 2-3 Wochen leider schon 2 oder 3x, suche noch die Ursache wieso die Freigabe nicht korrekt angebunden wird, werde wohl das Backupskript extra noch anpassen dürfen.

Ungeachtet dessen startet nun der slapd Dienst nicht mehr und damit wird beinahe das gesamte System unbrauchbar.

#7

Hast du slapd mal im debug mode gestartet ? e.g. slapd -d -1

1 Like
#8

Danke, das habe ich vorhin gesucht (mehr debug output oder irgendwo ein log mit mehr verbosity) und das kam als Output:

. . . . hunderte Zeilen später und direkt am Ende:
TLS: could not read DH parameters file `/etc/ldap/dh_2048.pem'.
TLS: error:0906D06C:PEM routines:PEM_read_bio:no start line ../crypto/pem/pem_lib.c:686
5d76940f main: TLS init def ctx failed: -1
5d76940f slapd destroy: freeing system resources.
5d76940f shadowbind_db_destroy
5d76940f OVER: db_destroy
5d76940f slapd stopped.
5d76940f connections_destroy: nothing to destroy.

root@XXX:~# ls -ahl /etc/ldap/dh*
-rw-r--r-- 1 root root 0 Sep  9 04:31 /etc/ldap/dh_2048.pem

root@XXX:~# openssl dhparam -out /etc/ldap/dh_2048.pem 2048

root@XXX:~# ls -ahl /etc/ldap/dh*
-rw-r--r-- 1 root root 424 Sep  9 20:08 /etc/ldap/dh_2048.pem

Der Dienst lässt sich anschließend neu starten und nach einem Reboot des UCS läuft augenscheinlich erstmal alles wieder - was auch immer die Datei heute früh 04:31 genullt hat.

Problem gelöst - wie auch immer das entstanden ist.

#9

Step 5 - Possibility B

1 Like
#10

Exakt dieses Problem, diese Ursache und diese Lösung. Habe ich hier halt nicht gefunden weil vmtl. immer die falschen Fragen gestellt.

Mastodon