Verschlüsseltes LDAP (LDAPS) nach Upgrade von Debian Etch auf Lenny

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. :-)


User eines SQUID-Proxy gegen LDAP authentifizieren

Möchte man seine Proxy-User nur nach einem Login in das Internet lassen bietet es sich an, die User gegen das ohnehin vorhandene Directory zu authentifizieren. Dazu verwenden man am einfachsten eine LDAP-Anfrage. Zusätzlich soll der Zugriff nur solchen Usern gestattet sein, die auch in einer entsprechenden Gruppe Mitglied sind.

Zunächst die  Authentifizierung:

auth_param basic program /usr/lib/squid/ldap_auth -b „o=FLADI“ -f „(&(cn=%s)(objectClass=Person))“ -s sub -v 3 -h ldap.fladi.de
Ein paar zusätzlichen Konfigurationen (z.B. Meldung bei erstem Proxy-Kontakt)
auth_param basic children 8
auth_param basic realm Internetzugang bei der Fladi.net
auth_param basic credentialsttl 8 hours
Auslesen der Gruppen des vorher authentifizierten Users
external_acl_type ldap_group %LOGIN /usr/lib/squid/squid_ldap_group -b „o=FLADI“ -f „(&(cn=%u)(groupMembership=%g))“ -s sub -v 3 -h ldap.fladi.de
Gruppe, in der der User Mitglied sein muss um Zugriff zu erhalten
acl wwwgroup external ldap_group cn=ProxyUser,ou=mynet,o=FLADI
Fertig. ;-)