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.

Grundkonfiguration

Host-URL => ldap://localhost

Version => 3 (wenn es nicht klappt: 2)

LDAP-Codierung => utf-8

Kennwörter verbergen => ja

Nutzertyp => posixAccount (rfc2307)

Kontexte => ou=evaluation,dc=schuldomain,dc=tld (bitte an eigene Werte anpassen)

Suchkontexte suchen => ja

Objekt Class => objectClass=posixAccount

Wir haben jetzt Moodle mitgeteilt, in welchem Teil des LDAP-Baumes (Kontext) es mit welchen Einstellungen nach Nutzerinnen suchen muss. Jetzt kümmern wir uns darum, wie er mit den gefundenen Daten umgehen soll, was hauptsächlich dazu dient, dass auch beim ersten dem Einloggen bereits vollständige Propfile vorliegen.

Data Mapping

Alle im folgenden erwähnten Felder sind zusätzlich mit den Einstellungen “Bei jedem Login”, “Nie”, “gesperrt” über die jeweiligen Dropdownmenus zu versehen.

Vorname => givenName

Nachname => sn

E-Mail-Adresse => mail

Stadt/Ort => postalAddress

Sprache => preferedLanguage

Beschreibung => description

Damit sollten sich die mittels des Scriptes generierten Nutzer/innen am System so anmelden können, dass keine Ergänzung der Profilfelder notwendig ist.

Für die Profis:

Das LDAP-Script (eval_to_ldap.php ) füllt im LDAP für jede Zufalls-ID eine Art “Objekt”, welches verschiedene Attribute (fakultativ und obligatorisch) enthält. Dieser Objekttyp heißt “posixAccount” und wir haben jetzt Moodle mitgeteilt, welches Attribut des Objektes er für welche Nutzereigenschaft verwenden soll, indem wir die Attributnamen einem Feld zugewiesen haben. Das ist eine spannende Fähigkeit von Moodle, da ich im LDAP Attribute ändern kann, die Moodle dann durch die Art des Datamappings ohne Rumgepfusche in der Datenbank sofort anzeigt.

Wir zeigen auf diese Weise etwa über das fakultative Attribut “gecos” die Klasse eines Schülers mit an, die sich ja jedes Jahr ändert. Die Verwaltung erfolgt dabei zentral im Schulverwaltungssystem, welches mit unserem LDAP gekoppelt ist. So lassen sich Personendaten und Moodledatenbank sinnvoll trennen.

zurück | vor

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?

Zunächst muss man in einem Linuxsystem als normaler Benutzer (Clientbenutzer) einen privaten und einen öffentlichen Schlüssel generieren. Das funktioniert über den Befehl:

ssh-keygen -d

Dabei wird ein Passwort abgefragt. Man kann seinen privaten Schlüssel zusätzlich durch ein Passwort schützen, d.h. nur derjenige, der dieses Passwort besitzt, darf mit diesem Schlüssel verschlüsseln. Möchte man z.B. via Script vom fremden Server Dateien holen oder schreiben (eine typischen Anwendung),  darf kein Passwort vergeben werden und gleichzeitig muss der private Schlüssel gegen unbefugten Zugriff verstärkt gesichert werden.

Durch diesen Befehl entstehen zwei Dateien im Homeverzeichnis des gerade eingeloggten Benutzers:

1. /.ssh/id_dsa.pub (öffentlicher Schlüssel)
2. /.ssh/id_dsa (privater Schlüssel)

Nur der erste Schlüssel darf verteilt werden, also das System verlassen!

Jetzt muss der öffentliche Schlüssel auf den Server gelangen., auf den man sich per Key einloggen möchte.

Damit sind die Arbeiten auf dem Client abgeschlossen.

Teil 2: Arbeiten auf dem Server

Man sollte sich zunächst überlegen, unter welchen Benutzernamen (Serverbenutzer) man sich auf dem Server einloggen möchte. Es ist nicht immer empfehlenswert, dass das der Rootbenutzer ist.

Man loggt sich zunächst auf dem Server mit dem gewünschten Benutzer ein und kopiert die Datei id_dsa.pub  vom Client in das Homeverzeichnis des Serverbenutzers. Danach legt man dort mit

touch $HOME/.ssh/authorized_keys

die Datei “authorized_keys” an und kopiert mit

cat $HOME/id_dsa.pub >> $HOME/.ssh/authorized_keys

den öffentlichen Schlüssel in diese Datei. Anschließend sollte man auf dem Server mit

rm $HOME/id_dsa.pub

Die kopierte Schlüsseldatei wieder löschen.

Teil 3: Generalprobe

Man loggt sich jezt als Clientbenutzer auf dem Client ein. Anschleßend überprüft man durch:

ssh serverbenutzer@server.tld

ob das alles funktioniert. Hat man einen Schlüssel ohne Passwort erzeugt, sollte man jetzt auf dem Server als

serverbenutzer

eingeloggt sein. Das funktioniert nicht, wenn man auf dem Client als ein anderer Benutzer eingeloggt ist weil da das Schlüsselpaar eben nur für einen Nutzer gilt.

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…

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.

Moodle kann dank LDAP-basierter Authentifizierung seine Nutzer weitgehend in einem LDAP-Baum verwalten. Moodle verwendet für Nutzerdatensätze weitgehend das inetorgperson-Schema, was schonmal sehr gut zu LDAP passt. Desweiteren kann Moodle Nutzerinnen und Nutzer aus mehreren LDAP-Bäumen gleichzeitig verwalten. Darin könnte ein Ansatz liegen, der die genannten drei Probleme weitgehend erschlägt.

Man organisiert einen LDAP-Baum, mit folgendem Aufbau:

- rootdn
--- moodlessysteme
------- Schule1
----------- Schüler
----------- Lehrer
------- Schule2
----------- Schüler
----------- Lehrer
------- Schule3
----------- ....
---- ldap-Admins
------- schule01
------- schule02
------- schule03

Die ldap-Admins haben jeweils Schreibrechte im gleichnamigen Unterbaum (und nur dort), sodass man sie innerhalb des jeweiligen Moodles als Binduser einsetzen und Nutzer durch Moodle im LDAP anlegen lassen kann.

Der konkrete Nutzer kann sein Profil trotzdem überarbeiten (die nicht gesperrten Felder) und die werden dann im LDAP automatisch aktualisiert. Der Datenimport erfolgt zweckmäßigerweise über das ldif-Format, was sich leicht auch aus Excel-Tabellen (cvs) oder einer bestehenden Moodlenutzerdatenbank einfach generieren lässt. Ein solches LDAP kann “nebenbei” auch als Adressbuch für die Schulverwaltung dienen.

Das Datamapping von Moodle ermöglicht nun zusätzlich eine Anonymisierung, etwa unter Zuhilfenahme der im inetorgperson-Schema befindlichen GID und UID-Nummer (die man dann z.B. mit einem zusätzlichen statischen Schlüssel versehen innerhalb des Moodlesystems anzeigt).  Somit ist eine genaue Nutzerzuordnung trotz Logging erstmal nur durch den Admin des openLDAP/AD möglich – so wie ansonsten auch – was dem Kontrollbedürfnis vieler deutscher Lehrerinnen und Lehrer vielleicht widerspricht. Wenn sich ein Schüler oder eine Schülerin selbst “outet”, kann man dagegen natürlich nichts tun. Generell kann man aber anonym bleiben.

Was wird nun aber noch möglich?

1. In Kombination mit einem LDAP-fähigen MTA können auf dem Server quasi “von selbst” (virtuelle User) gültige E-Mailaccounts angelegt werden, die sich z.B. via IMAP/POP3 (dovecot) extern mit dem LDAP-Passwort (was gleich dem Passwort für Moodle ist) verwalten lassen (Weiterleitungen sind auch möglich).
2. Der Datenschutz kann so granular erfolgen, wie es das jeweilige Anforderungsprofil erfordert. Attribute für die anonymisierten Daten lassen sich auch in das inetorgperson-Schema integrieren und dann in Moodle mappen. Dennoch werden im zentralen LDAP folgende personenbezogene Daten mindestens gespeichert aber nicht zwangsläufig angzeigt: Vorname, Name, Schule.
3. Nutzen verschiedene Schulen den gleichen LDAP-Dienst, genügt ein einfaches Hinzufügen des jeweiligen LDAP-Kontextes in das betreffende Moodle, damit Nutzer von Schule A Kurse von Schule B nutzen können. Das erfolgt idealerweise über ein Webinterface, was sich z.B. über das Adminpasswort des jeweilige Moodlesystems erreichen lässt – das Austragen ist dann genauso einfach – das sind simple MySQL-Querys.
4. Die Schule kann so jeden Dienst nutzen, der LDAP-fähig ist – das sind viele CMS- und Groupwarelösungen ebenso wie z.B. Mediawiki. Passwort und Login sind für jeden Nutzer dann immer gleich (so kann ich z.B. auch Person “zentral” sperren, indem ich ihr Passwort auf einen ungültigen Wert setze).

Dummerweise müssen die verschiedenen Schule dazu in einem zentralen LDAP organisiert sein. Das erfordert nach meinen Erfahrungen persönlichen Kontakt und Vertrauen, ist also überregional wahrscheinlich schwieriger zu handhaben als regional begrenzt.

Daher habe ich in einem meiner jüngst abgegebenen Projekte dieses System lediglich verhältnismäßig zufriedenstellend erprobt, jedoch nicht mehr realisiert. Es ist ein wenig Aufwand – insbesondere die Migration bestehender Systeme in ein LDAP – der sich aber lohnen dürfte, da sich so alle Möglichkeiten auftun, die LDAP eben bietet (und das Windowspendant AD momentan so populär macht).