OpenLDAP SASL2 Mech EXTERNAL

[Six]

So, mit Squeeze soll Debians OpenLDAP nun auch endlich OpenSSL Zeritfikate abkönnen. Also mal schnell einen OpenLDAP Provider/Consumer Setup aufgesetzt. Doch nun stolper ich über ein interesantes Problem: Der SASL2-Mechanism EXTERNAL steht nicht zu Verfügung, obwohl alles korrekt eingerichtet zu sein scheint.

Zum Verständnis: Ich richte OpenLDAP zunächst mit einer slapd.conf ein und konvertiere diese dann später in eine online cn=config.

Hier mal der relevante Auszug aus slapd.conf

Code: Alles auswählen

# TLS
TLSCertificateFile      /etc/ldap/TLS/foo.cert.pem
TLSCertificateKeyFile   /etc/ldap/TLS/foo.ldap.key.pem
TLSCACertificateFile    /etc/ldap/TLS/foo.pem
TLSVerifyClient         allow

Hier der relevante Auszug aus /etc/ldap/ldap.conf:

Code: Alles auswählen

TLS_CACERT  /etc/ldap/TLS/cacert.pem
TLS_REQCERT allow

TLS funktioniert, also sind die Zertifikate in Ordnung. Hier der Output eines Simple Bind mit TLS:

Code: Alles auswählen

foo:/etc/ldap$ldapsearch -xLLL -ZZ uid=dummy
dn: uid=dummy,ou=users,dc=foo,dc=local
uid: dummy
uidNumber: 1000
gidNumber: 1000
cn: dummy
sn: dummy
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
loginShell: /bin/bash
homeDirectory: /home/dummy

Läuft offensichtlich.

Aber:

Code: Alles auswählen

foo:/etc/ldap$ldapsearch -Y EXTERNAL -LLL
SASL/EXTERNAL authentication started
ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
        additional info: SASL(-4): no mechanism available:

n der $HOME/.ldaprc steht dies:

Code: Alles auswählen

TLS_CERT /home/dummy/certs/dummy.cert.pem
TLS_KEY /home/dummy/certs/dummy.ldap.key.pem
SASL_MECH EXTERNAL

saslpluginviewer bestätigt mir die Existenz des EXTERNAL Mechanismus:

Code: Alles auswählen

foo:/etc/ldap#saslpluginviewer
[...]
Plugin "EXTERNAL" [loaded],     API version: 4
        SASL mechanism: EXTERNAL, best SSF: 0
        security flags: NO_ANONYMOUS|NO_PLAINTEXT|NO_DICTIONARY
        features: WANT_CLIENT_FIRST|PROXY_AUTHENTICATION

Aber OpenLDAP weiß davon erst mal nix:

Code: Alles auswählen

foo:/etc/ldap#ldapsearch -x -ZZ -LLL -s base -b "" supportedSASLMechanisms
dn:
supportedSASLMechanisms: NTLM
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: PLAIN
supportedSASLMechanisms: LOGIN
supportedSASLMechanisms: DIGEST-MD5

Naheliegende Tests erbrachten dies:

Code: Alles auswählen

foo:/etc/ldap$ldapsearch -ZZ -Y EXTERNAL -LLL
ldap_start_tls: Connect error (-11)
        additional info: (unknown error code)

Uhoh, das sieht nach dem altem GNUtls-Scheiß aus. Und tatsächlich:

Code: Alles auswählen

foo:/etc/ldap$ldapsearch -ZZ -Y EXTERNAL -LLL -d -1
TLS: peer cert untrusted or revoked (0x42)
TLS: can't connect: (unknown error code).
ldap_err2string
ldap_start_tls: Connect error (-11)
        additional info: (unknown error code)

Argh, ich dachte, das wäre geregelt. Aber noch bin ich nicht bereit, die Flinte ins Korn zu werfen. Ich kann auch einfach etwas falsch gemacht haben. Hat jemand Ideen (jetzt außer OpenLDAP neu kompilieren)?

[muelleks]

Hallöchen

ich hatte nun auch mal überlegt meinen Server mit OpenLDAP auszustatten.
Soweit funktionierte bei mir auch alles bis zum dem Punkt wo ich TLS über SASL Aktivieren wollte.

Bei der Recherche im Internet bin ich dann auf den Beitrag gestoßen.

Ich bekomme bei fast allen Abfragen die gleiche Meldung.
Bis auf die folgende.

Code: Alles auswählen

foo@foo:/ldapsearch -x -ZZ -LLL -s base -b "" supportedSASLMechanisms
ldap_start_tls: Connect error (-11)
additional info: TLS: hostname does not match CN in peer certificate

Eventuell liegt habe ich da noch ein anderes Konfigurationsproblem.
Aber im Moment sieht es so aus als hätten wir beide das gleiche Problem.

Würde mich freuen wenn uns jemand bei der Lösung des Problem behilflich sein könnte.

Danke im vorraus für die Mühen.
Gruß
Muelleks

[Six]

Hallo und willkommen im df.de!

Hallöchen

ich hatte nun auch mal überlegt meinen Server mit OpenLDAP auszustatten.
Soweit funktionierte bei mir auch alles bis zum dem Punkt wo ich TLS über SASL Aktivieren wollte.

Bei der Recherche im Internet bin ich dann auf den Beitrag gestoßen.

Ich bekomme bei fast allen Abfragen die gleiche Meldung.
Bis auf die folgende.

Code: Alles auswählen

foo@foo:/ldapsearch -x -ZZ -LLL -s base -b "" supportedSASLMechanisms
ldap_start_tls: Connect error (-11)
additional info: TLS: hostname does not match CN in peer certificate

Eventuell liegt habe ich da noch ein anderes Konfigurationsproblem.
Aber im Moment sieht es so aus als hätten wir beide das gleiche Problem.

Würde mich freuen wenn uns jemand bei der Lösung des Problem behilflich sein könnte.

Danke im vorraus für die Mühen.
Gruß
Muelleks

OpenLDAP ist sehr empfindlich was hostnames angeht. Stelle sicher, dass du immer den FQDN deines Hosts benutzt, insb. als common name im Zertifikat.

[sdh82]

Hi,

das LDAP unter Squeeze kann wohl SASL_MECH EXTERNAL handeln. Mangel ist nur GnuTLS aber dies funktioniert auch.

Client:

Code: Alles auswählen

root@ares:~# ldapsearch -x -ZZ -LLL -s base -b "" supportedSASLMechanisms
dn:
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: EXTERNAL

root@ares:~# cat /etc/issue
Debian GNU/Linux 6.0 \n \l
root@ares:~# ldapsearch -ZZ -Y EXTERNAL -LLL -d -1
ldap_create
ldap_extended_operation_s
ldap_extended_operation
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP hera.xxxxx.xxx:389

........................................

ldap_sasl_interactive_bind_s: user selected: EXTERNAL
ldap_int_sasl_bind: EXTERNAL
ldap_int_sasl_open: host=hera.xxxxx.xxx
=> ldap_dn2bv(16)
<= ldap_dn2bv(email=ares@.........................)=0
SASL/EXTERNAL authentication started
ldap_sasl_bind_s
ldap_sasl_bind
ldap_send_initial_request
ldap_send_server_request
ber_scanf fmt ({it) ber:

..............

tls_read: want=5, got=5
  0000:  17 03 02 01 70                                     ....p             
tls_read: want=368, got=368
  0000:  dd 3a e9 79 9d 3b e0 41  a4 d1 03 42 b7 f0 dc 3f   .:.y.;.A...B...?  
  0010:  d9 9b f1 62 9d 69 59 32  7d 70 80 66 56 a5 ab a3   ...b.iY2}p.fV...  
  0020:  58 89 44 ff 13 ab 3a bd  39 16 bc 7a 70 c8 6f 3f   X.D...:.9..zp.o?  
  0030:  cf 33 d1 e4 e8 79 7f 17  0f 81 4b 4e 93 b4 2d 63   .3...y....KN..-c  
  0040:  8f d5 c0 ee 07 d1 1b 18  66 e1 64 70 cc 02 69 4f   ........f.dp..iO  
  0050:  bd b1 d4 ab 98 91 84 a3  74 a6 fc b6 0b 34 4c 8e   ........t....4L.  
  0060:  f4 44 e1 57 cd 35 53 e3  15 f8 93 e2 c7 61 f2 d3   .D.W.5S......a..  
  0070:  4b a1 e3 5f c0 77 10 5e  c6 0b 0e f6 84 14 76 5e   K.._.w.^......v^  

.....................

Server:

Code: Alles auswählen

root@hera:~# apt-cache policy slapd
slapd:
  Installed: 2.4.23-7
  Candidate: 2.4.23-7
  Version table:
 *** 2.4.23-7 0
        500 http://ftp.de.debian.org/debian/ squeeze/main amd64 Packages
        100 /var/lib/dpkg/status

Server Log:

Code: Alles auswählen

Feb 21 23:42:54 hera slapd[2029]: conn=1434 op=1 BIND authcid="email=ares@xxxxx.xxx,cn=ares.xxxxx.xxx,ou=xxxxx,o=xxx,st=baden-wuerttemberg,c=de" authzid="email=ares@xxxxx.xxx,cn=ares.xxxxx.xxx,ou=xxxxx,o=xxx,st=baden-wuerttemberg,c=de"
Feb 21 23:42:54 hera slapd[2029]: conn=1434 op=1 BIND dn="email=ares@xxxxx.xxx,cn=ares.xxxxx.xxx,ou=xxxxx,o=xxx,st=baden-wuerttemberg,c=de" mech=EXTERNAL sasl_ssf=0 ssf=256

Ich verwende meine slapd.conf, die ich in Debian Lenny einsetzte.

Gruß
sdh82

[Six]

Hi,

das LDAP unter Squeeze kann wohl SASL_MECH EXTERNAL handeln. Mangel ist nur GnuTLS aber dies funktioniert auch.

Sehr gut! Irgendwelche sachdienlichen Hinweise, wo mein Fehler liegen könnte?

[sdh82]

ist /etc/ldap/sasl2/slapd.conf vorhanden?
Gibt's in der gemeinten Datei im Eintrag mech_list: auch mal external?

Quelle: OpenLDAP 2.4 Das Praxisbuch von Galileo Computing

[Six]

Leider ja.

[sdh82]

stelle mal deine Konfiguration hier, vielleicht findet man ja das Problem.

[rockstable]

Deine Ldap URI aus der /etc/ldap/ldap.conf fehlt noch fürs debugging.
Der Fehler selbst ist eigentlich offensichtlich im Debugging output.
TLS: peer cert untrusted or revoked (0x42)

Du verwendest für Client und Server unterschiedliche CA-Certs.
Darum vertraut der Client dem Server-Zertifikat nicht und lehnt den TLS-Handshake ab, weswegen der Connect scheitert.

[TRex]

Danke für die Aufklärung, aber die kommt 3,5 Jahre zu spät