riecken.de

Vorausgesetzt wird, dass Moodle auf dem gleichen Server wir der eingerichtete und mit Daten befüllte slapd läuft. Schematisch ist diese Anleitung ganz allgemein verwendbar, um Moodle ein einen openLDAP-Server zu koppeln. Die “Bulkuploadleute” brauchen diese Anleitung nicht…

Zunächst einmal müssen wir sicherstellen, dass die Authentifizierng über openLDAP überhaupt in Moodle aktiviert ist. Dazu klicken Sie im Administrationsmenu

Website-Administration => Nutzer/innen => Authentifizierung => Übersicht

auf das geschlossene Auge bei “LDAP-Server”, so es denn noch geschlossen ist. Durch das Aktivieren der LDAP-Aurhentifizierung bleiben übrigens alle übrigen Authentifizierungsmethoden funktionsfähig. Jetzt erscheint im Menu

Website-Administration => Authentifizierung

ein neuer Eintrag mit dem Namen “LDAP-Server“, den es anzuklicken gilt. Es folgt eine umfangreiche Konfigurationsseite. Ich hangle mich mich jetzt nur durch die Felder hindurch, die geändert oder mit Daten befüllt werden müssen. Alle anderen Felder bleiben jungfräulich. Es werden folgende Angaben aus dem vorherigen Schritt benötigt:

• Wert der Variablen $organisation (evaluation)
• Wert der Variablen $domain (schuldomain)
• Wert der Variablen $tld (tld)

Ich nenne zunächst das Konfigurationsfeld gefolgt von einem Pfeil (=>), hinter dem der einzutragende Inhalt steht.

Den ganzen Beitrag lesen »

Es gibt zwar zu diesem Thema viele Tutorials im Netz, jedoch konnte ich mir bisher keines so richtig merken.

Was kann man damit eigentlich anstellen?

Normalerweise logge ich mich in einen Server mit einem Benutzernamen und einem Passwort ein. Der Server überprüft dann, ob mein eingegebener Benutzername zum auf dem Server gespeicherten Passwort (meist ein Hash) passt und gewährt mir im positiven Fall dann Zugriff. Das lässt sich eigentlich ganz gut mit einem Zahlenschloss an einem Fahrrad vergleichen: Nur wer die korrekte Kombination kennt, kann dieses Schloss öffnen. Bei einem Fahrradschloss kann ich als böser Bube jedoch durch Ausprobieren die korrekte Kombination herausfinden. Das ist lediglich eine Frage der Zeit. Je einfacher mein Passwort aufgebaut ist (etwa “3333″, desto weiniger Zeit wird der Angreifer benötigen.

Aufgrund dieser Problematik wurde im Serverbereich die Authentifizierung via Schlüssel (Key) erfunden. Das Verfahren ist eigentlich sehr pfiffig: Der Benutzer generiert zunächst einmal zwei Schlüssel: Einen privaten und einen öffentlichen. Bei der Anmeldung am Server geschieht nun folgendes:

Der Benutzer sendet seinen Benutzernamen, der aber mit mit seinem privaten Schlüssel verschlüsselt (unkenntlich gemacht) ist. Der Server besitzt den öffentlichen Schlüssel und den Benutzernamen des Benutzers. Bei ihm kommt nun eine kryptische Zeichenkette an, die er nur mit dem öffentlichen Schlüssel wieder in den Benutzernamen umwandeln kann. Die öffentliche Schlüssel muss zu dem privaten Schlüssel passen. Zudem taugt der öffentliche Schlüssel nur zur Entschlüsselung, nicht jedoch zur Verschlüsselung.

Um ganz genau zu sein (Danke Markus…):

Speziell bei SSH ist es nun so, dass die asymmetrische Verschlüsselung nach diesem Verfahren nur verwendet wird, um einen Schlüssel für eine performantere synchrone Verschlüsselung auszuhandeln. Nach dem Handshake machen Server und Client also “ihr eigenes Ding”.

Vorteil:

Nur wer im Besitz des privaten Schlüssels ist, kann sich am Server anmelden. Das Ausprobieren von Passworten ist theoretisch nicht denkbar (man müsste die Verschlüsselung imitieren), aber praktisch immens schwierig und zeitaufwendig.

Ein Bild für dieses Verfahren ist z.B. ein Fahrradschloss mit Schlüssel. Der private Schlüssel hängt am Schlüsselbund des Benutzers. Die Schlossmechanik selbst ist der öffentliche Schlüssel und weit aufwendiger zu imitieren als etwa eine Zahlenkombination herauszufinden.

Natürlich kann man mit dem Verfahren nicht nur Benutzernamen, sondern alle möglichen Texte verschlüsseln. – z.B. auch E-Mails. Den öffentlichen Schlüssel kann man gefahrlos weitergeben, sodass sich den jeder Empfänger herunterladen kann.

Hier einmal ein einfaches Schaubild:

Wie funktioniert das nun praktisch?

Den ganzen Beitrag lesen »

Bilder von Schülerinnen und Schülern sind oft ein Problem – vor allem dann, wenn man sie veröffentlich und das vielleicht sogar noch so tut, dass Namen einem bestimmten Foto zugeordnet werden können. In einigen Bundesländern ist das sogar strikt verboten.

Auch hier kann LDAP abmildern: Man nutzt ein Schul-LDAP als “Zapfstelle” für eine HTTP-basierte Authentifizierung, die vielen bestimmt bekannt ist (.htaccess).

Mit meinem Lieblingswebserver (lighty) geht das sehr leicht – das auth-Modul muss allerdings aktiviert sein.

server.modules                += ( “mod_auth” )

auth.backend                 = “ldap”

auth.backend.ldap.hostname   = “127.0.0.1″
auth.backend.ldap.base-dn    = “ou=ldapbaum,dc=foo,dc=tld”
auth.backend.ldap.filter     = “(uid=$)”

$HTTP["host"] == “subdomain.fuer.fotos” {
auth.require = (   “” => (
“method”  => “basic”,
“realm”   => “Anmeldung bitte mit Schulogin und -passwort fuer die Seite “,
“require” => “valid-user”
)
)
}

… und schon ist nach einem /etc/init.d/lighttpd force-reload der Zugriff auf die Seite http://subdomain.fuer.fotos mit allen Unterseiten nicht mehr ohne Anmeldung möglich, wenn lokal der LDAP-Server oder eine Kopie bzw. Replikation davon mitläuft. So kann sich der der potentielle Kinderschänder nicht mehr ohne Weiteres sein nächstes Opfer anhand des letzten Schwimmwettbewerbsbildes auswählen – es sei denn, er kommt selbst von der Schule (zugegebenermaßen eine sehr düstere Option). Ingesamt nett und simpel.

Wenn man das jetzt noch mit WebDAV und Moodle kombiniert, kann man sogar einzelnen Lehrkräften Schreibrechte in bestimmten Moodleordnern einräumen. Da Lighty reguläre Ausdrücke unterstützt, müsste das sogar recht schmerzfrei gehen. Aber das ist eine andere Geschichte…

… ist in meinen Augen so gar nicht gelungen, da immer wieder gleiche Probleme auftreten:

1. Moodle aktzeptiert z.B. nur Datensätze, die eine – im Format gültige E-Mailadresse – enthalten. Nun besitzt nicht jeder Schüler oder jede Schülerin eine solche – von Lehrkräften einmal ganz zu schweigen. Das führt oft dazu, dass die Admins “Fantasieadressen” erfinden – im allerschlimmsten Fall mit einem gültigen Domainanteil – womit man mit seiner Server-IP schnell auf gängigen Blacklists landet und dann kaum Mails mehr verschickt werden können.
2. Moodle loggt exzessiv Benutzeraktivitäten (eigentlich jeden Klick) – das Bewusstsein für Datenschutz scheint mir gerade in angloamerikanischen Kontexten nicht so sensibel entwickelt. In Deuschland gilt der Grundsatz der Datensparsamkeit. Man kann rechtlichen Problemen vorbeugen, indem man die Eltern entsprechende Einverständniserklärungen unterschreiben lässt, was einen erheblichen Aufwand bedeutet. Die Anzeige einer Information vor der erstmaligen Anmeldung, welche Daten in welchem Umfang erhoben werden, dürfte bei Minderjährigen rechtlich ins Leere laufen. Dieses Problem wird immer wieder gerne wegdiskutiert mit dem Argument, dass man sich zwischen dem pädagogisch Sinnvollen und der Gängelung durch rechtliche Kontexte kreativ bewegen muss. Fakt ist aber leider, dass Moodle nicht das Prinzip der Datensparsamkeit erfüllt.
3. Interoperabilität zwischen verschiedenen Moodlesystemen (und dadurch zwischen Schulen) wird durch MNET – das Moodlenetwork möglich. Ich war bisher immer entschieden zu doof, das zu konfigurieren. Außerdem ist mir nie ganz klargeworden, welche Daten da tatsächlich ausgetauscht werden.

Es folgt eine kleine Spinnerei, wie derartige Probleme technisch gut in den Griff zu bekommen sind. Das erfordert jedoch einiges an Brain 2.0 – denn die Lösung heißt in meinen Augen LDAP. Den ganzen Beitrag lesen »