Moodle und Benutzerverwaltung…

… 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.

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).

Facebook Like

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.