die LDAP-Anbindung der lmn7.1 für Moodle und Nextcloud werde ich vermutlich hinbekommen.
Meine Frage ist aber: bleiben die Nutzer so erhalten wie bisher? Das wäre für die beiden Systeme enorm wichtig, da ja sonst die ganzen Dateien bzw. Kurse auch weg wären.
Welche möglichen Stolpersteine/Fallen gibt es?
Ich habe noch Probleme, mich mit dem LDAP von außen zu verbinden. Es scheint ein Zertifikatsproblem zu sein.
Wenn ich von außerhalb den Server so anfrage (Port 637 wird an der FritzBox auf 636 umgeleitet und über die opnsense an den Server weitergeleitet): ldapsearch -x -H "ldaps://domäne:637" -d1
dann erhalte ich folgende Fehlermeldung:
Mit einer zusätzlichen Zeile in /etc/ldap/ldap.conf auf dem anfragenden Client: TLS_REQCERT never verschwindet der Fehler.
Was muss ich auf dem Server noch machen, damit es klappt? Auf der Moodle Seite habe ich keine Option gefunden, die Zertifikatsprüfung auszuschalten.
ständig fallen mir neue Stolpersteine ein.
Ich hatte die Nextcloud vor ca. 4 Jahren bei der Einstellung LDAP-Experte-Interner Benutzername auf „uid“ mit der lmn6.2 umgestellt. Seitdem wurden die Benutzer und ihre Verzeichnisse mit ihrer lesbaren uid angelegt, statt der LDAP/SAMBA(?) Form wie z.B. a85c781e-07b7-1037-8f14-aba2445373f9.
Ich habe also inzwischen bei Lehrern und Schülern einen Mischmasch.
Hat von euch schon jemand in diesem Szenario von lmn6.2 auf lmn7.1 geupdatet und die LDAP-Anbindung erneuert? Ich habe Angst, dass mir einige Benutzer fehlen bzw. nicht mehr richtig zugeordnet werden.
VG
Christian
Gerade habe ich versucht, die LDAP-Authentifizierung der Nextcloud vom alten Server auf den Server der LMN7.1 umzustellen.
Dazu habe ich den Server (wie auch in Moodle) mit dem entsprechenden Port angegeben, einen eigenen Bind-User erstellt und den auch eingetragen und die Base DN. Außerdem noch in den Einstellungen für Fortgeschrittene die Zertifikatsprüfung ausgeschaltet und auch in /etc/ldap/ldap.conf TLS_REQCERT never eingetragen, bzw. das war schon drin. Dennoch findet er den LDAP-Server nicht und kann die Konfiguration nicht abschließen. Die Fehlermeldungen im Fenster sind:
Die Base-DN scheint falsch zu sein.
Lost connection to LDAP server.
Erstaunlicherweise kann ich aber mit ldapsearch und den verwendeten Daten vom Nextcloud Server aus das Verzeichnis abfragen.
Wo könnte ich nun noch weiter suchen?
VG
Christian
Edit:
In den logs /var/log/nextcloud/nextcloud.log finde ich diese Zeile:
{„reqId“:„7iBBgUt7XeOMPzVXbL0G“,„level“:0,„time“:„2023-08-28T07:20:08+00:00“,„remoteAddr“:„“,„user“:„–“,„app“:„user_ldap“,„method“:„“,„url“:„–“,„message“:„Calling LDAP function ldap_unbind with parameters false“,„userAgent“:„–“,„version“:„27.0.2.1“,„data“:{„app“:„user_ldap“}}
tut mir leid. Das Problem hat sich weitgehend gelöst.
Ich habe den Nextcloud Server an die Stelle gepflanzt, wo sie auch später bleiben soll DMZ der neuen LMN71. Da funktioniert die LDAP - Abfrage und ich kann mich verbinden.
Ich muss nur noch schauen, wie ich die verschiedenen Kalender rüberrette. Die Dateien sind aber da, Gruppenverzeichnisse auch, manche geteilten Dateien aber nicht mehr.
Wie jedes mal: Herzlichen Dank für’s Mitlesen und die Anleitung ist super (Externe Authentifizierung - Nextcloud — linuxmuster.net 7.1 Dokumentation).
VG
Christian
Eine Sache hat mich viel Zeit gekostet: wenn man die LDAP-Anbindung ändert, geht man am besten so vor:
an der alten Stelle im lmn6.2 als lokaler Admin (für die Nextcloud) anmelden und die alte LDAP-Konfiguration abschalten (im Abschnitt Fortgeschrittene)
dann den Server umziehen (auch evtl. die IP-Adressen und die Einträge in /etc/hosts ändern) und die neuen LDAP-Einstellungen eintragen. Wenn das klappt wieder scharf stellen
Versucht man, sich mit einer nicht funktionierenden LDAP-Konfiguration als lokaler Admin anzumelden, kommt (zumindest bei mir, vielleicht auch wegen des HAProxys) ein interner Serverfehler. Man kann zwar die app user_ldap in der Nextcloud vorübergehend abschalten und sich anmelden. Aber um die neuen Einstellungen vorzunehmen, muss man das Plugin wieder aktivieren und dann landet man/ich wieder auf dem internen Serverfehler.