Nach einem Dist-Upgrade von Debian Etch auf Lenny funktionierte bei mir die verschlüsselte LDAP Abfrage nicht mehr. Wir haben auf dem Debian-Server ein zentrales ROOT-CA installiert und in der /etc/ldap/ldap.conf entpsrechend konfiguriert:

TLS_CACERT /etc/ldap/certs/our_Rootzertifikat.cer
TLS_REQCERT never

Nach dem Upgrade funktionierte aber die Authentifizierung in allen PHP-Applikationen (wie z.B. das TYPO3-Backend) nicht mehr. Das der Fehler nicht an den Applikationen bzw. PHP lag, war also recht offensichtlich.

Weitere Sicherheit in diese These brachte, das auch auf der Kommandozeile ein Abfrage via

ldapsearch -x -W -b ‚ou=FLADI,o=FLADI-DIR‘ -H ldaps://ldap.fladi.de:636 -D „cn=LOOKUP,ou=SVC,o=ADM“ ‚(&(objectClass=Persons)(cn=LU1))‘ -d 1

nicht möglich war und als Ergebnis ein weitesgehend nichtssagendes

ldap_sasl_bind(SIMPLE): Can’t contact LDAP server (-1)

lieferte. Da der Connect zum LDAP-Server jedoch funktionierte, musste es ein Fehler beim eigentlichen BIND sein. Entsprechendes debugging während einer Anmeldung durch eine PHP-Anwendung zeigte dies ebenso.

Als Ursache stellte sich heraus, dass mit Wechsel von Etch auf Lenny die OpenLDAP-Implementierung nicht mehr gegen OpenSSL verlinkt ist, sondern gegen GnuTLS. Diese interpretiert die ein oder andere Konfiguration wohl verschieden. Obgleich unsere Konfiguration (s.o.) ja schon recht überschaulich ist, lag hier der Fehler. Das Zertifikat wurde nicht richtig gelesen.

Abhilfe schaffte dann, anstelle der direkten Angabe des Zertifikates nur noch das Verzeichnis mit Zertifikaten zu konfigurieren.

TLS_CACERTDIR /etc/ldap/certs/

Seitdem klappt wieder alles wie es soll.

Nachtrag: Die o.g. Server-Adressen, Usernamen … wurden ersetzt und sind so in der Realität nicht zu gebrauchen. :-)