Schlagwort-Archive: myshn

LDAPs von MRBS 1.5 auf LD-Server

Ein auf einem externen Server (z.B. bei Hetzner) gehostetes MRBS kann mit den folgenden Einstellungen per LDAPs gegenüber dem internen SBE-Serverchen mit openLDAP authentifizieren:

$auth["type"] = "ldap";
unset($auth["admin"]);
$auth["admin"][] = "admin";

$ldap_host = "ldaps://123.123.123.123"; // IP des Schulservers
$ldap_port = 636;
$ldap_v3 = true;
$ldap_tls = true;
$ldap_base_dn = "ou=users;dc=schule,dc=ort,dc=schule-bw,dc=de";
$ldap_user_attrib = "uid";
$ldap_filter = "|(ldRole=teacher)(uid=admin)";
$ldap_disable_referrals = TRUE;

//$ldap_debug = TRUE; // Nur drin lassen wenn es nicht funzt

Die obigen Einträge beziehen sich auf die Datei config.inc.php im Verzeichnis /pfad/zu/mrbs/web. Debugmeldungen von MRBS (sofern oben einkommentiert) finden sich in der error.log des Apachen. Der Filter stellt hoffentlich sicher, dass nur Lehrer/innen sich anmelden können. Um MRBS zusätzlich gegenüber Einsichtnahmen durch Zweite abzusichern, muss der Login erzwungen werden. Dazu

// Datenschutz

 if( ! getAuthorised(1))
   {
    showAccessDenied($day,$month, $year, $area);
    exit();
   }

nach den Includes in alle nur erdenklichen und über Netz erreichbaren PHP Dateien (month.php, day.php, week.php, search.php, report.php usw) setzen.

Die anderen hier im Blog zu findenden Hinweise zur Konfiguration von LDAPs gegen einen SBE Server sollte man sich ebenfalls mal ansehen, wenn es mit den Einträgen oben nicht tun will. Es gibt einige Wände, vor die man laufen kann.

LDAPs von ownCloud auf LD-Server

Nicht nur die Anbindung des LD-Servers an eine externe DokuWiki Installation, sondern auch an ein externes ownCloud funktioniert über LDAPs und lässt sich wie folgt einrichten:

Der erste Schritt ist vom OC-Administrator vorzunehmen, der im Backend die LDAP App einschalten muss. Weiter muss auf dem ownCloud-Server auch php5-ldap installiert sein und in der folgenden Datei die Prüfung auf Zertifikate abgeschaltet werden, wenn man intern auf dem LD-Server für den eigenen LDAP nur selbst-signierte Zertifikate einsetzt (was in den meisten Fällen zutreffen dürfte – leider):

# /etc/ldap/ldap.conf

TLS_REQCERT allow

Als OC-Administrator lässt sich dann unter dem Menü-Eintrag /Administration die restliche Konfiguration vornehmen.

ocldap-server

In der Server-Registerkarte ist die URL (besser: IP) für den LD-Server zu hinterlegen. Danach klickt man einmal in Benutzer-DN, trägt aber nix ein, klickt einmal in Passwort, trägt aber nix ein und schreibt dann die DN Angaben in das letzte Feld. Bei BelWü-Kunden dürfte es sich hierbei um einen Eintrag in der folgenden Form handeln:

dc=schulkuerzel,dc=stadt,dc=schule-bw,dc=de

Dann klickt man auf Fortsetzen – wie auch bei allen anderen folgenden Registerkarten.

ocldap-userfilter

In der Nutzer-Filter-Registerkarte sollte inetOrgPerson vorausgewählt sein und ownCloud auch gleich alle internen Benutzer (und Workstations etc.) finden. Im Bild oben sind dies 1008 Benutzer. Das sind etwas viele, die sich anmelden dürften, weswegen man Beschränkungen vornehmen sollte. Im Folgenden beschränke ich die Nutzung für die Gruppe der Lehrer/innen.

ocldap-loginfilter

Die Beschränkung erfolgt schon bei der Anmeldung: Nur Mitglieder der Gruppe teacher werden akzeptiert. Die entscheidende Funktion wird durch vorauswählbare Einträge nicht scharf schaltbar, weshalb man selbst den Original-Filter bearbeiten muss, so dass dieser am Ende wie folgt aussieht:

(&(|(objectclass=inetOrgPerson))(|(ldRole=teacher))(|(uid=%uid)(|(mailPrimaryAddress=%uid)(mail=%uid))(|(cn=%uid))))

Hinzugefügt wurde in die Voreinstellungen ein

(|(ldRole=teacher))

ocldap-groupfilter

Der Gruppen-Filter von ownCloud bezieht sich nämlich nicht auf die Benutzerrechte im Anmeldekontext, sondern lediglich auf das Recht, innerhalb von ownCloud Gruppen bilden zu dürfen.

Was bei der Arbeit auf jeden Fall hilft, ist einmal auf dem LD-Server mit tshark zu gucken, ob überhaupt LDAPs Anfragen ankommen.

tshark -i extern port 636

Weiter macht es Sinn mit

tail -f /var/www/owncloud/data/owncloud.log

zu verfolgen, was alles bei den Anmeldeversuchen schief läuft. Man braucht mindestens einen Lehreraccount und einen Schüleraccount zum Testen – sonst wird man irre. Auch darf man damit rechnen, dass man mehrfach

service apache2 restart

auf dem ownCloud Server benötigt, weil sich dieser an den Einstellungen verschluckt hat. Das kann man gut in der owncloud.log verfolgen: Sollte diese im Sekundenabstand mit Zeilen gefüllt werden, die ungefähr diese Angaben enthalten, dann ist es mal wieder Zeit für einen Apache Restart und einen erneuten Versuch im OC-Backend:

{"app":"user_ldap","message":"Configuration Error (prefix ): Not a single Base DN given.","level":2,"time":"2014-12-19T16:50:15+00:00"}
{"app":"user_ldap","message":"Configuration Error (prefix ): login filter does not contain %uid place holder.","level":2,"time":"2014-12-19T16:50:15+00:00"}

Wer das alles für seine Linuxmuster.net Lösung haben will, wird im Wiki fündig. Wie immer sind die freien Schulserver-Lösungen bei der Dokumentation von Sonderwünschen und Erweiterungen vorbildlich.

LDAPs von DokuWiki auf LD-Server

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:

http://www.linuxmuster.net/wiki/anwenderwiki:webapps:portfolio#anpassen_der_grundkonfiguration_des_osp

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