In unser Portfolio sollen nur die Kolleg/innen reinkommen und nicht die Schüler/innen. Also authentifizierte dieses zunächst nur gegenüber dem Lehrermoodle – seit ein paar Tagen jedoch auch gegenüber dem hausinternen LDAP-Server über eine verschlüsselte Verbindung.
DokuWiki, die Basis für das Portfoliosystem, erlaubt hierbei jegliche Mischung aus Authentifizierungsverfahren, sofern man das Plugin AuthChained installiert hat. In unserem Fall lege ich die Administratoren und Redakteure händisch in der DokuWiki eigenen Datenbank an – die nur lesenden Benutzer/innen dürfen über LDAPs kommen. Sie sollen in der Default-Gruppe visitor landen, die im Backend von Dokuwiki so eingerichtet wurde, dass sie nur lesenden Zugriff auf die Portfolio-Seiten erhalten.
Dann wurde die dokuwiki/config/local.php umgestaltet. Hier die Variablen, die am Ende des Config-Marathons endlich die intendierte Wirkung hatten:
$conf['authtype'] = ‘authchained';
$conf['defaultgroup'] = ‘visitor';
$conf['disableactions'] = ‘register';
$conf['plugin']['authldap']['server'] = ‘ldaps://ip.des.servers.tld:636?;
$conf['plugin']['authldap']['port'] = 636;
$conf['plugin']['authldap']['usertree'] = ‘dc=schule,dc=ort,dc=schule-bw,dc=de';
$conf['plugin']['authldap']['userfilter'] = ‘(&(uid=%{user})(objectClass=ldUserAccount)(ldRole=teacher))';
$conf['plugin']['authldap']['version'] = 3;
$conf['plugin']['authchained']['authtypes'] = ‘authldap:authplain';
$conf['plugin']['authchained']['usermanager_authtype'] = ‘authplain';
$conf['auth']['chained']['authtypes'] = ‘ldap,plain';
$conf['auth']['chained']['usermanager_authtype'] = ‘plain';
$conf['auth']['chained']['find_auth_by_password'] = ‘false';
$conf['auth']['ldap']['version'] = ‘3’;
ldUserAccount und ldRole sind spezifisch für MySHN bzw. LogoDidact Systeme. Andere Schulserver-Lösungen haben sicherlich andere Bezeichnungen. Die Einträge in den LDAP von LMN sind in deren Wiki hervorragend dokumentiert und lieferten auch für obige LD-Lösung viele Ideen:
Anmeldeversuche von SuS werden nun mit der Fehlermeldung “Benutzername und / oder Passwort unbekannt” abgewiesen. Dokuwiki sucht schließlich nicht im LDAP-Baum nach allen Menschen auf ServerG, sondern nur noch nach LuL. Vermutlich ist das overkill, denn im Userfilter steht ja ebenfalls drin, dass nur LuL reindürfen. Aber es funktioniert und scheint mir sicherer zu sein.
Da der schulische LD-Server für LDAPs nur ein self-signed Zertifikat ausliefert kommt noch ein Eintrag in die /etc/ldap/ldap.conf auf dem Dokuwiki-Server
TLS_REQCERT allow
Hallo,
Sbe behauptet, dass der Logodidact-Server kein LDAPs kann und weigert sich, den entsprechenden Port zu öffnen (unsere Schule hat leider kein Root-Zugriff auf den Server).
Jetzt lese ich in Ihrem Blog, dass LDAPs doch funktioniert und bin etwas überrascht.
Können Sie mich mit weiteren Informationen versorgen: z.B. wurde auf dem Server für LDAPs noch etwas zusätzlich installiert? Oder geht das out-of-the-box.
Eine LDAPs-Authentifizierung von außen würde uns bei verschiedenen Szenarien, das Leben sehr erleichtern.
Vielen Dank für Ihre Informationen.
MfG Markus Müller
Ups. Sorry. Ich sehe diesen Post erst jetzt beim Löschen aufgelaufener SPAM Kommentare und inzwischen ist ein Jahr in die Binsen gegangen …
Zur Frage: Der LD Server kann LDAPs. Da steckt ein openLDAP Server drin und der kann das. Ob wir hierzu einst einen Port in der Firewall geöffnet haben oder die Konfiguration des openLDAP-Servers anpassten, daran kann ich mich nicht erinnern. Ist ja auch egal: es geht. Mir reicht es, wenn ich derartige Aussagen nur lesen muss und mir stellen sich alle Borsten auf.
Die Aussage von LD, dass ihr openLDAP Server kein LDAPs könne, halte ich für a) pure Faulheit etwas am System zu ändern b) einen Grund, den Anbieter des Schulservers sofort zu wechseln. Linuxmusternet wäre eine Alternative!