in Ermangelung von Zeit hier eine kurze Beschreibung, wie man eine Nextcloud per ldap an die lmn7 anbindet. Voraussetzung ist, dass der Zugriff von außen auf den Port 636 zum Server in der Opnsense freigeschaltet ist:
1. Server:
ldaps://ExterneIP
Port: 636
Benutzerdn: holt man sich aus /etc/linuxmuster/webui/config.yml bei binddn
Passwort: steht in /etc/linuxmuster/.secret/global-binduser
Basedn: OU=SCHOOLS,… den Rest findet man wieder in /etc/linuxmuster/webui/config.yml bei searchdn
–> Fortsetzen
2. Benutzer:
Nur diese Objetklassen: person
Dann bei “Nur aus diesen Gruppen:” einfach die Gruppen auswählen, die sich an der Cloud anmelden können sollen
–> Fortsetzen
3. Anmeldeattribute:
Haken bei LDAP-/AD-Benutzername
–> Fortsetzen
4.Gruppen:
Nur diese Objektklassen: group
Dann bei “Nur aus diesen Gruppen:” einfach die Gruppen auswählen, die als Tauschgruppen in der Cloud zur Verfügung stehen sollen
5. Fortgeschritten
Alles so lassen nur bei Ordnereinstellungen beim Punkt “Assoziation zwischen Gruppe und Benutzer” member(AD) auswählen
6. Experte
Dieser Punkt ist wichtig, wenn man in der Cloud die Benutzernamen sehen will und nicht irgendwelche UUID’s. Desweiteren bekommen die Nutzerordner im Nextcloudstorage den Namen des Benutzers und keine UUID.
Attribut für interne Benutzernamen: samaccountname
An alle diese Frage:
ICh habe schon immer bei Experte statt leer zu lassen das Attribut für den internen Benutzernamen und das LDAP-Mapping auf „uid“ stehen gehabt. Ich habe immer noch die Hoffnung, dass ich die Cloud einfach umziehen kann, ohne die User neu anzulegen.
Hat das jemand schon geschafft: Die Cloud gegenüber der v7 zu authentifizieren, ohne dass dabei alle User neu waren, d.h. die Shares neu mgemacht werden mussten, kalender neu erstellt und geteilt, circles neu angelegt, usw.
ICh habe schon immer bei Experte statt leer zu lassen das Attribut für
den internen Benutzernamen und das LDAP-Mapping auf „uid“ stehen gehabt.
ich nicht: deswegen mach ich es nach Dominiks Art.
Ich habe immer noch die Hoffnung, dass ich die Cloud einfach umziehen
kann, ohne die User neu anzulegen.
Hat das jemand schon geschafft: Die Cloud gegenüber der v7 zu
authentifizieren, ohne dass dabei alle User neu waren, d.h. die Shares
neu mgemacht werden mussten, kalender neu erstellt und geteilt, circles
neu angelegt, usw.
ich würde das eiskalt so machen:
nextcloud auf dem Server klonen, MAC Adresse ändern, andere externe IP
und URL eintragen (im Server und in der config.php) und den server rebooten.
Dann sollte also ein klon unter anderem Namen im Netz sein.
Jetzt kannst du in dem Wüten: also an die V7 anbinden und dann
ausgewählten Kollegen die URL geben und sagen: meldet euch mal an und
schaut, ob alles da ist.
Ist es das: das Orginal nochmal klonen (man ist ja paranoid…) und dann
das Orginal umstellen.
Einmal habe ich noch LDAP-Gruppennamenzuordnung löschen gedrückt, bin mir aber nicht sicher, ob das sein soll/darf/muss.
Die App „Circles“ musste ich zunächst deaktivieren und auf dem Cloudserver hat sich ein php-Prozess aufgehängt. Mein Home_auf_Server share für alle habe ich auch mal vorsichtshalber entfernt.
Danach funktioniert aber das Einloggen per „kuechel“ und die Shares sind da. Die Kalender sind da und auch deren Shares. Die Nutzer und Gruppen werden angezeigt.
Später konnte ich „circles“ dann auch wieder aktivieren und die Nutzer sind dann da.
Allgemein: Man braucht eventuell viel Geduld, weil Nextcloud sich im Hintergrund irgendwie neu sortieren muss und ein fehlgeschlagenes Login kann man im nextcloud.log sicher mal anschauen, bevor man diesen Weg hier verwirft.
tut mir Leid, dass es so lange gedauert hat…
Hier ist ein Bild meiner Regel:
Firewall->NAT->Portweiterleitung
Da erlaube Ich ZUgriff von 129.143.0.0/16 (BelWü Adressen) auf den Port 636 des Servers.
ich kann nur raten: die LDAP-Konfiguration einmal komplett löschen (natürlich muss man sich alle Daten merken) und nochmal von vorne anfangen.
Der GUI dieser Extension traue ich nicht (mit gutem Grund).
VG, Tobias
Evlt. mal ein neuer Thread wert: Gruppen in Gruppen in LDAP/AD und dann in den angehängten Services, hier Nextcloud:
Ich hab die Checkbox „Eingebundene Gruppen“ in der Fortgeschrittenen Konfiguration (bin mir nicht sicher, ob ich das aktiv machen musste, oder ob das standardmäßig aktiviert ist) siehe hier:
Und das Fazit ist, dass es zwar funktioniert, dass Schüler aus der 10a, deren GRuppe 10a im Projekt „p_schueler“ aufgenommen wurde, in der Cloud auch der Gruppe „p_schueler“ angehören.
Allerdings ist das etwas frustrierend, wenn man es aktuell überprüfen will.
Die Cloud scheint zu cachen und ich kann nicht vorhersagen, wann ein User, der über die SChulkonsole aufgenommen wurde, dann auch in der Cloud erscheint. Aber, es funktioniert irgendwann. (cron.php hab ich schon ausprobiert).
Liebe Kollegen,
ich muss dieses Thema nochmal aufgreifen. Aktuell versuche ich eine Umkonfigurierung meiner extern gehosteten Nextcloud, damit ich sie an die V7 abinden kann.
In einer der Anleitungen für die V6 steht, man müsse auf dem Server der NC in der Hosts-Datei den Servernamen (server.linuxmuster.net) an die externe IP koppeln, weil das sonst mit dem Zertifikat nicht klappt - ok, leuchtet ein.
Dann soll man die server.crt von der Linuxmuster auf den NC-Server kopieren. Hab ich damals für die V6 gemacht, hat geklappt. Bei der V7 gibt es aber das Server-Zertifikat nicht. Kann das sein? Im Ordner von CUPS liegt eines rum, aber das kann es ja wohl nicht sein?
Wie ist jetzt das aktuelle Vorgehen für die V7?
Denk dran: ich mach ein datamining: die Nutzer werden also in der NC nicht mit einer eigenen ID versehen, sondern der samaccountname der lmn7 wird verwendet.
Das muss bei dir vorher auch schon so gewesen sein, sonst kann die NC die neuen nutzer nicht richtig zuordnen und jeder wird neu angelegt.
danke - werde den Setup mal versuchen.
Was mich irritiert, ist die Tatsache, dass bereits beim Testen vom Base DN zwei Fehler angezeigt werden:
„BaseDN scheint falsch zu sein“
„Lost connection to ldap-server“
Ergänzende Info:
Ich muss durch eine weitere FW durch, in der für mich Port 555 geöffnet wurde.
Ich hab den Port in der OPNsense mal probehalber auf Port 22 genattet und komm an den Server mit seinem DNS-Namen ran. Es wird also richtig aufgelöst und die FW leitet auf den gewünschten Port weiter. Jetzt hab ich die Regel abgeändert und auf den 636er eingestellt. Warum dann die Verbindung zum LDAP-Server „verloren“ wird?
Wenn ich von der Shell allerdings das hier absetze:
Ich hab probehalber mal den Haken bei „LDAP-Filter manuell eingeben“ gesetzt und den BaseDN testen lassen. Da sprang die Konfig auf grün und meldete mehr als 1000 Einträge.
Blöd wie ich bin, wollte ich das reproduzieren:
Haken raus: Fehler
Haken wieder rein. AUCH FEHLER !!!
Ich hab probehalber mal den Haken bei „LDAP-Filter manuell eingeben“
gesetzt und den BaseDN testen lassen. Da sprang die Konfig auf grün und
meldete mehr als 1000 Einträge.
Blöd wie ich bin, wollte ich das reproduzieren:
Haken raus: Fehler
Haken wieder rein. AUCH FEHLER !!!
Wieso geht das EINMAL und dann nicht mehr?
die Wege des Herrn sind unergründlich …
In so einem Fall: LDAP config löschen (Knopf auf der ersten LDAP
einstellungsseite) und eine neue anlegen
So hat das zumindest damals bei Owncloud 7 funktioniert wo LDAP
einrichten noch viel hakeliger war.
Aktuell sprang die „Ampel“ wieder auf grün, ich kann aber auf der zweiten Seite keine Objektklasse auswählen …
Ich glaube „lost connection …“ dürfte das Hauptproblem an der Sache sein …
…
Bin jetzt einmal durch die Konfiguration durch, allerdings nicht mit allen deinen Einstellungen,
da zwischendurch immer wieder die Verbindung verloren wurde und ich wollte erst mal einfach
durch sein …
Können diese Verbindungsabbrücke mit der OPNSense zu tun haben?
Ich hab die NAT Regel 636 -> 636 geclont und auf 555->636 geändet. Da sollte doch nicht mehr nötig sein.
Ich sehe die Anfrage auch grün im LiveLog … was kann so einen Verbindungsabbruch bewirken?
Ergänzung:
Gerade eben ist einmalig eine Anmeldung gegangen, dann ist anscheinend die Verbindung wieder abgebrochen und ich bin auf einen internen Serverfehler zurück gefallen …
Ergänzung II:
Hab testweise eine Rolle rückwärts gemacht und den alten Server mit der IPFire wieder aktiviert, die Verbindungsdaten eingetragen, … kein Abbruch, sauberer Connect, …
Tja … liegt es an der Konfig der OPNsense oder der vom NC-Server …
Ich habe bei uns gerade umgestellt, die Angaben in der Anleitung passen, allerdings bekam ich nach Anmeldung als Lehrer einen neuen leeren Account zugewiesen, der in der Benutzerliste dann doch als UUID auftauchte (trotz samaccountname). Ich habe dann als Admin in den LDAP-Experten-Einstellungen trotz Warnung, das auf Produktivsystemen nicht zu machen, auf LDAP-Benutzernamenzuordnung löschen
geklickt, mich wieder als Lehrer angemeldet und war in meinem alten Account mit allen Daten, die sich auch bearbeiten lassen.