LDAPs funktioniert nicht

fpgit

Hallo,
evtl. hat jemand einen Tipp. Wir möchten gern von LDAP auf LDAPs umstellen. CA-Zertifikat ist auf dem Server hinterlegt.
Leider liefert I-DOIT im Log und der Webseite nur folgende Info: LDAP Bind failed (Can't contact LDAP server). Host: x.x.x.x:636. User: CN=testldap

Auch gibt es keine ldap debug datei auf dem Server.
Danke

Michael Huhn

Hallo @fpgit,

wenn LDAPS verwendet wird muss der Hostname des LDAP Servers verwendet werden.
Dann sollte dieser natürlich auch zu einer IP zurückzuführen sein.

Mal die Fehlermeldung genau prüfen und vom i-doit Server aus einen Ping an den Hostnamen des LDAP senden.

Das logging von LDAP kann in i-doit unter Systemeinstellungen eingeschaltet werden.

mfg
Micha

A Former User

Hallo @fpgit,
ich wollte mal nachfragen, ob Du eine Lösung gefunden hast.
Ich stehe leider aktuell vor dem selben Problem, dass die Zertifikate korrekt eingespielt wurden (Erfolgreiche Verbindung über: openssl s_client -connect ldap.server.de:636)

Das Log ist über die Systemeinstellungen aktiviert jedoch wird mir dort wie auch in der GUI nur die Fehlermeldung:

Error!

LDAP Bind failed (Can't contact LDAP server). Host: ldap.server.de:636. User: CN=user,DC=ldap,DC=server,DC=de

bzw im ldap-Log:

 ldap.DEBUG: Testing connection to ldap.server.de:636 (CN=user,DC=ldap,DC=server,DC=de) [] []

Wie @Michael-Overkamp vorgeschlagen hat, ist der LDAP Server vom i-doit Server sowohl über IP, Alias als auch Hostname per Ping erreichbar.

MfG
Nico

Philipp Hörselmann

Moin @nschäfer
in welchem Format liegt dein Zertifikat genau vor?
Ist bei dir vielleicht noch zusätzlich IPv6 aktiviert? Uns fiel auf, dass es manchmal auch zu Problemen bedingt durch IPv6 bzgl. LDAPS kommt.

Viele Grüße
Phil

A Former User

Hallo Phil,

danke für die Rückmeldung!
Ich habe zum Test IPv6 auf dem Server (i-doit) deaktivert und noch einmal getestet. Leider mit dem selben Ergebnis....

Das Zertifikat wurde als Standard PEM mit Dateiendung .crt auf dem Server (Ubuntu 18) im Verzeichnis /usr/local/share/ca-certificates abgelegt und über update-ca-certificates hinzugefügt.

Auf einem anderen Server (zabbix Monitoring; ebenfalls Ubuntu 18) war dieses Vorgehen mit dem selben Zertifikat aussreichend, um LDAPS zu ermöglichen.

Grüße,
Nico

Michael Huhn

Moin @nschäfer,

bisher habe ich folgende Lösungen von Kunden erhalten:

Viele Nutzer haben schlichtweg das Zertifikat nicht oder nicht richtig importiert.
Oder es wurde nicht der Hostname aus dem Zertifikat angegeben.
Der Hostname kann nicht aufgelöst werden.
Ein Kunde konnte mit Wireshark das Problem finden. Mit IPv4 klappte die Zertifikatsprüfung, mit IPv6 nicht. Nachdem IPv6 auf dem Linux deaktiviert wurde war das Problem gelöst.

Mögliche Lösung bei mehreren Domain Controllern:

...bei LDAP gibt es seitens der Active Directory Domain Controller zunächst nicht viel zu beachten:

Es wird ein Zertifikat benötigt, das bestimmte Anforderungen erfüllt (https://support.microsoft.com/en-us/help/321051/how-to-enable-ldap-over-ssl-with-a-third-party-certification-authority)

Es sollte möglichst nur ein Zertifikat für diese Zwecke auf einem DC vorhanden sein (wird interessant, wenn bereits eins für Kerberos-Authentifizierung vorhanden ist – was unter Sicherheitsaspekten vermutlich überall der Fall ist

Eine verschlüsselte Verbindung kann gegen AD per LDAPS (TLS/SSL schon bei Verbindungsaufbau) oder STARTTLS (explizites Kommando zum Anfang der Verbindung) erfolgen

Es ist ein Gemenge von Client und Server-Einstellungen (Links weiter unten), wenn LDAP Channel Binding und LDAP Signing berücksichtigt wird; nicht jedes System (Linux) unterstützt out oft he box alle Optionen.

Linkservice

https://support.microsoft.com/en-us/help/4520412/2020-ldap-channel-binding-and-ldap-signing-requirements-for-windows
https://support.microsoft.com/en-us/help/935834/how-to-enable-ldap-signing-in-windows-server
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/ldap-channel-binding-and-ldap-signing-requirements-march-2020/ba-p/921536#
https://support.microsoft.com/en-in/help/4034879/how-to-add-the-ldapenforcechannelbinding-registry-entry

Vielleicht können Sie die Schritte die MS zur Problemlösung empfiehlt durchgehen? Hier wäre ein Link.
Wenn Sie das Problem gefunden haben wäre ich für eine Information, wie genau das Problem gelöst wurde, dankbar.

A Former User

Hallo @Michael-Overkamp,

danke für die ausführliche Linksammlung

Du kannst in die Liste der Möglichen Fehlerursachen auch die Zertifikatsverschlüsselung mit aufnehmen.
Wir erstellen unsere Zertifikate nicht selber, sondern bekommen diese von unserem Rechenzentrum bereitgestellt. Diese sind leider mit SHA-1 verschlüsselt worden und deshalb wurde die Verbindung abgelehnt.

...
signed using RSA-SHA1 (broken!)
...
Status: The certificate is NOT trusted. The certificate chain uses insecure algorithm.

Falls noch jemand anderes über diesen Punkt stolpern sollte:
Mir haben die gnutls-cli weiter geholfen. Mit folgendem Befehl habe ich eine aussagekräftigere Fehlermeldung bekommen können.

gnutls-cli --print-cert -p 636 --x509cafile /etc/ssl/certs/ca-certificates.crt ldap.server.de

Danke für die Unterstützung!

Viele Grüße,
Nico