OpenLDAP, TLS & SASL

[kastor]

Hi,

ich versuche grade einen OpenLDAP Server auf mit Debian Lenny aufzuziehen. Mittlerweile hab ich das Setup fast im Griff, eine Geschichte macht mir aber noch Probleme. Ich hätte gerne, dass sich alle Clients nur per TLS am Server anmelden können. Dafür hab ich Zertifikate, die sind auch korrekt eingebunden und funktionieren (sagt mit openssl s_client, Konfiguration des Servers ist hier abgelegt: http://nopaste.debianforum.de/34924). Folgender Aufruf funktioniert auch ohne Probleme, und ergibt das gewünschte Ergebnis:

Code: Alles auswählen

ldapsearch -b 'dc=some,dc=thing' -D 'uid=testuser,dc=some,dc=thing' -w 'secret' 'objectclass=*

Laut dem Logfile klappt hier der simple Bind über TLS auf den testuser. Versuche ich mich hingegen nicht über TLS simple, sondern zb. mit CRAM-MD5 zu binden, bekomme ich folgendes:

Code: Alles auswählen

$ ldapsearch -b 'dc=some,dc=thing' -D 'uid=testuser,dc=some,dc=thing' -w 'secret' -Y CRAM-MD5 'objectclass=*'
SASL/CRAM-MD5 authentication started
ldap_sasl_interactive_bind_s: Invalid credentials (49)
        additional info: SASL(-13): user not found: no secret in database

Auf Serverseite bekomme ich folgende Meldungen:

Code: Alles auswählen

Sep  4 18:39:23 asd slapd[31284]: conn=2 fd=15 ACCEPT from IP=123.456.789.012:53822 (IP=0.0.0.0:636)
Sep  4 18:39:23 asd slapd[31284]: conn=2 fd=15 TLS established tls_ssf=256 ssf=256
Sep  4 18:39:23 asd slapd[31284]: conn=2 op=0 BIND dn="uid=testuser,dc=some,dc=thing" method=163
Sep  4 18:39:23 asd slapd[31284]: conn=2 op=0 RESULT tag=97 err=14 text=SASL(0): successful result:
Sep  4 18:39:23 asd slapd[31284]: conn=2 op=1 BIND dn="uid=testuser,dc=some,dc=thing" method=163
Sep  4 18:39:23 asd slapd[31284]: SASL [conn=2] Failure: no secret in database
Sep  4 18:39:23 asd slapd[31284]: conn=2 op=1 RESULT tag=97 err=49 text=SASL(-13): user not found: no secret in database
Sep  4 18:39:23 asd slapd[31284]: conn=2 fd=15 closed (connection lost)

Offenbar klappt der TLS Handshake, nur die Authentifizierung des testusers klappt nicht, da das Passwort offenbar nicht in der verwendeten SASL DB steht. Ich habe jetzt zwei Fragen:

- Muss ich noch was extra konfigurieren, damit die Benutzer in der SASL DB eingetragen werden, wenn sie angelegt werden (oder beim ändern des userPasswords)?
- Ich lese öfters, dass bei Verwendung von SASL das Hashing des Passworts im slapd komplett abgeschalten werden muss, damit SASL die Challenges generieren kann. Ich will aber die Klartextpasswörter auf keinen Fall im LDAP Baum stehen haben. Gibts da ne andere Möglichkeit, die Passwörter doch nicht im Klartext zu speichern, und trotzdem CRAM-MD5, bzw. DIGEST-MD5 zu nutzen?

Schon mal vielen Dank für evtl. Antworten!

[Six]

Ich stütze mich auf Experimente mit dem frisch als Stable veröffentlichten Squeeze.

Du kannst SASL2 Passwörter mit

Code: Alles auswählen

saslpasswd2 -c <username> 

in die SASL2DB schreiben.

Weiterhin glaube ich, dass du auf die GNUtls Problematik gestoßen bist. Ich schlage mich mit einem ähnlichen Problem bzgl. MECH EXTERNAL rum und habe die Überzeugung gewonnen, dass auch Squeezes OpenLDAP für TLS-gesicherte Kommunikation nicht zu gebrauchen ist. Versuche deswegen, dein OpenLDAP gegen OpenSSL neu zu bauen (oder wechsel auf eine Distribution, wo das funktioniert, z. B. SUSE.)

[kastor]

Hi,

danke für die Antwort. Das Problem scheint tatsächlich GnuTLS bedingt zu sein. Ähnliche Probleme beobachte ich mittlerweile auch ab und zu bei der Verwendung bestimmter E-Mail Clients und einem SSL gesichertem Exim SMTP Server. Windows Mobile 6.1 und 6.5 können zb. gar keine Mails mehr mit SSL Verschlüsselung verschicken, Opera Mail scheint ab und zu zu scheitern: "A TLS packet with unexpected length was received". Laut dem Debian Bugtracker gibts da wohl auch nur den Ausweg, Exim mit OpenSSL zu übersetzen. Irgendwo wiederspricht das jedoch dem Grundgedanken, auf APT und Binärpakete zu setzen.

Die Politik von Debian auf GnuTLS zu setzen kann ich zwar Nachvollziehen, nur für den Betrieb eines Servers find ich die Auswirkungen davon teilweise untragbar -- besonders wenn der Server sich in eine heterogene Umgebung einfügen soll. Andere Systeme, die zumindest in Sachen SSL nicht *nur* auf die Lizenz achten machen da eher weniger, bzw. gar keine Probleme (zb. FreeBSD).

Gruß, Kastor

[Six]

Hi,

danke für die Antwort. Das Problem scheint tatsächlich GnuTLS bedingt zu sein. Ähnliche Probleme beobachte ich mittlerweile auch ab und zu bei der Verwendung bestimmter E-Mail Clients und einem SSL gesichertem Exim SMTP Server. Windows Mobile 6.1 und 6.5 können zb. gar keine Mails mehr mit SSL Verschlüsselung verschicken, Opera Mail scheint ab und zu zu scheitern: "A TLS packet with unexpected length was received". Laut dem Debian Bugtracker gibts da wohl auch nur den Ausweg, Exim mit OpenSSL zu übersetzen. Irgendwo wiederspricht das jedoch dem Grundgedanken, auf APT und Binärpakete zu setzen.

Die Politik von Debian auf GnuTLS zu setzen kann ich zwar Nachvollziehen, nur für den Betrieb eines Servers find ich die Auswirkungen davon teilweise untragbar -- besonders wenn der Server sich in eine heterogene Umgebung einfügen soll. Andere Systeme, die zumindest in Sachen SSL nicht *nur* auf die Lizenz achten machen da eher weniger, bzw. gar keine Probleme (zb. FreeBSD).

Gruß, Kastor

Volle Zustimmung. Ich setze in diesem Bereich deswegen seit geraumer Zeit auf RHEL und Clones und benutze Debian nur noch , wenn SSL keine Rolle spielt. Ist echt traurig.