Dienstag, 13. Dezember 2022

LDAPs für WebUntis

EDIT: Diese Anleitung ist veraltet, bitte die Anleitung zum LDAP im Downloadbereich der paedML Linux beachten, dort ist alles offiziell beschrieben. 


Im Beitrag zu WebUntis 

https://paedmllinux.blogspot.com/2021/07/webuntis-per-ldap-mit-paedml-linuxgs-72.html

hatte ich bisher die Einrichtung ohne LDAPs Verbindung beschrieben. 

Nun kommt endlich der Nachtrag.

Vorsicht: Verwenden der Anleitung auf nur eigene Gefahr!

Voraussetzung ist eine konfigurierte Nextcloud, welche im Internet unter einer Adresse wie cloud.meine-schule.de erreichbar ist. 

Auf der Nextcloud muss als erstes der Nginx Proxyserver installiert werden, der die LDAPs-Anfrage mit dem gültigen LetsEncrypt-Zertifikat annimmt. Dieser leitet dann die Anfrage intern an den paedML Server weiter. 

Per Putty auf der Nextcloud:

univention-install nginx

Gegebenenfalls die Abfrage bestätigen und installieren. 

Nun muss nginx konfiguriert werden. 

Öffnen Sie die Datei 

/etc/nginx/nginx.conf

dort müssen die Zeilen

include /etc/nginx/conf.d/*.conf;

include /etc/nginx/sites-enabled/*;

mit einer Raute # auskommeniert werden, 


danach fügen Sie am Ende die folgende Konfiguration hinzu: 

stream {

server {

listen 8636 ssl;

proxy_pass 10.1.0.1:7636;

proxy_ssl on;

ssl_certificate /etc/univention/letsencrypt/signed_chain.crt;

ssl_certificate_key /etc/univention/letsencrypt/domain.key;

}

}

Dadurch lauscht Nginx auf dem Port 8636 und leitet die Anfragen an den Server auf dem Port 7636 weiter, weist sich aber gleichzeitig mit dem SSL Zertifikat der Nextcloud aus. 

Nach dem Speichern den Nginx neustarten. 

service nginx restart

Nun muss der Port 8636 noch auf dem Nextcloud Server erlaubt werden, dies funktioniert über UCR Variablen in der Konsole der Nextcloud:

ucr set security/packetfilter/lmz-nginx/tcp/8636/all='ACCEPT'

ucr set security/packetfilter/lmz-nginx/tcp/8636/en='LDAPS'

Nach dem Ausführen muss die Firewall-Einstellungen neu geladen werden. 

 [ -x "/etc/init.d/univention-firewall" ] && invoke-rc.d univention-firewall restart

Nun muss noch der Port 636 von der Firewall zum Port 8636 auf der Nextcloud weiter geleitet werden. 

Auf der PfSense den Punkt Firewall --> NAT öffnen, dort dann auf "Hinzufügen (unten)" klicken.

In die Regel muss der Zielportbereich auf LDAP/S gestellt werden, die Umleitungsziel-IP auf Einzelner Host mit 192.168.201.7 (bzw. die IP der Nextcloud, falls abweichend)

Der Umleitungszielport sollte dann auf 8636 gestellt sein. 
Als Beschreibung habe ich "LDAPS-Weiterleitung für WebUntis/Moodle" verwendet. 

Danach unten auf Speichern klicken. 

Für mehr Sicherheit kann man die Quelle auch noch auf eine IP oder einen Alias einschränken, eine Schritt für Schritt Anleitung dafür sollte aber auch im Nextcloud Installationshandbuch zu finden sein, weshalb ich diese hier schuldig bleibe. 


Letztlich kann in WebUntis der Server von LDAP mit der IPAdresse zu LDAPs mit der URL geändert werden, also z.B. LDAPS://cloud.meine-schule.de

Dienstag, 29. November 2022

Moodle und globale Gruppen

WARNUNG: Diese Anleitung ist veraltet, Univention hat einen Import-Hook erstellt, der das Feld "description" auf die Klasse gesetzt, dieser ist bereits auf allen paedMLs installiert. Bitte das aktuelle LDAP-Dokument in Downloads der paedML beachten!!


Die paedML Linux mit ihrem UCS@school Server verwaltet Benutzer in ihrem LDAP leider anders als z.B. von Moodle erwartet wird. Im UCS@school können Benutzer in mehreren Klassen sein können, z.B. in einem Schulverbund, daher wird diese Information nicht in den User-Daten abgelegt sondern in den Klassen.

Um die erwartete eindeutige Zuordnung von Usern zu Klassen doch noch einzubauen kann der neue Benutzerimport aber so abgeändert werden, dass die Klasse auch in ein weiteres LDAP Feld abgelegt wird.  

Im Verzeichnis 

\\backup\opsi_depot_rw\update72\Benutzerimport

kann über die Hilfsdateien eine Konfigurationsdatei "user_import.json" erstellt und auf den Server nach 

/var/lib/ucs-school-import/configs/user_import.json

geladen werden. 

Mit einem beliebigen Editor (WinSCP, Putty, usw) muss die Datei dort wie folgt abgeändert werden:

Nach "Klasse": "school_classes" kommt ein Komma, in der nächsten Zeile dann die Zuordnung "Klasse": "description" ohne Komma. 

Mit diesem Zusatz wird beim nächsten Import bei den Usern das Feld "description" hinzugefügt. Verwenden Sie hierzu am besten die CSV-Datei Ihres letzten Imports. 

VORSICHT: Falls Lehrkräfte importiert werden, welchen mehreren Klassen  zugeordnet sind, könnte diese Einstellung Probleme verursachen.


Nun muss die Änderung noch in Moodle übernommen werden. 
Über Webseiten-Administration -> Plugins -> Authentifizierung -> LDAP-Server
Muss bei der Datenzuordnung noch die Klasse/Lerngruppe auf das Feld "description" gesetzt werden. 

Damit sollten dann profilfeld-basierenden Zuweisung globaler Gruppen ohne weitere Probleme möglich sein. 

Dienstag, 13. September 2022

OPSI-capture

Neues Schuljahr, neue Software... Und es wurde mal wieder Zeit für ein neues Image...

Ein Großteil meiner Rechner kommt gut mit dem Standard Windows aus, aber für CNC Anwendungen und Arzt-Abrechnungs-Software muss es manchmal ein Image sein. 

Meinen Dickkopf auf "Ich mach das jetzt" gestellt und knappe 4 Tage gegen eine Wand gelaufen. Damit mir und auch anderen dies nicht passiert, hier nochmal eine Anleitung:

1. Allgemeine Vorbereitung 

Z.B. über \\backup\opsi_depot_rw\update72\Skripte die Datei austausch-windows21h2.exe verwenden um opsi-local-image-win10-x64 mit dem Image zu versorgen. 

Danach den Ordner \\backup\opsi_depot_rw\opsi-local-image-win10-x64\installfiles nach 

\\backup\opsi_depot_rw\opsi-local-image-win10-x64-capture\installfiles kopieren, am besten per WinSCP oder Putty. Sonst könnten gegebenenfalls die Rechte "beeinflusst" werden. 

Nun sinnvollerweise die Rechte prüfen, mit Putty auf dem Opsi

 cd /var/lib/opsi/depot/opsi-local-image-win10-x64-   capture/installfiles/sources/

 ls -l

In der Übersicht die Rechte der Datei install.wim kontrollieren, sollte -rwxrwx--- sein. Bei mir war leider ein + hinter dieser Liste, wodurch ich leider zu oft scheiterte, daher dann 

 setfacl -bR *

und ein 

 opsi-set-rights .

und danach mit ls -l nochmal prüfen. 

EDIT: Das entfernen der LOCK-Datei, wie hier gleich beschrieben, kann ignoriert werden, wenn im opsi-local-imgage-wim-capture der Wert force_clear_lock auf true gesetzt wird.
Danke an Martin für den Tipp!

Jetzt noch nachsehen, ob im Ordner 

/var/lib/opsi/depot/opsi-local-image-win10-x64-capture/ 

eine Datei mit der Endung .LOCK ist, ich glaube es war opsi-local-image-win10-x64-capture.LOCK. Diese wird geschrieben, wenn ein Capture-Versuch läuft, aber auch wenn einer fehlschlägt. Nicht vergessen, wenns schief geht --> LOCK entfernen...

2. Client vorbereiten

Nun muss ein Client erstellt werden von dem aus das Capture Image gemacht werden soll. 

Meine Probleme:
Meine erste Idee war es, diesen Client in einer virtuellen Umgebung (vSphere) anzulegen. Leider bekam ich nach der Installation der Software beim "Sysprep" einen Bluescreen wegen PNPUTIL (Treibern), von daher habe ich das bespielen von Windows dann auf echter Hardware gemacht. Auch hier kann man auf die Nase fallen. Eine Generation meiner Computer braucht einen speziellen Treiber für das Netzwerk in WinPE. Bei der Installation von Windows wurde der über die in Opsi eingebundenen Treiber übergeben, beim Capture-Vorgang waren diese dann aber nicht verfügbar. Ich habe dann auf einen anderen Client mit unterstützter Netzwerkkarte  gewechselt und damit waren dann alle Probleme beseitigt. 

Nun zur Vorbereitung:
Im Opsi bitte bei opsi-local-image-prepare auf die Backup Partition achten, wenn diese zu klein ist kann das Image nicht übertragen werden. Ich hab bei einem 256GB PC 100GB als Partition, 6GB fürs WinPE und 51% für Backup eingestellt. 

Gerne das Windows direkt mit opsi-local-image-win10-x64-capture ausrollen (dann ist die Version garantiert passend!), dazu die Version Education einstellen. Im Opsi ConfigEditor gegebenenfalls auf "Server-Konsole" -> paedML Linux -> Imageliste ... Capture aktualisieren, damit man Education auswählen kann. Dies sollte man vor allem auch nach dem Capture-Vorgang wiederholen um die Übersicht über erstellte Images zu behalten. 


Windows nun wie gewohnt ausrollen opsi-local-image-prepare -> opsi-local-image-win10x64-capture (Imagename: Education), jedoch verzichte ich auf die Installation der meisten Ospi-Pakete, daher entferne ich aus "setup_after_install" die Clientprodukte und mein Schul-Metapaket. 


Wichtig ist aber, dass das Paket "win10-sysprep-app-update-blocker" installiert wird, dies verhindert das Nachladen von Windows Apps welche sonst den Capture-Vorgang verhindern können. 
Das Paket config-win10 kann aber auch nicht schaden. 

Nun kann das Bespielen des Clients losgehen. 
Bei meiner Schule sind dies CNC Anwendungen wie SolidWorks, SolidCAM und Simulationssoftware von Siemens und vieles mehr.  

Hier kann es auch sinnvoll sein gegebenenfalls den Autostart etwas zu bereinigen, da viele Programme gerne ihre "Updater" oder irgendwelche "Schnellstart" Software beim Hochfahren von Windows starten. 

Letztlich startet man den Capture-Vorgang mit "opsi-local-image-wim-capture".  Dieses Produkt sollte vorher richtig eingestellt werden. die "image_flag" sollte auf "Education" gesetzt werden, den "imagename" auf eine Schuleigene Bezeichnung wie "Technik 2022" oder "Medizin". "image_description" kann natürlich mit Details über das Image befüllt werden, darf aber auch leer bleiben. Beim "target_product" muss natürlich "opsi-local-image-win10x64-capture" eingetragen werden. 
Wenn nun nichts schief geht schreibt opsi ein lokales Image, führt danach Windows sysprep aus, überträgt danach das Sysprep Image an den Opsi-Server in das Capture-Produkt. Im Anschluss stellt Opsi das lokale Image (von vor dem Sysprep) wieder her. 

Wenn nun kein "failed" in Opsi angezeigt wird wurde das Image übertragen und das Capture war erfolgreich. Im Opsi-ConfigEd kann nun noch "Server-Konsole" -> paedML Linux -> Imageliste ... Capture aktualisieren
Danach sollte der neue Image-Name in "opsi-local-image-win10x64-capture" vorhanden sein. 

Montag, 21. März 2022

MSOffice2021 installieren

Langsam steht bei unserer Schule ein Update der Office-Pakete an. Daher hier kurz eine Anleitung für die Installation von neueren Office-Produkten. 

Mit putty auf dem Opsi-Server:

opsi-package-updater install office-deployment-tool

opsi-package-updater install office2021

office365 oder office2019 sind ebenfalls möglich. 

Nun muss auf einem Client das "office-deployment-tool" auf "setup" gesetzt werden. 

In der Konfiguration kann hier die Zielversion angegeben werden. 

Das Paket lädt nun die Installationsdateien in den Ordner "preload" in 

C:\opsi.org\tmp\office-deployment-tool

des Clients. Kopieren Sie nun den "preload"-Ordner auf den Opsi-Server nach

\\backup\opsi_depot_rw\office2021\files

und führen Sie auf dem Opsi über putty noch ein 

opsi-set-rights

aus. 

Nun können Sie die das Paket office2021 mit der Property "installofficeversion" auf 

 "ProPlus2021Volume" installieren. 

Analog funktioniert dies natürlich auch mit anderen Versionen. 

Vorsicht: Ich habe noch keinen Weg für die Update-Verteilung, sobald ich dazu mehr sagen kann werde ich den Artikel hier erweitern. 






Montag, 13. Dezember 2021

Einrichten eines Proxy-Servers mit Jugendschutzfiltern für das MDM-Netz der paedML-Linux mit Erweiterung für iPads

Anmerkung Johannes Albani: Das LMZ hat nun die Anleitung zu JusProgDNS veröffentlicht.  Dieser Dienst könnte eine Alternative zur im folgenden Vorgestellten Jugendschutz Filterung darstellen. 

Anmerkung Tino Aidam: Wie es scheint, ist die Shalla-Liste zumindest vorrübergehend offline, wann sie wieder online geht ist nicht bekannt. 

 ("Due to personal reasons and the political situation in this country the company Shalla Secure Services has been closed and in consequence the blacklist service has been stopped.
Sorry for any inconveniences.
Time will tell if we can start in another country again.", http://www.shallalist.de/, 17.03.2022)

Diese Anleitung kann weiterhin mit anderen Blacklists genutzt werden, die an Stelle der Shalla-Liste eingetragen werden können. 

 

Wenn man in der paedML-Linux iPads nach der Anleitung des LMZ einsetzten will, wird man feststellen, dass Stand heute (08.12.2021) die aktuellste Anleitung keine wirklich befriedigende Antwort auf die Frage bringt, wie man denn eine Proxyfilterung für diese umsetzen kann. Glücklicherweise bietet die von der paedML-Linux eingesetzte Firewall - die pfSense – eine Möglichkeit, einen Squid-Proxy einzusetzen, um genau das zu erreichen.

Dazu muss man auf der Firewall unter „System/Package Manager“ die beiden Pakete „squid“ und „squidGuard“ installieren. Squid ist dabei der eigentliche Proxy und squidGuard der zugehörige Webfilter.

 

 

Wenn diese Pakete installiert sind, kann man den Proxyserver unter „Services/Squid Proxy Server“ konfigurieren.

Hier aktivieren wir nun einige Punkte:

   1. Enable Squid Proxy:

Ziemlich selbsterklärend

 

        2. Proxy Interfaces:

Hier wählen wir aus, auf welchen Interfaces unser Proxy laufen soll. In meinem Fall ist das das IPAD-Netz (entspricht dem MDM Netz aus der LMZ-Anleitung).
Zumindest bei mir ist der Proxy bereits angewesen und dem pädagogischen Netz zugewiesen, dies ist aber laut technischem Support LMZ nicht notwendig, da auf dem Server der paedML-Linux (10.1.0.1) bereits ein squid-Proxy läuft.

 

        3. Transparent HTTP Proxy:

Damit man keine Einstellungen auf den iPads machen muss, wir der Proxy als transparenter Proxy aufgesetzt.

 

        4. Transparent Proxy Interface(s):

Hier wählen wir wieder aus, auf welches Netzwerk wir den Proxy anwenden wollen. In meinem Fall das IPAD-Netz.

 

 

Da wir nicht nur HTTP-Anfragen abfangen wollen (die meisten „interessanten“ Webseiten benutzen inzwischen HTTPS), müssen wir nun noch das DNS-Filtering für HTTPS aktivieren.

Um das tun zu können, müssen wir unter „System/Cert. Manager“ noch eine neue interne CA (Certification Authority) hinzufügen (Falls man das gleiche Fenster benutzt, speichern nicht vergessen).
Auf dem Bild ist meine neue CA schon zu sehen, ich habe sie nicht extra nochmal gelöscht

 

Dazu auf „Add“ gehen und einfach eine neue Authority erstellen. Hier einen Namen eintragen. Ich habe noch die Haken bei „Trust Store“ und „Randomize Serial“ gesetzt, die restlichen Felder bleiben unberührt.

Nun mit Save erstellen und wieder zu „Services/Squid Proxy Server“ wechseln.

Dort stellen wir noch folgendes ein:

        5. HTTPS/SSL Interception:

Aktivieren, damit gefiltert wird

 

    6. SSL/MITM Mode:

            Splice All, sonst müssen wir auf allen Clients Zertifikate installieren

 

   7. SSL Intercept Interface(s):

Auch hier geben wir wieder die Interfaces an, auf denen das ganze laufen soll. In meinem Fall wieder IPAD.

 

        8. CA:


Hier wählen wir die eben erstellte interne CA aus.

Was das Logging angeht, dürft ihr selbst entscheiden, ob ihr Loggen wollt, wie viele Tage geloggt werden sollen usw.

Nun speichern wir das Ganze und haben damit unseren Proxy erstellt.

 

Jetzt müssen wir noch die Filter setzen. Das machen wir unter „Services/SquidGuard Proxy Filter“.

Hier habe ich die Haken bei

Enable

Enable Log

Enable Log Rotation

Und Enable Blacklist

gesetzt. Außerdem ist als Blacklist-URL http://www.shallalist.de/Downloads/shallalist.tar.gz hinterlegt. Die Shalla-Liste ist eine Liste, die diverse Kategorien von Webseiten enthält, von denen wir später auswählen können, welche wir blocken wollen. Sie ist außerdem die Liste, die vom LMZ in der paedML-Linux bereits benutzt wird, da bleibt man also konsequent.



Das ganze natürlich wieder mit Save speichern.

Achtung: Alle Einstellungen, die wir hier machen, werden erst aktiv, wenn der grüne Apply-Button gedrückt wird. Auch wenn man eine Einstellung geändert und gespeichert hat, ist sie noch nicht gültig, bis der Knopf gedrückt wurde. Bei der Ersteinrichtung ist auch der Status des Squid Gurads noch „Stopped“.

Nun unter der Unterkategorie „Blacklist“ einmal die hinterlegte Shalla-Liste durch einen Klick auf „Download“ herunterladen.

Jetzt gehen wir noch in die Unterkategorie „Common ACL“ und erweitern Target Rules List durch einen Klick auf das +-Symbol:

 

Hier Setzt man als unterstes den „Default access“ auf „allow“, damit grundsätzlich das Surfen im Internet erlaubt ist. Darüber kann man dann nach Kategorien auswählen, was man Blocken will.
Da ich nicht genau weiß, was in der Shalla-Liste enthalten ist und tendenziell eher für weniger als für mehr Restriktionen bin, habe ich mich mit dem Blocken mal zurück gehalten und werde die Liste nach Bedarf ausbauen.

Da ich vorhabe, auch die Dienst-iPads unserer Lehrer in dieses Netzwerk aufzunehmen, werde ich vielleicht auch noch unter der Unterkategorie „Groups ACL“ weitere Einschränkungen nur für die shared iPads unserer Schule hinzufügen, dass muss sich noch zeigen.

Nachdem wir unsere Filter-Einstellungen wieder gespeichert haben, müssen wir jetzt nochmal unter „General settings“ den Grünen Apply-Button drücken, denn sonst sind unsere Filter zwar schön und gut, aber leider nicht aktiv.

Nach der Anwendung läd sich die Seite einmal neu und der Status bleibt auf „STOPPED“. Wenn man die Seite allerdings 30 Sekunden später nochmal manuell neu läd, hat sich der Status auf „STARTED“ aktualisiert und ihr solltet von den iPads aus dem Netzwerk aus keine geblockten Webseiten mehr erreichen können (und ggf. jedes Mal ein wunderschönes Log speichern. Viel Spaß beim Erklären, wieso euer iPad auf www.porno.de wollte ;-P)

Ich habe das ganze zugegebenermaßen nicht alleine herausgefunden, sondern mich sehr stark an dieser Anleitung orientiert und bin dort abgewichen, wo mir eine andere Vorgehensweise sinnvoller erschien.

Ich hoffe, diese Anleitung hat euch weitergeholfen,

Viele Grüße,
Tino Aidam