AGSS:LDAP Schema

Aus AGSS
Zur Navigation springen Zur Suche springen


Einheitliches LDAP Schema[Bearbeiten]

LDAP-Struktur eines Schulservers
Abbildung: LDAP-Struktur eines Schulservers

Allgemeine Grundsätze[Bearbeiten]

Wichtig für die zukünftige Entwicklung: alle Daten sollen ins LDAP! Hierüber herrscht allgemeine Einigkeit.

=> D.h. z.B. für ein Backup:

  slapcat 
  /var/lib/* (Mails)
  /home/* 
mehr Daten sind dann nicht zu sichern


Allerdings ist dies noch nicht bei allen angebotenen Diensten möglich - deshalb muss hier mittelfristig noch mit Workarounds gearbeitet werden. Vorstellbar ist z.B. die Datenhaltung im LDAP und ein DUMP der entsprechenden Daten in das Filesystem, damit die Dienste diese Files dann einlesen können.

Struktur des OSS-LDAP Schemas[Bearbeiten]

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
ou="ldapconfig"-Zweig

Hinweise von Andreas:

  • ou=ldapconfig (und Struktur) mehr in die Öffentlichkeit pushen! Das ist gut, aber zu wenig bekannt!
  • über Kerberos sind auch bei NFS mehr als 16 Gruppen möglich - allerdings nur mit einigem Aufwand


=> Netgroups anstelle von objectClass

=> Jede primary Gruppe bekommt einen Template-Benutzer (für [Desktop-]Profile)

Problem:

  • Lehrer unterrichtet in mehreren Klassen und ist Klassenlehrer in einer bestimmten Klasse. In dieser einen Klasse soll er mehr Rechte haben als ein normaler Lehrer - aber nicht in anderen Klassen.

=> zusätzliches Attribut an schoolAccount hängen:

User = primary group
Role => evtl. sogar auf Gruppen und auf Benutzerbasis


Fehler beim Erstellen des Vorschaubildes: Datei fehlt
ou="group"-Zweig

Ein User in der group "teachers" könnte so zusätzliche "roles" haben - etwa "Proxy-Admin". In der Gruppe 10A könnte eine "role" auf den "class teacher" verweisen.

Für "Proxy-Admin", etc. sollten hier Posix-Gruppen genommen werden um auch auf Filesystem-Ebene entsprechend zugreifen zu können.

  • writeDN sowohl für Gruppen als auch für Benutzer

=> ein Benutzer mit writeDN für Gruppe kann nicht die Benutzer ändern

objectClass = schoolGroup
Type =


Fehler beim Erstellen des Vorschaubildes: Datei fehlt
grafische Ansicht des ou="people"-Zweigs eines Schulservers

LDAP-Struktur unterhalb eines Nutzers – Addon für Schulbuchverlage und Softwareanbieter:

uid=...
addr=...
cn=<vendorname>
+--- objectClass=schoolVendorObject
-----vendorParameterR  =(case sensitiv read only)
-----vendorParameterRW =(case sensitiv read/write)
-----vendorParameterW  =(case sensitiv writeable)
-----vendorParameterIR =(case insenstitv read only)
-----vendorParameterIRW=(case insenstitv read/write)
-----vendorParameterIW =(case insenstitv writable)

==> gesteuert über ACI – Teile unterhalb der jeweiligen objectClass sollen nur von einem bestimmten Programm geschrieben werden können – andere Teile nur von Lehrern.

=> die ldapconfig sollte ggf. von den Herstellern benutzt werden, um (auch im laufenden Betrieb) den LDAP-Server über neue Konfigurationen zu informieren.

ACLs und Upgradebarkeit => zu diskutieren

  • capability= beschreibt die aktuellen Fähigkeiten des LDAP-Baums

=> Aufnehmen in ou=ldapconfig als Objekt mit eigener objektClass. Damit ist ein Update später leichter.

InternetFreischaltung => wer schaltet wann was mit welchen "Rechten"?

=> Lösung über iptables bzw. ipchains kann bis auf Benutzerebene. Problem: Nutzer bekommt keine Rückmeldung --> schlechteste Lösung

=> Lösung über Proxy => hier gibt es auch mehrere Möglichkeiten:

  • über LDAP-Attribut pro Schüler (siehe auth_param basic program)
  • über Raumweises Sperren (mittels ACL oder SquidGuard)

==> (derzeit?) zwei verschiedene Lösungen nötig - anzustreben wäre eine Schaltung pro Schüler. Probleme:

  • Schüler wurden gesperrt und kommen später nicht rein. (Zeitschaltung)
  • Schüler, die aus bestimmten Gründen nicht dürfen, kommen plötzlich rein (Lösung: zwei Attribute defaultInternet + internetEnabled im LDAP)

Nutzen einer Gruppe Internet? Nur Nutzer in dieser bestimmten Gruppe kommen rein.

==> zu diskutieren!


Wir brauchen "sysconfig-Variablen", die bestimmte Preferenzen der Schule abbilden. Z.B. Thema Internet:

=> Internet ist immer frei / nicht frei

=> Zeitsteuerung

=> böse Buben dürfen auf Lehrer-Anforderung trotzdem ins Netz (zeitlich begrenzt)? Ebenso z.B. bei Quota-Einstellungen, Email, etc.

Für diese Variablen sollten default-Werte während der Installation gesetzt werden, die aber verändert werden können. Damit können Schulen den Server schnell aufsetzen - ihn aber später noch leicht an ihre Bedürfnisse anpassen.

(Das würde z.B. für den OSS bedeuten:

ou=ldapconfig,c=schoolserver

==> hier kommen die derzeitigen Werte von /etc/sysconfig/schoolserver rein)

Hardwaredatenbank für Support[Bearbeiten]

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
ou="computers"-Zweig

Vortrag Malte:

  • Hardwaredatenbank für Support => derzeit in MySQL implementiert

Damit die Schule eine Inventarisierung ihrer Hardware vornehmen kann, wäre es nützlich, die Hardwaredaten eines Rechners gleich bei der Aufnahme dieses Rechners ins Schulnetz (Anmelden an der Domäne, Eintragen in dhcp) auf dem Server zu speichern.

Hier können in erster Linie Linux-Tools gute Dienste leisten. Ein einfaches "hwinfo" ist schon nicht schlecht. SUSE bietet hier mit dem Tool "sitar" (System InformaTion At Runtime) schon seit längerer Zeit ein noch ausgefeilteres Tool an, welches alle benötigten Informationen für den Support sammelt.

Malte => Inventarisierungsstruktur evtl. openSource (?)


IMPORT VON SCHÜLERN => SCHULVERWALTUNGSPROGRAMM


  • Benötigt wird eine Schnittstelle auf allen Schulservern, wie man automatisiert Schüler anlegt. Da sollten aber evtl. schon bestimmte Informationen drin sein. (Datenschutz?)
  • Da es für jedes Bundesland und teilweise sogar bei jeder Schule andere Schulverwaltungslösungen gibt, muss die angestrebte Lösung möglichst flexibel sein.

Lösung: Scripte konvertieren den Originalexport in ein XML-Format (XML soll in dt. Verwaltungen bald stark forciert werden). Dieses XML-Format wiederum wird dann vom Schulserver eingelesen.

=> es sollte eine Definition für ein XML-Format geben.

=> Auch wenn CVS-Export, dann in XML-konvertieren und einlesen.

(Hintergrund: damit lassen sich u.a. Kodierungsfehler (UTF-8 vs. ISO-8859-1 vermeiden.)

  • Für die Identifizierung der Benutzer sollte ein Hash als unique-ID dienen, der nicht mit Datenschutzproblemen belastet ist.

=> Beispiel: Die Benutzer-ID des Schulverwaltungsprogramm hashen (md5) (Warum hashen? Die ist doch sowieso nur im entsprechenden Programm drin!)

- Diese ID-Nummer muss gespeichert werden (LDAP oder File?)

- evtl. ist die ID aber auch anderswoher übernommen (bei Lehrern z.B. von der Dienststelle - aber lohnt der Aufwand?).