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

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. 

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. 

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.