Churchtools <--> LDAP <--> Nextcloud
-
@aschild Ich habe das auch schon ausprobiert. Das hat auch nichts genutzt.
Da ich aber nicht der Admin unseres ChurchTools bin, frage ich mich, ob es evtl. an einem falschen Passwort liegt?Der Support von CT will auch nur weiterhelfen, wenn ich vorher einen Test mit ldapsearch durchgeführt habe. Da ich leider kein Linux habe, kann ich es darüber nicht testen.
-
@detmold-nord Linux kannst du auch mal schnell in einer VM testen... Oder wenn du willst kann ich das für dich machen.
PM an mich mit den Angaben -
@aschild Vielen Dank für die Idee mit der VM. Da hätte ich auch selbst draufkommen können.
Ich habe das wie von dir vorgeschlagen mit einer Linux VM durchgeführt. Das Ergebnis sieht so aus - siehe Bild. Wie muss ich das interpretieren? -
@detmold-nord Das sagt dir schon mal dass dein Login funktioniert.
Aber so wie es aussieht, hat das root login zu wenig Berechtigungen im Churchtools, denn du müsstest jetzt da eine Liste der CT user (nur die mit aktiviertem Login) und Gruppen erhalten.Mein eigener Eintrag sieht so aus:
# aschild, users, churchtools dn: cn=aschild, ou=users, o=churchtools cn: aschild displayname:: QW5kcsOpIFNjaGlsZA== id: 6 uid: aschild nsuniqueid: u6 givenname:: QW5kcsOp street: xxxxxxx telephoneMobile: xxxxxxxx telephoneHome: xxxxx postalCode: xxxxxx l: xxxxx sn: Schild email: xxxxxxxxxxx mail: xxxxxxxxxxxx objectclass: CTPerson memberof: cn=kirchgemeinderat,ou=groups,o=churchtools memberof: cn=familiengottesdienste,ou=groups,o=churchtools memberof: cn=gemeindewochenende,ou=groups,o=churchtools memberof: cn=theateranlass i-pkk,ou=groups,o=churchtools memberof: cn=pkks,ou=groups,o=churchtools memberof: cn=pkk ipsach,ou=groups,o=churchtools memberof: cn=i-pkk,ou=groups,o=churchtools memberof: cn=it kommission,ou=groups,o=churchtools memberof: cn=lesezirkel nidau,ou=groups,o=churchtools memberof: cn=invenio,ou=groups,o=churchtools memberof: cn=adventswerkstatt ipsach,ou=groups,o=churchtools memberof: cn=neugestaltung gd raum ipsach,ou=groups,o=churchtools memberof:: Y249w7ZmZmVudGxpY2hlIGdydXBwZW4sb3U9Z3JvdXBzLG89Y2h1cmNodG9vbHM= memberof: cn=freiwilligenanlass ipsach 2020,ou=groups,o=churchtools memberof: cn=werbung klassische gd's,ou=groups,o=churchtools memberof: cn=gemeindewoche montmirail 2021,ou=groups,o=churchtools
Und Gruppen sehen so aus, wenn due den -b Parameter auf uo=groups,o=detmold-nord änderst
# kuw 2. klasse kuw-unterricht, groups, churchtools dn: cn=kuw 2. klasse kuw-unterricht, ou=groups, o=churchtools cn: KUW 2. Klasse KUW-Unterricht displayname: KUW 2. Klasse KUW-Unterricht id: 319 nsuniqueid: g319 objectclass: group objectclass: CTGroupKUW uniquemember:: Y249bmTDvHJzdCxvdT11c2VycyxvPWNodXJjaHRvb2xz uniquemember:: Y249c3fDpGZsZXIsb3U9dXNlcnMsbz1jaHVyY2h0b29scw==
-
@aschild Der ChurchTools Support hat nochmal an der ganzen Sache herumgepuhlt. Jetzt bekomme ich bei der ldapsearch Abfrage folgendes:
Wenn ich diese Meldung richtig verstehe, dann kommt jetzt keine Verbindung zu standen, bzw. das Passwort ist evtl. falsch.
-
@detmold-nord sagte in Churchtools <--> LDAP <--> Nextcloud:
@aschild Der ChurchTools Support hat nochmal an der ganzen Sache herumgepuhlt. Jetzt bekomme ich bei der ldapsearch Abfrage folgendes:
Wenn ich diese Meldung richtig verstehe, dann kommt jetzt keine Verbindung zu standen, bzw. das Passwort ist evtl. falsch.
Ja, Logindaten stimmen nicht
-
@aschild ich mach einfach hier mal weiter ...
Ich hänge da ein bisschen in den Seilen, manchmal tut es, und dann wieder nicht ...
Hier sieht man, dass ich zwar gruppen auswählen kann, aber m.E. baut er das LDAP-Filter nicht richtig zusammen.
Heute hat es auch schon funktioniert, da sah das dann so aus (bin ich froh, dass ich da screenshots gezogen habe)
Irgendeine Einstellung muss ihn wohl dazu bringen, dass er aus der Gruppe nicht die korrekte Abfrage errechnen kann.
Wenn ich das LDAP filter manuell einstelle, dann funktioniert es.
-
@bwl21 der untere Filter sieht gut aus. Kann es sein, dass es Probleme gibt, sobald du mit Umlauten in den Gruppennamen daherkommst?
-
@aschild der ist auch von hand eingegeben. Allerdings hatte ich auch schon einen Zustand bei dem die auswahl in der Gui funktioniert hat. Dort habe ich die Abfrage ja letztlich her. Und damals waren auch schon Umlaute drin.
bin einigermassen ratlos.
Ich habe gesehen (beim Reiter gruppen), dass es Probleme gibt, wenn eine Gruppenbezeichung runde Klammern enthält. Daraufhin habe ich die runden Klannern in den Gruppenbezeichungen entfernt. Hat aber leider nichts gebracht.
Nextcloud baut die Abfrage in eine Script namens
wizard.php
zusammen. Da kommt schon die fehlerhafte Abfrage zurück.Irgendwie sieht es schon so aus, als ob nextcloud die Gruppeninfo nicht richtig reinbkeommt, und daher die Ldap-Abfrage nicht korrekt konstruieren kann.
Vielleicht liegt es dan der Menge der Gruppen (183)
-
@aschild @Detmold-Nord ich habe mal etwas weiter rumprobiert, und festgestellt:
-
die Gruppenfelder werden wohl erst belebt, wenn man einmal die Benutzer in der NC-Instanz angezeigt hat
-
ich habe es mal mit einer anderen Nextcloud-Applikation (nur bei meiner privaten Instanz habe ich überhaupt zugriff auf die Logs) probiert. Dort sehe ich in den Logs
D.h. es ist entweder ein bug in Nextcloud oder im LDAPService von CT.
Auf jeden Fall sieht es so aus, als müsste ich die LDAP-filter von Hand bearbeiten. Da ich das irgendwann mal wieder übergeben möchte, scheidet das fast aus.
Also habe ich folgende Möglichkeiten:
-
ich verzichte auf die Intergration von Nextcloud via LDAP und lasse NC einfach separat administrieren
-
ich richte eine gruppe ein (RG Nextclouduser) und dort trage ich die Leute ein, für die auf NC ein Account eingerichtet werden soll. Damit bleibt das Userfilter dann konstant, auch wenn neue Gruppen hinzukommen. Dann muss man auf der NC-Seite nur noch die relevanten Gruppen eintragen damit diese auch in NC ankommen.
Das wäre natürlich besser, wenn man das alles auf der CT-Seite (als Gruppeneigenschaften) pflegen könnte.
Soweit hänge ich also noch immer etwas in den Seilen.
-
-
@aschild @Detmold-Nord könnt ihr mir weiter helfen?
Leider kommen ja auf LDAP/Nextcloud-Fragen relativ wenig Antworten. Einen neuen Thread wollte ich nicht aufmachen.
Ich habe festgestellt, dass auf Nextcloud Reste übrig bleiben, wenn man in CT einen Benutzer aus der synchronisation rausnimmt. Der Account kann sich zwar nicht mehr anmelden, wird aber im Suchfeld beim Share noch immer gefunden. Das ist für mich ein Datenschutzproblem.
Ich habe bislang leider auch keinen stabilen Weg gefunden diese Reste zu entfernen:
php occ ldap:show-remnants
zeigt die reste anphp occ user:delete "u123"
sollte den Rest eigentlich entfernen (lt. https://docs.nextcloud.com/server/20/admin_manual/configuration_user/user_auth_ldap_cleanup.html) tut es aber nicht.
Woanders habe ich gelesen, dass man mit phphmyadmin die Tabelle
oc_cards
leer machen soll. Das ist aber schon ein massiver Eingriff.Wir werden daher die LDAP-Nextcloud Verbindung zunächst wieder aufgeben. Daher versuche ich nur noch unserer Nextcloud wieder sauber zu kriegen.
-
@bwl21 Das löschen von nicht mehr existierenden Accounts in Nextcloud hatte ich noch gar nicht auf dem Radar...
Werden denn bei dir mit show-remnants welche angezeigt?
Wenn ja, und das user:delete nicht funktioniert, dann ist das wohl ein NC problem -
@aschild leider ist mir auf unserem Gemeinde-Nextcloud die
occ
nicht zugänglich Wir nutzen hier das (m.E. sehr attraktive) Angbot von Hetzner.Letztlich hat Hetzner uns alle unerwünschen Spuren gelöscht (toller Support).
Das ist auf jeden Fall ein NC Problem. Das liegt daran, dass die NC-LDAP-app die Daten auch in die Tabelle
oc_cards
reinschreibt, aber nicht wieder rauslöscht.das ist beschrieben in
- https://help.nextcloud.com/t/ldap-users-still-in-contact-search-field-after-disabling-ldap-configuration/32043 beschrieben.
- https://help.nextcloud.com/t/ldap-users-are-not-removed-from-oc-cards-when-removed-from-ldap/14678
ich finde aber keinen Issue-Report bei NC und sehe mich nicht in der Lage einen solchen zu schreibe.
m.E ist es aber auch auch ein Problem, dass CT zu viele Daten über LDAP ausgibt und man diese im LDAP-Client filtern muss. Und wenn man es da falsch macht (das. passiert leider schnell wenn man der Anleitung von CT folgt) hat man zu viele Daten übertragen.
Allein schon der LDAP-User über den die LDAP-Schnittstelle zugreift hat schon zu viele Berechtigungen ...Wie gesagt, wir verzichten daher zunächst auf LDAP. Ich habe daraus auch gelernt, keine Daten aus CT über Schnittstellen zu exportieren zu verwenden, die ich nicht selber genau kenne, beobachten und ggf. anpassen kann.
pS. da scheint es auch ein anderes Problem zu geben https://github.com/nextcloud/server/issues/28379, aber das habe ich nicht beobachtet.
-
@bwl21 Ja, Hetzner ist wirklich toll was den Support angeht (Und auch der Preis ist gut), wir sind da schon seit bald 20 Jahren Kunde für diverse Sachen
Der CT LDAP Server ist schon OK, der kann/muss ja mehr Daten herausgeben als du ev. verwendest, mit LDAP kann man ja noch anderes machen und dann benötigt man andere Felder.
Da der LDAP CT-Account ja alle User+ Gruppen sehen muss um zu funktionieren, benötigt der auch die entsprechenden Berechtigungen, da kommst du nicht drum herum. Ist ja auch nicht erin Konto welches man ans Anschlagsbrett heftet
-
Hallo zusammen, da ich durch diesen Thread es schon sehr weit geschafft habe mit CT, LDAP und Nextcloud (Storage Share bei Hetzner) dachte ich, ich versuche es mal hier um dem letzen Problem, das ich nicht behoben bekomme den Garaus zu machen: Ich finde alle Personen, die ich finden möchte, finde aber keine Gruppen. Alle Einstellungen habe ich eigentlich nach bestem Wissen und Gewissen aus diesem Thread für uns übernommen, aber ich kriege einfach keine Gruppen geladen...Nachfolgend Screenshots aus Nextcloud vpn allen Einstellungstabs und von den Rechten des LDAP Users in CT. CT gehostet bei CT, LDAP Service von CT, Nextcloud von Hetzner (Storage Share). Bin für jede Hilfe dankbar! Im ersten Screenshot wurde lediglich die Subdomain unsers CT ausgeblendet