8
LDAPS-Verbindung funktioniert nur sporadisch
Hallo zusammen,
ich möchte mittels PHP per LDAPS auf meinen Windows-Domain-Controller zugreifen, konkret mit den Anwendungen Nextcloud und WordPress. Ich habe nun das Problem, dass die Verbindungen sporadisch nicht aufgebaut werden können, d. h., manchmal funktioniert eine Abfrage, oft aber auch nicht. Konkret kann laut Fehlermeldung oftmals keine Verbindung zum DC aufgebaut werden ("Can't contact LDAP server"). Nutze ich hingegen eine LDAP-Verbindung, so funktioniert alles ohne Aussetzer.
Das öffentliche Zertifikat des DC / der Zertifizierungsstelle habe ich in der Linux-Maschine gespeichert und auch einen Verweis in der /etc/ldap/ldap.conf gesetzt:
Habt ihr einen Tipp, wo das Problem liegen könnte?
Viele Grüße
Michael
ich möchte mittels PHP per LDAPS auf meinen Windows-Domain-Controller zugreifen, konkret mit den Anwendungen Nextcloud und WordPress. Ich habe nun das Problem, dass die Verbindungen sporadisch nicht aufgebaut werden können, d. h., manchmal funktioniert eine Abfrage, oft aber auch nicht. Konkret kann laut Fehlermeldung oftmals keine Verbindung zum DC aufgebaut werden ("Can't contact LDAP server"). Nutze ich hingegen eine LDAP-Verbindung, so funktioniert alles ohne Aussetzer.
Das öffentliche Zertifikat des DC / der Zertifizierungsstelle habe ich in der Linux-Maschine gespeichert und auch einen Verweis in der /etc/ldap/ldap.conf gesetzt:
TLS_CACERT /etc/ssl/certs/cert-ca.crtHabt ihr einen Tipp, wo das Problem liegen könnte?
Viele Grüße
Michael
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 610841
Url: https://administrator.de/contentid/610841
Ausgedruckt am: 25.11.2024 um 17:11 Uhr
8 Kommentare
Neuester Kommentar
Moin,
Dann ist die Konfiguration soweit korrekt. Wäre sie es nicht, würde es nie funktionieren.
Es kommt offensichtlich zu einem Timeout. Entweder antwortet der LDAP-Server nicht schnell genug oder der PHP-Server wartet nicht lange genug. Ich würde da erst einmal auf den LDAP-Server tippen. Wie sehen denn die Abfragen aus?
Wie meinst Du das? Von wo aus nutzt Du wie eine LDAP-Verbindung womit?
Liebe Grüße
Erik
Zitat von @m8ichael:
ich möchte mittels PHP per LDAPS auf meinen Windows-Domain-Controller zugreifen, konkret mit den Anwendungen Nextcloud und WordPress. Ich habe nun das Problem, dass die Verbindungen sporadisch nicht aufgebaut werden können, d. h., manchmal funktioniert eine Abfrage, oft aber auch nicht.
ich möchte mittels PHP per LDAPS auf meinen Windows-Domain-Controller zugreifen, konkret mit den Anwendungen Nextcloud und WordPress. Ich habe nun das Problem, dass die Verbindungen sporadisch nicht aufgebaut werden können, d. h., manchmal funktioniert eine Abfrage, oft aber auch nicht.
Dann ist die Konfiguration soweit korrekt. Wäre sie es nicht, würde es nie funktionieren.
Konkret kann laut Fehlermeldung oftmals keine Verbindung zum DC aufgebaut werden ("Can't contact LDAP server").
Es kommt offensichtlich zu einem Timeout. Entweder antwortet der LDAP-Server nicht schnell genug oder der PHP-Server wartet nicht lange genug. Ich würde da erst einmal auf den LDAP-Server tippen. Wie sehen denn die Abfragen aus?
Nutze ich hingegen eine LDAP-Verbindung, so funktioniert alles ohne Aussetzer.
Wie meinst Du das? Von wo aus nutzt Du wie eine LDAP-Verbindung womit?
Liebe Grüße
Erik
Moin!
Es kommt offensichtlich zu einem Timeout. Entweder antwortet der LDAP-Server nicht schnell genug oder der PHP-Server wartet nicht lange genug. Ich würde da erst einmal auf den LDAP-Server tippen. Wie sehen denn die Abfragen aus?
Ganz simple Nutzerabfragen zur Authentifizierung über die OU Benutzer im ActiveDirectory.
Wie meinst Du das? Von wo aus nutzt Du wie eine LDAP-Verbindung womit?
Sorry, etwas unkonkret beschrieben; Ich meinte natürlich eine unverschlüsselte Verbindung, exakt gleiches Szenario und dieselben Maschinen. Hier dann nie Probleme.
Viele Grüße
Michael
Konkret kann laut Fehlermeldung oftmals keine Verbindung zum DC aufgebaut werden ("Can't contact LDAP server").
Es kommt offensichtlich zu einem Timeout. Entweder antwortet der LDAP-Server nicht schnell genug oder der PHP-Server wartet nicht lange genug. Ich würde da erst einmal auf den LDAP-Server tippen. Wie sehen denn die Abfragen aus?
Ganz simple Nutzerabfragen zur Authentifizierung über die OU Benutzer im ActiveDirectory.
Nutze ich hingegen eine LDAP-Verbindung, so funktioniert alles ohne Aussetzer.
Wie meinst Du das? Von wo aus nutzt Du wie eine LDAP-Verbindung womit?
Sorry, etwas unkonkret beschrieben; Ich meinte natürlich eine unverschlüsselte Verbindung, exakt gleiches Szenario und dieselben Maschinen. Hier dann nie Probleme.
Viele Grüße
Michael
ich möchte mittels PHP per LDAPS auf meinen Windows-Domain-Controller zugreifen, konkret mit den Anwendungen Nextcloud und WordPress. Ich habe nun das Problem, dass die Verbindungen sporadisch nicht aufgebaut werden können, d. h., manchmal funktioniert eine Abfrage, oft aber auch nicht. Konkret kann laut Fehlermeldung oftmals keine Verbindung zum DC aufgebaut werden ("Can't contact LDAP server"). Nutze ich hingegen eine LDAP-Verbindung, so funktioniert alles ohne Aussetzer.
Hat das Monitoring auf dem angefragten System Erkenntnisse gebracht?
Hi,
wie adressierst Du die Quelle? Über Name oder IP-Adresse eines DC's oder über den Domänen-FQDN ?
Falls Domänen-FQDN:
Stehen in der DNS-Zone eventuell noch alte Server drin mit einem A-Record ohne Namen? ("identisch mit übergeordnetem Ordner")
Oder andere, welche z.B. auf Web-Server o.ä. verweisen, welche z.B. unter http://domänenFQD Sites hosten?
Falls über Servername oder IP-Adresse:
Wenn es mal geht und mal nicht, dann wären ja Zertifikatsprobleme auszuschließen. Dann würde ich mal in Richtung Netzwerk forschen.
E.
wie adressierst Du die Quelle? Über Name oder IP-Adresse eines DC's oder über den Domänen-FQDN ?
Falls Domänen-FQDN:
Stehen in der DNS-Zone eventuell noch alte Server drin mit einem A-Record ohne Namen? ("identisch mit übergeordnetem Ordner")
Oder andere, welche z.B. auf Web-Server o.ä. verweisen, welche z.B. unter http://domänenFQD Sites hosten?
Falls über Servername oder IP-Adresse:
Wenn es mal geht und mal nicht, dann wären ja Zertifikatsprobleme auszuschließen. Dann würde ich mal in Richtung Netzwerk forschen.
E.
Moin,
Ich wollte eigentlich wissen, wie der query string aussieht. Also Quellcode.
Du kannst ja User mit John Smith und Domain mit acme.com ersetzen.
Sorry, etwas unkonkret beschrieben; Ich meinte natürlich eine unverschlüsselte Verbindung, exakt gleiches Szenario und dieselben Maschinen. Hier dann nie Probleme.
Ohja. Das ist eine entscheidende Information. Wenn Du unverschlüsselt verbindest geht's immer, wenn nicht, dann manchmal nicht? Wenn ich das richtig verstanden habe, dann ist das der einzige Unterschied. Womit wird verschlüsselt? Aus PHP und Webanwendung schließe ich mal https. Was sagen denn die Logs von PHP und des Webservers dazu? Auf welchem BS laufen denn die Webanwendungen? Auf was für einem Server (hosted, managed oder einfaches Webhosting ohne eigenen Server)? Achja, was sagen die Logs des DC zu dem Thema?
Liebe Grüße
Erik
Zitat von @m8ichael:
Ganz simple Nutzerabfragen zur Authentifizierung über die OU Benutzer im ActiveDirectory.
Es kommt offensichtlich zu einem Timeout. Entweder antwortet der LDAP-Server nicht schnell genug oder der PHP-Server wartet nicht lange genug. Ich würde da erst einmal auf den LDAP-Server tippen. Wie sehen denn die Abfragen aus?
Ganz simple Nutzerabfragen zur Authentifizierung über die OU Benutzer im ActiveDirectory.
Ich wollte eigentlich wissen, wie der query string aussieht. Also Quellcode.
Du kannst ja User mit John Smith und Domain mit acme.com ersetzen.Wie meinst Du das? Von wo aus nutzt Du wie eine LDAP-Verbindung womit?
Sorry, etwas unkonkret beschrieben; Ich meinte natürlich eine unverschlüsselte Verbindung, exakt gleiches Szenario und dieselben Maschinen. Hier dann nie Probleme.
Ohja. Das ist eine entscheidende Information. Wenn Du unverschlüsselt verbindest geht's immer, wenn nicht, dann manchmal nicht? Wenn ich das richtig verstanden habe, dann ist das der einzige Unterschied. Womit wird verschlüsselt? Aus PHP und Webanwendung schließe ich mal https. Was sagen denn die Logs von PHP und des Webservers dazu? Auf welchem BS laufen denn die Webanwendungen? Auf was für einem Server (hosted, managed oder einfaches Webhosting ohne eigenen Server)? Achja, was sagen die Logs des DC zu dem Thema?
Liebe Grüße
Erik
Hi,
sorry, war nen Tag ausgefallen...
Es handelt sich jeweils um eigene Server. Der DC ist ein Windows Server 2012R2 und wird direkt per IP angesprochen, um Fehler in der Namensauflösung auszuschließen; das anfragende System ein Ubuntu (18.04) mit aktuellem LAMP. Die Logs des DC beinhalten tatsächlich nen Fehler (also wenn der Fehler auftritt):
bzw.
Nach dieser Aktion schließt dann der DC offenbar die Verbindung, denn auf dem anfragenden System erhalte ich dann maximal die lapidare Meldung
Weitere Fehler sind hierzu nicht in den Logs auf der Ubuntu-Maschine enthalten.
Offenbar kann der DC nicht immer etwas mit den verschlüsselten Daten anfangen bzw. diese dekodieren. Blöd ist halt, dass es manchmal klappt...
Viele Grüße
Michael
sorry, war nen Tag ausgefallen...
Zitat von @erikro:
Ohja. Das ist eine entscheidende Information. Wenn Du unverschlüsselt verbindest geht's immer, wenn nicht, dann manchmal nicht? Wenn ich das richtig verstanden habe, dann ist das der einzige Unterschied. Womit wird verschlüsselt? Aus PHP und Webanwendung schließe ich mal https. Was sagen denn die Logs von PHP und des Webservers dazu? Auf welchem BS laufen denn die Webanwendungen? Auf was für einem Server (hosted, managed oder einfaches Webhosting ohne eigenen Server)? Achja, was sagen die Logs des DC zu dem Thema?
Ohja. Das ist eine entscheidende Information. Wenn Du unverschlüsselt verbindest geht's immer, wenn nicht, dann manchmal nicht? Wenn ich das richtig verstanden habe, dann ist das der einzige Unterschied. Womit wird verschlüsselt? Aus PHP und Webanwendung schließe ich mal https. Was sagen denn die Logs von PHP und des Webservers dazu? Auf welchem BS laufen denn die Webanwendungen? Auf was für einem Server (hosted, managed oder einfaches Webhosting ohne eigenen Server)? Achja, was sagen die Logs des DC zu dem Thema?
Es handelt sich jeweils um eigene Server. Der DC ist ein Windows Server 2012R2 und wird direkt per IP angesprochen, um Fehler in der Namensauflösung auszuschließen; das anfragende System ein Ubuntu (18.04) mit aktuellem LAMP. Die Logs des DC beinhalten tatsächlich nen Fehler (also wenn der Fehler auftritt):
00000057: LdapErr: DSID-0C0C0095, comment: Error decoding ldap message, data 0, v2580bzw.
Falscher ParameterNach dieser Aktion schließt dann der DC offenbar die Verbindung, denn auf dem anfragenden System erhalte ich dann maximal die lapidare Meldung
Connection to server ... lostWeitere Fehler sind hierzu nicht in den Logs auf der Ubuntu-Maschine enthalten.
Offenbar kann der DC nicht immer etwas mit den verschlüsselten Daten anfangen bzw. diese dekodieren. Blöd ist halt, dass es manchmal klappt...
Viele Grüße
Michael
Noch einen Nachtrag:
Ja, per TLS über den Port 636 (ldaps://...).
Zitat von @erikro:
Wenn Du unverschlüsselt verbindest geht's immer, wenn nicht, dann manchmal nicht? Wenn ich das richtig verstanden habe, dann ist das der einzige Unterschied. Womit wird verschlüsselt? Aus PHP und Webanwendung schließe ich mal https.
Wenn Du unverschlüsselt verbindest geht's immer, wenn nicht, dann manchmal nicht? Wenn ich das richtig verstanden habe, dann ist das der einzige Unterschied. Womit wird verschlüsselt? Aus PHP und Webanwendung schließe ich mal https.
Ja, per TLS über den Port 636 (ldaps://...).
Hallo,
hatte dasselbe Problem und konnte es lösen.
Client-OS ist Debian 11. Was genau auf dem Server läuft, weiß ich nicht. Irgendso'n Windows.
Das wichtige hier ist maxssf. Siehe slapd.conf(5) für ne Beschreibung was der Parameter bedeutet. Der ließe sich auch per ldap_set_opt / LDAP_OPT_X_SASL_SSF_MAX setzen, aber das ist im PHP-Modul nicht drinne. Code-Änderung wäre aber straightforward.
Wenn man sich das im wireshark anschaut, sieht man dass ursprünglich im TLS-Stream (der ja bereits verschlüsselt ist) zusätzlich die Applikations-Daten nochmal mit GSS-Methoden verschlüsselt sind. Scheinbar verhaspelt sich dort Client oder Server, wenn man das zusammen mit TLS macht.
Alle Werte kleiner/gleich 256 gehen bei mir. Vermutlich ist "0" auch ok, die Sicherheit wird ja schon durch TLS gewährleistet.
hatte dasselbe Problem und konnte es lösen.
Client-OS ist Debian 11. Was genau auf dem Server läuft, weiß ich nicht. Irgendso'n Windows.
<?php
$ldap = ldap_connect("ldaps://adserver1.example.net/");
ldap_set_option($ldap, LDAP_OPT_X_SASL_NOCANON, true);
ldap_set_option($ldap, LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($ldap, LDAP_OPT_X_TLS_CACERTFILE, "/usr/local/share/ca-certificates/example/example-ca.crt");
ldap_sasl_bind($ldap, null, null, "GSSAPI", null, null, null, "maxssf=256");
$result = ldap_search($ldap, 'DC=example,DC=net', '(sAMAccountName=Wulf4096)');
var_dump(ldap_get_entries($ldap, $result));Das wichtige hier ist maxssf. Siehe slapd.conf(5) für ne Beschreibung was der Parameter bedeutet. Der ließe sich auch per ldap_set_opt / LDAP_OPT_X_SASL_SSF_MAX setzen, aber das ist im PHP-Modul nicht drinne. Code-Änderung wäre aber straightforward.
Wenn man sich das im wireshark anschaut, sieht man dass ursprünglich im TLS-Stream (der ja bereits verschlüsselt ist) zusätzlich die Applikations-Daten nochmal mit GSS-Methoden verschlüsselt sind. Scheinbar verhaspelt sich dort Client oder Server, wenn man das zusammen mit TLS macht.
Alle Werte kleiner/gleich 256 gehen bei mir. Vermutlich ist "0" auch ok, die Sicherheit wird ja schon durch TLS gewährleistet.
