Nochmal ldaps -- Abfragen auf Port 636 und 3269 (HowTo)

Hi.
Sorry, es reißt nicht ab … ich frage nochmal in einem neuen Thread und hoffe, dass jemand weiter weiß:

Wenn ich auf dem Server diese Abfrage starte:

 ldapsearch  -b "ou=default-school,ou=SCHOOLS,dc=linuxmuster,dc=meine-schule,dc=de" -H ldaps://server.linuxmuster.meine-schule.de:636 -x -D global-binduser@linuxmuster.meine-schule.de -w geheimesPasswort givenName=Michael

wird alles ohne Probleme durchgeführt.

Ersetze ich den Hostnamen aber gegen die IP 10.16.1.1, so erhalte ich:

"ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) .

Ich nehme an, dass da auch das Problem liegt, warum ich mit moodle keine Verbindung zum Samba-AD hinbekomme … habe aber keine gute Erklärung, denn
nslookup server liefert völlig richtig:

Server:         10.16.1.1
Address:        10.16.1.1#53

Name:   server.linuxmuster.meine-schule.de
Address: 10.16.1.1

Hat jemand eine Idee, warum das per IP nicht klappt? Hat das wieder mit irgendwelchen Zertifikaten zu tun, die nur mit FQDNs nicht aber mit IP-Adressen funktionieren???

Ach ja: Wenn ich den Befehl (mit Hostname anstelle der IP) von einem anderen Client im Servernetz ausführe, erscheint ebenfalls ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)steckt da evtl ein Firewall-Problem hinter?

:thinking:
Michael

Kaum schreibt man alles hin, stolpert man über einen Hinweis:

Ich habe wie dort vorgeschlagen die Option -d1 verwendet und sehe dann:

...
attempting to connect: 
connect success
TLS: peer cert untrusted or revoked (0x42)
TLS: can't connect: (unknown error code).
ldap_err2string

… und dann wird auch klar, warum die lokale Abfrage mit der IP-Adresse nicht mehr funktioniert:

TLS: hostname (10.16.1.1) does not match common name in certificate

Es dreht sich also offenbar um ein Zertifikatsproblem … daher nochmal in die Runde gefragt: Habt ihr auf dem v7 Server irgendwas an den Zertifikaten gemacht?

Ich hatte hier von der Firewall ein gültiges LE-Zertifikat nach /etc/linuxmuster/ssl/server.cert.bundle.pem kopiert – sonst aber mit den anderen Zertifikaten nichts gemacht oder geändert.

Erwartungsgemäß kommen übrigens Anfragen auf Port 389 an, also
einfach nur ldap://10.16.1.1 … will man aber nicht, oder??

Hallo Michael,

eine ldaps-Anfrage mit IP kann nur ohne Zertifikatsprüfung funktionieren, denn man bekommt ja kein Zertifikat für eine IP-Adresse.

Dass es (mit dem FQDN) vom Server, aber nicht von anderen Clients aus funktioniert, könnte eventuell daran liegen, dass der Ldap nur das Zertifikat selbst ausliefert, nicht jedoch die Kette bis zum Root-Zertifikat.

Beste Grüße

Jörg

Hallo Jörg … im Parallelthread kommen wir der Sache gerade auf die Spur. Eigentlich gehört das hierhin und nicht in den .htaccess-Thread …
ich X-verlinke das mal…

Und woran könnte das wiederum liegen? Bei anderen scheint die Abfrage auf Port 636 auch von extern ja keine Probleme zu bereiten?

@mdt … also ich habe alles so gemacht und den Server vorsichtshalber neu gestartet. Erreicht habe ich aber nichts, denn ich bekomme weiterhin von einem Client, der sich verbinden will:

connect success
TLS: peer cert untrusted or revoked (0x42)
TLS: can't connect: (unknown error code).
ldap_err2string

Auf Port 389 verbindet er sich aber … ich weiß leider weiterhin nicht, ob die Verbindung (zusammen mit kerberos) unverschlüsselt oder verschlüsselt ist bzw ob man nicht einfach alles auf 389 lassen kann und sich den ganzen Aufwand hier sparen kann???

Mit diesem Befehl teste ich solche Verbindungen:

echo -n | openssl s_client -CApath /etc/ssl/certs/ -connect <name>:443

Das steht der Pfad zu den Zertifikaten drin, wo du ja das Zertifikat hingelegt hast. Geht das? Was sagt er?

ja, das funktioniert. Auf Port 443 kommt das LE-Zertifikat (wie es sein soll) und auf 663 das eigene (self signed). Es bleibt aber bei der Fehlermeldung vom Client, wenn ich eine Abfrage auf 636 starte.

Sowohl 389 als auch 3268 machen vom Client aus keine Probleme. Kann jemand die Frage beantworten, ob das eine verschlüsselte Verbindung ist? Kerberos ist doch mit im Spiel!??!?

Holger (@baumhof): Hast du den ldapsearch-Befehl mal von einem Client aus probiert? Bei dir scheint das Problem ja nicht zu bestehen, da z.B. deine moodle-Anbindung an das AD über Port 636 zu laufen scheint?!?

Hallo Michael,

Holger (@baumhof https://ask.linuxmuster.net/u/baumhof): Hast du den
ldapsearch-Befehl mal von einem Client aus probiert? Bei dir scheint das
Problem ja nicht zu bestehen, da z.B. deine moodle-Anbindung an das AD
über Port 636 zu laufen scheint?!?

nein, hab ich glaube ich nicht.

Welchen Befehl soll ich den mal probieren?

Ja: bei mir geht es über Port 636

LG

Holger

Das ist höchst merkwürdig – oder kann es daran liegen, dass du für dein LAN und den Server darin keinen extern auflösbaren FQDN hast aber ich schon?

Jedenfalls ist der Fortschritt im Moment überaus zäh und für mich undurchsichtig zu deuten, wo es klemmt. Ich denke aber, dass ich das Problem soeben gelöst habe (bzw hatte @mdt bereits alle notwendigen Fakten aufgeschrieben; ich musste sie „nur“ nochmal für mich ordnen. Danke nochmal für die zahlreichen Tipps!!).

Also es ist so: Wenn ich auf dem Server selbst das hier mache:

ldapsearch  -b "ou=default-school,ou=SCHOOLS,dc=linuxmuster,dc=meine-schule,dc=de" -H ldaps://server.linuxmuster.meine-schule.de:636 -x -D global-binduser@linuxmuster.meine-schule.de -w geheimesPasswort givenName=Michael

klappt das alles; ganz egal, ob ich da ldap:// mit Port 389 oder 3268 oder aber ldaps:// mit Port 636 oder 3269 eingebe.

Das gleiche auf einem Client lief aber immer nur dann, wenn ich Port 389 oder 3268 verwendet habe. (Es ist dabei für mich immernoch unklar, wie so eine Verbindung in Kombination mit Kerberos aussieht?!? Ist das unverschlüsselt oder nicht?).

Immer, wenn ich von einem anderen Client (im Servernetz) die Ports 636 oder 3269 verwendet habe, gab es einen Zertifikatsfehler à la:
Can't contact LDAP server (-1) (mit der Option -d1 wird das genauer aufgeschlüsselt – dann steht da, dass es ein TLS-Fehler ist!)

Nun habe ich mir das Server-Zertifikat mit dem Befehl
echo -n | openssl s_client -CApath /etc/ssl/certs/ -connect server.linuxmuster.meine-schule.de:636
auf den Client kopiert und dann den Befehl nochmal abgesetzt mit einem vorangestellten:

LDAPTLS_CACERT=./mein-server-zertifikat.crt ldapsearch  -b "ou=default-school ....

Das war der entscheidende Hinweis, dann damt lief es plötzlich. @mdt hatte also die ganze Zeit völlig Recht: Das Server-Zertifikat war dem Client nicht bekannt.
Die richtige Vorgehensweise, wie man es dem Client bekannt macht, habe ich für Ubuntu dann hier gefunden:

For everything to work and not only your browser, you need to add that CA certificate to the system's trusted CA repository.
In ubuntu:
    * Go to /usr/local/share/ca-certificates/
    * Create a new folder, i.e. "sudo mkdir school"
    * Copy the .crt file into the school folder
    * Make sure the permissions are OK (755 for the folder, 644 for the file)
    * Run "sudo update-ca-certificates"

Danach lief der ldapseach-Befehl dann auch ohne das vorangestellte LDAPTLS_CACERT= endlich erfolgreich auf allen Ports; also auch endlich auf Port 636 und 3269 mit ldaps://

Ob moodle nun auch den Kontakt zum Server aufnimmt, teste ich aber heute nicht mehr … will das kleine Erfolgserlebnis nicht sofort wieder zunichte machen :slight_smile:

Also dann – diese Vorgehensweise betrifft sicher noch andere, die ihrem Server einen FQDN spendiert haben und sich über Zertifikatsmeldungen (die man ggf auf den ersten Blick nicht als solche identifiziert…?!) wundern. Ich ändere den Betreff wieder zu (HowTo) und markiere es (vorerst?) als gelöst.

Schöne Grüße,
Michael

P.S.: die Option LDAPVerifyServerCert Off habe ich im apache2 nun natürlich auch wieder deaktiviert! :+1:

Das ist genau, was ich gesagt habe :wink: Das gilt nicht allein für Ubuntu sondern für Debian und alle Debian-Derivate…

Ja alles richtig, ich hatte das Zertifikat anfangs einfach an die ca-certificates.crt selbst angehängt (& Neustart) … das war scheinbar nicht genug?

Bin froh, dass das schon mal klappt – und wäre es noch mehr, wenn damit auch die moodle-LDAP(S)-Anmeldung klappt. Es hat mich gewundert, dass Moodle nicht über Port 389 wollte, ldapsearch aber schon?!?
Morgen weiß ich mehr – danke nochmal. Hätte ich selbst nicht erraten :+1:

Es scheint drei Methoden zu geben:

  • Die .pem-Datei,
  • Die .0 Datei mit dem Namen das Hashes des Zertifikats
  • Die Zusammenfassung aller Zertifikate

ldapsearch nutzt die Zusammenfassung in /etc/ssl/certs/ca-certificates.crt.

Ein moodle-Screenshot sagt mehr als tausend Worte :+1: :

Prima!

Und nun alles von vorn mit dem offiziellen LE-Zertifikat!

:smiley: :smiley: :smiley:

… das habe ich mir bisher gespart, weil das LE-Zert ja eigentlich von der OPNSense-FW verwaltet werden soll und ich eigentlich auf das Hin- und Herkopieren der .crt verzichten wollte. :scream:

Wenn’s nicht anders geht - ok!? Aber wenn’s auch so läuft? Wo ist der zusätzliche Vorteil?

Dass alle weiteren Clients das self-signed Zertifikat nicht brauchen… aber zusätzliche Clients (Rechner, nicht Dienste) gibt es nicht, oder?

…ist noch nicht 100%ig klar, welche Clients sich eines Tages alle in der DMZ tummeln … evtl hosten wir die Nextcloud auch bei uns (mit dem Vorteil, dass dann Home_auf_Server einfach(er) einbindbar ist)

Hier eine Antwort unter

Wenn man versucht ldbsearch mit SSL und Kerbereos zu benützen, bekommt man die Fehlermeldung…

https://www.tech-island.com/tutorials/samba-active-directory-server#ldbsearch_funktioniert_nicht_mit_SSL_und_kereros