Source: http://docs.software-univention.de/ucsschool-handbuch-4.1.html
Timestamp: 2017-11-23 18:40:27+00:00

Document:
3.3. (Erneuter) Domänenbeitritt eines Schulservers
3.4. Umwandlung einer Single-Server-Umgebung in eine Multi-Server-Umgebung
4.3. Pflege von Benutzerkonten über CSV-Dateien
4.3.1. Import von CSV-Dateien
4.4. Verwaltung von Schulklassen
4.4.1. Anlegen von Schulklassen
4.4.2. Bearbeiten von Schulklassen
4.4.3. Löschen von Schulklassen
4.5. Verwaltung von Rechnern
4.5.1. Anlegen von Rechnerkonten
4.5.2. Bearbeiten von Rechnerkonten
4.5.3. Löschen von Rechnerkonten
14.1.2. Installation zusätzlicher Anmeldeserver
Vollen Zugriff auf die Administrationsfunktionen von UCS@school erhalten die Schuladministratoren. Sie können z.B. Computer zu Rechnergruppen zusammenfassen, neue Internetfilter definieren oder auch Lehrerpasswörter zurücksetzen.
Für die Pflege der Benutzerkonten stehen mehrere Möglichkeiten zur Verfügung. Die Bearbeitung von Benutzerkonten kann über die Univention Management Console erfolgen. Darüber hinaus bringt UCS@school flexible Importskripte mit. Sie lesen Tabulator-getrennte Importdateien ein, die üblicherweise aus vorhandenen Schulverwaltungssystemen extrahiert werden können und so einen automatisierten Abgleich ermöglichen.
UCS@school unterstützt derzeit nur einen Schulserver pro Standort. Darüber hinaus können weitere UCS-Systeme mit Samba 4 installiert und an den Schul-Standorten betrieben werden. Diese zusätzlichen UCS-Systeme können jedoch nicht in Verbindung mit UCS@school-Funktionalitäten eingesetzt werden; z.B. wird das Sperren von Dateifreigaben über die UCS@school-UMC-Module auf den zusätzlichen UCS-Systemen nicht unterstützt. Zusätzlich müssen die Rechnerobjekte der zusätzlichen UCS-Systeme vor dem Domänenbeitritt unterhalb der Organisationseinheit (OU) der Schule angelegt werden (siehe auch Abschnitt 2.2.1). Die Einrichtung zusätzlicher UCS-Systeme wird in Abschnitt 14.1 beschrieben.
Seit UCS@school 3.2 R2 wird zwischen dem Namen einer Schule und dem Schulkürzel (OU-Namen) unterschieden. Der Name einer Schule kann frei gewählt werden und wird primär in den UMC-Modulen angezeigt (in anderem Kontexten wird dieser Wert häufig auch als Anzeigename bezeichnet). Der eigentliche Name der Organisationseinheit (OU) wird nachfolgend auch als Schulkürzel bezeichnet. Das Schulkürzel sollte ausschließlich aus Buchstaben, Ziffern oder dem Bindestrich bestehen, da es unter anderem die Grundlage für Gruppen-, Freigabe- und Rechnernamen bildet. Häufig kommen hier Schulnummern wie 340 oder zusammengesetzte Kürzel wie g123m oder gymmitte zum Einsatz.
Voraussetzung für diese Unterteilung ist eine physikalische Trennung der beiden Netzwerksegmente. D.h. das edukative Netz und das Verwaltungsnetz können nicht gleichzeitig im gleichen Netzwerksegment verwendet werden.
UCS@school basiert auf Univention Corporate Server (UCS). UCS@school wird dabei als Repository-Komponente eingebunden. Die Installation von UCS ist im UCS-Handbuch dokumentiert. Nachfolgend wird nur auf ggf. auftretende Unterschiede zur Grundinstallation von Univention Corporate Server sowie die Installation von UCS@school selbst eingegangen.
Im folgenden werden zwei Installationsvarianten beschrieben: die Installation als Single-Server-Umgebung und die Installation als Multi-Server-Umgebung mit einem Domänencontroller Master und mindestens einem Schulserver. Die nachträgliche Umwandlung einer Single-Server-Umgebung in eine Multi-Server-Umgebung wird unterstützt und in Abschnitt 3.4 genauer beschrieben.
Bei der UCS-Installation muss die Systemrolle Domänencontroller Master ausgewählt werden. Nach der UCS-Installation kann in Univention Management Console das Modul App Center geöffnet und dort die Applikation UCS@school nachinstalliert werden. Nach Abschluss der Installation wird in Univention Management Console ein neues Modul angezeigt, mit welchem die wizardgesteuerte Konfiguration von UCS@school durchgeführt wird:
Das Konfigurationsmodul fragt auf dem DC Master zunächst nach der Art der UCS@school-Umgebung, die installiert werden soll. Hier ist der Eintrag Single-Server-Umgebung auszuwählen.
UCS@school benötigt für die Bereitstellung von Datei- und Drucker-Freigaben den Samba-Dienst. Sofern auf dem DC Master noch kein Samba-Dienst installiert ist, kann zwischen Samba 3 und Samba 4 ausgewählt werden.
Die Daten eines Schulservers werden im Verzeichnisdienst in Organisationseinheiten (OU) gespeichert (siehe auch Kapitel 2). Im letzten Schritt des Konfigurationsassistenten wird nach dem Namen der Schule gefragt. Dieser ist ein frei wählbarer Bezeichner (wie z.B. Gymnasium Mitte), der primär in den UMC-Modulen verwendet wird. Das ebenfalls abgefragte Schulkürzel entspricht dem eigentlichen Namen der Organisationseinheit, welche vom UMC-Modul im Zuge der Konfiguration automatisch angelegt wird. Das Schulkürzel sollte ausschließlich aus Buchstaben (a-z und A-Z), Ziffern (0-9) oder dem Bindestrich (-) bestehen, da es unter anderem die Grundlage für Gruppen-, Freigabe- und Rechnernamen bildet. Häufig kommen hier Schulnummern wie 340 oder zusammengesetzte Kürzel wie g123m oder gymmitte zum Einsatz. Nach der Eingabe des Schulnamens wird automatisch ein Vorschlag für ein Schulkürzel gemacht, welcher jedoch manuell angepasst werden kann.
Während der Konfiguration werden benötigte Softwarepakete automatisch aus dem Univention App Center heruntergeladen und installiert. Somit sind nach der Konfiguration alle für die Datenpflege und Steuerung von UCS@school benötigten Pakete auf dem DC Master zugreifbar.
Wurde während der Installation des DC Masters ein DHCP-Server installiert, verschiebt der UCS@school-Konfigurationsassistent das DHCP-Server-Objekt des DC Masters (zu finden unter cn=dhcp,LDAPBASIS) automatisch in den entsprechenden DHCP-Container der OU (cn=dhcp,ou=OUNAME,LDAPBASIS). Dies ist für die korrekte Funktion des DHCP-Servers notwendig.
Das Konfigurationsmodul fragt auf dem DC Master zunächst nach der Art der UCS@school-Umgebung, die installiert werden soll. Hier ist der Eintrag Multi-Server-Umgebung auszuwählen.
Weitere Konfigurationsoptionen werden in einer Multi-Server-Umgebung auf dem DC Master nicht benötigt.
Während der Konfiguration werden benötigte Softwarepakete automatisch aus dem Univention App Center heruntergeladen und installiert. Somit sind nach der Konfiguration alle für die Datenpflege benötigten Pakete auf dem DC Master zugreifbar.
Auf Servern mit der Rolle Domänencontroller Backup (kurz DC Backup) werden alle Domänendaten und SSL-Sicherheitszertifikate als Nur-Lese-Kopie gespeichert.
Ein DC Backup dient als Fallback-System des DC Master. Sollte dieser ausfallen, kann ein DC Backup die Rolle des DC Master dauerhaft übernehmen. Der Einsatz eines DC Backup ist optional.
Die Installation von UCS@school auf einem DC Backup erfolgt analog zur in Abschnitt 3.2 beschriebenen Installation des DC Master.
Sofern DC Backup-Systeme in der UCS-Domäne vorhanden sind, muss dort ebenfalls UCS@school installiert und konfiguriert werden. Sollte dies nicht der Fall sein, kann es zu schweren Replikationsproblemen auf den Schulservern kommen.
An jedem Schul-Standort muss ein Schulserver installiert werden.
Bei der UCS-Installation muss die Systemrolle Domänencontroller Slave (kurz DC Slave) ausgewählt werden. Nach der UCS-Installation kann in Univention Management Console das Modul App Center geöffnet und dort die Applikation UCS@school nachinstalliert werden. Nach Abschluss der Installation wird in Univention Management Console ein neues Modul angezeigt, mit welchem die wizardgesteuerte Konfiguration von UCS@school auf dem DC Slave durchgeführt wird:
Das Konfigurationsmodul kann auf einem DC Slave nur dann erfolgreich durchlaufen werden, wenn die Konfiguration des DC Masters bereits über das dort installierte Konfigurationsmodul abgeschlossen wurde.
Nach der Konfiguration ist es erforderlich, dass der DC Slave erneut der Domäne beitritt. Im zweiten Schritt werden die für den erneuten Beitritt notwendigen Anmeldedaten (Benutzername, Passwort) abgefragt. Hier kann der Benutzer Administrator oder ein Mitglied der Gruppe Domain Admins angegeben werden. Der vollqualifizierte Rechnername (FQDN) des DC Masters wird üblicherweise automatisch ermittelt und vorausgefüllt. Sollte dies nicht möglich sein, muss der vollständige Rechnername inkl. DNS-Domäne angegeben werden, z.B. master.example.com.
Die Daten eines Schulservers werden im Verzeichnisdienst in Organisationseinheiten (OU) gespeichert (siehe auch Kapitel 2). Daher wird im Konfigurationsassistenten nach dem Namen der Schule gefragt. Dieser ist ein frei wählbarer Bezeichner (wie z.B. Gymnasium Mitte), der primär in den UMC-Modulen verwendet wird. Das ebenfalls abgefragte Schulkürzel entspricht dem eigentlichen Namen der Organisationseinheit, welche vom UMC-Modul im Zuge der Konfiguration automatisch angelegt wird. Das Schulkürzel sollte ausschließlich aus Buchstaben, Ziffern oder dem Bindestrich bestehen, da es unter anderem die Grundlage für Gruppen-, Freigabe- und Rechnernamen bildet. Häufig kommen hier Schulnummern wie 340 oder zusammengesetzte Kürzel wie g123m oder gymmitte zum Einsatz. Nach der Eingabe des Schulnamens wird automatisch ein Vorschlag für ein Schulkürzel gemacht, welcher jedoch manuell angepasst werden kann.
Nach der Angabe des Schulnamens ist die Art des Schulservers anzugeben. Es kann zwischen einem Schulserver für das Edukativnetz (Edukativer Schulserver) und einem Schulserver für das Verwaltungsnetz (Verwaltungsserver) gewählt werden. Die Funktionen für den IT-gestützten Unterricht werden dabei nur von den Schulservern im Edukativnetz bereitgestellt.
Sollte an einem Schulstandort der Schulserver des Verwaltungsnetzes vor dem edukativen Schulserver konfiguriert werden, fragt der Konfigurationsassistent zusätzlich den Namen des zukünftigen edukativen Schulservers ab. Sollte der hier angegebene Name des Schulservers nicht korrekt sein, muss vor dem Import von Benutzern der Freigabeserver für die Benutzer-Heimatverzeichnisse korrigiert werden (siehe auch Abschnitt 4.1.2).
Für den Verwaltungsserver muss ein vom edukativen Netz physikalisch getrenntes Netzwerksegment sowie ein eigenes IP-Subnetz verwendet wird, um Konflikte mit dem Schulserver des Edukativnetzes zu vermeiden (siehe auch Abschnitt 2.3).
Während der Konfiguration werden benötigte Softwarepakete automatisch aus dem Univention App Center installiert und ein erneuter Domänenbeitritt durchgeführt. Somit sind nach der Konfiguration alle für die Steuerung von UCS@school benötigten Pakete auf dem DC Slave zugreifbar.
Wurde während der Installation des DC Slaves ein DHCP-Server installiert, verschiebt der UCS@school-Konfigurationsassistent das DHCP-Server-Objekt des DC Slaves (zu finden unter cn=dhcp,LDAPBASIS) automatisch in den entsprechenden DHCP-Container der OU (cn=dhcp,ou=OUNAME,LDAPBASIS). Dies ist für die korrekte Funktion des DHCP-Servers notwendig, da jeder Schulserver eine individuelle LDAP-Suchbasis verwendet.
§3.3. (Erneuter) Domänenbeitritt eines Schulservers
Die Einrichtung eines Schulservers ist auch ohne das oben beschriebene UMC-Konfigurationsmodul möglich bzw. notwendig, wenn während des Konfigrationsprozesses Probleme auftreten sollten. Nur in einem solchen Szenario müssen die in diesem Abschnitt beschriebenen Schritte manuell durchgeführt werden:
Vor dem Domänenbeitritt des Schulservers muss die Schule (OU) des Schulservers in der Univention Management Console des DC Masters angelegt werden (siehe Abschnitt 4.1). Das Anlegen der Schule (OU) erfolgt üblicherweise automatisch durch das UMC-Konfigurationsmodul und muss nur dann manuell durchgeführt werden, wenn die Schule (OU) im LDAP-Verzeichnis noch fehlt.
Anschließend muss das System erneut der Domäne beitreten. Dies erfolgt auf der Kommandozeile durch Aufruf des Befehls univention-join.
§3.4. Umwandlung einer Single-Server-Umgebung in eine Multi-Server-Umgebung
Für die Umwandlung sind einige Befehle auf der Kommandozeile des DC Masters auszuführen, die einen Austausch des UCS@school-Metapakets sowie eine Konfigurationsänderung durchführen (Bitte das Minuszeichen hinter dem zweiten Paketnamen beachten):
Mit der Deinstallation des Pakets ucs-school-singlemaster werden die nachfolgenden UCS@school-spezifischen Pakete (z.B. UMC-Module), die normalerweise nicht auf einem DC Master der Multi-Server-Umgebung installiert sind, automatisch zur Löschung vorgesehen. Die eigentliche Löschung findet während des nächsten Updates oder durch den manuellen Aufruf von apt-get autoremove statt. Dabei ist zu beachten, dass neben den genannten Paketen ggf. auch ungenutzte Paketabhängigkeiten entfernt werden.
Richtlinien, die (ggf. automatisch von UCS@school) an Container der Schul-OUs verknüpft wurden, sollte auf ihre Einstellungen hin überprüft werden. Dies betrifft unter anderem die DHCP-DNS-Einstellungen sowie die Einstellungen für UCC-Systeme (siehe auch Abschnitt 12.2).
Es ist zu beachten, dass auch nach der abgeschlossenen Umwandlung in eine Multi-Server-Umgebung der auf dem DC Master installierte Samba3- oder Samba4-Dienst bestehen bleibt und nicht automatisch deinstalliert wird.
Die Daten einer Schule werden in einer Organisationseinheit (OU) - einem Teilbaum des LDAP-Verzeichnisdienstes - gespeichert (siehe auch Kapitel 2). Die Verwaltung der logischen Einheit Schule kann in der Univention Management Console über das Modul Schulen erfolgen, welches sich in der Modulgruppe Schul-Administration befindet. Es ermöglicht das Suchen nach, sowie das Anlegen, Bearbeiten und Löschen von Schulen in der UCS@school-Umgebung.
In Single-Server-Umgebungen ist die Angabe eines Schulservernamens nicht erforderlich, während in Multi-Server-Umgebungen der Rechnername des Schulservers angegeben werden muss. Der eingetragene Schulserver wird automatisch als Dateiserver für Klassen- und Benutzerfreigaben verwendet (siehe Abschnitt 6.2 und Abschnitt 7.2).
Das Löschen einer Schule umfasst auch das Entfernen aller damit verbundenen Objekte wie Benutzerkonten, Klassen, Arbeitsgruppen, Rechner, DHCP-Leases, Drucker und Freigaben! Das Löschen einer Schule kann nicht rückgängig gemacht werden!
Über die Schaltfläche Weiter gelangt man auf die zweite Seite des Assistenten. Dort werden die für UCS@school relevanten Benutzerattribute abgefragt: Vorname, Nachname, Benutzername, ggf. Klasse, E-Mail-Adresse und Passwort. Über die Schaltfläche Neue Klasse erstellen ist es möglich, direkt in das UMC-Modul Klassen (Schule) zu wechseln, um dort eine weitere Schulklasse anlegen zu können. Die Angabe von E-Mail-Adresse und Passwort ist optional. Ist kein Passwort vergeben, muss das Passwort vom Administrator (oder Lehrer) zurückgesetzt werden, bevor das Benutzerkonto vom Benutzer erstmalig verwendet werden kann.
§4.3. Pflege von Benutzerkonten über CSV-Dateien
Zusätzlich zum UMC-Modul Benutzer (Schulen), welches die Pflege einzelner Benutzerkonten erlaubt, bringt UCS@school den Assistenten CSV-Import für die Pflege von Benutzerkonten über CSV-Dateien mit.
Der Assistent erlaubt es, eine CSV-Datei mit Benutzerinformationen einzulesen. Die eingelesenen Daten werden z.B. auf Schreibfehler oder Konflikte geprüft und werden vor dem eigentlichen Import innerhalb des Assistenten noch einmal angezeigt. Dort können die Daten nachträglich bearbeitet werden. Neben dem Anlegen neuer Benutzerkonten ist es auch möglich, vorhandene Benutzerkonten zu modifizieren oder zu löschen.
§4.3.1. Import von CSV-Dateien
Für den Import einer CSV-Datei muss das UMC-Modul CSV-Import aus der UMC-Modulgruppe Schul-Administration geöffnet werden. Der Assistent sieht vor, dass durch eine CSV-Datei nur Benutzer einer bestimmten Benutzerrolle importiert werden können. Der gleichzeitige Import von z.B. Schülern und Lehrern durch den Import einer einzelnen CSV-Datei ist also nicht möglich. Auf der ersten Seite des Assistenten ist daher die gewünschte Benutzerrolle auszuwählen (siehe Abbildung 4.1). Sind mehrere Schulen in der UCS@school-Umgebung eingerichtet, wird zusätzlich abgefragt, in welche Schule die CSV-Datei importiert werden soll.
Abbildung 4.1. CSV-Import: Auswahl der Benutzerrolle
Nach dem Auswählen der Schaltfläche Weiter ist auf der zweiten Seite der Import-Modus auszuwählen sowie die CSV-Datei hochzuladen.
In der Standardeinstellung werden die in der CSV-Datei angegebenen Benutzerkonten hinzugefügt. Sollten gleichlautende Benutzerkonten schon im Verzeichnisdienst existieren, werden sie entsprechend der CSV-Datei modifiziert. Dieser Import-Modus ist für den Erstimport von Benutzerkonten (z.B. ein einzelner Klassensatz) oder das nachträgliche Modifizieren einer Teilmenge der vorhandenen Benutzerkonten gedacht.
Liegt eine CSV-Datei mit allen gültigen Benutzern vor, kann alternativ der zweite Import-Modus verwendet werden. In diesem Modus werden (zusätzlich zum vorher beschriebenen Verhalten) alle Benutzerkonten gelöscht, die im Verzeichnisdienst, aber nicht in der CSV-Datei enthalten sind. Zum Beispiel kann so zum Schuljahreswechsel ein CSV-Komplettexport der Schülerdatenbank aus der Schulverwaltungssoftware durchgeführt und die CSV-Datei in UCS@school importiert werden: für neue Schüler werden Benutzerkonten erstellt, die Benutzerkonten von vorhandenen Schülern werden aktualisiert und die Benutzerkonten von abgegangenen Schülern werden gelöscht. Für den zweiten Import-Modus ist die Checkbox Austausch der vorhandenen Benutzer mit der ausgewählten Benutzerrolle durch die Benutzer der CSV-Datei zu aktivieren.
Abbildung 4.2. CSV-Import: Upload der CSV-Datei
Mit dem Hochladen einer CSV-Datei wechselt der Assistent automatisch zum dritten Schritt, in dem eine Zuordnung der Spalten der CSV-Datei zu konkreten Benutzerattributen erfolgt. Folgende Benutzerattribute stehen für die Zuordnung zur Verfügung:
Für die einfachere Zuordnung zeigt der Assistent die ersten 10 Zeilen der CSV-Datei an. Mit einem Klick auf den Titel der jeweiligen Spalte kann die Zuordnung geändert werden (siehe Abbildung 4.3).
Für den Import wird mindestens die Zuordnung der Benutzerattribute Vorname und Nachname benötigt. Wurde dem Attribut Benutzername keine Spalte aus der CSV-Datei zugeordnet, wird der Benutzername automatisch aus dem Vornamen und dem Nachnamen generiert (<Vorname>.<Nachname>). Bei jedem weiteren Import wird der Benutzername erneut generiert und ggf. anhand von zusätzlich angegebenen Attributen einem bestehenden Benutzerkonto zugeordnet.
Abbildung 4.3. CSV-Import: Zuordnung der Benutzerattribute
Auf der letzten Seite des Assistenten werden zur Prüfung alle vorgesehenen Änderungsschritte in einer Tabelle angezeigt. Jede Zeile der Tabelle repräsentiert ein Benutzerkonto und enthält die folgenden Angaben:
den Benutzernamen (ggf. automatisch generiert, falls nicht zugeordnet),
die zugeordneten Attribute aus der CSV-Datei,
die vorgesehene Aktion für das Benutzerkonto, welche angibt, ob das betreffende Benutzerkonto neu angelegt werden soll (Erstellen), bereits existiert und modifiziert werden soll (Ändern) oder gelöscht werden soll (Löschen). Darüber hinaus können Einträge während des Imports auch manuell ausgelassen werden (Ignorieren).
der Angabe der betreffenden Zeile in der CSV-Datei
Werden bei der automatischen Prüfung der CSV-Datei Unstimmigkeiten oder Probleme erkannt, werden die betreffenden Attributfelder farblich hervorgehoben:
Gelbe Zellen weisen auf ungewöhnliche Änderungen hin (z.B. eine Änderung des Geburtsdatums). Die betreffenden Zeilen sollten manuell geprüft werden. Sie stellen jedoch kein Hindernis für einen Import dar.
Rot markierte Zellen enthalten ein gravierendes Problem, wie z.B. die doppelte Vergabe eines Benutzernamens oder die ungültige Schreibweise eines Geburtsdatums. Probleme, die durch die roten Zellen angezeigt werden, müssen korrigiert werden (siehe unten), da ansonsten der Import verweigert wird. Alternativ kann die betroffene Zeile markiert und über die Schaltfläche Ignorieren komplett ignoriert werden.
Beim Verweilen des Mauszeigers über einer farblich markierten Zeile wird ein Tooltip mit näheren Informationen zu erkannten Problemen angezeigt. Über die Checkbox Nur Zeilen mit Problemen anzeigen kann die Anzeige auf Einträge mit gelb oder rot markierten Zellen beschränkt werden.
Abbildung 4.4. CSV-Import: Überprüfung der bevorstehenden Änderungen
Um fehlerhafte Werte einer Zeile zu korrigieren, muss die betroffene Zeile zunächst ausgewählt und anschließend die Schaltfläche Bearbeiten angeklickt werden. Es öffnet sich ein Bearbeitungsdialog, in dem alle Werte einer Tabellenzeile angezeigt werden. Alternativ kann in der Tabelle mit einem Doppelklick auf die betreffende Zelle ebenfalls der Dialog zum Bearbeiten eines Eintrags geöffnet werden.
Über die Schaltfläche Zurücksetzen können nach einer Modifikation die markierten Zeilen wieder auf die Originalwerte aus der CSV-Datei zurückgesetzt werden.
Nach Abschluss der manuellen Prüfung und möglicher Korrekturen kann über die Schaltfläche Weiter eine Zusammenfassung über die bevorstehenden Änderungen im Verzeichnisdienst angezeigt werden (siehe Abbildung 4.5). Nach der Bestätigung der bevorstehenden Änderungen werden diese in den Verzeichnisdienst eingepflegt. Je nach Menge der zu importierenden Daten kann dies einen Moment dauern. Ein Fortschrittsbalken informiert über den aktuellen Fortschritt.
Abbildung 4.5. CSV-Import: Abschließende Zusammenfassung
Nach Abschluss des Imports wird eine kurze Rückmeldung zum Import angezeigt. Die angelegten bzw. geänderten Benutzerkonten stehen nach Abschluss der Verzeichnisdienstreplikation auf den betreffenden UCS@school-Systemen zur Verfügung.
§4.4. Verwaltung von Schulklassen
§4.4.1. Anlegen von Schulklassen
§4.4.2. Bearbeiten von Schulklassen
§4.4.3. Löschen von Schulklassen
§4.5. Verwaltung von Rechnern
§4.5.1. Anlegen von Rechnerkonten
§4.5.2. Bearbeiten von Rechnerkonten
§4.5.3. Löschen von Rechnerkonten
Bei der Angabe von Schulklassen ist zu beachten, dass die Klassennamen domänenweit eindeutig sein müssen. Das heißt, eine Klasse 1A kann nicht in mehreren OUs verwendet werden. Bei der Erstellung von Klassen über das UMC-Modul Klassen (Schulen) wird daher automatisch die OU und ein Bindestrich dem Klassennamen als Präfix vorangestellt. Dieses Vorgehen wird auch für den Import auf der Kommandozeile empfohlen.
Bei der Verwendung von Samba 4 benötigt der S4-Connector einige Zeit, um die Benutzer in die Samba 4-Benutzerdatenbank zu synchronisieren. Je nach Menge der Importdaten und der verwendeten Hardware kann die Synchronisation einige Stunden benötigen. Währenddessen kann es zu Verzögerungen in der Synchronisation von nicht-import-abhängigen Änderungen im LDAP oder Active Directory kommen (z.B. interaktive Änderung von Benutzerpasswörtern).
Netzwerke können derzeit nur auf der Kommandozeile über das Skript /usr/share/ucs-school-import/scripts/import_networks importiert werden. Das Skript muss auf dem Domänencontroller Master als Benutzer root aufgerufen werden. Das Format der Import-Datei ist wie folgt aufgebaut:
In UCS@school gibt es vielfältige Möglichkeiten die Druckmoderation zu konfigurieren und einzusetzen. Nachfolgend wird die Einrichtung eines einzelnen Szenarios beschrieben, welches leicht an die Bedürfnisse der eigenen Schulumgebung angepasst werden kann. In dem beschriebenen Szenario wird der Zugriff auf die physikalischen Drucker für alle Schüler gesperrt.
An den Druckerfreigabeobjekten (UMC-Modul Drucker) können spezielle Zugriffsrechte gesetzt werden. Dabei kann der Zugriff für einzelne Benutzer oder ganze Gruppen erlaubt bzw. gesperrt werden. Um den Schülern den Zugriff auf die physikalischen Drucker zu verbieten, muss an den Druckerfreigaben für diese Drucker der Zugriff durch Benutzer der OU-spezifischen Gruppe schueler-OU> (z.B. schueler-gsmitte) verboten werden. Für den PDF-Drucker PDFDrucker sollten keine Einschränkungen gemacht werden.
Schüler haben damit nur noch die Möglichkeit Druckaufträge an den PDFDrucker zu senden. Im UMC-Modul Drucker moderieren können die Druckaufträge anschließend durch den Lehrer aufgelistet und betrachtet werden. Dafür ist ein geeignetes Programm zur Anzeige von PDF-Dateien auf den Lehrerrechnern erforderlich. Die Druckaufträge können dann durch den Lehrer an einen beliebigen physikalischen Drucker der Schule weitergeleitet oder auch verworfen werden.
Druckerfreigaben werden, wie in einer Standard-UCS-Installation, über das UMC-Modul Drucker auf dem Domänencontroller Master angelegt. Weiterführende Dokumentation findet sich im Druckdienste-Kapitel des UCS-Handbuchs [ucs-handbuch].
Auf dem Schulserver kann über das UMC-Modul Domänenbeitritt das Joinskript 80ucs-school-umc-printermoderation (erneut) ausgeführt werden.
Weitere Freigaben werden, wie in einer Standard-UCS-Installation, über das UMC-Modul Freigaben auf dem Domänencontroller Master angelegt. Weiterführende Dokumentation findet sich im Freigaben-Kapitel des UCS-Handbuchs [ucs-handbuch].
Benutzerkonten von Lehrern können durch eine zusätzliche Gruppenmitgliedschaft zu Schuladministratoren umgewandelt werden. Sie unterliegen dann jedoch der Einschränkung, dass die Benutzerkonten der Lehrer-Schuladministratoren nur auf den edukativen Schulserver und nicht auf den Schulserver des Verwaltungsnetzes repliziert werden.
Die zusätzliche Gruppenmitgliedschaft muss manuell über das UMC-Modul Benutzer auf dem Domänencontroller Master hinzugefügt werden. Auf dem Reiter Gruppen muss das Benutzerkonto in die Gruppe admins-OU (bei der OU gym17 ist dies die Gruppe admins-gym17) aufgenommen werden.
Soll das Benutzerkonten des Schuladministrators auch auf den Systemen des Verwaltungsnetzes verfügbar sein, so reicht es nicht aus, die Gruppenmitgliedschaft zu ändern. Es muss manuell ein neues Benutzerkonto über das UMC-Modul Benutzer auf dem Domänencontroller Master angelegt werden.
Die Benutzerkonten der Schuladministratoren müssen unterhalb der OU der Schule im Container cn=admins,cn=users angelegt werden. Die Auswahl findet mit der Option Container beim Anlegen eines Benutzers statt. Bei einer OU gym17 muss beispielsweise der Container gym17/users/admins ausgewählt werden.
Der Benutzer muss außerdem im Reiter Gruppen in die Gruppe admins-OU, also z.B. admins-gym17 aufgenommen werden.
Sollte der Schuladministrator auch als Lehrer tätig sein, muss zusätzlich die Gruppe lehrer-OU, also z.B. lehrer-gym17, hinzugefügt werden.
Abschließend müssen die Angaben für Profilpfad und Heimatverzeichnispfad am Benutzerobjekt gesetzt werden, um das gleiche Verhalten wie bei Schüler- und Lehrerkonten zu erhalten (siehe dazu auch Abschnitt 6.2).
In Univention Corporate Server 3.x stehen zwei verschiedene Samba-Varianten zur Auswahl:
Samba 3 implementiert Domänendienste auf Basis der Domänen-Technologie von Microsoft Windows NT. Samba 3 ist die aktuelle stabile und bewährte Haupt-Release-Serie des Samba-Projekts und ist seit vielen Jahren in UCS integriert.
Samba 4 ist die nächste Generation der Samba-Suite. Die wichtigste Neuerung von Samba 4 besteht in der Unterstützung von Domänen-, Verzeichnis- und Authentifizierungsdiensten, die kompatibel zu Microsoft Active Directory sind. Mit Samba 4 lassen sich deswegen Active Directory-kompatible Windows-Domänen aufbauen. Diese ermöglichen auch die Verwendung der von Microsoft bereit gestellten Werkzeuge beispielsweise für die Verwaltung von Benutzern oder Gruppenrichtlinien (GPOs). Die aktuell vom Samba-Projekt veröffentlichten Versionen von Samba 4 unterliegen in der Weiterentwicklung noch stärkeren Änderungen als Samba 3. Univention hat die benötigten Komponenten für die Bereitstellung von Active Directory kompatiblen Domänendiensten mit Samba 4 getestet und in enger Zusammenarbeit mit dem Samba-Team in UCS integriert. Parallel dazu wurde für UCS Samba 3 mit Samba 4 integriert. Somit werden auch bei Verwendung der Active Directory kompatiblen Domänendienste die erprobten Datei- und Druckdienste aus Samba 3 verwendet.
Windows-Clients, die ihre DNS-Einstellungen über DHCP beziehen, erhalten in der Standardeinstellung automatisch die IP-Adresse des Schul-DCs als DNS-Server zugewiesen. Dafür wird beim Joinen eines Schulservers automatisch am unter dem Schul-OU-Objekt liegenden DHCP-Container eine DHCP-DNS-Richtlinie verknüpft. Das automatische Verknüpfen dieser Richtlinie kann über das Setzen einer UCR-Variable auf dem Schulserver (bzw. dem Domänencontroller Master bei Single-Server-Umgebungen) deaktiviert werden. Die folgende Variable muss vor der Installation von UCS@school oder dem Update des Systems gesetzt werden:
Bei Neuinstallationen von UCS@school wird standardmäßig Samba 4 empfohlen. Umgebungen, die von einer Vorversion aktualisiert wurden, können von Samba 3 auf Samba 4 migriert werden. Das dafür notwendige Vorgehen ist unter der folgenden URI dokumentiert:
Die zwei UCR-Variablen müssen auf allen Samba4-Domänencontrollern gesetzt werden. Dies kann z.B. in der UMC über eine UCR-Richtlinien global definiert werden. Nach der Änderung müssen die Dienste samba4 und univention-directory-listener neu gestartet werden:
invoke-rc.d samba4 restart
iTALC bringt ein Installationsprogramm mit, das durch alle notwendigen Schritte führt. Während der Installation sollte nur der iTALC Service installiert und der iTALC Master abgewählt werden.
Nach der Installation von iTALC auf dem Windows-Client muss der öffentliche Schlüssel importiert werden, damit der Schulserver Zugriff auf das installierte iTALC-Backend erhält. Dies erfolgt durch Aufruf der iTALC Management Console unter Authentifizierung -﻿> Schlüsseldatei-Assistent starten -﻿> Öffentlichen Schlüssel importieren (Client-Computer) -﻿> Lehrer. Unter Bitte geben Sie den Ort des öffentlichen Zugriffsschlüssels an, der importiert werden soll ist der iTALC-Schlüssel des Schulservers anzugeben. Der Schlüssel wird automatisch auf der SYSVOL-Freigabe des Schulservers unter dem Namen der Schuldomäne unter scripts abgelegt (Kommt Samba 3 zum Einsatz, wird der Schlüssel auf der Netlogon-Freigabe abgelegt). Der Dateiname der Schlüsseldatei enthält den Namen des Schulservers für den sie generiert wurde, um Namenskonflikte auf der SYSVOL-Freigabe bei der Verwendung von Samba 4 zu vermeiden. Damit der iTALC-Assistent die Schlüsseldatei selbständig erkennt, sollte die Datei italc-key_SERVERNAME.pub.key.txt verwendet werden.
In der Grundeinstellung läuft auf jedem Schulserver (bzw. im Single-Server-Betrieb auf dem Domänencontroller Master) ein Proxy-Server auf Basis von Squid im Zusammenspiel mit squidGuard. Der Proxy erlaubt Lehrern in Schulstunden den Zugriff auf einzelne Webseiten zu beschränken oder auch generell bestimmte Webseiten zu sperren. Dies ist in der UCS@school-Lehrerdokumentation [ucs-school-teacher] beschrieben.
Die Proxykonfiguration wird in der Grundeinstellung durch DHCP verteilt, diese Einstellung wird jedoch nicht von allen Browsern unterstützt. Die Konfiguration kann alternativ über eine Proxy-Autokonfigurationsdatei (PAC-Datei) automatisiert werden. In PAC-Dateien sind die relevanten Konfigurationparameter zusammengestellt. Die PAC-Datei eines Schulservers steht unter der folgenden URL bereit:
RADIUS ist ein Authentifizierungsprotokoll für Rechner in Computernetzen. Es wird in UCS@school für die Authentifizierung von Rechnern für den Wireless-LAN-Zugriff eingesetzt.
Der RADIUS-Server muss auf den Access Points konfiguriert werden. Die vom Client übertragenen Benutzerkennungen werden dann durch den festgelegten RADIUS-Server geprüft, der wiederum für die Authentifizierung auf den UCS-Verzeichnisdienst zugreift.
Nun müssen alle Access Points der Schule in der Konfigurationsdatei /etc/freeradius/clients.conf registriert werden. Pro Access Point sollte ein zufälliges Passwort erstellt werden. Dies kann z.B. mit dem Befehl makepasswd geschehen. Die Kurzbezeichnung ist frei wählbar. Ein Beispiel für einen solchen Eintrag für einen Access Point:
Die IP-Adresse des Schulservers muss als RADIUS-Server angegeben werden
Der Radius-Port ist 1812 (sofern kein abweichender Port in FreeRADIUS konfiguriert wurde)
Das in der /etc/freeradius/clients.conf hinterlegte Passwort
Die Konfiguration unterscheidet sich je nach Betriebssystem des Clients. Im Univention Wiki findet sich eine exemplarische Schritt-für-Schritt-Anleitung für die Einrichtung unter Windows XP: http://wiki.univention.de/index.php?title=Einrichtung-WLAN-Authentifizierung-WinXP, sowie für die Einrichtung unter Windows 7: http://wiki.univention.de/index.php?title=Einrichtung-WLAN-Authentifizierung-Win7.
Im Fehlerfall sollte die Logdatei /var/log/freeradius/radius.log geprüft werden. Erfolgreiche Logins führen zu einem Logeintrag Auth: Login OK und eine fehlgeschlagene Authentifizierung beispielsweise zu Auth: Login incorrect.
ucsschool/exam/default/room definiert den vorausgewählten Raum für eine neue Klassenarbeit. Der Eintrag beinhaltet den LDAP-Namen des Raumes (inklusive des Schul-OU-Präfxies), also bspw. meineschule-PC Raum. Ist die Variable nicht gesetzt, wird standardmäßig der alphabetisch erste Raum ausgewählt.
Zu diesem Thema ist auch ein Hinweis von Microsoft zu Windows XP Systemen zu beachten: „Jede Version von Windows XP Professional stellt eine Funktion zur Optimierung für schnelles Anmelden zur Verfügung. Computer mit diesen Betriebssystemen warten standardmäßig beim Starten nicht auf den Start des Netzwerks. Nach der Anmeldung werden die Richtlinien im Hintergrund verarbeitet, sobald das Netzwerk zur Verfügung steht. Dies bedeutet, dass der Computer bei der Anmeldung und beim Start weiterhin die älteren Richtlinieneinstellungen verwendet. Daher sind für Einstellungen, die nur beim Start oder bei der Anmeldung angewendet werden können (z. B. Softwareinstallation und Ordnerumleitung), möglicherweise nach dem Ausführen der ersten Änderung am Gruppenrichtlinienobjekt mehrere Anmeldungen durch den Benutzer erforderlich. Diese Richtlinie wird gesteuert durch die Einstellung in Computerkonfiguration\Administrative Vorlagen\System\Anmeldung\Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten. Diese Funktion ist in den Betriebssystemversionen von Windows 2000 oder Windows Server 2003 nicht verfügbar.“ [1]
Diese Richtlinie wird über eine Administrative Vorlage (ADMX) definiert, die in Microsoft Knowledgebase Artikel 555324. [2] beschrieben ist. Erst nach Einbinden der Administrative Vorlage (ADMX) können folgende Einstellungen getroffen werden. Beispiele für ADMX-Dateien liegen unter /usr/share/doc/ucs-school-umc-exam/examples/GPO. Zum Einbinden der ADMX-Dateien müssen diese auf die SYSVOL-Freigabe kopiert werden (siehe Abschnitt 11.3.1).
Diese Richtlinie definiert eingeschränkte Dateisystemberechtigungen gemäß Microsoft Knowledgebase Artikel 823732 [3].
Aufgrund der Tiefe des Eingriffs der Software Restriction Policies ist zu empfehlen, diese zunächst in einer Testumgebung zu auszuprobieren. Bei der Analyse von Zugriffsfehlern kann die Ereignisanzeige des Windows-Clients helfen [4].
Es sollte beachtet werden, dass schreibbare Verzeichnisse, auf die der Zugriff nicht per Software Restriction Policy eingeschränkt ist, Benutzern die Möglichkeit geben, Programmdateien dort abzulegen und so die definierten Regeln zu umgehen [5].
[1] http://technet.microsoft.com/de-de/library/cc785665(v=ws.10).aspx
[2] http://support.microsoft.com/kb/555324
[3] http://support.microsoft.com/kb/823732
[4] Weitere sinnvolle Hinweise zur Analyse und Pflege der Software Restriction Policies liefert z.B. http://www.nsa.gov/ia/_files/os/win2k/Application_Whitelisting_Using_SRP.pdf
Die UCC-Systeme können Kerberos als Authentifizierungsmethode für die transparente Authentifizierung gegenüber dem HTTP-Proxy (Squid) des Schulservers verwenden. Diese Authentifizierungsmethode ist in der Standardeinstellung im HTTP-Proxy des Schulservers deaktiviert und muss manuell durch das Setzen der Univention Configuration Registry-Variable squid/krb5auth=yes aktiviert werden. Anschließend ist auf dem Schulserver ein Neustart des Dienstes squid notwendig, der entweder über das UMC-Modul Systemdienste oder auf der Kommandozeile über das Kommando invoke-rc.d squid3 restart durchgeführt werden kann.
§14.1.2. Installation zusätzlicher Anmeldeserver
In UCS@school-Umgebungen in denen Samba 4 Active Directory-kompatible Dienste bereitstellt, kann zur Skalierung der Anmeldedienste ein zusätzlicher UCS DC Slave an einem Schulstandort installiert werden. Dieser zusätzliche, sekundäre Domänencontroller wird als normaler UCS DC Slave installiert und muss danach durch Ausführung eines speziellen Skripts an dem Schulstandort der Domäne beitreten. Auf diesem sekundären Domänencontroller wird nicht die UCS@school App installiert.
Zwischen dem Samba4-Verzeichnisdienst auf dem neuen UCS DC Slave und dem UCS@school-Server wird die DRS Replikation eingesetzt, die Samba 4 auch im Standard-UCS verwendet. Die für UCS@school charakteristische selektive LDAP-Replikation von Verzeichnisdaten findet wie üblich weiter vom UCS DC Master zu den DC Slave-Systemen statt. Allerdings findet die Synchronisation mit dem Samba4-Verzeichnisdienst nur auf dem primären Schulserver statt.
Der sekundäre Domänencontroller stellt nur redundante Anmeldedienste zur Verfügung, UCS@school-spezifische Dienste und UMC-Module stellt er nicht bereit.
Damit in diesem Setup der Domänenbeitritt von Windows-Clients problemlos funktioniert, sollten für diese immer über die UCS@school-spezifischen Import-Werkzeuge Rechnerobjekte in der Univention Management Console angelegt werden. Wenn dies nicht vor dem Domänenbeitritt eines Windows-Clients erfolgt, kann der Domänenbeitritt mit einer Windows-Fehlermeldung abbrechen. Dies ist darauf zurückzuführen, dass zur Konfliktvermeidung im Samba-Verzeichnisdienst auf dem sekundären Schul-DC per Voreinstellung keine neuen Maschinenkonten angelegt werden können.
Um einen solchen sekundären Domänencontroller an einem Schulstandort zu installieren und in die Domäne aufzunehmen, müssen auf dem Master folgende vorbereitende Schritte als root durchgeführt werden:
<Schul-OU> <Name des neuen Schul-DCs>
/usr/share/ucs-school-import/scripts/move_domaincontroller_to_ou \
--ou <Schul-OU> --dcname <Name des neuen Schul-DCs>
cd /usr/share/ucs-school-import/scripts
scp ucs-school-join-secondary-samba4 root@<Name des neuen Schul-DCs>:
Danach muss auf dem neuen DC Slave für den Domänenbeitritt folgender Schritt als Benutzer root ausgeführt werden:
/root/ucs-school-join-secondary-samba4 <IP des primären Schul-DCs>
[ucs-handbuch] Univention GmbH. 2015. Univention Corporate Server - Handbuch für Benutzer und Administratoren. https://docs.software-univention.de/handbuch-4.1.html.
[ucc-handbuch] Univention GmbH. 2014. Univention Corporate Client - Manual for administrators. https://docs.software-univention.de/ucc-manual.html.
[ucs-school-teacher] Univention GmbH. 2012. UCS@school - Handbuch für Lehrkräfte und Schuladministratoren. https://docs.software-univention.de/ucsschool-lehrer-handbuch-4.0.pdf.
[ucs-performance-guide] Univention GmbH. 2015. UCS performance guide. https://docs.software-univention.de/performance-guide-4.1.html.

References: §3

§3

§4

§4

§4

§4

§4

§4

§4

§4

§4

§4

§14