ich habe gerade einen externen Nextcloud-Server aufgesetzt, der per LDAP angebunden werden soll. Ich habe mich dabei an die Anleitung “Benutzerdaten für ownCloud aus LDAP holen” aus dem Wiki gehalten (http://www.linuxmuster.net/wiki/anwenderwiki:owncloud:basics:benutzer_aus_ldap).
Im Moment klappt es, dass ich alle Benutzer aus dem LDAP bei den “Benutzern” sehe, auch die passenden Gruppen sind zu sehen.
Ich hänge bei der Anleitung kurz vor den Optimierungen beim Punkt “Testweise einen Benutzer anmelden”. Das klappt bei mir nicht. Ich bin sicher, dass ich ein korrektes Passwort habe und den Benutzer korrekt geschrieben habe.
Ich bekomme bei der Anmeldeseite die Fehlermeldung “Falsches Passwort”. Mit dem lokalen Administrations-Account klappt der Login, klar.
Der Fehler wird in Nextcloud auch protokolliert:
user_ldap Bind failed: 49: Invalid credentials
core Login failed: ‘meinname’ (Remote IP: ‘XXX.XXX.XXX.XXX’)
Ich habe die LDAP-Einstellungen in Nextcloud noch einmal neu eingegeben und überprüft, das Problem besteht weiter.
Hat jemand ein ähnliches Problem schon einmal gelöst? Ich habe auch versucht log-Einträge auf dem linuxmuster-Server zu finden. Gibt es solche? Ich hatte nichts gefunden…
standardmäßig ist in der lmn 6.2 kein Bind-Nutzer eingerichtet, da der LDAP ohnehin auch anonyme Abfragen zulässt. Du kannst m.E. als BindUser testweise einen beliebigen Nutzer verwenden.
Hast du denn ein anderes System, das von extern auf den LDAP zugreift? Dann läge der Fehler tatsächlich bei der Owncloud, sonst gibt es viele Fehlerquellen: Router, Firewall und Server müssen für den Zugriff von extern konfiguriert sein.
ich habe mal den LDAP-Admin mit Passwort eingetragen (habe noch 6.1; Daten aus slapd.conf). Ein beliebiger Nutzer hat keine Zugriff, das gibt eine Fehlermeldung.
Am Problem änderte das jedoch nicht, ich hatte ja auch anonym Zugriff auf alle LDAP-Daten. Ein weiteres externes System habe ich momentan nicht, das auf die Daten zugreift…
Warum nur die Passwortabfrage scheitert verstehe ich nicht, dies sollte eigentlich nicht auf die Firewall o.ä. zurückzuführen sein, oder?
ich habe mal den LDAP-Admin mit Passwort eingetragen (habe noch 6.1;
Daten aus slapd.conf). Ein beliebiger Nutzer hat keine Zugriff, das gibt
eine Fehlermeldung.
da muss ein beliebiger Nutzer aus dem LDAP rein.
Ich weiß nicht, ob das nötig ist: aber so habe ich es in meinen
Nextclouds eingerichtet.
Nutzer so angeben:
uid=,ou=accounts,dc=linuxmuster,dc=local
Und natürlich dessen Passwort.
Domäne (server.linuxmuster.lokal) => dc=linuxmuster,dc=lokal
Den Nutzer test habe ich angelegt (als Lehrer), er hat ein Passwort das ich sicher kenne. Sobald ich einen anderen Namen als den ldap-Admin angebe, gibt es die Meldung, dass die Konfiguration nicht korrekt sei.
Ich hänge mal ein Bild an. Anonym ist alles ok.
oft werden LDAP-Probleme durch hakelige Zertifikate verursacht, z. B. weil sie selbstsigniert sind oder dem Client die Zertifikatskette nicht vollständig bekannt ist.
Es ist deshalb einen Versuch wert, es erst mal unverschlüsselt zu versuchen, um das Problem einzugrenzen
oft werden LDAP-Probleme durch hakelige Zertifikate verursacht, z. B.
weil sie selbstsigniert sind oder dem Client die Zertifikatskette nicht
vollständig bekannt ist.
Es ist deshalb einen Versuch wert, es erst mal unverschlüsselt zu
versuchen, um das Problem einzugrenzen
bei ihm läuft es unverschlüsselt…
Wenn man da umstellt, so muss man dran denken, dass verschlüsselt und
unverschlüsselt jeweils andere Ports benötigt.
ich glaube mich zu erinnern, dass man dem LDAP auch sagen muss, dass die Nextcloud nachschauen darf. Kann das sein? Obwohl das seltsam wäre, da Du ja die User siehst…
das habe ich gemacht. Die IP ist drin. Wobei ich jetzt schon gar nicht mehr sicher bin, ob die IP korrekt ist. Ich habe einfach die IP des Servers aus dem roten Netz eigetragen, auf dem die Nextcloud läuft. Ist das korrekt? Wir haben auch noch eine feste IP, die habe ich auch noch ergänzt.
das habe ich gemacht. Die IP ist drin. Wobei ich jetzt schon gar nicht
mehr sicher bin, ob die IP korrekt ist. Ich habe einfach die IP des
Servers aus dem roten Netz eigetragen, auf dem die Nextcloud läuft. Ist
das korrekt? Wir haben auch noch eine feste IP, die habe ich auch noch
ergänzt.
… das kommt darauf an, wie die Anfrage läuft: also von eurem Router aus
direkt an den IPFire, oder über die Domain des Servers von außen an den
IPFire…
Je nach dem muss was anderes rein.
Aber erstmal:
stell sicher, dass der ldaps Port durch geht: Port 636 tcp
Das testest du von der Nextcloud aus, indem du mit telnet versuchst auf
den Port zu verbinden.
Schau das nach: es müßte etwa so aussehen
telnet 636
Schau auch in die Firewallconfig: ob da das Loch für 636 ist und schreib
BelWü sie sollen 636 im Cisco frei machen.
Und wegen: der slapd nimmt Verbindungen an oder nicht:
das konfiguriert man in der /etc/ldap/slapd.conf
Kommt die Anfrage per ldaps so sind annonyme Anfragen ohne weitere
Einträge in der Datei OK.
KOmmt sie nicht per ldaps, dann geht das erstmal nicht (is a
Securityfeature, not a Bug).
In der slapd.conf steht meine Nextcloud schon mal nicht drin.
Dann muss man nach dem Zertifikat schauen: es ist ein selbstsigniertes
(nehme ich an): vor allem: wenn du über eien 192.168.0.x IP an den
Server kommst: dann stimmt es auf keinen Fall (keine Zertifikate für IPs).
Also muss der php-ldap Modum auf der Nextcloud das Zertifikat trotzdem
akzeptieren: und das nimmt es, meine ich, aus der /etc/ldap/ldap.conf
auf dem Nextcloudserver.
Bei mir steht da drin:
TLS_REQCERT never
als letzte Zeile: vielleicht fehlt dir das noch …
ich taste mich weiter vor. Inzwischen habe ich mal einen Logdatei für den ldap erzeugen lassen. Ich habe dann versucht mich als Nutzer anzumelden. Teile der Logdatei davon sind (den Anmeldenamen habe ich durch MEINNAME ersetz):
ohne ldaps - Port 389 -WIE im Bild zuerst eingegeben
Jan 29 16:44:03 server slapd[5858]: conn=1018 fd=20 ACCEPT from IP=192.168.0.126:60274 (IP=0.0.0.0:389)
Jan 29 16:44:03 server slapd[5858]: conn=1018 op=0 BIND dn="" method=128
Jan 29 16:44:03 server slapd[5858]: conn=1018 op=0 RESULT tag=97 err=0 text=
Jan 29 16:44:03 server slapd[5858]: conn=1018 op=1 SRCH base="ou=accounts,dc=linuxmuster,dc=lokal" scope=2 deref=0 filter="(&(|(objectClass=posixAccount))(uid=MEINNAME))"
Jan 29 16:44:03 server slapd[5858]: conn=1018 op=1 SRCH attr=dn uid samaccountname memberof 1.1 mail displayname 1.1 jpegphoto thumbnailphoto
Jan 29 16:44:03 server slapd[5858]: conn=1018 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jan 29 16:44:03 server slapd[5858]: conn=1018 op=2 SRCH base="uid=MEINNAME,ou=accounts,dc=linuxmuster,dc=lokal" scope=0 deref=0 filter="(|(objectClass=posixAccount))"
Jan 29 16:44:03 server slapd[5858]: conn=1018 op=2 SRCH attr=1.1
Jan 29 16:44:03 server slapd[5858]: conn=1018 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jan 29 16:44:03 server slapd[5858]: conn=1019 fd=21 ACCEPT from IP=192.168.0.126:60275 (IP=0.0.0.0:389)
Jan 29 16:44:03 server slapd[5858]: conn=1019 op=0 BIND dn="uid=MEINNAME,ou=accounts,dc=linuxmuster,dc=lokal" method=128
Jan 29 16:44:03 server slapd[5858]: conn=1019 op=0 RESULT tag=97 err=49 text=
Jan 29 16:44:04 server slapd[5858]: conn=1019 op=1 UNBIND
Jan 29 16:44:04 server slapd[5858]: conn=1019 fd=21 closed
Jan 29 16:44:04 server slapd[5858]: conn=1018 op=3 UNBIND
Jan 29 16:44:04 server slapd[5858]: conn=1018 fd=20 closed
Jan 29 16:44:04 server slapd[5858]: conn=1020 fd=20 ACCEPT from IP=192.168.0.126:60276 (IP=0.0.0.0:389)
Jan 29 16:44:04 server slapd[5858]: conn=1020 op=0 BIND dn="" method=128
Jan 29 16:44:04 server slapd[5858]: conn=1020 op=0 RESULT tag=97 err=0 text=
Jan 29 16:44:04 server slapd[5858]: conn=1020 op=1 SRCH base="uid=MEINNAME,ou=accounts,dc=linuxmuster,dc=lokal" scope=0 deref=0 filter="(|(objectClass=posixAccount))"
Jan 29 16:44:04 server slapd[5858]: conn=1020 op=1 SRCH attr=1.1
Jan 29 16:44:04 server slapd[5858]: conn=1020 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
Jan 29 16:44:04 server slapd[5858]: conn=1020 op=2 UNBIND
Jan 29 16:44:04 server slapd[5858]: conn=1020 fd=20 closed
Danach Änderung auf ldaps - port 636
Jan 29 16:49:23 server slapd[5858]: conn=1033 fd=20 ACCEPT from IP=192.168.0.126:60292 (IP=0.0.0.0:636)
Jan 29 16:49:23 server slapd[5858]: conn=1033 fd=20 TLS established tls_ssf=256 ssf=256
Jan 29 16:49:23 server slapd[5858]: conn=1033 op=0 BIND dn="" method=128
Jan 29 16:49:23 server slapd[5858]: conn=1033 op=0 RESULT tag=97 err=0 text=
Jan 29 16:49:23 server slapd[5858]: conn=1033 op=1 SRCH base="dc=linuxmuster,dc=lokal" scope=2 deref=0 filter="(objectClass=*)"
Jan 29 16:49:23 server slapd[5858]: conn=1033 op=1 SRCH attr=dn
Jan 29 16:49:23 server slapd[5858]: conn=1033 op=1 SEARCH RESULT tag=101 err=0 nentries=500 text=
Jan 29 16:49:23 server slapd[5858]: conn=1033 op=2 SRCH base="dc=linuxmuster,dc=lokal" scope=2 deref=0 filter="(objectClass=*)"
Jan 29 16:49:23 server slapd[5858]: conn=1033 op=2 SRCH attr=dn
Jan 29 16:49:23 server slapd[5858]: conn=1033 op=2 SEARCH RESULT tag=101 err=0 nentries=408 text=
Jan 29 16:49:23 server slapd[5858]: conn=1033 op=3 UNBIND
Jan 29 16:49:23 server slapd[5858]: conn=1033 fd=20 closed
Jan 29 16:49:31 server slapd[5858]: conn=1034 fd=20 ACCEPT from IP=192.168.0.126:60293 (IP=0.0.0.0:636)
Jan 29 16:49:31 server slapd[5858]: conn=1034 fd=20 closed (TLS negotiation failure)
Jan 29 16:49:32 server slapd[5858]: conn=1035 fd=20 ACCEPT from IP=192.168.0.126:60294 (IP=0.0.0.0:636)
Jan 29 16:49:32 server slapd[5858]: conn=1035 fd=20 closed (TLS negotiation failure)
Das Verhalten war etwas seltsam. Zuerst kurz die grüne Anzeige für eine korrekte Konfiguration und auch die Meldung, dass x Datensätze gelesen wurden, danach gab es einen Fehler. Das sieht man auch an dem Log - ein TLS Fehler. Das sollte dann ein Zertifikat-Problem sein, oder?
Ich schaue jetzt noch in diese Richtung…
hallo tobias,
bei mir tut es ohne eintrag einer benutzer-dn. so wie es in der anleitung im wiki steht.
ich habe als eintrag beim server: ldaps://meine_feste_serverip_von_belwue und den port 636.
der eintrag für die base-dn ergibt sich aus grep BASE /etc/ldap/ldap.conf (auf dem linuxmuster-server).
ich fand, dass die einträge im ldap-frontend immer sehr zäh reagiert haben, so dass ich es effektiver fand, die komplette konfiguration über den mülleimer oben zu löschen und neu zu beginnen.
vg
wolfgang
wenn du LDAPS verwendest (und das Zertifikat auch verifiziert werden soll), sollte der Servername mit seinem FQDN angegeben werden und nicht über die IP. Dein Nextcloud-Server muss diesen FQDN aber auch auflösen können. Evtl. muss du dazu einen Eintrag in der /etc/hosts machen bzw. den DNS-Server anpassen.
BTW: Hat dein Linuxmuster-Server diese IP (192.168.0.21)? Sollte eigentlich sowas wie 10.16.1.1 o.ä. sein.
Schau auch mal hier (und den in diesem Link verlinkten anderen Beitrag). Dort gibt es ein paar Befehle, wie du LDAP(S) auf der Kommandozeile testen kannst. Wenn es dort klappt, dann klappt es auch im Webinterface von Nextcloud.
