Neuer ChurchTools LDAP-Wrapper [Node.js]

milux

Hallo zusammen,

für die lesefaulen Menschen: Nach dem CT-Autoupdater von Dennis und mir gibt es jetzt das nächste praktische Tool von uns: Ich habe einen neuen CT-LDAP-Wrapper geschrieben.
Interessierte bitte hier entlang: https://github.com/milux/ctldap

Längere Erklärung:

Ich habe vor ca. 2 Wochen versucht, die Benutzeraccounts von ChurchTools in unserer NextCloud-Instanz nutzbar zu machen, natürlich über den CT-LDAP-Wrapper.

Unser momentanes Setup (Es wird demnächst noch effizienter und sicherer, dazu gleich noch mehr.) sieht wie folgt aus:

ChurchTools auf PHP 7.0 inkl. MySQL bei ALL-INKL
Raspberry Pi 3 mit Raspbian und neuestem Node.js 7.x in unserer Gemeinde, inkl. dem notwendigen Port-Forwarding für LDAP
NextCloud momentan noch bei ALL-INKL auf PHP 7.1, demnächst auf einem Synology NAS in unserer Gemeinde (s. unten, Datenschutz!)

Nach bzw. bereits während der Einrichtung bin ich auf eine Vielzahl von Problemen gestoßen:

Die App benötigt direkten Zugriff auf die MySQL-Datenbank über eine persistente Verbindung, natürlich unverschlüsselt!
Die Gruppenzuordnungen waren komplett kaputt. Die Gruppen wurden zunächst nicht einmal erkannt. (Technisch: Ihnen fehlte die grundlegende ObjectClass von LDAP-Gruppen (group)) Außerdem wurden die Verknüpfungen nur in eine Richtung überhaupt gesetzt, und selbst das unvollständig/falsch, weil der JS-Code falsch war. (Technisch: Ein asynchroner Request in einer Schleife wurde nur unvollständig abgearbeitet, dementsprechend wurden je nach Tempo des MySQL-Servers nur einige wenige Gruppen gesetzt, bevor alles ausgeben wurde. -> "Race-Condition")
Ein Login eines CT-Users dauerte mindestens 3 Minuten (!!!) (Technisch: Der Cache war im Code zur Hälfte auskommentiert und zur anderen Hälfte falsch programmiert und dadurch unbrauchbar, die Daten wurden immer frisch aus MySQL gezogen.)
Alle nicht alphanumerischen Buchstaben wurden entfernt -> Weder hübsch noch notwendig.

In diesem Zustand war uns klar, dass wir den Wrapper nicht sinnvoll produktiv einsetzen können.
Da für uns ein zuverlässiger Einsatz wichtig ist, habe ich zunächst versucht, alle Unzulänglichkeiten des Originals auszubessern.
Letzten Endes habe ich angefangen, das komplette Programm umzuschreiben. Die Codebasis mit dem Originals ist, wenn es überhaupt noch eine gibt, nur in Spuren nachweisbar.

Folgendes hat sich geändert:

Es gibt (statt direktem, unverschlüsseltem MySQL) eine separate PHP-API, die auf den CT-Server kopiert werden muss. Das Konfig-File von CT muss nach Anleitung um eine zusätzliche Zeile mit einem Sicherheitsschlüssel ergänzt werden. Die Daten werden vom Wrapper über diese API abgefragt, wobei volle SSL-Unterstützung gegeben ist, wenn CT per SSL gesichert ist. (Datenschutz must-have, siehe unten!)
Der LDAP-Server hält die User- und Group-Daten in einem (funktionierenden) Cache, dessen maximales Alter in ms konfigurierbar ist. (Standard: 10000 bzw. 10 Sekunden)
Es gibt ein Setup-Skript (Nur für root-User!), dass das Programm automatisch konfiguriert und durch die Einrichtung führt.
Es gibt ein init.d-Script (Nur für root-User!) für den automatischen Start/Stop, Statusabfragen und Port-Weiterleitung über iptables (nat), damit die "echten" LDAP-Ports nutzbar sind, ohne den Wrapper als root auszuführen.
Weder Nutzernamen, noch Gruppennamen, noch sonst irgendwas wird verkrüppelt. Es gibt allerdings Bugs im Zusammenhang mit einigen Sonderzeichen bei manchen LDAP-Clients, z.B. im Automatik-Modus bei den Auswahlen des NextCloud-Plugins! Das ist kein Bug des Wrappers!

Ich hoffe einige Gemeinde haben mit diesem neuen Wrapper Freude, damit sich der Zeitaufwand lohnt, den ich in den neuen Wrapper gesteckt habe.

Ich empfehle aus Datenschutzgründen ausdrücklich:

ChurchTools mit SSL zu sichern
entsprechend die API-URL mit "https://" zu beginnen
sowie LDAP-Wrapper und die LDAP-Clients (OwnCloud, NextCloud, etc.) im selben Intranet zu betreiben!

Da in unserem Setup bisher Punkt 3 verletzt ist, werden wir erst in den produktiven Betrieb für nicht-Tester übergehen, wenn wir unsere NextCloud von ALL-INKL auf ein Gemeinde-internes NAS umgezogen haben, wo sowohl der Raspi als auch das NAS im gleichen gesicherten, internen VLAN laufen. Nur so kann ausreichende Sicherheit gewährleistet werden!

milux

Und bevor der Erste fragt:
Natürlich supporte ich dieses Projekt auch, soweit es mir meine Zeit erlaubt. Wenn es Probleme gibt, macht bitte einen "Issue" bei GitHub auf. Falls das zu schwer ist, sind auch Beiträge hier im Thread oder PNs in Ordnung, aber ich bevorzuge GitHub.

sctech

Klingt fantastisch! Ich werde das auf jeden Fall ausprobieren und davon berichten.

sctech

Ich habe das Ganze nun einmal getestet. Von der Umsetzung her sieht alles perfekt aus - schnell eingerichtet und die LDAP-Abfragen erfolgen schnell und reibungslos.

Nun habe ich versucht, unsere Synology RackStation beim LDAP-Server anzumelden. Hier bin ich aber gescheitert, denn irgendwie entspricht das gelieferte LDAP-Schema nicht der geforderten Norm RFC 2307 (siehe https://www.synology.com/de-de/knowledgebase/DSM/help/DSM/AdminCenter/file_directory_service_ldap
). Attributzuordnungen lassen sich zwar konfigurieren, aber irgendwie will das Ganze nicht so wirklich...

Welcher Norm entspricht die Datenlieferung des LDAP-Wrappers?

Dann habe ich noch folgendes festgestellt:
Wenn ich "ou=users,o=churchtools" oder "ou=groups,o=churchtools" abfrage, erhalte ich jeweils das korrekte Resultat. Frage ich lediglich nach "o=churchtools" müsste ich doch Benutzer und Gruppen erhalten, oder? Hier erhalte ich ein leeres Resultat zurück.

Danke fürs Feedback und deine Arbeit!

milux

@seetalchile Ich habe leider exakt dasselbe Verhalten festgestellt, und muss an dieser Stelle leider sagen, dass es mich auch nicht wundert.

Bzgl. der RFC 2307: Weder der ursprüngliche Wrapper, noch meiner, halten sich derzeit ein irgendeinen Standard - leider. Wenn du mir sagen kannst, was man an dem LDAP-Schema ändern oder ergänzen muss, damit das läuft, wäre ich in der Tat sehr dankbar. Hab' dazu bisher nämlich nix handfestes gefunden.
Ich hab' auch länger versucht, es irgendwie mit meiner Synology-Box zu koppeln. Nachdem ich mich die Schnittstelle nur mit nichtssagenden Fehlermeldungen abgespeist hat, habe ich irgendwann aufgegeben.
Die Inkonsistenz bei der Abfrage der Struktur unter o=churchtools ist mir bekannt. Ich sollte mich darum wohl in der Tat mal kümmern. An der Stelle ist einfach nichts definiert, daher wird auch nichts ausgegeben. Wenn ich Zeit habe, werde ich das noch ein wenig aufpolieren.

milux

Es gibt auch noch eine technische Limitierung, die es bisher verhindert, das ganze über RADIUS anzubinden:
Da in der DB von CT die Daten mit einem sicheren Hashverfahren (bcrypt) gesichert sind, kann der LDAP-Server nur Plaintext-Anmeldungen. Für jedes andere Verfahren müssten die Passwörter im passenden Hash-Format vorliegen, was eine Anpassung von ChurchTools (inkl. erheblicher Schwächung der Sicherheit) erfordern würde, Plus einen Passwortwechsel aller Personen. Not gonna happen...
Dasselbe Problem könnte auch der Endgegner bei der Synology-Integration werden.

sctech

Danke für deine Antwort! Schon mal gut, dass unsere Erkenntnisse übereinstimmen Ich werde mich auf jeden Fall in nächster Zeit mal noch eingehender mit der Anbindung zu Synology beschäftigen und ggf. bei deren Support auch eine Spezifikation anfordern.

Das Einzige, was ich zu RFC 2307 gefunden habe:
https://www.rfc-editor.org/pdfrfc/rfc2307.txt.pdf
http://www.mitlinx.de/ldap/index.html?http://www.mitlinx.de/ldap/ldap_schema.htm

milux

@seetalchile Der komplette RFC ist mir zu umfangreich für ein Hobbyprojekt, und der andere Link erzählt nur Sachen, die ich schon weiß. Ich weiß, dass die User vom Typ posixAccount sein müssen, aber was dann genau ins Schema rein muss, und ob es überhaupt machbar ist, steht in den Sternen...

sctech

Ich bin zur Zeit in Kontakt mit dem Support von Synology. Zu meiner Frage nach einer exakten Spezifikation zur Anbindung des LDAP-Clients werde ich noch eine Rückmeldung erhalten. Dies sei bei der Entwicklungsabteilung nun in Abklärung.

Vorab habe ich bereits einmal die Antwort erhalten, dass sich die Schnittstelle an die Vorgaben von LDAP v3 (RFC 2251) halte: https://www.rfc-editor.org/rfc/pdfrfc/rfc2251.txt.pdf

Ich halte auf dem Laufenden...

sctech

Ich habe nun eine Schemadatei von Synology erhalten, kann aber nicht viel daraus lesen. @milux Evtl. kannst du etwas damit anfangen?
https://www.dropbox.com/s/pd651y4inn9bb7g/syno.schema.zip?dl=0

milux

Die Attribute beginnen praktisch alle mit "syno", also muss es eine Beschreibung von einem Synology-spezifischen Format sein. Das hilft uns gar nicht weiter.
Ich fürchte, du hast dein Anliegen entweder nicht richtig erklärt, oder bist an einen inkompetenten Kontakt geraten, denn so wie es aussieht, haben sie nicht wirklich verstanden, was wir brauchen...

tomzi

Eine andere Frage... Kann der Wrapper auch mit den von church.tools gehosteten Servern verwendet werden?
Oder
Kann der CT Wrapper auf einem anderen Server als CT installiert werden und die Daten von einem externen (zb von church.tools) gehosteten server 'abholen'?

mhuber

@tomzi : ja das ist möglich. Einfach den ctldap irgendwo betreiben und in der ctldap.config die richtige URL für die ChurchTools-Instanz eintragen. (https://xyz.church.tools)

sctech

@milux Wir sind aktuell dabei, CTLDAP in Verbindung mit NextCloud zu testen. Dies funktioniert alles ganz prima - danke! Nun ist ein Anliegen aufgekommen: Gerne würden wir nicht immer ganze Grupppen, sondern nach Teilnehmerrollen unterschiedlich berechtigen.

Beispiel:

Kurs xyz

Leiter haben schreibenden Zugriff auf die Gruppenordner abc und def
Teilnehmer haben lesenden Zugriff auf den Gruppenordner abc

Ist es richtig, dass dieses Szenario zur Zeit nicht möglich ist?

Wenn ich das Prinzip richtig verstehe, müsste in diesem Fall pro GRUPPE-ROLLE-Kombination eine LDAP-Gruppe ausgegeben werden. Wäre eine solche Umsetzung denkbar? In diesem Fall könnten dann auch Leute mit Teilnehmerrolle "Anfrage" bzw. "zu löschen" besser abgegrenzt werden.

drstone

Hallo zusammen.

Cool das es hier weiter geht, Danke Milux für deine Arbeit.

Wir haben noch den originalen ldap wrapper am laufen, allerdings mit einigen Anpassungen das es funktionierte. Ich werd das bei Gelegenheit auf deinen Wrapper umstellen.

@seetalchile, die gleiche Anforderung ist bei uns auch aufgekommen, die Rolle als Berechtigung in Own/Nextcloud verwenden zu können.

Außerdem eine Gruppenvererbung, also das jemand in der Gruppe "Gottesdienst" auch zugriff auf Ordner der untergeordneten Gruppe "Musik" hat.

dürfte sich nur mit "Gruppe_rolle" oder ähnlichem abbilden lassen, für 2. hab ich gar keine Idee. Aber vielleicht jemand anderes?

koehdaniel

Hallo,

gibt es zu dem Punkt "GRUPPE-ROLLE-Kombination" schon etwas neues oder ist hier absehbar, wann es eine Lösung geben wird?

Wir möchten gerne in Zukunft nur die Leiter einer Gruppe dazu Berechtigen ihre Seite in Wordpress bearbeiten zu können. Aktuell wäre leider jeder Teilnehmer hierzu in der Lage.

Gruß Daniel

bwl21

ich hole das Thema wieder hoch ... gibt es da ansäzt ausser die Gruppenrollen ganz aufzugeben?

drstone

Hallo Daniel.

Ich hatte letztes Jahr mal was gebaut, das CTS in der Gruppenliste zusätzlich zu jeder Gruppe noch die Gruppen/Rollen Kombination ausgibt.

Also gibt es dann im Ldap eine Gruppenliste die so aussieht:

Hauskreis
Hauskreis@Leiter
Hauskreis@Teilnehmer
...

Optimalerweise erstellt man hierfür noch ein Gruppenflag und exportiert diese RollenGruppen nur für die mit Flag, da das nicht unbedingt bei allen Gruppen so notwendig ist und die Liste extrem lang wird, aber damit funktioniert die Nextcloud Freigabe.

Hatte bei mir so funktioniert, aber hatte (und habe) keine Zeit das näher zu verfolgen. Ich hab in der CT Funktion für die Gruppenliste ein zusätzlichen Parameter hinzugefügt und diesen Parameter vom CtLdap client gesetzt, sodas das auch keine Auswirkung auf sonstige Anwendungen hat.

Wenn das jemand probieren oder weiterverfolgen will stell Ich gern meine Codeschnipsel zur Verfügung.