Anbindung Nextcloud Anleitung

Hallo,

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
  • UUID-Attribute für Benutzer: samaccountname
  • UUID-Attribute für Gruppen: leer lassen
4 „Gefällt mir“

Hi Dominik,

danke für die Anleitung.

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.

??
VG, Tobias

Hallo Tobias,

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.

Viel Glück

LG

Holger

Hi Holger, hi dominik,

es scheint zu funktionieren:
Ich habe

es genauso gemacht.

  • 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.

Danke!
Vg, Tobias

Hallo!

und wie reiche ich den Port nach außen durch?

Bekomme mit

openssl s_client -connect $ip_in_rot_des_opnsense:636

nur

140056110483264:error:0200206E:system library:connect:Connection timed out:…/crypto/bio/b_sock2.c:110:
140056110483264:error:2008A067:BIO routines:BIO_connect:connect error:…/crypto/bio/b_sock2.c:111:
connect:errno=110

Gruß Enrico

Hallo Enrico,

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.

LG

Holger

Also ich habe jetzt anstatt der Belwue, WAN net drin…aber es tut immernoch nicht…

Nextcloud auf docker in grün selbst ist erreichbar: meine Cloud

Hallo!

Also ich kann jetzt ‚openssl s_client -connect cloud.luckau-digital.de:636‘ machen. Aber nextcloud sperrt sich immer noch.

> CONNECTED(00000005)
>depth=0 O = Forscherlabor Schlabendorf, OU = FORSCHERLABOR, CN = server.forscherlabor.lan, subjectAltName = server.forscherlabor.lan
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 O = Forscherlabor Schlabendorf, OU = FORSCHERLABOR, CN = server.forscherlabor.lan, subjectAltName = server.forscherlabor.lan
verify error:num=21:unable to verify the first certificate
verify return:1
>---
>Certificate chain
 0 s:O = Forscherlabor Schlabendorf, OU = FORSCHERLABOR, CN = server.forscherlabor.lan, subjectAltName = server.forscherlabor.lan
   i:O = Forscherlabor Schlabendorf, OU = FORSCHERLABOR, CN = FORSCHERLABOR.LAN, subjectAltName = FORSCHERLABOR.LAN
>---
>Server certificate
-----BEGIN CERTIFICATE-----
MII...
-----END CERTIFICATE-----
subject=O = Forscherlabor Schlabendorf, OU = FORSCHERLABOR, CN = server.forscherlabor.lan, subjectAltName = server.forscherlabor.lan
>issuer=O = Forscherlabor Schlabendorf, OU = FORSCHERLABOR, CN = FORSCHERLABOR.LAN, subjectAltName = FORSCHERLABOR.LAN
>---
>Acceptable client certificate CA names
O = Forscherlabor Schlabendorf, OU = FORSCHERLABOR, CN = FORSCHERLABOR.LAN, subjectAltName = FORSCHERLABOR.LAN
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA+SHA256:ECDSA+SHA256:RSA+SHA384:ECDSA+SHA384:RSA+SHA512:ECDSA+SHA512:RSA+SHA224:ECDSA+SHA224:RSA+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms: RSA+SHA256:ECDSA+SHA256:RSA+SHA384:ECDSA+SHA384:RSA+SHA512:ECDSA+SHA512:RSA+SHA224:ECDSA+SHA224:RSA+SHA1:ECDSA+SHA1
Peer signing digest: SHA256
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
>---
>SSL handshake has read 1567 bytes and written 463 bytes
Verification error: unable to verify the first certificate
>---
>New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 43...
    Session-ID-ctx: 
    Master-Key: 6....
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1569576151
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
    Extended master secret: yes
---

Hallo odo2063,

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:
grafik

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).

VG, Tobias

Hallo!

Also ich habe jetzt mal noch den Port 389 rausgezogen und das geht. :-/

gibt es noch Ideen wie ich das mit Verschlüsselung hinbekomm?

Ansonsten noch die Anmerkung, dass die Lehrer ja in der Gruppe „teachers“ sind, wie bringt man dem LDAP neue Gruppen bei? (z.B. alle_Lehrer)

Gruß Enrico

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?

VG
Wolfgang

Hallo Wolfgang,

ich hab da nichts mit Zertifikaten rumgemacht, sondenr in die /etc/ldap/ldap.conf auf dem NC Server am Ende den Eintrag gemacht:

TLS_REQCERT never

Meine NC config siehst du hier (für die lmn7).
Die IP meines lmn7 Servers ist aufgewischt.

Interne Domain des Schulservers ist bzpf.lan

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.

LG

Holger

Hi,

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:

ldapsearch -b „ou=default-school,ou=SCHOOLS,dc=meineschule,dc=lan“ -H ldaps://server.meineschule.lan:555 -x -D „CN=global-binduser,OU=Management,OU=GLOBAL,DC=meineschule,DC=lan“ -w lxlxlxlxlxlxlx CN=meinlogin

Dann bekomme ich Ergebnisse …

Da sollte alles stimmen … geht aber nicht …

VG
Wolfgang

Ergänzung:

Noch mehr seltsam …

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?

Hallo Wolfgang,

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 :slight_smile:

So hat das zumindest damals bei Owncloud 7 funktioniert wo LDAP
einrichten noch viel hakeliger war.

LG

Holger

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 …

Zur „Lösung“ des Problems …

neuer Anlauf …

Auf der OPNSense war auf der NIC für das WAN der Haken für block bogon noch drinnen und nachdem ich ja durch ein privates Transfernetz muss …

VG
Wolfgang

Hallo,

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.

Grüße,
Stefan