UCS@ school 2.4 - Univention

UCS@school
Handbuch für Administratoren

Version 2.4
Revision 6804
Stand: 11. Oktober 2010
Alle Rechte vorbehalten. / All rights reserved.
(c) 2002 bis 2010
Univention GmbH
Mary-Somerville-Straße 1
28359 Bremen
Deutschland
feedback@univention.de
Jede aufgeführte Marke und jedes Warenzeichen steht im Eigentum ihrer jeweiligen eingetragenen Rechts-
inhaber. Linux ist ein eingetragenes Warenzeichen von Linus Torvalds.
The mentioned brand names and registered trademarks are owned by the respective legal owners in each
case. Linux is a registered trademark of Linus Torvalds.

Inhaltsverzeichnis
1 Einführung 5
2 Domänenkonzept 7
2.1 Serverkonzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Organisationseinheiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Verwaltungsnetz vs. Edukativnetz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Benutzerkonten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Installation 11
3.1 Domänencontroller Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Domaincontroller Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Domänencontroller Slave (Schul-DC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4 Datenpflege 15
4.1 Organisationseinheiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Benutzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3 (Klassen-)Gruppen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4 Netzwerke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.5 Rechner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.6 Drucker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.7 Pre- und Post-Hook-Skripte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.8 Hook: automatische Erstellung der Freigabe “Marktplatz” . . . . . . . . . . . . . . . . . . . 22
4.9 Hook: Setzen des LDAP-Containers für DHCP-Objekte . . . . . . . . . . . . . . . . . . . . 23
5 Schulspezifische Anwendungen 25
5.1 Benutzerverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2 Gruppenverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3 Computerraum-Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.4 Druckermoderation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.5 Materialverteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.6 Unterrichtsvorbereitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.7 Webfilter-Einstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.8 Helpdesk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6 Windows-Dienste 33
6.1 iTALC-Installation auf Windows-Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.2 Windows-Netlogon-Skripte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3

Inhaltsverzeichnis
Hinweise auf weitere Dokumentation 37
4

1 Einführung
UCS@school ist eine auf Univention Corporate Server (UCS) basierende IT-Komplettlösung mit zahl-
reichen Zusatzkomponenten für Nutzung, Betrieb und Management von Informationstechnologie (IT) in
Schulen. UCS@school vereint die Stärken des Enterprise-Betriebssystems UCS im Bereich einfacher
und zentraler Verwaltung von IT-Umgebungen mit den Vorteilen klassischer Schulsoftware für den Com-
putereinsatz im Unterricht.
UCS ist die ideale Plattform für Schulen und Schulträger, um IT gemeinsam mit den dazu gehören-
den Service- und Supportprozessen auch für mehrere Schulen zentral und wirtschaftlich bereitzustellen.
UCS@school ergänzt diese auch im Unternehmens- und Behördeneinsatz bereits langjährig bewährte
Lösung um zahlreiche praxiserprobte Komponenten für den IT-Betrieb und den IT-gestützten Unterricht in
der Schule. Dazu gehören alle wichtigen Funktionen zur Unterrichtssteuerung für Lehrer.
Die Lösung UCS@school setzt sich aus drei Bestandteilen zusammen:
1. dem UCS-Basissystem
2. dem Univention Management System
3. der UCS@school-Komponente für UCS
Das Basissystem umfasst das Betriebssystem (die UCS-Linux-Distribution auf Basis von Debian GNU/Li-
nux) sowie Werkzeuge zur Installation, Aktualisierung und lokalen Konfiguration von Clients und Servern.
Das Univention Management System realisiert einen Single-Point-of-Administration, über den die Kon-
ten aller Domänenmitglieder (Benutzer, Gruppen und Rechner) in einem Verzeichnisdienst verwaltet wer-
den. Dafür bedient es sich der Standardkomponenten OpenLDAP, Kerberos, DNS und SSL. Es lässt sich
sowohl über eine web- als auch über eine kommandozeilenbasierte Schnittstelle verwenden. Das Mana-
gementsystem ist erweiterbar und besitzt eine flexible Client-Server-Architektur, durch die Änderungen auf
die davon betroffenen Systeme übertragen und dort aktiviert werden.
Die UCS@school-Komponente erweitert das UCS-System um zahlreiche Funktionen für den standort-
übergreifenden Betrieb der gesamten IT-Infrastruktur, für den schulinternen IT-Betrieb und auch den IT-
gestützten Unterricht.
Über das Univention Management System können alle Bestandteile der UCS-Domäne über Rechner-,
Betriebsystem- und Standortgrenzen hinweg organisationsweit zentral verwaltet werden. Es steht somit
ein echter Single-Point-of-Administration für die Domäne zur Verfügung, der auch die im Schulumfeld
benötigten Kerndienste wie DNS, DHCP, Datei- und Druckdienste umfasst. Darüber hinaus werden auch
die Benutzerkonten (für z.B. Schüler und Lehrer) im OpenLDAP-Verzeichnisdienst vorgehalten. Um dieses
zentrale Identitymanagement weiter zu vereinfachen, bringt UCS@school unter anderem eine CSV-Datei-
basierte Importschnittstelle zur Pflege von zum Beispiel Benutzern oder Rechnern mit.
Um den IT-gestützten Unterricht zu ergänzen, wurde die UCS-Benutzeroberfläche an die Anforderungen
von Lehrern angepasst. Ohne besondere IT-Kenntnisse können sie zum Beispiel ihre Unterrichtsvorberei-
5

1 Einführung
tung und Klassenraumplanung organisieren oder den Internetzugang für ausgewählte Computer temporär
sperren. Lehrern ist es auch möglich, den Bildschirminhalt eines Schüler-PCs einzusehen, via Netzwerk
individuelle Hilfestellungen zu geben oder einen beliebigen Desktop auf alle anderen Computer in der
Klasse oder per Beamer zu übertragen. Auch bei im Schulalltag wiederkehrenden Tätigkeiten, wie dem
Zurücksetzen von Passwörtern für Schüler-Benutzerkonten, werden Lehrer unterstützt.
Die nachfolgenden Kapitel beschreiben die Implementierung von UCS@school sowohl in kleinen Umge-
bungen mit einer Schule als auch größeren Umgebungen mit mehreren Schulen. Hierfür werden umfang-
reiche UCS-Kenntnisse vorausgesetzt, welche unter anderem für die Installation benötigt werden. Weitere
Hinweise zur Administration von UCS-Systemen können dem UCS-Handbuch entnommen werden.
Für die Bedienung der UCS@school-spezifischen Module der Univention Management Console (nachfol-
gend kurz UMC genannt) steht ein zusätzliches Dokument [1] bereit.
6
Abbildung 1.1: UCS@school-spezifische UMC-Module

2 Domänenkonzept
Inhaltsverzeichnis
2.1 Serverkonzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Organisationseinheiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Verwaltungsnetz vs. Edukativnetz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Benutzerkonten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Univention Corporate Server (UCS) bietet ein plattformübergreifendes Domänenkonzept mit einem ge-
meinsamen Vertrauenskontext zwischen Linux- und Windows-Systemen. Innerhalb dieser Domäne ist ein
Benutzer mit seinem im Univention Management System hinterlegten Benutzernamen und Passwort auf
allen Systemen bekannt, und kann für ihn freigeschaltete Dienste nutzen.
UCS@school baut auf das flexible Domänenkonzept von UCS auf, mit dem sowohl sehr kleine als auch
sehr große Umgebungen mit mehreren Standorten realisiert werden können. Die nachfolgenden Abschnit-
te gehen davon aus, dass das UCS-Domänenkonzept bereits bekannt ist (siehe auch Kapitel “Domänen-
konzept” im UCS-Handbuch).
2.1 Serverkonzepte
Für den Betrieb von UCS@school in kleinen Umgebungen reicht bereits ein einzelnes Serversystem aus,
das dann als UCS Domänencontroller Master alle benötigten Dienste bereitstellt.
Für Schulträger bzw. große Schulen, die größere Umgebungen mit mehreren Schulen bzw. Standorten
oder mit einer großen Anzahl an Clients betreiben, kann es erforderlich werden, zusätzliche UCS-Systeme
in Betrieb zu nehmen. Diese Systeme werden in der Domäne mit der Systemrolle Domänencontroller
Slave (nachfolgend kurz: Schul-DC) aufgesetzt und bieten dann am jeweiligen Standort alle benötigten
Dienste an. Dies wird z.B. notwendig, um den DHCP-Dienst an mehreren Standorten mit physikalisch
getrennten Netzen einzusetzen.
Auf den Schul-DCs läuft lokal ebenfalls der LDAP-Verzeichnisdienst, auf den alle weiteren Dienste, die
an dem Standort betrieben werden, zurückgreifen. Der Schul-DC repliziert zu diesem Zweck automatisch
das LDAP-Verzeichnis des Domänencontroller Master, so dass stets alle notwendigen Daten aktuell und
vollständig vorgehalten werden. Der Betrieb des lokalen Verzeichnisdienstes reduziert so die zu über-
tragenden Datenmengen zum Domänencontroller Master und gewährleistet einen reibungslosen Betrieb,
auch wenn die Verbindung zwischen Schul-DC und dem zentralen Domänencontroller Master-System
einmal ausfallen sollte.
Aus Sicherheitsgründen sieht das Konzept von UCS@school vor, dass die Schul-DCs nur eine Teilrepli-
kation des LDAP-Verzeichnisses des Domänencontroller Master vornehmen. In der Standardeinstellung
replizieren sie nur für sie relevante Teile (z.B. Benutzer und Gruppen der jeweiligen Schule) sowie die
globalen Strukturen des LDAP-Verzeichnisses.
7

2 Domänenkonzept
2.2 Organisationseinheiten
Zur Unterteilung der im LDAP-Verzeichnisdienst hinterlegten Objekte und Einstellungen wird für jede
Schule im LDAP-Verzeichnis eine eigene Organisationseinheit (OU) angelegt. Unterhalb dieser OU wer-
den Container für z.B. Benutzerobjekte, Gruppen, DNS- und DHCP-Einstellungen, usw. angelegt (siehe
auch Abbildung auf Seite 10). Diese OUs werden direkt unterhalb der LDAP-Basis angelegt.
Sollten mehrere unterschiedliche Schulformen (z.B. Gymnasium und Berufsschule) innerhalb eines Ge-
bäudes untergebracht sein, ist es ratsam, für jede Schulform eine eigene OU zu erstellen, da dies häufig
die zentrale Benutzerverwaltung (z.B. bei der Versetzung) erleichtert.
Jedem Schul-DC wird bei der Teilreplikation des Verzeichnisses eine feste OU zugeordnet. In der Standar-
deinstellung repliziert ein Schul-DC nur die ihm zugeordnete OU sowie die globalen Strukturen des LDAP-
Verzeichnisses. Ausnahmen für Standorte, an denen mehrere OUs mit nur einem Schul-DC betrieben
werden, können definiert werden.
Der Name einer OU sollte sich auf Buchstaben und Ziffern sowie auf den Bindestrich beschränken, da er
z.B. die Grundlage für Gruppen- und Rechnernamen bildet. Häufig kommen hier Schulnummern wie 712
oder zusammengesetzte Kürzel wie 28G01 oder gymmitte zum Einsatz.
Abbildung 2.1 verdeutlicht hier noch einmal den Aufbau des LDAP-Verzeichnisdienstes. Das Kürzel XXX
steht hierbei für den jeweiligen Namen der OU.
2.3 Verwaltungsnetz vs. Edukativnetz
Neben der Bereitstellung von Diensten für den edukativen Bereich werden die gleichen Dienste oft auch
für die Verwaltung innerhalb der einzelnen Standorte benötigt. Es kann daher zusätzlich zur Unterteilung
in Organisationseinheiten (OU) noch eine Unterteilung der OU in Verwaltungsnetz und Edukativnetz erfol-
gen.
Diese optionale Unterteilung findet auf Ebene der Serversysteme bzw. der Netzwerksegmente statt und
sieht vor, dass mindestens ein Schul-DC für das edukative Netz und ein Schul-DC für das Verwaltungsnetz
betrieben wird. Im Gegensatz zum edukativen Schul-DC wird die Verzeichnisdienst-Replikation des Ver-
waltungs-Schul-DCs noch weiter eingeschränkt. Schul-DCs des Verwaltungsnetzes replizieren von den
OU-spezifischen Benutzerkonten die Konten der Schuladministratoren, Mitarbeiter und Lehrer.
2.4 Benutzerkonten
Wie in Abbildung 2.1 bereits ersichtlich, werden Benutzerkonten bei UCS@school in vier unterschiedliche
Typen unterschieden:
8
• Schüler
• Lehrer
• Schuladministratoren
• Mitarbeiter

Jedem Benutzertyp werden dabei unterschiedliche Rechte innerhalb der Domäne zuteil.
2.4 Benutzerkonten
Schülern wird in der Standardeinstellung kein Zugriff auf die Administrationsoberflächen gewährt. Sie
können sich mit ihren Benutzerkonten nur an z.B. Windows-Clients anmelden und die für sie freigegebenen
Dateifreigaben und Drucker verwenden.
Lehrer erhalten im Gegensatz zu Schülern zusätzliche Rechte, um z.B. auf UMC-Module zugreifen zu
können, die das Zurücksetzen von Schülerpasswörtern oder das Auswählen von Internetfiltern ermögli-
chen. Auf welche UMC-Module sie Zugriff erhalten, kann vom Domänen-Administrator individuell definiert
werden. Sie erhalten in der Regel nur Zugriff auf einen Teil der von Univention Management Console
bereitgestellten Funktionen.
Vollen Zugriff auf die Administrationsfunktionen von UCS@school in Univention Management Console
erhalten normalerweise die Schuladministratoren. Sie können z.B. Computer zu Rechnergruppen zu-
sammenfassen, neue Internetfilter definieren oder auch Lehrerpasswörter zurücksetzen.
Der Benutzertyp Mitarbeiter kommt häufig im Umfeld der Schulverwaltung zum Einsatz. Er besitzt in der
Standardeinstellung ähnliche Zugriffsrechte wie ein Schülerkonto, kann jedoch mit zusätzlichen Rechten
ausgestattet werden.
Es ist hierbei zu beachten, dass Überschneidungen der Benutzertypen Lehrer, Mitarbeiter und Schulad-
ministrator möglich sind. So können z.B. Benutzerkonten erstellt werden, die eine Nutzung des Kontos
sowohl als Lehrer im edukativen Netz einer OU als auch als Mitarbeiter im Verwaltungsbereich einer OU
ermöglichen.
Für die Pflege der Benutzerkonten stehen mehrere Möglichkeiten zur Verfügung. Die Bearbeitung von
Benutzerkonten kann über die von UCS bereitgestellten kommandozeilen- als auch über die webbasierte
Variante des Univention Directory Manager (UDM) erfolgen. Darüber hinaus bringt UCS@school flexible
Importskripte mit, die auf dem kommandozeilenbasierten UDM aufbauen und durch eigene Hook-Skrip-
te an eigene Bedürfnisse angepasst werden können. Sie lesen Tabulator-getrennte Importdateien ein,
die üblicherweise aus vorhandenen Schulverwaltungssystemen extrahiert werden können und so einen
automatisierten Abgleich ermöglichen.
9

2 Domänenkonzept
10
LDAP­Basis
Globale Strukturen
groups
OU=XXX
UCS – übliche Container und Objekte
ouadmins
Ucsschool
users
groups
computers
shares
dhcp
printers
policies
networks
admins
lehrer
schueler
mitarbeiter
Domain User XXX
lehrer­XXX
schueler­XXX
mitarbeiter­XXX
raeume
schueler
dc
member
klassen
admins­XXX
DC – Edukativnetz
DC – Verwaltungsnetz
OUXXX – DC – Edukativnetz
OUXXX – DC – Verwaltungsnetz
XXXRaum017B
XXXRaum432
XXX­InformatikAG
XXX­MusikAG
Klassen
dcXXX­01
mbXXX­01
mbXXX­02
XXX­1A
XXX­2D
XXX­3C
Abbildung 2.1: LDAP-Strukturen für UCS@school
XXX­1A
XXX­2D
XXX­3C
Container Objekte

3 Installation
Inhaltsverzeichnis
3.1 Domänencontroller Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Domaincontroller Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3 Domänencontroller Slave (Schul-DC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Der Installationsvorgang setzt sich aus der Installation von Univention Corporate Server sowie der Instal-
lation der zusätzlichen Komponente UCS@school zusammen. Nachfolgend wird nur auf ggf. auftretende
Unterschiede zur Grundinstallation von UCS sowie die Installation von UCS@school selbst eingegangen.
Nähere Informationen zur Installation von UCS können dem UCS-Handbuch entnommen werden.
Die eigentliche Installation einer Single-Server-Umgebung unterscheidet sich kaum von der einer Master-
Slave-Umgebung. Die Installation des Domänencontroller Master-Systems wird daher für beide Server-
konzepte (Single-Server- bzw. Master-Slave-Umgebung) gemeinsam beschrieben. Single-Server-Umge-
bungen können nachträglich auch in Master-Slave-Umgebungen umgewandelt werden, indem Domänen-
controller Slave-Systeme (Schul-DCs) in die Domäne eingebunden werden.
3.1 Domänencontroller Master
Das UCS-System, auf dem später die Datenpflege vorgenommen werden soll, muss mit der Systemrolle
Domänencontroller Master installiert werden. Die dafür notwendigen Schritte können dem UCS-Hand-
buch entnommen werden. Während der Installation sollten folgende Punkte beachtet werden:
• Es wird empfohlen, eine eigene DNS-Domäne z.B. schule.local zu verwenden, die nicht mit öffent-
lichen DNS-Namen kollidiert, um spätere DNS-Probleme mit sich überlappenden DNS-Namen zu
vermeiden.
• Nachfolgend wird davon ausgegangen, dass alle UCS-Systeme direkten Zugang zum Internet be-
sitzen. Sollte dies nicht der Fall sein, könnte die Verwendung von lokalen Repositories notwendig
werden. Weitere Hinweise hierzu finden sich im UCS-Handbuch.
• Während der Installation von UCS@school auf einem Domänencontroller Master wird bei einer Sin-
gle-Server-Umgebung automatisch Samba 1 installiert, so dass dieser anschließend PDC 2 für die
konfigurierte Windows-Domäne wird.
• Auf den Schul-DCs wird automatisch das Paket univention-samba-slave-pdc installiert, so dass
jeder Schul-DC einen Windows-PDC darstellt. Der Betrieb mehrerer Schul-DCs in einem physikali-
schen Subnetz ist daher derzeit nicht möglich. Darüber hinaus sollte für eine Master-Slave-Umge-
bung während der Installation des Domänencontroller Master darauf geachtet werden, daß Samba
1 Anmelde- und Dateifreigabe-Dienst für Windows-Systeme
2 Primärer Windows Domänencontroller, kurz PDC
11

3 Installation
nicht mitinstalliert wird, sofern das System zusammen mit einem Schul-DC in einem physikalischen
Subnetz betrieben werden soll. Dazu muss während der Installation in der Softwareauswahl das
Paket Samba abgewählt werden.
Um die UCS@school-Komponente auf den UCS-Systemen automatisch aus dem UCS-Online-Repository
zu beziehen, muß auf den jeweiligen Systemen im UMC-Modul Online-Updates die Komponente ucs-
school eingetragen und aktiviert werden.
Alternativ können auf den Systemen auch die benötigten Univention Configuration Registry-Variablen auf
der Kommandozeile gesetzt werden:
root@master:~# ucr set repository/online/component/ucsschool/server=apt.univention.de
root@master:~# ucr set repository/online/component/ucsschool/version=current
root@master:~# ucr set repository/online/component/ucsschool=enabled
Für die Installation von UCS@school werden mehrere Meta-Pakete bereitgestellt, die die weiteren benö-
tigten Pakete automatisch installieren. Auf einem Domänencontroller Master muss für eine Single-Server-
Umgebung das Paket ucs-school-singlemaster installiert werden. Über Paketabhängigkeiten werden
automatisch alle für die Grundinstallation benötigten Pakete wie z.B. für Datenpflege, LDAP-ACLs, UMC-
Module, Netlogon-Skripte für Windows und HTTP-Proxy mitinstalliert.
In einer Master-Slave-Umgebung ist das Paket ucs-school-master auf dem Domänencontroller Master
zu installieren. Durch das Paket werden nur die für den Domänencontroller Master relevanten Pakete für
Datenpflege und LDAP-ACLs installiert.
Die Paketinstallation kann durch den Aufrufs eines Befehls auf der Kommandozeile durchgeführt werden
(hier: Single-Server-Umgebung):
root@master:~# univention-install ucs-school-singlemaster
Nach der Installation der Pakete sollte ein Neustart des Systems durchgeführt werden.
Besonderheiten einer Single-Server-Umgebung
Die Single-Server-Umgebung weist einige Besonderheiten auf, die hier kurz erläutert werden:
12
• Es wird während der Installation automatisch die OU musterschule angelegt. Der Name
der OU kann vor der Installation über die Univention Configuration Registry-Variable
ucsschool/defaultschoolname geändert werden.
root@master:~# ucr set ucsschool/defaultschoolname="gym123"
Sollte ein abweichender Name vergeben worden sein, ist zu beachten, dass die in diesem Dokument
genannten DNs und Container-Namen, die die Musterschule betreffen, entsprechend abweichen.
• Die Suchbasis des DHCP-Dienstes wird auf dem Domänencontroller Master automatisch auf die OU
musterschule umgesetzt. Die DHCP-Einträge von bestehenden und neuen Rechnersystemen müs-
sen anschließend manuell im Container cn=dhcp,ou=musterschule,LDAPBASIS abgelegt wer-
den, um einen reibungslosen DHCP-Betrieb zu gewährleisten.
• Windows-Systeme, die ohne ein zuvor angelegtes Rechnerkonto der Domä-
ne beitreten, werden entgegen dem Standard-UCS-Verhalten in dem Container
cn=computers,ou=musterschule,LDAPBASIS angelegt.

3.2 Domaincontroller Backup
3.2 Domaincontroller Backup
Sind in einer UCS@school-Master-Slave-Umgebung Systeme installiert, die mit der Systemrolle Domä-
nencontroller Backup aufgesetzt wurden, ist es erforderlich, dass auf diesen Systemen das Paket ucs-
school-ldap-acls-master eingespielt wird. Ist das Paket auf den Domänencontroller Backup-Systemen
nicht eingespielt, kommt es auf den Schul-DCs zu Problemen bei der Replikation des Verzeichnisdienstes.
Darüber hinaus sollten auch die UCS@school-spezifischen LDAP-Schema-Pakete ucs-school-umc-
helpdesk-schema und ucs-school-import-schema auf dem Domänencontroller Backup nachinstalliert
werden, um Probleme nach dem Hochstufen eines Domänencontroller Backups zum Domänencontroller
Master zu vermeiden.
Die Installation der Pakete kann ebenfalls über Univention Management Console oder auf der Kommandozeile
erfolgen:
root@backup:~# univention-install ucs-school-ldap-acls-master \
ucs-school-umc-helpdesk-schema ucs-school-import-schema
3.3 Domänencontroller Slave (Schul-DC)
An den einzelnen Schul-Standorten ist jeweils mindestens ein Domänencontroller Slave (Schul-DC) zu
installieren. Je nach Netzanbindung und Anzahl der am jeweiligen Standort verwendeten UCS-Systeme
kann es sinnvoll sein, pro Standort ein System mit lokalem Repository zu installieren.
Bei der Installation der Schul-DCs sollte bereits während des Installationsvorgangs darauf geachtet wer-
den, dass der Name des Schul-DCs in das Namensschema passt. Während des Datenimports bzw.
des Anlegens einer OU werden automatisch Rechnerobjekte für die Schul-DCs mitangelegt. Sollte hier
kein spezieller Name für den Schul-DC angegeben worden sein, wird das reguläre Namensschema für
UCS@school-Schul-DCs verwendet.
Das Namensschema sieht vor, dass der Name des ersten Schul-DCs einer OU dcXXX-01 lautet, wo-
bei XXX durch den kleingeschriebenen Namen der OU zu ersetzen ist (Beispiele: dc28g01-01 oder
dcgym123-01). Es kann auch ein eigener Name für den Schul-DC verwendet werden, der dem Befehl
create_ou beim Anlegen der OU übergeben werden muss (siehe hierzu Kapitel 4.1).
Bevor der Schul-DC der Domäne beitritt, muss die entsprechende OU (und damit auch ein Rechnerkonto)
für den Schul-DC im Verzeichnisdienst angelegt werden. Während der Installation des UCS-Systems sollte
daher kein Domänenbeitritt stattfinden. Hinweise zum Anlegen einer OU finden sich im Kapitel 4.1.
Ist die UCS-Installation abgeschlossen, kann anschließend die Installation der UCS@school-Komponente
auf dem Schul-DC vorbereitet werden. Dazu muss auch auf dem Schul-DC das UCS-Online-Repository
eingerichtet werden. Dies kann, wie bereits bei der Installation des Domänencontroller Master beschrieben
wurde, auf der Kommandozeile oder im Modul Online-Updates der Univention Management Console
erfolgen.
Es sind folgende Univention Configuration Registry-Variablen zu setzen:
• repository/online/component/ucsschool/server=apt.univention.de
• repository/online/component/ucsschool/version=current
13

3 Installation
• repository/online/component/ucsschool=enabled
Die eigentliche Installation der UCS@school-Pakete erfolgt auf dem Domänencontroller Slave über die
Installation eines Metapakets: ucs-school-slave. Anschließend muss ein erneuter Domänenbeitritt des
Schul-DCs durchgeführt werden, was über den Aufruf des Befehls univention-join erreicht wird. Auf
Domänencontroller Slave-Systemen ist dafür die Angabe von Benutzernamen und Passwort eines Benutzers
der Gruppe Domain Admins notwendig. Die Installation erfolgt auf der Kommandozeile:
root@dc28g01-01:~# univention-install ucs-school-slave
root@dc28g01-01:~# univention-join
Nach der Installation der Pakete sollte ein Neustart des Systems durchgeführt werden.
14

4 Datenpflege
Inhaltsverzeichnis
4.1 Organisationseinheiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Benutzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3 (Klassen-)Gruppen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4 Netzwerke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.5 Rechner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.6 Drucker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.7 Pre- und Post-Hook-Skripte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.8 Hook: automatische Erstellung der Freigabe “Marktplatz” . . . . . . . . . . . . . . . . . . . 22
4.9 Hook: Setzen des LDAP-Containers für DHCP-Objekte . . . . . . . . . . . . . . . . . . . . 23
Ein wichtiges Element der Schulumgebung ist die Pflege der gespeicherten Daten. Dies wird besonders
deutlich am Schuljahreswechsel, bei dem alle Schüler in andere Klassen versetzt werden und die Lehrer
ebenfalls neuen Klassen zugeordnet werden. Weiterhin ist es unerlässlich die IT-Infrastruktur zu erfassen
und zu verwalten.
Hinsichtlich des verwendeten Serverkonzeptes (Single-Server-Umgebung bzw. Master-Slave-Umgebung)
zeigen sich bei der Pflege der Benutzerdaten keine Unterschiede. In den folgenden Abschnitten wird be-
schrieben, welche Funktionalität zur Pflege dieser Daten bereitsteht und wie diese genutzt werden kann.
Achtung:
Die Pflege erfolgt ausschließlich auf dem Domänencontroller Master.
UCS@school bringt einige Skripte mit, die zum Datenimport und zur Veränderung von Da-
ten eingesetzt werden können. Sie sind auf dem Domänencontroller Master im Verzeichnis
/usr/share/ucs-school-import/scripts/ zu finden.
Die Skripte für den Datenimport sind so ausgelegt, dass vor einer Änderung benötigte Strukturen im LDAP-
Verzeichnis auf Vollständigkeit überprüft und fehlende Objekte automatisch angelegt werden.
Jedes Skript verwendet für den Datenimport ein eigenes Dateiformat, das auf CSV basiert. Die einzel-
nen Felder sind durch ein Tabulatorzeichen zu separieren. Im Folgenden werden die Datenformate be-
schrieben. Spaltenbeschreibungen, die in Klammern geschrieben sind, kennzeichnen optionale Felder.
Alle weiteren Felder sind Pflichtangaben.
4.1 Organisationseinheiten
Die Datenstruktur im LDAP-Verzeichnisdienst sieht Organisationseinheiten (kurz: OU) direkt unterhalb der
LDAP-Basis vor, die diverse Benutzer-, Gruppen-, Freigaben- und sonstige Objekte aufnehmen. Diese
Organisationseinheiten werden automatisch bei Bedarf z.B. während des Imports von Benutzerkonten
15

4 Datenpflege
angelegt. Tippfehler in den Datenquellen für die Import-Skripte sorgen somit nicht zwangsläufig für eine
Fehlermeldung, können aber ungewollt für neue OUs sorgen.
Bei der Installation einer Single-Server-Umgebung wird auf dem Domänencontroller Master automatisch
die OU musterschule eingerichtet, sofern vor der Installation kein abweichender OU-Name definiert wur-
de (siehe dazu Kapitel 3.1). Sie kann als Ausgangsbasis für erste Tests mit UCS@school dienen. Das
Anlegen weiterer OUs ist natürlich möglich. In einer Master-Slave-Umgebung, die in der Regel für größere
Umgebungen gewählt wird, werden während der Installation keine OUs angelegt.
Für das Anlegen einer OU ist das Skript create_ou zuständig. Es erwartet als ersten Parameter den Na-
men der anzulegenden OU. Sollte eine bereits im LDAP-Verzeichnis existierende OU angegeben werden,
wird die Datenstruktur der OU automatisch auf Vollständigkeit geprüft und ggf. ergänzt.
root@master:/usr/share/ucs-school-import/scripts# ./create_ou 28G01
Mit dem Anlegen einer OU wird automatisch ein Rechnerkonto für einen Schul-DC angelegt. Im Falle einer
Single-Server-Umgebung bleibt dieses Rechnerkonto ungenutzt.
In einer Master-Slave-Umgebung ist es sinnvoll, vor der Installation der Schul-DCs die benötigten OUs auf
dem Domänencontroller Master anzulegen, damit die für die Schul-DCs benötigten Rechnerkonten bereits
im LDAP angelegt wurden und ein erneuter Joinvorgang entfällt.
Die Namen der automatisch erstellten Rechnerkonten werden nach folgendem Format generiert: Der Na-
me beginnt mit dc, gefolgt von der kleingeschriebenen OU. Im Anschluß daran steht der Typ des Schul-
DCs, für edukative Schul-DCs kein Zeichen und für Verwaltungs-Schul-DCs ein kleines v. Am Ende steht
die zweistellige Nummer des Schul-DCs, abgetrennt durch einen Bindestrich. So wird z.B. der Name
dcgym123-01 für den Schul-DC der OU gym123 generiert.
Sollten Schul-DCs vor dem Anlegen der OUs installiert und der Domäne beigetreten sein bzw. weicht der
Name der Schul-DCs vom automatisch generierten Namen ab, können diese Systeme auch nachträglich
in die Domäne aufgenommen werden. Dazu muss das Skript create_ou neben der OU auch den Namen
des bereits beigetretenen Schul-DCs übergeben bekommen:
root@master:/usr/share/ucs-school-import/scripts# ./create_ou 28G01 slave28
Nach dem Aufruf dieses Befehls, muss der jeweilige Schul-DC den Domänenbeitritt erneut durchführen.
Achtung:
Bei der Angabe von OU-Namen ist zu beachten, dass die Gross-Klein-Schreibung beim Anlegen der OU
und bei späteren Datenimports beibehalten wird, da es ansonsten zu Fehlern beim Import kommen kann.
4.2 Benutzer
Benutzerkonten für die UCS@school-Umgebung können über das Skript import_user importiert bzw.
modifiziert werden. Das Skript legt diese Benutzerkonten automatisch an der korrekten Stelle im LDAP-
Verzeichnis ab und sorgt für die richtigen Gruppenmitgliedschaften.
Das Skript erwartet den Namen einer CSV-Datei als ersten Parameter, wobei das Format der Eingabedatei
wie folgt aufgebaut sein muss:
16

Feld Beschreibung Mögliche Werte Beispiel
Aktion Art der Benutzermodifikation A=Hinzufügen,
M=Modifizieren,
D=Löschen
Benutzername Der zum Login verwendete Benutzername — m.mustermann
Nachname Der Nachname des Benutzers — Mustermann
Vorname Der Vorname des Benutzers — Michael
OU Die OU unter der der Benutzer angelegt werden soll — 28G01
Klasse Name der Klasse des Benutzers; nur Lehrer können in mehreren Klassen
vertreten sein!
Rechte derzeit ungenutzt; das Feld sollte leer bleiben, so dass 2 Tabulator-Zeichen
aufeinander folgen
— 1A,1B,2A,4C
—
A
4.2 Benutzer
Emailadresse Mailadresse des Benutzers — m.musterm@beispiel.edu
(Lehrer) Definiert, ob der Benutzer ein Lehrer ist 0=Kein Lehrer, 1=Lehrer 1
(Aktiv) Definiert, ob das Benutzerkonto beim Anlegen sofort aktiviert wird 0=nicht aktivieren,
1=aktivieren
(Mitarbeiter) Definiert, ob der Benutzer ein Mitarbeiter ist 0=Kein Mitarbeiter,
1=Mitarbeiter
Beispiel für eine Importdatei:
A max Mustermann Max 28G01 1A max@schule.edu 0 1 0
M m.musterma Mustermann Moritz 28G01 1A,2D,4C m.m@schule.edu 1 1 0
D a.musterfr Musterfrau Anke 28G01 2B a.mfr@schule.edu 1 1 1
Über das Feld Aktion kann die Art der Benutzermodifikation gesteuert werden. Folgende Aktionen sind
definiert:
Aktion Beschreibung
A Hinzufügen
M Modifizieren
D Löschen
Sollte ein Benutzer modifiziert werden (Aktion M), der vorher noch nicht angelegt wurde, wird der Be-
nutzer implizit mit den angegebenen Werten angelegt. Das Löschen von Benutzern (Aktion D) kann nur
erfolgreich ausgeführt werden, wenn der Benutzer vorher bereits dem System hinzugefügt wurde. Dabei
ist wichtig, dass auch beim Löschen gültige Werte übergeben werden.
Die Angabe von Klassen bezieht sich bei Schülern in der Regel auf eine einzelne Klasse. Lehrer können
dagegen in mehreren Klassen vertreten sein. Diese sollten auch angegeben werden (kommasepariert),
damit die Benutzerkonten der Lehrer automatisch in die jeweilige Klassengruppe eingetragen werden und
sie somit auch Zugriff auf die jeweilige Dateifreigabe der Klasse erhalten.
Die optionalen Felder Lehrer und Mitarbeiter bestimmen die Rolle des Benutzers im System, außerdem
wird über diese Einträge gesteuert, in welchen Containern die Benutzerkonten im Verzeichnisdienst abge-
legt werden. Werden die Werte nicht angegeben, so wird der Benutzer mit der Rolle Schüler angelegt. Es
ist möglich einem Benutzer beide Rollen, Lehrer und Mitarbeiter, zu geben.
Über das optionale Feld Aktiv wird gesteuert, ob das Benutzerkonto aktiviert werden soll. Ist kein Wert
angegeben, wird das Konto automatisch aktiviert.
Es ist zu beachten, dass die Benutzerkonten mit einem zufälligen, unbekannten Passwort initialisiert wer-
den. Idealerweise werden die Benutzerkonten in mehreren Schritten freigeschaltet:
1
0
17

4 Datenpflege
• Sofern manuell ein Konto für einen Schuladministrator angelegt wurde, wird diesem Konto über den
Univention Directory Manager ein neues Passwort zugewiesen.
• Der Schuladministrator ist anschließend über das Modul Benutzerverwaltung der Univention Mana-
gement Console in der Lage, die Lehrerkonten freizuschalten, indem dort neue Passwörter gesetzt
werden.
• Im letzten Schritt können Lehrer klassenweise den Schülern ihre Konten freischalten. Dies erfolgt
ebenfalls über das UMC-Modul Benutzerverwaltung.
Während des manuellen Anlegens von Benutzern der OU “XXX” sind einige Randbedingungen zu beach-
ten:
• Schuladministratoren
– Das Benutzerobjekt muss im Container cn=admins,cn=users,ou=XXX,LDAPBASIS liegen.
– Das Benutzerobjekt muss Mitglied der Gruppe
cn=admins-XXX,cn=ouadmins,cn=groups,LDAPBASIS sein.
– Das Benutzerobjekt kann Mitglied der Gruppe cn=lehrer,cn=groups,ou=XXX,LDAPBASIS sein.
– Das Benutzerobjekt kann Mitglied von einer oder mehreren Klassengruppen sein.
• Mitarbeiter
• Lehrer
– Das Benutzerobjekt muss im Container cn=mitarbeiter,cn=users,ou=XXX,LDAPBASIS liegen.
– Das Benutzerobjekt muss Mitglied der Gruppe cn=mitarbeiter,cn=groups,ou=XXX,LDAPBASIS
sein.
– Das Benutzerobjekt muss im Univention Directory Manager-Attribut ucsschool-user-role den
Wert staff enthalten.
– Das Benutzerobjekt muss im Container cn=lehrer,cn=users,ou=XXX,LDAPBASIS liegen.
– Das Benutzerobjekt muss Mitglied der Gruppe cn=lehrer,cn=groups,ou=XXX,LDAPBASIS sein.
– Das Benutzerobjekt kann Mitglied von einer oder mehreren Klassengruppen sein.
– Das Benutzerobjekt muss im Univention Directory Manager-Attribut ucsschool-user-role den
• Schüler
Achtung:
Wert teacher enthalten.
– Das Benutzerobjekt muss im Container cn=schueler,cn=users,ou=XXX,LDAPBASIS liegen.
– Das Benutzerobjekt muss Mitglied der Gruppe cn=schueler,cn=groups,ou=XXX,LDAPBASIS
sein.
– Das Benutzerobjekt muss im Univention Directory Manager-Attribut ucsschool-user-role den
Wert pupil enthalten.
Das Importskript legt die Benutzerkonten im LDAP-Verzeichnisdienst unterhalb der jeweils angegebenen
OU ab. In einer Master-Slave-Umgebung liegen durch die selektive Replikation auf den Slave-Systemen
nur die Benutzerkonten der jeweiligen OU vor. Benutzern ist es daher nicht möglich, sich mit ihrem Benut-
zerkonto gegenüber dem Schul-DC einer anderen OU zu authentisieren.
18

4.3 (Klassen-)Gruppen
4.3 (Klassen-)Gruppen
Mit dem Import von Benutzern wird automatisch für jede Klasse eine gleichlautende Gruppe sowie eine
Dateifreigabe auf dem ersten Schul-DC der jeweiligen OU angelegt. Sollten nach dem Benutzer-Import
noch Gruppen fehlen, können diese über das Skript import_group importiert werden. Auch hier wird
automatisch für jede Gruppe eine Dateifreigabe auf dem ersten Schul-DC eingerichtet.
Es 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. Daher sollte jeder Klasse automatisch die OU vorangestellt
werden. Sprechende Namen, wie zum Beispiel Igel oder BiologieAG, sind für Klassennamen
ebenso möglich wie Buchstaben-Ziffern-Kombinationen (10R). Beispiele für die OU gym123:
gym123-1A
gym123-1B
gym123-2A
gym123-Igel
Das Dateiformat für die Gruppen-Importdatei ist wie folgt aufgebaut:
Feld Beschreibung Mögliche Werte Beispiel
Aktion Art der Gruppenmodifikation A=Hinzufügen,
M=Modifizieren,
D=Löschen
OU OU in der die Gruppe modifiziert werden soll — 28G01
Gruppenname Der Name der Gruppe — 1A
(Beschreibung) Optionale Beschreibung der Gruppe — Klasse 1A
Beispiel für eine Importdatei:
A 28G01 1A Klaaassen 1A
A 28G01 LK-Inf Leistungskurs Informatik
M 28G01 1A Klasse 1A
D 28G01 LK-Inf Leistungskurs Informatik
D 28G01 R12 Klasse R12
4.4 Netzwerke
Netzwerke können über das Skript import_networks importiert werden. Das Format der Import-Datei
ist wie folgt aufgebaut:
Feld Beschreibung Beispiel
OU OU des zu modifizierenden Netzwerks 28G01
Netzwerk Netzwerk und Subnetzmaske 10.0.5.0/255.255.255.0
(IP-Adress-Bereich) Bereich, aus dem IP-Adressen für neuangelegte Systeme automatisch vergeben werden 10.0.5.10-10.0.5.140
(Router) IP-Adresse des Routers 10.0.5.1
(DNS-Server) IP-Adresse des DNS-Servers 10.0.5.2
(WINS-Server) IP-Adresse des WINS-Servers 10.0.5.2
Beispiel für eine Importdatei:
28G01 10.0.5.0 10.0.5.1 10.0.5.2 10.0.5.2
28G01 10.0.6.0/25 10.0.6.5-10.0.6.120 10.0.6.1 10.0.6.2 10.0.6.15
Wird für das Feld Netzwerk keine Netzmaske angegeben, so wird automatisch die Netzmaske
255.255.255.0 verwendet. Sollte der IP-Adressbereich nicht explizit angegeben worden sein, wird der
Bereich X.Y.Z.20-X.Y.Z.250 verwendet.
A
19

4 Datenpflege
Zur Vereinfachung der Administration der Netzwerke steht zusätzlich das Skript import_router zur
Verfügung, das nur den Default-Router für das angegebene Netzwerk neu setzt. Es verwendet das gleiche
Format wie import_networks.
4.5 Rechner
Entgegen dem regulären UCS-Standard ist es in einer UCS@school-Umgebung nicht möglich, Windows-
Systeme auch ohne existierendes Rechnerkonto der Domäne beitreten zu lassen, auch wenn der Schul-
DC ein Windows-PDC ist. Diese müssen zuvor manuell bzw. über ein Import-Skript im LDAP-Verzeichnis
angelegt werden. In der Standardeinstellung werden IP-Adressen über DHCP nur an bekannte DHCP-
Clients (Rechner/Drucker/...) vergeben. Dafür ist es notwendig, dass bei jedem Rechnerobjekt neben der
IP-Adresse auch die passende MAC-Adresse hinterlegt wird.
Dem Schulträger wird damit die Möglichkeit gegeben, einen Überblick über die an Schulen eingesetzte
Infrastruktur zu erhalten, da es Lehrern und Schuladministratoren aufgrund von LDAP-Zugriffsbeschrän-
kungen nicht möglich ist, zusätzliche Rechnerkonten zu erstellen.
Achtung:
Über den Univention Directory Manager können Rechnerkonten auch manuell ohne IP- bzw. MAC-Adresse
angelegt werden. Es stehen in diesem Fall jedoch nicht alle Funktionen von UCS@school zur Verfügung
(z.B. die Verwendung von iTALC).
Rechner werden über das Skript import_computer importiert. Das Format der Import-Datei ist wie folgt
aufgebaut:
Feld Beschreibung Mögliche Werte Beispiel
Rechnertyp Typ des Rechnerobjektes ipmanagedclient, macos, managedclient,
memberserver, mobileclient, thinclient, windows
windows
Name Zu verwendender Rechnername — win28g01-01
MAC-Adresse MAC-Adresse (wird für DHCP benötigt) — 00:0c:29:12:23:34
OU OU, in der das Rechnerobjekt modifiziert
werden soll
IP-Adresse (/ Netzmaske) IP-Adresse des Rechnerobjektes und optional
die passende Netzmaske
— 28G01
— 10.0.5.45/255.255.255.0
(Inventarnr.) Optionale Inventarnummer — TR47110815-XA-3
Die Subnetzmaske kann sowohl als Prefix (24) als auch in Oktettschreibweise (255.255.255.0) angege-
ben werden. Die Angabe der Subnetzmaske ist optional. Wird sie weggelassen, wird die Subnetzmaske
255.255.255.0 angenommen.
Beispiel für eine Importdatei:
ipmanagedclient router28g01-01 10:00:ee:ff:cc:02 28G01 10.0.5.1
windows win28g01-01 10:00:ee:ff:cc:00 28G01 10.0.5.5
windows win28g01-02 10:00:ee:ff:cc:01 28G01 10.0.5.6
macos mac28g01-01 10:00:ee:ff:cc:03 28G01 10.0.5.7
ipmanagedclient printer28g01-01 10:00:ee:ff:cc:04 28G01 10.0.5.250
Die importieren Rechner werden so konfiguriert, dass ihnen die angegebene IP-Adresse automatisch
per DHCP zugeordnet wird und der angegebene Rechnername über das Domain Name System (DNS)
aufgelöst werden kann.
20

4.6 Drucker
4.6 Drucker
Drucker werden über das Skript import_printer importiert. Das Format der Import-Datei ist wie folgt
aufgebaut:
Feld Beschreibung Mögliche Werte Beispiel
Aktion Art der Druckermodifkation A=Hinzufügen, M=Modifizieren,
D=Löschen
OU OU, in der das Druckerobjekt modifiziert werden soll — 28G01
Druckserver Name des zu verwendenden Druckservers — dc28g01-01
Name Name der Druckerqueue — laserdrucker
URI URI, unter dem der Drucker erreichbar ist — lpd:/10.0.5.250
Die Druckerwarteschlange wird beim Anlegen eines neuen Druckers auf dem im Feld Druckserver ange-
gebenen Druckserver eingerichtet.
4.7 Pre- und Post-Hook-Skripte
Während des Datenimports kann es notwendig sein, dass in Abhängigkeit von der jeweiligen Umgebung
zusätzlich einige weitere Einstellungen vorgenommen werden müssen. Mit den Pre- und Post-Hook-Skrip-
ten besteht die Möglichkeit vor und nach dem Import eines Objektes Skripte auszuführen. Zu allen Objek-
ten und den davon jeweils unterstützten Operationen können mehrere Skripte definiert werden, die dann
vor und nach den Operationen Anpassungen vornehmen.
Damit die Import-Skripte die Hook-Skripte finden können, müssen diese unterhalb des Verzeichnisses
/usr/share/ucs-school-import/hooks/ abgelegt werden. Dort gibt es für jede unterstützte Operation ein
eigenes Unterverzeichnis. Beispielsweise gibt es das Verzeichnis user_create_pre.d, das alle Skripte
enthalten muss, die vor dem Import eines Benutzers ausgeführt werden sollen. Alle weiteren Verzeichnisse
sind nach dem gleichen Schema benannt: __pre.d für die Skripte, die vor einer
Operation ausgeführt werden sollen und __post.d für die Skripte, die nach einer
Operation ausgeführt werden sollen. Das Paket ucs-school-import bringt diese Verzeichnisse bereits
mit. Skripte, die bei der Ausführung berücksichtigt werden sollen, müssen zwei Bedingungen erfüllen. Der
Name darf nur aus Ziffern, Buchstaben und Unter- und Bindestrichen bestehen und die Ausführungsrechte
müssen für die Datei gesetzt sein. Alle anderen Dateien in diesen Verzeichnissen werden ignoriert.
Die Hook-Skripte werden derzeit für die Objekttypen ou, user, group, printer, computer, network und
router für die Operationen create, modify und remove ausgeführt. Dabei ist zu beachten, dass für Rech-
ner (computer), Netzwerke, Router und Schul-OUs nur die Operation zum Erzeugen (create) definiert ist
und daher auch nur dafür Hook-Skripte definiert werden können.
Die Pre-Hook-Skripte werden mit einem Parameter aufgerufen. Dieser enthält den Namen einer Datei in
der die Zeile des als nächstes zu bearbeitenden Objektes aus der Import-Datei gespeichert ist. Darüber
können die Skripte jede Einstellung für das Objekt auslesen; allerdings ist zu berücksichtigen, dass zu
diesem Zeitpunkt die Daten noch nicht durch das Import-Skript geprüft worden sind. Die Post-Hook-Skripte
bekommen als zusätzlichen Parameter noch die LDAP-DN des gerade bearbeiteten Objektes.
Das folgende Beispiel-Skript soll ausgeführt werden, nachdem eine neue Schul-OU angelegt wurde. Da-
für muss das Skript in das Verzeichnis /usr/share/ucs-school-import/hooks/ou_create_post.d/ kopiert
werden. Die Aufgabe des Skriptes soll es sein, die LDAP-Basis für den DHCP-Server der Schule per
A
21

4 Datenpflege
Univention Configuration Registry-Richtlinie auf den Container cn=dhcp unterhalb der LDAP-Basis der
Schule zu setzen.
#!/bin/sh
ldap_base="$(ucr get ldap/base)"
# Auslesen der ersten Spalte (enthält den OU Namen)
ou="$(awk -F ’\t’ ’{print $1}’ "$1")"
# Den Standard Schul-DC Namen erzeugen
host="dc${ou}-01.$(ucr get domainname)"
# Eine UCR-Richtlinie erstellen und mit dem Schul-DC verknüpfen
udm policies/registry create --position "cn=policies,ou=$ou,$ldap_base" \
--set name=dhcpd_ldap_base \
--append "registry=dhcpd/ldap/base=cn=dhcp,ou=$ou,$ldap_base"
udm computers/domaincontroller_slave \
--dn "cn=dc${ou}-01,cn=dc,cn=computers,ou=$ou,$ldap_base" \
--policy-reference "cn=dhcpd_ldap_base,cn=policies,ou=$ou,$ldap_base"
echo "$(basename $0): Added policy dhcpd_ldap_base ."
Obwohl das Skript create_ou keine Eingabedatei übergeben bekommt, wird für die Hook-Skripte eine
generiert, die in der Zeile den Namen der OU enthält. Wenn ein vom Standard abweichender Schul-DC-
Name angegeben wurde, wird dieser als zweiter Wert übergeben. Für alle anderen Operationen auf den
Objekten können Hook-Skripte auf äquivalente Weise erstellt werden.
Erweiterung von Importdateien
Eine weitere Funktion von den Hook-Skripten ist die Möglichkeit mit Erweiterungen in den Import-Dateien
umzugehen, d.h. wenn in den Importdateien mehr Felder eingetragen sind, als durch die Import-Skripte
selbst verarbeitet werden, so können die erweiterten Attribute in den Hook-Skripten ausgelesen und ver-
arbeitet werden. Als Beispiel könnten bei den Benutzern Adressinformationen oder eine Abteilung gespei-
chert werden. Die zusätzlichen Felder werden in den Importdateien jeweils hinten an die Zeilen getrennt
durch einen Tabulator angehängt. Da die Hook-Skripte die komplette Zeile übergeben bekommen, kann
ein Post-Hook Skript genutzt werden, um die neuen Felder auszulesen und die Informationen z.B. an dem
gerade erzeugten Benutzer zu ergänzen.
4.8 Hook: automatische Erstellung der Freigabe “Marktplatz”
Um den Austausch von Dokumenten zwischen Benutzern zu erleichtern, wird empfohlen, die Freigabe
Marktplatz auf den jeweiligen Schul-DCs anzulegen, auf die alle Benutzer Zugriff erhalten.
Der Hook ou_create_post.d/52marktplatz_create wird ab UCS@school für UCS 2.4 mitgelie-
fert und legt beim Aufruf von create_ou die Freigabe “Marktplatz” automatisch an. Über die Univention
Configuration Registry-Variable ucsschool/import/generate/share/marktplatz kann der Hook
de-/aktiviert werden, indem der Variable der Wert no bzw. yes zugeordnet wird.
Über drei weitere Univention Configuration Registry-Variablen kann das Verhalten des Hooks gesteuert
werden:
22

4.9 Hook: Setzen des LDAP-Containers für DHCP-Objekte
• ucsschool/import/generate/share/marktplatz/sharepath
Diese Variable definiert das Verzeichnis auf dem Server, welches als Freigabe “Marktplatz” freigege-
ben wird. In der Standardeinstellung wird das Verzeichnis /home/groups/Marktplatz verwen-
det.
• ucsschool/import/generate/share/marktplatz/group
Beim Anlegen der Freigabe wird die in dieser Variable definierte Gruppe als Gruppenbesitzer der
Freigabe festgelegt. In der Standardeinstellung ist dies die Gruppe Domain Users. Es ist zu beach-
ten, dass abweichend vom UCS-Standard die über die Importskripte angelegten Benutzer nicht in
der Gruppe Domain Users enthalten sind.
• ucsschool/import/generate/share/marktplatz/permissions
Die Zugriffsrechte der Freigabe sind in oktaler Schreibweise anzugeben (z.B. 0777). In der Standar-
deinstellung erhalten der Benutzer root, die vordefinierte Gruppe (z.B. Domain Users) sowie alle
sonstigen Benutzer Lese- und Schreibrechte (0777).
Das UMC-Modul Unterrichtsvorbereitung ist bereits für die Verwendung der Freigabe Marktplatz aus-
gerichtet und bietet die Möglichkeit, in bestimmten Zeiträumen den Zugriff auf die Freigabe Marktplatz
zu unterbinden. Sollte die Freigabe auf dem Schul-DC nicht existieren, ist das Auswahlkästchen in dem
UMC-Modul ohne Funktion.
4.9 Hook: Setzen des LDAP-Containers für DHCP-Objekte
Auf den Schul-DCs wird ein abweichender Container für DHCP-Objekte verwendet, weshalb die Univen-
tion Configuration Registry-Variable dhcpd/ldap/base entsprechend gesetzt werden muss. Um das
manuelle Setzen der UCR-Variable für jede neue OU bzw. jeden neuen Schul-DC zu vermeiden, wird
über den Standard-Hook ou_create_post.d/40dhcpsearchbase_create automatisch beim Erstel-
len einer OU die UCR-Richtlinie ou-default-ucr-policy im Container cn=policies,ou=XXX,LDAPBASIS
angelegt und anschließend mit dem OU-Objekt ou=XXX,LDAPBASIS verknüpft. Über die Richtlinie wird
die Univention Configuration Registry-Variable dhcpd/ldap/base entsprechend gesetzt. Dadurch wird
sichergestellt, dass die in der Richtlinie gesetzten UCR-Variablen auf allen UCS-Systemen der OU auto-
matisch übernommen werden.
23

4 Datenpflege
24

5 Schulspezifische Anwendungen
Inhaltsverzeichnis
5.1 Benutzerverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2 Gruppenverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3 Computerraum-Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.4 Druckermoderation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.5 Materialverteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.6 Unterrichtsvorbereitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.7 Webfilter-Einstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.8 Helpdesk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
UCS@school bringt diverse UMC-Module mit, die die Administration für Lehrer und Schuladmins erleich-
tern:
Abbildung 5.1: Schulspezifische Anwendungen
Im folgenden werden die Module kurz beschrieben. Eine ausführliche Beschreibung zur Benutzung der
UMC-Module findet sich im UCS@school-Handbuch für Lehrkräfte [1].
5.1 Benutzerverwaltung
Das Modul Benutzerverwaltung bietet Lehrern und Schuladministratoren die Möglichkeit, Passwörter von
Schülerkonten zurückzusetzen. Weiterhin können Schuladministratoren auch Passwörter von Lehrerkon-
ten zurücksetzen.
25

5 Schulspezifische Anwendungen
5.2 Gruppenverwaltung
Abbildung 5.2: UMC-Modul “Benutzerverwaltung”
Über das Modul Gruppenverwaltung können von Schuladministratoren zusätzliche Gruppen, wie z.B. eine
Informatik-AG, angelegt werden. Lehrer und Schuladministratoren können dann Schüler in diese zusätz-
lichen Gruppen hinzufügen oder sie wieder entfernen. Diese Zusatzgruppen sind unabhängig von der
zentralen Datenpflege des Schulträgers und können allein von der Schule gepflegt werden.
26

Abbildung 5.3: UMC-Modul “Gruppenverwaltung”
5.3 Computerraum-Administration
Allerdings unterliegen diese Zusatzgruppen ebenfalls der Beschränkung, dass der Gruppenname do-
mänenweit eindeutig sein muss. Daher wird dem Benutzer beim Anlegen einer neuen Gruppe automa-
tisch der Name der OU als Prefix vorgeschlagen. Dieser Prefix kann über die Univention Configuration
Registry-Variable umc/schooladmin/groups/defaultgroupprefix beeinflusst werden. Die Zeichenkette
%(departmentNumber)s wird dabei automatisch gegen den Namen der OU ausgetauscht.
5.3 Computerraum-Administration
Über dieses Modul können Computerräume erstellt und gelöscht werden. Den Computerräumen können
durch die Schuladministratoren Computer zugewiesen werden. Darüber hinaus können die bereitgestell-
ten iTALC-Funktionen (siehe auch Kapitel 6) über dieses Modul gesteuert werden:
• Deaktivieren von Eingabegeräten (Tastatur/Maus)
• Sperren des Benutzerbildschirms
• Übertragung eines beliebigen Lehrer-/Schüler-Bildschirms an alle anderen Rechner eines Klassen-
raums
• Herunterfahren/Neustart von Windows-Rechnern
27

5 Schulspezifische Anwendungen
Abbildung 5.4: Übersichtsseite der Computerraum-Administration
Einige der Angaben der Computerraum-Übersichtsseite können durch das Setzen der Univention Confi-
guration Registry-Variable umc/roomadmin/hideitems ausgeblendet werden. Die Variable enthält eine
kommaseparierte Liste bestehend aus Schlüsselwörtern, die jeweils eine Angabe ausblenden:
• Das Schlüsselwort room blendet die Spalte Raum aus.
• In der Spalte Adressen werden IP- und MAC-Adressen angezeigt. Sie können getrennt über die
Schlüsselworte ipaddress und macaddress gesteuert werden. Werden beide Schlüsselworte an-
gegeben, wird die Spalte Adressen ausgeblendet.
• Die Spalte Inventarnummer kann über das Schlüsselwort inventorynumber ausgeblendet werden.
In der Standardeinstellung werden Raum, MAC-Adresse und Inventarnummer ausgeblendet.
28
Abbildung 5.5: Ausgewählte Computer beaufsichtigen

5.4 Druckermoderation
5.4 Druckermoderation
Dieses Modul ermöglicht Lehrern eine Moderation wartender Druckaufträge. Die Druckaufträge können
vorab eingesehen, angenommen oder abgelehnt werden. Schüler und Lehrer haben weiterhin die Mög-
lichkeit, die angestoßenen Druckaufträge von einer Dateifreigabe vom Schul-DC zu beziehen. Bei der In-
stallation des Pakets ucs-school-umc-printermoderation wird automatisch über ein Joinskript ein neuer
PDF-Drucker PDFDrucker in der OU des Schul-DCs erstellt. In einer Single-Server-Umgebung wird der
Drucker global erstellt.
5.5 Materialverteilung
Abbildung 5.6: UMC-Modul “Druckermoderation”
Über dieses Modul können Lehrer Unterrichtsmaterialien in die Heimatverzeichnisse von mehreren oder
allen Schülern einer Klasse oder Zusatzgruppe verteilen. Die verteilten Dateien können manuell oder
automatisch zu einem vorgegebenen Zeitpunkt vom Lehrer wieder eingesammelt und in seinem Heimat-
verzeichnis – nach Schülern sortiert – gespeichert werden.
5.6 Unterrichtsvorbereitung
Das Modul ermöglicht, eine wiederkehrende Reservierung eines Klassenraums vorzunehmen. Dabei kön-
nen Einstellungen wie zu verteilende Dateien, Einstellung des Proxy-Filters, Internet an/aus, usw. an der
Reservierung hinterlegt werden, so dass diese automatisch beim Erreichen des reservierten Zeitraums
aktiviert werden.
29

5 Schulspezifische Anwendungen
30
Abbildung 5.7: UMC-Modul “Materialverteilung”
Abbildung 5.8: UMC-Modul “Unterrichtsvorbereitung”

5.7 Webfilter-Einstellungen
5.7 Webfilter-Einstellungen
Über das Modul können Filterlisten für bestimmte Computerräume definiert und aktiviert werden, so dass
der Internetzugriff auf bestimmte URLs beschränkt werden kann.
5.8 Helpdesk
Abbildung 5.9: UMC-Modul “Webfilter-Einstellungen”
Über das Helpdesk-Modul können Lehrer per E-Mail Kontakt zum lokalen Helpdesk-Team aufnehmen.
Damit dieses Modul genutzt werden kann, muß auf dem Domänencontroller Master bzw. den jeweiligen
Schul-DCs die Univention Configuration Registry-Variable ucsschool/helpdesk/recipient auf die E-Mail-
Adresse des lokalen Helpdesk-Teams gesetzt werden.
31

5 Schulspezifische Anwendungen
32
Abbildung 5.10: UMC-Modul “Helpdesk”

6 Windows-Dienste
Inhaltsverzeichnis
6.1 iTALC-Installation auf Windows-Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.2 Windows-Netlogon-Skripte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Für den Betrieb von Windows-Clients stellt Univention Corporate Server bekannte Kerndienste wie
DHCP, DNS und Datei- und Druckdienste bereit. Zur engeren Einbindung eines Windows-Clients in das
UCS@school-Konzept, kann dort eine spezielle Windows-Software (iTALC) installiert werden, welche es
Lehrkräften in Verbindung mit einem UMC-Modul erlaubt, z.B. Bildschirme und Eingabegeräte auf den
Windows-Clients zu sperren oder eine Übertragung des Lehrerbildschirms auf mehrere Schülerbildschir-
me zu starten.
Darüber hinaus stehen Netlogon-Skripte zur Verfügung, die während der Benutzeranmeldung automatisch
Konfigurationseinstellungen, wie dem Setzen eines HTTP-Proxyservers, vornehmen.
6.1 iTALC-Installation auf Windows-Clients
Für die Nutzung der iTALC-Funktionen wird vorausgesetzt, dass auf den Windows-Clients iTALC installiert
wurde. iTALC ist im Internet unter http://italc.sf.net/ beziehbar. Interoperabilitätstests zwischen
UCS@school und iTALC wurden ausschließlich mit der iTALC-Version 1.0.9 unter Windows XP SP3 durch-
geführt.
iTALC bringt einen graphischen Installer mit, der durch alle notwendigen Schritte führt. Während der Instal-
lation sollte nur die notwendige iTALC Client Application installiert und die iTALC Master Application
abgewählt werden. Im darauffolgenden Schritt der Installation muss ein neues Schlüsselpaar erzeugt wer-
den (erster Punkt). Alle anderen Schritte der Installation können mit den Standardeinstellungen fortgeführt
werden.
Nach der Installation von iTALC auf dem Windows-Client muss dort eine Public-Key-Datei ausgetauscht
werden, damit der Schul-DC Zugriff auf das installierte iTALC-Backend erhält. Die vom Schul-DC benötig-
te Datei /etc/italc/keys/public/teacher/key muss auf alle iTALC-Systeme einer OU kopiert werden. Die
Datei ist auf dem Windows-System unter C:\ Programme\ iTALC\ keys\ public\ teacher\ key abzulegen.
Damit das Raumverwaltungsmodul der Univention Management Console eine Verbindung zu einem Win-
dows-Rechner aufbauen kann, muss für alle Windows-Rechnerkonten die korrekte IP-Adresse hinterlegt
worden sein. Fehlt diese, ist die Nutzung der iTALC-Funktionen nicht möglich.
33

6 Windows-Dienste
6.2 Windows-Netlogon-Skripte
Abbildung 6.1: iTALC-Installation: Startbildschirm
UCS@school bringt zusätzliche Windows-Netlogon-Skripte mit, die von einem bereits beste-
henden Netlogon-Skript aufgerufen werden sollten. Folgende Netlogon-Skripte werden unter
/var/lib/samba/netlogon/ bereitgestellt:
34
• univention-netlogon-proxy.vbs
Um eine Beschränkung des Internetzugriffs durchführen zu können, wird der Internetzugriff der
Browser über einen Proxyserver gefiltert. Damit dieser Proxyserver automatisch in Mozilla Firefox
und/oder Internet Explorer auf den Windows-Clients gesetzt wird, kann dieses Netlogon-Skript in
den Loginvorgang integriert werden. Das Verhalten des Skriptes kann über mehrere Univention Con-
figuration Registry-Variable beeinflusst werden:
– samba/netlogonscript/proxy/enable/iexplorer=no deaktiviert das Setzen des Proxyservers
für Internet Explorer (Standard: yes)
– samba/netlogonscript/proxy/enable/firefox=no deaktiviert das Setzen des Proxyservers für
Mozilla Firefox (Standard: yes)
– samba/netlogonscript/proxy/firefox/binary enthält den Windows-Pfad zum Mozilla Firefox-
Binary, der für das Setzen benötigt wird (Standard: C:\ Programme\ Mozilla Firefox\ firefox.exe)
• umc-distribution.vbs
Über das Netlogon-Skript umc-distribution.vbs wird automatisch eine Verknüpfung auf dem

Abbildung 6.2: iTALC-Installation: Sicherheitseinstellungen
6.2 Windows-Netlogon-Skripte
Schüler- bzw. Lehrer-Desktop erstellt, unter dem die über die Materialverteilung bereitgestellten
Dokumente verfügbar sind. Der Verzeichnisname für Schüler kann über die Univention Configura-
tion Registry-Variable ucsschool/datadistribution/datadir/recipient definiert werden.
In der Voreinstellung wird das Verzeichnis Unterrichtsmaterial genannt.
• ucs-school-italc.cmd
In Kapitel 6.1 wird beschrieben, dass auf dem Windows-Client für die Verwendung von iTALC eine
Public-Key-Datei ausgetauscht werden muss. Dieser Vorgang kann über das Netlogon-Skript ucs-
school-italc.cmd vereinfacht werden. Es muss mit Administrator-Rechten ausgeführt werden. Wird
es z.B. während des Benutzerlogins ausgeführt, wird die Key-Datei automatisch auf dem neuesten
Stand gehalten. Die Key-Datei ist über einen Symlink in der Samba-Netlogon-Freigabe im Unterver-
zeichnis italc abrufbar.
Über zwei Univention Configuration Registry-Variablen kann der Kopiervorgang beeinflusst werden:
– samba/netlogonscript/italc/key/public/serverpath gibt die Quelle für den Kopiervorgang an.
In der Standardeinstellung wird die Key-Datei auf der Netlogon-Freigabe des Anmeldeservers
gesucht (%LOGONSERVER%\ netlogon\ italc\ italc-key.pub).
– samba/netlogonscript/italc/key/public/localpath definiert das Ziel des Kopiervorgangs. Falls
iTALC in einem abweichenden Verzeichnis installiert wurde, muss diese Univention Configura-
tion Registry-Variable ggf. angepasst werden. In der Standardeinstellung enthält die Variable
den Wert C:\ Programme\ iTALC\ keys\ public\ teacher\ key.
35

6 Windows-Dienste
36

Literaturverzeichnis
[1] Univention. UCS@school - Handbuch für Lehrkräfte zum alltäglichen Umgang mit der Univention
Management Console (UMC). 2010.
http://www.univention.de/fileadmin/download/dokumentation_ucs_schule/
handbuch_ucsschool_lehrer_2.4.pdf.
[2] Univention. Univention Corporate Server - Handbuch für Benutzer und Administratoren. 2010.
http://www.univention.de/fileadmin/download/dokumentation_2.4/
handbuch_ucs24.pdf.
[3] Tobias Doerffel. iTALC - Intelligent Teaching And Learning with Computers. 2010.
http://italc.sourceforge.net/.
[4] Univention. Übersichtsseite zu UCS@school. 2010.
http://www.univention.de/schule.html.
37