LDAP extern: bind geht, auth nicht - update eines slapd-Pakets?

Wir haben 6.2 (babo) installiert und konnten bis zu einem Zeitpunkt x die externe Authentifizierung nutzen (u.A. von einem PHP-Skript aus, hier mit alter PHP-Version 7.0). Seit Zeitpunkt x (leider unbekannt, weil nicht gemonitored, inrgendwann innerhalb der letzten sechs Monate?) geht es nicht mehr. Jetzt wollten wir gerne die aktuelle Nextcloud-Version anschließen (18.0.3, auf php7.4) und selbige verheddert sich dermaßen mit LDAP, dass gar nix mehr geht (tatsächlich bis zum PHP-Timeout von 30 Sekunden).
ldapsearch auf der Konsole des NC-Servers gegen den lmn: geht, ich kann mich per ldaps anonym mit dem Server verbinden (bind?), der wirft mir dann entweder alle user aus oder den zum Filter passenden (z.B. Pumuckel).
Was auch auf der Konsole nicht geht: auth. Wenn ich mit -W ein Passwort abfragen lasse, dann meckert ldapsearch über wrong credentials.
Da es mit zwei verschiedenen PHP-Versionen (von zwei verschiedenen Servern aus) nicht geht, erscheint es mir naheliegend, dass auf slapd-Seite etwas geändert wurde - weiß jemand™ etwas?
VG
Kai

Hallo Kai,

habt ihr ein selbst signiertes Zertifikat für ldaps? Habt ihr vielleicht auf dem alten System (php 7.0) die Zertifikatsprüfung abgeschaltet udn unter den neuen Bednigungen (php 7.4) nicht mehr?

Grüße,
Sven

falls es mit dem cert zusammenhängt … das hatten wir vor einiger Zeit mal hier diskutiert:

Nein, es ist (wie vorher auch) ein wildcard-cert von Let’s encrypt, welches für die gesamte interne Subdomain gilt, also *.lan.meineschule.de.
Es wird mit openssl s_client -connect 631 getestet und für gut befunden, soweit ich das beurteilen kann.

ich denke, das sollte 636 heißen (typo)? 631 ist cups …

Das müsste aber funktionieren! Du kannst den Schalter -d1 verwenden. Guck mal hier:

Jo, 636 ist natürlich richtig, war Typo.
Mit meinem bescheidenen Wissen würde ich meinen, dass ein Zertifikatsproblem eine diesbezügliche Fehlermeldung werfen würde, oder?
root@meinecloud:~# ldapsearch -x -D ‚uid=pumuckel,ou=accounts,dc=lan,dc=meine-domain,dc=de‘ -W -H ldaps://alterstsserver.lan.meine-domain.de -b ou=accounts,dc=lan,dc=meine-domain,dc=de uid=pumuckel -d1
ldap_url_parse_ext(ldaps://alterstsserver.lan.meine-domain.de)
ldap_create
ldap_url_parse_ext(ldaps://alterstsserver.lan.meine-domain.de:636/??base)
Enter LDAP Password:
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP alterstsserver.lan.meine-domain.de:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 10.15.2.131:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
attempting to connect:
connect success
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({i) ber:
ber_flush2: 83 bytes to sd 3
ldap_result ld 0x55dc871f7d10 msgid 1
wait4msg ld 0x55dc871f7d10 msgid 1 (infinite timeout)
wait4msg continue ld 0x55dc871f7d10 msgid 1 all 1
** ld 0x55dc871f7d10 Connections:

** ld 0x55dc871f7d10 Outstanding Requests:

  • msgid 1, origid 1, status InProgress
    outstanding referrals 0, parent count 0
    ld 0x55dc871f7d10 request count 1 (abandoned 0)
    ** ld 0x55dc871f7d10 Response Queue:
    Empty
    ld 0x55dc871f7d10 response count 0
    ldap_chkResponseList ld 0x55dc871f7d10 msgid 1 all 1
    ldap_chkResponseList returns ld 0x55dc871f7d10 NULL
    ldap_int_select
    read1msg: ld 0x55dc871f7d10 msgid 1 all 1
    ber_get_next
    ber_get_next: tag 0x30 len 12 contents:
    read1msg: ld 0x55dc871f7d10 msgid 1 message type bind
    ber_scanf fmt ({eAA) ber:
    read1msg: ld 0x55dc871f7d10 0 new referrals
    read1msg: mark request completed, ld 0x55dc871f7d10 msgid 1
    request done: ld 0x55dc871f7d10 msgid 1
    res_errno: 49, res_error: <>, res_matched: <>
    ldap_free_request (origid 1, msgid 1)
    ldap_parse_result
    ber_scanf fmt ({iAA) ber:
    ber_scanf fmt (}) ber:
    ldap_msgfree
    ldap_err2string
    ldap_bind: Invalid credentials (49)
    ldap_free_connection 1 1
    ldap_send_unbind
    ber_flush2: 7 bytes to sd 3
    ldap_free_connection: actually freed

Die Software ist mir hier über, mehrzeilige Codeblöcke werden offenbar von markdown gesprengt :-/ Sorry!

hast du den Teil in [ code] und [ /code] eingeschlossen? Dann müsste es eigentlich richtig dargestellt werden…
Zur Lösung des Problems weiß ich nun leider auch nicht mehr weiter … es sieht alles richtig aus, meine ich!??

Hallo Kai,

auf der Clientseite fällt mir hier nichts auf. Hast Du mal einen Blick in die Logs auf dem Ldap-Server geworfen? Damit man daraus schlauer wird, muss man eventuell das Loglevel hoch setzen (in der Datei /etc/ldap/slapd.conf, zum Beispiel loglevel 256 128 32 8 – danach service slapd restart).

Beste Grüße

Jörg

Aber die Tags ohne Leerzeichen! Nur zur Sicherheit!