OpenLDAP mit StartTLS unter Debian Lenny defekt

OpenLDAP mit StartTLS unter Debian Lenny defekt

Ich versuche, OpenLDAP auf Lenny mit StartTLS zum Laufen zu bringen. Ich habe eine Fedora 13-Maschine, die ich als Client zum Testen verwende. Bisher ignoriert der Fedora-Client die Anweisung „host“ in /etc/ldap.conf, wenn ich versuche, eine Verbindung über ldapsearch herzustellen. Der Client möchte eine Verbindung zu 127.0.0.1:389 herstellen, selbst wenn ich bei Verwendung von ldapsearch -H ldaps://server.name on angebe. /etc/ldap.conf auf der Client-Maschine ist im Modus 444.

Aber selbst wenn ich versuche, über eine SSH-Sitzung eine lokale Verbindung herzustellen, werden mir Fehler wie dieser angezeigt: ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)

Jemand hat mich mit einem Cluebat geschlagen, bitte.

Update: Sie müssen ~/.ldaprc für Einstellungen wie „Host“ verwenden. Außerdem habe ich gerade nmap für den LDAP-Server verwendet und es wurden 636 und 389 im offenen Zustand angezeigt.

Hier ist, was auf dem Bildschirm gedruckt wird, wenn ich versuche, eine Verbindung herzustellen,ldapsearch -ZZ –x '(objectclass=*)'+ -d -1

ldap_erstellen
ldap_erweiterte_operation_s
Erweiterter LDAP-Vorgang
ldap_sende_erste_Anforderung
ldap_neue_Verbindung 1 1 0
ldap_int_öffnen_Verbindung
ldap_connect_to_host: TCP 192.168.10.41:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Versuch 192.168.10.41:636
ldap_pvt_connect: fd: 3 tm: -1 asynchron: 0
ldap_open_defconn: erfolgreich
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_dump: buf=0x9bdbdb8 ptr=0x9bdbdb8 end=0x9bdbdd7 länge=31
  0000: 30 1d 02 01 01 77 18 80 16 31 2e 33 2e 36 2e 31 0....w...1.3.6.1  
  0010: 2e 34 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 .4.1.1466.20037   
ber_scanf fmt ({) ber:
ber_dump: buf=0x9bdbdb8 ptr=0x9bdbdbd end=0x9bdbdd7 länge=26
  0000: 77 18 80 16 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e w...1.3.6.1.4.1.  
  0010: 31 34 36 36 2e 32 30 30 33 37 1466.20037        
ber_flush2: 31 Bytes zu SD 3
  0000: 30 1d 02 01 01 77 18 80 16 31 2e 33 2e 36 2e 31 0....w...1.3.6.1  
  0010: 2e 34 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 .4.1.1466.20037   
ldap_write: will=31, geschrieben=31
  0000: 30 1d 02 01 01 77 18 80 16 31 2e 33 2e 36 2e 31 0....w...1.3.6.1  
  0010: 2e 34 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 .4.1.1466.20037   
ldap_result ld 0x9bd3050 msgid 1
wait4msg ld 0x9bd3050 msgid 1 (unendliches Timeout)
wait4msg weiter ld 0x9bd3050 msgid 1 alle 1
** ld 0x9bd3050 Verbindungen:
* Host: 192.168.10.41 Port: 636 (Standard)
  refcnt: 2 Status: Verbunden
  zuletzt verwendet: So 6. Jun 12:54:05 2010


** ld 0x9bd3050 Ausstehende Anfragen:
 * msgid 1, origid 1, status InBearbeitung
   ausstehende Empfehlungen 0, Anzahl der übergeordneten Elemente 0
  ld 0x9bd3050 Anzahl der Anfragen 1 (abgebrochen 0)
** ld 0x9bd3050 Antwortwarteschlange:
   Leer
  ld 0x9bd3050 Antwortanzahl 0
ldap_chkResponseList ld 0x9bd3050 msgid 1 alle 1
ldap_chkResponseList gibt ld 0x9bd3050 NULL zurück
ldap_int_select
read1msg: ld 0x9bd3050 msgid 1 alle 1
ber_get_next
ldap_read: will=8, habe=0

ber_get_next ist fehlgeschlagen.
ldap_err2string
ldap_start_tls: LDAP-Server kann nicht kontaktiert werden (-1)

Antwort1

Standardmäßig prüft der Client, ob das Zertifikat des Servers vorliegt. Fügen Sie einfach "TLS_REQCERT never" zu /etc/openldap/ldap.conf hinzu.

Antwort2

Ich habe es kürzlich geschafft, SSL mit SLAPD auf Lenny zum Laufen zu bringen. Ich weiß zwar nicht mehr genau, was ich gemacht habe, aber ich erinnere mich, dass es etwas mit dem Unterschied in den Chiffren zwischen GNUTLS und OPENSSL zu tun hatte. Die SLAPD-Pakete für Lenny wurden gegen GNUTLS kompiliert. Könnte etwas damit zu tun habenDas.

Antwort3

Es sieht so aus, als ob die Schlüsseldatei nicht gelesen werden kann. Sie sollten einen Schlüssel ohne Passwort haben. Fügen Sie openldap zur SSL-Zertifikatgruppe hinzu. Erstellen Sie die Gruppe mit dem Schlüssel SSL-Zertifikat und den Berechtigungen 440. Der Befehl openssl s_client kann zum Debuggen von TLS-Problemen verwendet werden.

Antwort4

Wenn Sie ein SSL-Zertifikat haben, das mit einem Zwischenzertifikat signiert ist (was heutzutage nicht ungewöhnlich ist), werden Sie unter Lenny Probleme mit TLS in slapd haben. Wie von Sybreon erwähnt, ist Lenny slapd mit GNUTLS verknüpft, das nicht alle von Ihnen benötigten Optionen unterstützt.

Die Lösung besteht darin, den Lenny-Backport von slapd zu verwenden. Wir haben jedoch festgestellt, dass der Backport 2.4.17-2.1~bpo50+1 mit libdb4.6 kompiliert, das einen Fehler enthält, der uns nach etwa einer Woche Laufzeit beeinträchtigt.

Wenn Sie TLS benötigen, empfehle ich Ihnen daher derzeit nicht, Lenny zum Ausführen von slapd zu verwenden. Führen Sie stattdessen ein Upgrade auf Squeeze durch.

verwandte Informationen