Ldap authentifizierung geht nichtmehr

Hallo,

nach einer 24 Stunden Schicht zum Versuchen das Problem zu lösen, wende ich mich an euch und hoffe ihr habt Tipps für mich. :wink:

Ich betreibe virtualisiert (Proxmox) einen Linuxmuster 6.2 Server. Im grünen Netz habe ich zusätzlich einen Ubuntu 18.04.2 Server mit einer Nextcloud und einer Moodle Plattform. Seit gestern mittag funktioniert plötzlich die ldap Authentifizierung bei beiden Plattformen nichtmehr.

Mit ldapsearch -x -h 10.16.1.1 -s sub -b ‚dc=linuxmuster-net,dc=lokal‘ „uid=dummy“ kann ich die ldap Daten der einzelnen Benutzer vom Ubuntuserver aus ohne Probleme abrufen. Auch die ldap-test Funktionen unter der Nextcloud funktionieren. Nur die Authentifizierung schlägt fehl. (bei moodle „ungültige Anmeldedaten“, bei Nextcloud „falsches Passwort“ und wenn ich obigen ldapsearch befehl um „-W“ ergänze „ldap_bind: Invalid credentials (49)“)

Anmelden mit den Benutzerdaten an Client PCs und der Schulkonsole funktioniert problemlos.
Auch (da wirds langsam komisch) die Anmeldung als Lehrer an Veyon (italc Nachfolger) auf den Clients, welches ebenfalls über ldap authentifiziert.

Wenn ich direkt auf der Linuxmuster Console ldapsearch -x -h 10.16.1.1 -s sub -b ‚dc=linuxmuster-net,dc=lokal‘ -W „uid=dummy“ eingebe, bekomm ich auch die antwort „Invalid credentials (49)“

Merkwürdig: wenn ich bei der Passwortabfrage bei ldapsearch einfach Enter drücke ohne ein Passwort einzugeben bekomm ich dennoch kommentarlos die ldap Daten - ist das normal?

Bevor das Problem auftauchte habe ich ein wenig an den DNS Forward Einstellungen der Firewalls rumgepfuscht, um die Moodleplattform intern direkt erreichbar zu machen. Aber zum einen sollte das nichts mit dem Problem zu tun haben (Moodle/Nextcloud steht ja im grünen Netz), zum anderen habe ich sicherheitshalber schon alles wieder auf die ursprünglichen Einstellungen zurückgesetzt. (in meiner Verzweiflung habe ich sogar schon sämmtliche virtuelle Maschinen inklusive Proxmox selbst neu gestartet… hat leider auch nichts gebracht :wink: )

Ich hoffe ihr könnt mir ein wenig weiterhelfen, ich steh irgendwie auf dem Schlauch, das ergibt für mich keinen Sinn…

viele Grüße
Michael

Hallo Michael,
hast Du die Log-Ausgabe von ldap auf dem LMN - Server mit -vv mal mit Details angeworfen und Dir die Log-Ausgabe angesehen?
Hast Du mal auf abgelaufene Zertifikate geprüft?
VG
Chris

Hallo Chris,

edit: Habe die logs doch gefunden:
der gescheiterte auth mit ldapsearch in der /var/log/auth.log:
nss_ldap: reconnecting to LDAP server…
nss_ldap: reconnected to LDAP server ldap://localhost/ after 1 attempt
nss_ldap: reconnecting to LDAP server…
nss_ldap: reconnected to LDAP server ldap://localhost/ after 1 attempt

Zertifikate sollten kein Problem sein, ich nutze ldap ja nur intern und unverschlüsselt, oder?

Eine Sache ist mir eingefallen: ich habe gestern kurz linuxmuster-setup --modify aufgerufen, da ich dachte dort würde man dns Einstellungen des Servers sehen (Denkfehler, wurde mir schon gleich nach dem eintippen klar). Habe mich nur schnell durchgeklickt, ohne etwas zu ändern. Das ist trotzdem bislang der heißeste Kandidat für die Ursache, denn die 2 Einstellungen die ich sonst noch in der weboberfläche des IPfires gemacht hab, habe ich längst rückgängig gemacht und ihn neu gestartet…

viele Grüße
Michael

Hallo Michael,

das mit dem linuxmuster-setup --modify ist mir auch mal passiert…

Dabei wurde bei mir auch die ldap-Konfiguration auf die „Werkseinstellungen“ zurückgesetzt. Ein Backup der funktionierenden Konfiguration sollte sich jedoch in /var/backup/linuxmuster finden (als *.gz).

Viele Grüße

Andreas

Hallo Michael,
spiele wie von Andreas vorgeschlagen, die bisherige ldap Konfig zurück. Danach der prüfe bitte, ob slapd und ldap laufen und den Inhalt deren Konfig-Dateien. Falls nicht, bitte starten.
Dann prüfe, was folgender Befehl ausgibt:

ldapsearch -x -H ldap://10.16.1.1

Falls Du doch mit Verschlüsselung arbeitest, musst Du bei obigem Befehl als Protokoll ldaps angeben.
VG
Chris

Vielen Dank!

das zurückspielen der Backup confs (+ neustart der Service) hat geholfen (wobei die eigentlich im orginalzustand gewesen sein müssten… auf den ersten Blick habe ich keine Unterschiede gesehen).

Merkwürdig ist, dass ich mit
ldapsearch -x -h 10.16.1.1 -s sub -b ‚dc=linuxmuster-net,dc=lokal‘ -W „uid=dummy“
in der Console (sowohl linuxmuster auch server von moodle und nextcloud) noch immer nach passworteingabe ein „invalid credentials (49)“ bekomme - der Login bei moodle und Cloud geht aber wieder.
Ist irgendwas an der Abfrage falsch? Die identische Abfrage nur ohne „-W“ liefert mir problemlos die ldap daten den users dummy zurück…

viele Grüße und Danke nochmals!
Michael