Situation: LDAPs Verbindungen sollen via pfSense und dem dortigen HAProxy an den LD-Server ge-proxied werden, um mehr Kontrolle über die zulässigen LDAP-Hosts zu haben als mit plain LD-Server.
Problem: Obwohl die LDAPs Verbindung vom Client via pfSense und HAProxy zum lokalen LDAP-Server klappt, geht keine Antwort vom LDAP-Server nach Außen.
Lösung: TLS1.3 verbieten – mit TLS1.2 funktioniert es. Das Feld im Frontend nennt sich „Advanced ssl options“ und braucht den folgenden Eintrag:
no-tlsv13
Dann ist es im übrigen auch auf der pfSense einstellbar, dass es Wurst sein soll, dass das LDAP-Zertifikat auf dem LD-Server self signed ist. Hauptsache das Zertifikat in Richtung Internet ist sauber (z.B. Let’sEncrypt-Certificate mit ACME Plugin für pfSense), damit sich z.B. ein Moodle verbinden kann.
Irgendein Update (vermutlich im Dezember 21) zerschoss mir hier den Mount des schulweiten Tauschverzeichnisses in die Nextcloud. Mit den folgenden Einstellungen tut es dann wieder:
Hinweis: Mit smbclient -L 10.16.1.1 gucken, was der LD-Server so rausposaunt.
Question 2 Answer ist eine nette PHP-MySQL-Alternative to askbot und bringt hier auch ein LDAP Auth-Plugin mit. Will man dieses nutzen, um gegen einen LD-Server zu authentifizieren, dann kann man die folgenden Einstellungen wählen, damit „es tut“:
Selbstverständlich wäre hier für den Produktivbetrieb in unsicherer Umgebung LDAPs und Port 636 zu wählen.
Ich bin zuerst nicht auf die Idee gekommen, hier AD auszuwählen und versucht zuerst mit OpenLDAP zum Ziel zu gelangen. Das wollte nicht klappen, so dass ich in einem Anfall von „mal gucken“ plötzlich wie oben gezeigt Erfolg hatte.
Weil es so ein unschönes Gefummel war, dokumentiere ich hier für mich (und auch andere Benutzer von LD / SBE) die Anbindung der nextCloud per LDAPs an den LD-Server, die dafür sorgt, dass beim Login der Benutzer gleich noch deren Tausch- und Homeverzeichnisse in die nextCloud gelupft werden. Dass dann bei uns noch Collabora CODE dazukommt rundet die Sache schön ab.
Kurz zum allgemeinen Setup: Eine VM mit Ubuntu 18.04 LTS werkelt intern auf einem Virtualisierungshost, der mit seinen Netzwerkkarten in den jeweils für ihn wichtigen VLANs hängt. Auf diesem bridgen die VMs direkt in die VLANs rein. In Richtung Internet steht vor diesem VM-Host eine PFSense als Firewall in den jeweils relevanten Netzen.
Die VM für nextCloud etc. hat zwei virtuelle Netzwerkkarten: Eine zeigt via grauem VLAN in Richtung PFSense (damit in Richtung Internet) und trägt die öffentliche IP des Servers. Die andere Netzwerkkarte hängt als Bridge im grünen VLAN und wird vom LD-Server direkt versorgt. Über diese zweite („grüne“) Netzwerkkarte hole ich mir per LDAPs die Benutzerdatenbank und führe den SMB/CIFS-Mount der Homeverzeichnisse aus.
Das Paket php-ldap muss an Bord und konfiguriert sein.
Hinweis: Den Zertifikatscheck kann man im nC LDAP Modul ausschalten für die ersten Tests – oder direkt auf der VM in /etc/ldap/ldap.conf durch den Eintrag TLS_REQCERT allow. Nicht schön, aber zum Testen eine Fehlerquelle weniger.
Die Server-IP mit vorangestelltem ldaps:// und im Feld Port 636 eintragen. Die zwei folgenden Felder können für LD-Server leer gelassen werden.
Da das automatische Auslesen der Base DN bei mir nicht funktioniert hat, musste ich diese von Hand angeben. In meinem Fall: ou=users,dc=kvfg-schule,dc=de
Beim LD-Server liegen die User in ldUserAccount.
Die Loginattribute wählt das von mir hier verwendete nC 15 dann von selbst richtig aus.
DIe passende Objektklasse ist posixGroup.
Das würde nun reichen, um die Benutzer in nC rein zu lassen und auch, um das Tauschverzeichnis automatisch einzubinden, aber nicht, um die Homeverzeichnisse der User automatisch zu mounten. Das liegt daran, dass nC aus dem LDAP die UUID nimmt, um die nC-Benutzernamen zu erstellen. Wir brauchen aber für den Automount der Homes unserer Benutzer deren uid (das ist dann gleichzeitig der Benutzername des Users). Es gilt demnach, nC zu überreden, die UUID zu ignorieren und stattdessen die uid der LDAP-Benutzer zu verwenden.
Auf der Registerkarte Expert finden wir diese Möglichkeit. Bei Internal Username Attribute muss uid eingetragen werden.
Hinweis: Im Reiter Advanced gibt es die Möglichkeit, die von nC lokal erstellten Benutzerverzeichnisse (im Datenverzeichnis von nC) mit %uid benamen zu lassen, statt mit der UUID. Das geschieht durch die Einstellungen oben nun automatisch so. Man darf die Angabe auf keinen Fall doppelt machen (also im Reiter Advancedund im Reiter Expert). Die Fehlermeldungen, die man nach einem Doppeleintrag erhält, beziehen sich auf Homeverzeichnispfade, die nicht aus dem LDAP gelesen werden können. Nicht wirklich hilfreich.
Das Debugging ist wenig witzig. Was hilft, ist hier schon ausführlich beschrieben worden, weswegen ich mir diese Ausführungen heute sparen will. Was hier und heute dazu kommt: Es lohnt der regelmäßige Blick in die Datenbank von nC (z.B. über phpmyadmin). Da dürfen bei den Benutzern keine UUIDs auftauchen (das sind kryptische Kombinationen aus Zahlen und Buchstaben), sondern ausschließlich deren uids (also deren Benutzernamen). Hat das nicht geklappt, darf man von Vorne beginnen. Es empfiehlt sich deswegen, zuerst eine Basiskonfiguration anzulegen und diese zu sichern, die dann wieder eingespielt werden kann, wenn man sich in eine blöde Ecke konfiguriert hat. Das ebenfalls sehr nervige LDAP-Caching von nC lässt sich mit einem beherzten Restart des Apachen beeinflussen.
SMB/CIFS Mount
Die Pakete libsmbclient php-smbclient php-smb und auch die cifs-utils müssen installiert und konfiguriert sein. Letzteres nicht nur zum Testen, ob der SMB-Mount überhaupt funktioniert, sondern auch, weil die anderen Pakete ohne die cifs-utils nicht rund laufen werden.
Nachdem den Benutzern von nC die Verwendung von SMB/CIFS erlaubt wurde, die Einträge wie im Bild aus dem Adminaccount heraus vornehmen. Dabei den Folder Name und die IP des SMB-Servers den eigenen Gegebenheiten anpassen.
Nicht irritieren lassen, dass die „Böbbel“ beim Admin rot bleiben. Da der nC-Admin nicht aus dem LDAP kommt, sondern ein rein lokaler nC-Benutzer ist, muss der SMB-Mount hier auf die Nase fallen.
Die Einträge Login-creditials, saved in session sorgen bei den LDAP-Benutzern aber später dafür, dass die automatischen Mounts klappen. Das $user sorgt für die Ersetzung des Namens für das Home-Share durch den Benutzernamen (die uid), der beim Login in der nC angegeben wurde. Deswegen ja auch das Gefrickel mit dem LDAP oben!
Die Benutzer müssen nun nur noch aufpassen, dass sie sich nicht mit dem Desktop-Client automatisch das gesamte Verzeichnis Tausch/Schule syncen 🙂
Wie man sich per Docker noch ein Collabora CODE auf die VM mit der nC holt, ist an vielen anderen Stellen im Netz schon ausführlich beschrieben worden. Für den Alttag würde ich dann 6GB RAM und 4 CPUs für die VM empfehlen: CODE wie auch nC ziehen zusammen ziemlich an den Ressourcen.
Eines noch: Moodle 3.6 bringt die Möglichkeit zur Anbindung an eine nextCloud mit.
Summa summarum: Wer braucht da noch Ella? DIY and federation are the key!
Nach Beendigung des Klassenarbeitsmodus auf einer LD vergisst diese gelegentlich, die richtigen Pfade zurück in den LDAP Baum zu schreiben. Meldet sich der Benutzer danach an, erhält er ein Homeverzeichnis, das dem aus dem Klassenarbeitsmodus entspricht
und kommt an seine eigenen Dateien nicht mehr ran. Außerdem hat er keinen Zugriff auf die Tauschverzeichnisse.
Einfachster Weg: Den LDAP Baum in eine Datei kippen
ldapsearch -U admin > ldap-tree
Den Dump dann mit grep und Freunden nach „Klassenarbeit“ durchsuchen und die Fundstellen zusammen mit den betroffenen Benutzern inklusive username notieren.
Auf einem Client jxplorer installieren (der sich in den Ubuntu Repos befindet) und sich mit diesem mit dem LDAP auf dem Server verbinden. Der anzugebende LDAP Server ist hierbei die IP des Schulservers / LD-Servers (also z.B. 10.16.1.1), als Benutzer nehmen wir den ldap-admin, dessen genaue Bezeichnung / DN wir aus dem gerade exportierten LDAP Baum nehmen können
cn=ldap-admin,dc=kvfg,dc=tue,dc=schule-bw,dc=de
Verwendet man für diesen das Passwort des admin (Administrator), dann erhält man nur lesenden Zugriff. Schreibenden Zugriff bekommt man mit dem Passwort, das in
eintragen – und nicht den Eintrag aus ldRealHomeDirectory übernehmen, der nur den Serverpfad enthält. Auf dem LD-Server ist der Pfad oben ein Symlink.
Am Ende des Prozesses noch durch die Homeverzeichnisse – auch den ver-symlinkten Teil unterhalb von /home/dynamic – durchsehen und nach evtl. noch bestehenden Symlinks auf das ehemalige Klassenarbeitsverzeichnis suchen. Diese löschen.
Ein auf einem externen Server (z.B. bei Hetzner) gehostetes MRBS kann mit den folgenden Einstellungen per LDAPs gegenüber dem internen SBE-Serverchen mit openLDAP authentifizieren:
$auth["type"] = "ldap";
unset($auth["admin"]);
$auth["admin"][] = "admin";
$ldap_host = "ldaps://123.123.123.123"; // IP des Schulservers
$ldap_port = 636;
$ldap_v3 = true;
$ldap_tls = true;
$ldap_base_dn = "ou=users;dc=schule,dc=ort,dc=schule-bw,dc=de";
$ldap_user_attrib = "uid";
$ldap_filter = "|(ldRole=teacher)(uid=admin)";
$ldap_disable_referrals = TRUE;
//$ldap_debug = TRUE; // Nur drin lassen wenn es nicht funzt
Die obigen Einträge beziehen sich auf die Datei config.inc.php im Verzeichnis /pfad/zu/mrbs/web. Debugmeldungen von MRBS (sofern oben einkommentiert) finden sich in der error.log des Apachen. Der Filter stellt hoffentlich sicher, dass nur Lehrer/innen sich anmelden können. Um MRBS zusätzlich gegenüber Einsichtnahmen durch Zweite abzusichern, muss der Login erzwungen werden. Dazu
nach den Includes in alle nur erdenklichen und über Netz erreichbaren PHP Dateien (month.php, day.php, week.php, search.php, report.php usw) setzen.
Die anderen hier im Blog zu findenden Hinweise zur Konfiguration von LDAPs gegen einen SBE Server sollte man sich ebenfalls mal ansehen, wenn es mit den Einträgen oben nicht tun will. Es gibt einige Wände, vor die man laufen kann.
# /etc/apache2/sites-available/default-ssl.conf
<Directory /var/www/pfad/zu/redmine>
RailsBaseURI /redmine
PassengerResolveSymlinksInDocumentRoot on
</Directory>
Wichtig ist hier, dass der Eintrag für den DocumentRoot des bearbeiteten VirtualHost nicht ganz woanders hinzeigt, sonst fliegt PassengerResolveSymlinksInDocumentRoot auf die Nase (weitere Infos hier). Also im zugehörigen VirtualHost Eintrag prüfen, ob er stimmt:
Dort Sendmail für den Default Mode freischalten (funktioniert selbstverständlich auch mit Postfix):
# default configuration options for all environments
default:
email_delivery:
delivery_method: :sendmail
Bei Bedarf ebenda den Pfad für die Attachments überarbeiten. Der Default Pfad ist
/var/lib/redmine/default/files
wo dann Unterordner nach Datum des Uploads angelegt werden. Wer das anders haben will kann sich z.B. unter /var/www/pfad/zu/redmin_files anlegen, dem Apachen daran alle Rechte geben und den veränderten Pfad dann in configuration.yml eintragen:
Das Apache Modul aktivieren und die Konfiguration neu laden:
sudo a2enmod passenger
sudo service apache2 restart
Leider enden hier viele Installationsanleitungen. Ich musste wie folgt weiter bauen:
Zuerst schien es mir so, als ob Ruby ohne bundler und sqlite3 Fähigkeiten nichts mit Redmine anzufangen wusste. Ich sah beim Aufruf nur eine leere Seite. Das hier half weiter:
gem install bundler sqlite3
Jetzt bekam ich wenigstens eine Fehlermeldung über eine fehlende und nicht beschreibbare Gemfile.lock Datei zu sehen. Ein
touch /usr/share/redmine/Gemfile.lock
chown www-data.www-data /usr/share/redmine/Gemfile.lock
service apache2 restart
setze die Datei an die gewünschte Stelle und machte Redmine läuffähig. Mit admin admin kann man sich anmelden und aus Redmine heraus die restliche Konfiguration anpassen.
Was dann noch fehlt war die Anbindung über LDAPs an den hausinternen Server. Redmine bringt ein LDAP Modul schon mit, also muss man nur die richtigen Einträge für einen LD-Server herausfinden. Geklappt hat es hiermit:
Name: Anbindung_LD-Server
Host: ip.adresse.des.servers
Port: 636
BaseDN: dc=schule,dc=ort,dc=schule-bw,dc=de
On the fly Benutzererstellung: True
Login = uid
Firstname = givenName
Lastname = sn
Email = mailPrimaryAddress
Geholfen haben mir bei der Arbeit die folgenden Anleitungen: [1] [2] [3]
Webseiten und Dienste auf einem LD-Server laufen intern in LXC Containern oder auf einem Apache, sind jedoch nach Außen über Pound angebunden – und da ist die mitgelieferte Version ein Stück Softwaregeschichte. „Aktuell“ auf LD-Servern ist Version 2.5-1, der in der Default-Konfiguration eine ganze Reihe von Sicherheitsproblemen mit sich bringt. Nicht umsonst erhält man bei SSLLabs für eine nicht-angepasste LD-Server-Installation ein schlichtes F-Rating.
Man muss sich selbst helfen. Support oder Hilfe über die Foren darf man bei einem „Hauptsacheestutsystem“ nicht erwarten.
Mit dem folgenden Eintrag in die /etc/pound/pound.cfg stellt man sich zumindest bezogen auf das SSLLabs-Rating schon einmal viel besser auf und erhält ein C.
Der Weisheit letzter Schluss ist das nicht: Die Konfiguration wird nach Systemupdates immer mal wieder überschrieben, so dass man hier gelegentlich vorbei schauen sollte. Außerdem hinterlässt auch die Zeile oben noch das eine oder andere Leck.
Aber es ist besser als vorher.
PS: Ein aktuelles Ubuntu Trusty hätte einen Pound 2.6-3 an Bord. Siehe http://packages.ubuntu.com/trusty/pound Der 2.5-1er Pound auf dem LD-Server scheint aus Oneiric zu stammen. Das war im Jahr 2011.
Pydio wird vom LD-Server in einem LXC Container als Virtuallisierungsschicht mitgeliefert. Nur dumm, dass die gesamte Konfiguration des LD-Servers immer über Subdomains läuft, was den Einsatz eines günstigen Zertifikats für nur eine Domain unmöglich macht, will man nicht auf self-signed zurückgreifen. Self-signed verbietet sich jedoch im schulischen Umfeld für die Dienste, die alle nutzen können sollten, weil man so die LuL und SuS dazu erzieht, Zertifikatswarnungen nicht ernst zu nehmen. Meine Lösung verwendet nun einen Apache Reverse Proxy [1], um die interne Pydio Domain extern in einem Unterverzeichnis der SSL-verschlüsselbaren Schuldomain einzublenden. Damit das klappt, müssen der Reverse Proxy Pound des LD-Servers mit dem Reverse Proxy Apache und dem NGinx im LXC-Container in Reihe geschaltet werden. Das geht so:
1. Kontrollieren ob der Symlink auf /etc/apache2/sites-available/pydio in /etc/apache2/sites-enabledweg ist (die Konfiguration findet an anderer Stelle statt).
2. In der /etc/apache2/sites-enabled/000-default die folgenden Einträge in den Abschnitt für VirtualHost * und auch in den Abschnitt für VirtualHost *:443 vornehmen:
ProxyRequests Off
<Proxy *>
Order allow,deny
Allow from all
</Proxy>
ProxyPass /pydio http://pydio/
ProxyPassReverse /pydio http://pydio/
3. In der /etc/logodidact/service.conf Pydio für die Domain, die man schon mit SSL versorgt, einschalten:
auf dem LD-Server muss eine Antwort liefern, sonst braucht man nicht weiterforschen, sondern muss die DNS Probleme in den Griff bekommen. Auch ein
links2 http://pydio
links2 https://pydio # weniger relevant, s.U.
sollte Ergebnisse liefern – mindestens eine Zeile HTML Code sollte zu sehen sein, mehr schafft links2 nicht, weil es kein JavaScript kann.
Der Aufruf von Pydio funktioniert dann reibungslos, wenn man den „trailing slash“ im URI zu Pydio nicht vergisst. Ohne diesen sieht man nur ein leeres Fenster. Alle Links für die Kolleg/innen und Schüler/innen sollten also so aussehen:
https://sub.domain.tld/pydio/
Jetzt funktioniert das Setup durchgehend ohne Zertifikatswarnungen und zumindest bis zum internen Reverse Proxy Pound auch verschlüsselt.
Wie und ob Pound dann dem Apache Reverse Proxy (als Übersetzer zwischen Internet und virtueller Pydio Maschine m LXC Container) die Daten verschlüsselt weiterreicht habe ich nicht geprüft. Ich vermute aber, auf Grund der Konfiguration, dass dem nicht so ist. Das sollte aber kein Problem darstellen, da an diesen Datenstrom nur root direkt auf dem Server rankommt.
Zu empfehlen ist eine Konfiguration von Pydio durch den Benutzer admin. Auf Pydio ist dieser mit den nötigen Rechten ausgestattet, weil der LXC Container über LDAP am LD-Server hängt. Hier sollte man alles abschalten was geht – vor allem die Funktionen zum unbegrenzten Teilen per Link und ohne Passwort. Denn: LD stellt Pydio extrem offen zur Verfügung. So offen, dass man aus Urheberrechts- und Datenschutzsicht Einschränkungen vornehmen muss, will man seine Schule und Schüler nicht ausliefern.
Weiter ist die Pydio Installation auch komplett veraltet (Version 5.0.4 – aktuell ist 6). Damit muss man wohl leben bei dieser Schulserverlösung. Deren Marketingabteilung wird das Konzept sicherlich als „bewährte Software“ verticken. Auf den bekannteren Exploit-DBs fand ich aktuell aber nichts, was Skript-Kiddies auf die Schnelle gegen Pydio einsetzen könnten.
Nicht nur die Anbindung des LD-Servers an eine externe DokuWiki Installation, sondern auch an ein externes ownCloud funktioniert über LDAPs und lässt sich wie folgt einrichten:
Der erste Schritt ist vom OC-Administrator vorzunehmen, der im Backend die LDAP App einschalten muss. Weiter muss auf dem ownCloud-Server auch php5-ldap installiert sein und in der folgenden Datei die Prüfung auf Zertifikate abgeschaltet werden, wenn man intern auf dem LD-Server für den eigenen LDAP nur selbst-signierte Zertifikate einsetzt (was in den meisten Fällen zutreffen dürfte – leider):
# /etc/ldap/ldap.conf
TLS_REQCERT allow
Als OC-Administrator lässt sich dann unter dem Menü-Eintrag /Administration die restliche Konfiguration vornehmen.
In der Server-Registerkarte ist die URL (besser: IP) für den LD-Server zu hinterlegen. Danach klickt man einmal in Benutzer-DN, trägt aber nix ein, klickt einmal in Passwort, trägt aber nix ein und schreibt dann die DN Angaben in das letzte Feld. Bei BelWü-Kunden dürfte es sich hierbei um einen Eintrag in der folgenden Form handeln:
dc=schulkuerzel,dc=stadt,dc=schule-bw,dc=de
Dann klickt man auf Fortsetzen – wie auch bei allen anderen folgenden Registerkarten.
In der Nutzer-Filter-Registerkarte sollte inetOrgPerson vorausgewählt sein und ownCloud auch gleich alle internen Benutzer (und Workstations etc.) finden. Im Bild oben sind dies 1008 Benutzer. Das sind etwas viele, die sich anmelden dürften, weswegen man Beschränkungen vornehmen sollte. Im Folgenden beschränke ich die Nutzung für die Gruppe der Lehrer/innen.
Die Beschränkung erfolgt schon bei der Anmeldung: Nur Mitglieder der Gruppe teacher werden akzeptiert. Die entscheidende Funktion wird durch vorauswählbare Einträge nicht scharf schaltbar, weshalb man selbst den Original-Filter bearbeiten muss, so dass dieser am Ende wie folgt aussieht:
Der Gruppen-Filter von ownCloud bezieht sich nämlich nicht auf die Benutzerrechte im Anmeldekontext, sondern lediglich auf das Recht, innerhalb von ownCloud Gruppen bilden zu dürfen.
Was bei der Arbeit auf jeden Fall hilft, ist einmal auf dem LD-Server mit tshark zu gucken, ob überhaupt LDAPs Anfragen ankommen.
tshark -i extern port 636
Weiter macht es Sinn mit
tail -f /var/www/owncloud/data/owncloud.log
zu verfolgen, was alles bei den Anmeldeversuchen schief läuft. Man braucht mindestens einen Lehreraccount und einen Schüleraccount zum Testen – sonst wird man irre. Auch darf man damit rechnen, dass man mehrfach
service apache2 restart
auf dem ownCloud Server benötigt, weil sich dieser an den Einstellungen verschluckt hat. Das kann man gut in der owncloud.log verfolgen: Sollte diese im Sekundenabstand mit Zeilen gefüllt werden, die ungefähr diese Angaben enthalten, dann ist es mal wieder Zeit für einen Apache Restart und einen erneuten Versuch im OC-Backend:
{"app":"user_ldap","message":"Configuration Error (prefix ): Not a single Base DN given.","level":2,"time":"2014-12-19T16:50:15+00:00"}
{"app":"user_ldap","message":"Configuration Error (prefix ): login filter does not contain %uid place holder.","level":2,"time":"2014-12-19T16:50:15+00:00"}
Wer das alles für seine Linuxmuster.net Lösung haben will, wird im Wiki fündig. Wie immer sind die freien Schulserver-Lösungen bei der Dokumentation von Sonderwünschen und Erweiterungen vorbildlich.
