XAMPP + LDAP über SSL

[Leeloo5E]

Warum geht das mit einem normalen Apachen und dem XAMPP-Apachen nicht?

Tipp, Link, Antwort oder vielleicht Absicht?

[Knappe]

Ich lasse diesen Thread mal wieder aufleben, da ich ein ähnliches Problem wie @Leeloo5E habe.

Vorweg

1.) Ich setzte als Server
-->Linux, openSUSE 10.2 und
-->OpenLDAP, Version und
-->OpenSSL, Version 0.9.8.d und
-->XAMPP, Version xampp-linux-1.5.1. mit php 5.1.1

2) auf der Entwicklungkiste
-->WinXP prof SP2,
-->XAMPP, Version 1.6.0a mit php 5.2.1
ein

Von WinXP --> soll via SSL bzw. TLS auf den LDAP-Server auf dem Linux-Server zugegriffen werden :

Alle Anwendungen auf dem WinXP-Rechner,
z.B. Thunderbird (Adressbuch)
z.B Pegasus (Adressbuch)
z.B. Oulook Express (Adressbuch)
schaffen das.

Nach dem ersten Connect, wird nach der Bestätigung des Zertifikats gefragt --> bestätigt = Zugriff erfolgt.

Der Zugriff kann danm sowohl über

- SSL = Port 636 oder
- TLS = 389

erfolgen.

Genau das funktioniert aber mit php 5.2.1 aus dem o.g. XAMPP-Paket nicht !

Hier die (anonymisierten) Code-Zeilen aus dem Script :

Code: Select all

<?php
   // verbinden zum ldap server
   $ldap_conn      =   ldap_connect("ldap://ldapserver.mydomain.de","389") or die("Keine Verbindung zum LDAP server möglich.");

   if ($ldap_conn) {

      //   Go with LDAP version 3 if possible (needed for renaming and Novell schema fetching)
      @ldap_set_option($ldap_conn,LDAP_OPT_PROTOCOL_VERSION,3);

      /*   Disabling this makes it possible to browse the tree for Active Directory, and seems
      to not affect other LDAP servers (tested with OpenLDAP) as phpLDAPadmin explicitly
      specifies deref behavior for each ldap_search operation. */
      @ldap_set_option($ldap_conn,LDAP_OPT_REFERRALS,0);

      // Set Debug Level
      ldap_set_option(NULL, LDAP_OPT_DEBUG_LEVEL, 7);

      function_exists('ldap_start_tls') or die('Your PHP install does not support TLS.');
      if (!@ldap_start_tls($ldap_conn)) {
         printf("LDAP-Fehlernummer: %s<br>\n", ldap_errno($ldap_conn));
         printf("LDAP-Fehler: %s<br>\n", ldap_error($ldap_conn));
         die("Argh!<br>\n");
      }

      // binden zum ldap server
      $ldap_bind   =   ldap_bind($ldap_conn, $ldap_rdn, $ldap_pass);

      // Bindung überprüfen
      if ($ldap_bind) {
          echo "LDAP bind erfolgreich...<P><P>";
         $filter   =   "(cn=otto*)";
         $justthese= array( "ou", "sn", "displayname", "mail");

         //      $justthese=   array("uid");
         //      $sr=ldap_read($ldapconn, $srdn, $filter, $justthese);
         //      $entry = ldap_get_entries($ldapconn, $sr);

         //Search the directory
         $result = ldap_search($ldap_conn, $ldap_address, $filter, $justthese);
      
        //Create result set
         $entries = ldap_get_entries($ldap_conn, $result);
      
         //Sort and print
         echo "Anzahl Adresssätze count: " . ($entries["count"] - 1) . "<br /><br /><b>Users:</b><br />";
      
         for ($i=0; $i < $entries["count"]; $i++)
         {
            echo $entries[$i]["displayname"][0]."<br />";
         }

         //      ldap_unbind($ldapconn);
      } else {
         echo "LDAP bind fehlgeschlagen...";
   }
   ldap_close($ldap_conn);
}
?>

Fehler bei "if (!@ldap_start_tls($ldap_conn)) {"

LDAP-Fehlernummer: 91
LDAP-Fehler: Connect error

Dieses Script läuft OHNE jegliche Änderung auf dem Linux-Server (= Client) und auch OHNE diesen start-tls-Befehl auf dem Entwicklungsrechner !

Auf dem Server kann ich erkennen ...

Firewall ist offen, den LDAP-Zugriff von der WinXP-Kiste kann ich auf dem Server im syslog verfolgen (debuglevel auf 4096 gesetzt).
Dort kann ich aber nicht erkennen, warum der start-tls-Befehl "schief geht"
Alle Zertifkate sind auf dem Server richtig gesetzt und werden von allen Clients (ob Linux und/oder WinXP) auch richtig erkannt.

Ausnahme nur bei XAMPP

Laut phpinfo() ist "LDAP" auf der WinXP-Kiste geladen :

ldap
LDAP Support enabled
RCS Version $Id: ldap.c,v 1.161.2.3.2.3 2007/01/05 15:06:55 iliaa Exp $
Total Links 1/unlimited
API Version 2004
Vendor Name OpenLDAP
Vendor Version 0

Auch im Apachen sind wohl die Module geladen

Loaded Modules core mod_win32 mpm_winnt http_core mod_so mod_actions mod_alias mod_asis mod_auth_basic mod_authn_default mod_authn_file mod_authnz_ldap mod_authz_default mod_authz_groupfile mod_authz_host mod_authz_user mod_cgi mod_dav mod_dav_fs mod_dir mod_env mod_include mod_info mod_isapi util_ldap mod_log_config mod_mime mod_negotiation mod_setenvif mod_status mod_ssl mod_autoindex_color mod_php5 mod_perl mod_jk

Gleiches gilt auch für den Apachen auf dem Linux-Server.

Beim LDAP-Modul gibt es dagegen Unterschiede (nachvollziehbar) :

LDAP Support enabled
RCS Version $Id: ldap.c,v 1.161 2005/08/03 14:07:22 sniper Exp $
Total Links 1/unlimited
API Version 3001
Vendor Name OpenLDAP
Vendor Version 20311

(übrigens ist auf dem Linux-Server php, Version 5.1.1 installiert)
Mir erscheint aber die API-Version 2004 im Win-XAMPP-Paket sehr alt ?

Der Fehler liegt also
- nicht im php-Script
- nicht in der php.ini
- nicht in der httpd.conf

Eine Kontrolle mit phpLDAPadmin brachte exakt das gleiche Ergebnis.


Es scheint also an/in den Binaries von php zu liegen, denn der Apache hat (meiner Meinung nach) überhaupt nichts mit dem missglücktem Zugriff zu diesem Zeitpunkt zu tun

Würde mich über eine Beseitigung dieser Problematik freuen (brauche halt auch diesen start-tls-Befehl).

Wenn´s hilft, kann ich auch noch andere Tests machen und das Ergebnis hier dann posten.

[edit]
Habe mir mal aus dem Source-Code der Version 5.2.1 von php.net die entsprechende Routine rausgesucht ("/ext/ldap/ldap.c") :

Code: Select all

#ifdef HAVE_LDAP_START_TLS_S
/* {{{ proto bool ldap_start_tls(resource link)
   Start TLS */
PHP_FUNCTION(ldap_start_tls)
{
   zval **link;
   ldap_linkdata *ld;
   int rc, protocol = LDAP_VERSION3;

   if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, &link) == FAILURE) {
      WRONG_PARAM_COUNT;
   }

   ZEND_FETCH_RESOURCE(ld, ldap_linkdata *, link, -1, "ldap link", le_link);

   if (((rc = ldap_set_option(ld->link, LDAP_OPT_PROTOCOL_VERSION, &protocol)) != LDAP_SUCCESS) ||
      ((rc = ldap_start_tls_s(ld->link, NULL, NULL)) != LDAP_SUCCESS)
   ) {
      php_error_docref(NULL TSRMLS_CC, E_WARNING,"Unable to start TLS: %s", ldap_err2string(rc));
      RETURN_FALSE;
   } else {
      RETURN_TRUE;
   }
}
/* }}} */
#endif
#endif /* (LDAP_API_VERSION > 2000) || HAVE_NSLDAP || HAVE_ORALDAP_10 */

Vom Source-Code her gibt es keinen Unterschied zwischen Windows und Linux (siehe hier).

Kann es dann also nur am Compiling/Linking liegen oder ?

[dormi]

Ich habe ein ähnliches aber auch sehr sehr seltsames Phänomen.
Und zwar habe ich ein popliges php Script, in folgender Form:

Code: Select all

$ server = "ldaps://....";
$port = 636;
$con =  ldap_connect("ldaps://", $port);
$bh = ldap_bind($ds, $user, $pass);

Der Bind funktioniert auch, wenn das Script auf der Konsole ausgeführt oder über HTTP aufgerufen wird.

Über HTTPS kracht der Bind.

Jemand eine Idee ?

[KingCrunch]

Mag vielleicht etwas spitzfindig sein, aber meines Erachtens ist ldaps und https etwas verschiedenes ^^

[Talisker]

Hallo zusammen,

die Ursache der Verbindungsprobleme liegt in der Zertifikatsbehandlung des OpenLDAP-Clients. Der LDAP-Client überprüft standardmäßig beim SSL (TLS) Verbindungsaufbau die Gültigkeit des LDAP-Serverzertifikates. Ist dieses Zertifikat selbstsigniert verweigert der Client die Verbindung. Ist das Serverzertifikat signiert, muß der öffentliche Schlüssel der root-CA auf dem Client hinterlegt sein.

Am einfachsten schaltet man die Client-seitige Zertifikatsüberprüfung ab. Dazu muß in die ldap.conf der Eintrag "TLS_REQCERT never" rein. Unter Linux ist die Konfigurationsdatei unter /etc/openldap/ldap.conf, unter Windows unter c:\OpenLDAP\sysconf\ldap.conf zu finden.

Viel Erfolg!

Hier der Link auf die ldap.conf manpage: http://www.openldap.org/software/man.cgi?query=ldap.conf&apropos=0&sektion=0&manpath=OpenLDAP+2.3-Release&format=html

[Knappe]

@Talisker

in Verbindung mit der neusten XAMPP-Version (1.6.3b) stellt sich das Problem nicht mehr.

Hier kann man dann wieder ruhig

Code: Select all

TLS_REQCERT allow

eintragen.

Funktioniert einwandfrei

[bitspyer]

Ich häng mich mal hier mit einem ähnlichen Problem rein:

Selbes Problem wie hier im Thread beschrieben, allerdings bekomme ich über die CLI Schnittstelle eine Antwort. Rufe ich das selbe Script per http auf, bekomme ich die antwort, das keine Verbindung zustande kommt....

Ich habe Null Plan wo ich schauen könnte...

Gruss,
Bitspyer

[Knappe]

Ich habe Null Plan wo ich schauen könnte...

Also erst einmal das Debugging einschalten :

Code: Select all

ldap_set_option(NULL, LDAP_OPT_DEBUG_LEVEL, 7);

Diese Anweisung muss VOR dem erstem "ldap_connect" stehen (gefunden habe ich das hier) !

Dann (und nur dann) werden naemlich die LDAP-Zugriffe selbst, sowie die Angaben aus dem wirklich benutztem Zertifikat in das Protokoll (welches in der httpf.conf unter "ErrorLog" definiert wurde) eingetragen.

Bei mir funktionieren die LDAP-Zugriffe absolut fehlerfrei :
sowohl mit "ldap://ldapserver.testdomain.de" ohne und mit TLS,
wie auch "ldaps://ldapserver.testdomain.de".

Im letzteren Beispiel wird via SSL auf den LDAP-Server zugegriffen (spielt keine Rolle, ob vorher eine Verbindung zur Domain via http:// oder https:// erfolgte !).

Aber : in diesem Fall darf natuerlich die Anweisung

Code: Select all

ldap_start_tls(...)

nicht mehr benutzt werden (SSL & TLS moegen sich halt nicht )

Es muss natuerlich bei TLS bzw. SSL-Zugriffen darauf geachtet werden, dass der Domain-Name aus der

Code: Select all

ldap_connect (...)  -Klausel

mit der "CN="-Angabe aus dem schon o.g. protokollierten Zugriffen uebereinstimmt; also nicht verwechseln mit der Domain-Angabe aus der Browserzeile (der hat damit nichts zu tun).

Damit wird auch schnell klar, dass man tunlichst auf IP-Adressangaben - selbst zu Testzwecken - in Verbindung mit TLS- und/oder SSL-LDAP-Zugriffen verzichten sollte, denn diese stimmen wohl eher nicht mit der "CN="-Angabe aus dem benutztem Zertifkat ueberein


Wenn in dem schon o.g. Protokoll folgende Zeile enthalten ist :

TLS trace: SSL3 alert read:fatal:handshake failure

dann sollte man in der /etc/openldap/slap.conf und /etc/ldap.conf BZW. /etc/openldap.ldap.conf den Eintrag

Code: Select all

TLSVerifyClient allow   ODER
TLSVerifyClient never

setzen.


Kann auf der Konsole z.B. folgender Befehl fuer eine SSL-Verbindung erfolgreich abgesetzt werden

Code: Select all

ldapsearch -x -H ldaps://ldapserver.testdomain.de -D "cn=admin,dc=mydomain,dc=de" -w passwd "(&(objectClass=posixAccount)(uid=* ))"

oder vielleicht mit diesem eine TLS-Verbindung

Code: Select all

ldapsearch -x -H ldap://ldapserver.testdomain.de -D "cn=admin,dc=mydomain,dc=de" -w passwd "(&(objectClass=posixAccount)(uid=* )) -ZZ"

dann laeuft der Zugriff auf den LDAP-Server einwandfrei.

Demzufolge koennte es sich um ein Problem mit einem selbstsigniertem Zertifkat handeln (dessen Pruefung aber eigentlich durch die "TLSVerifyClient"-Angabe ausgeschatlet sein sollte).

[Leeloo5E]

Nachdem ich nun lange mit Linux und den dort zur Verfügung stehenden Apache und PHP gearbeitet habe, holt mich XAMPP unter Windows wieder ein. Generell alles fein. Nur der Versuch (wieder mal) per LDAPs bzw. Port 636 ein Bind mit einem LDAP-Server herzustellen, scheitert. Diesmal jedoch am vorgezeigten Zertifikat. Während es unter Linux einfach ist, die entsprechende ldap.conf mit

Code: Select all

TLS_REQCERT never

zu füllen. Ist es unter Windows nicht ganz so einfach, denn

Code: Select all

 /etc/openldap/ldap.conf

existiert unter Windows nicht.

Unter zu Hilfenahme der Suche und weiterer Recherchen, soll es angeblich möglich sein per

Code: Select all

c:\openldap\sysconf\ldap.conf

die nötigen Einstellungen vorzunehmen. Gesagt, getan: Habe also besagte Datei ordnungsgemäß angelegt. Effekt bleibt aber bestehen.

ldap_create
ldap_url_parse_ext(ldaps://10.12.100.1)
ldap_bind_s
ldap_simple_bind_s
ldap_sasl_bind_s
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection
ldap_int_open_connection
ldap_connect_to_host: TCP 10.12.100.1:636
ldap_new_socket: 1656
ldap_prepare_socket: 1656
ldap_connect_to_host: Trying 10.12.100.1:636
ldap_connect_timeout: fd: 1656 tm: -1 async: 0
ldap_ndelay_on: 1656
ldap_ndelay_off: 1656
TLS trace: SSL_connect:before/connect initialization
TLS trace: SSL_connect:SSLv2/v3 write client hello A
TLS trace: SSL_connect:SSLv3 read server hello A
TLS certificate verification: depth: 1, err: 19, subject: /OU=Organizational CA/
O=NWT, issuer: /OU=Organizational CA/O=NWT
TLS certificate verification: Error, self signed certificate in certificate chai
n
TLS trace: SSL3 alert write:fatal:unknown CA
TLS trace: SSL_connect:error in SSLv3 read server certificate B
TLS trace: SSL_connect:error in SSLv3 read server certificate B
TLS: can't connect.
ldap_err2string

Die Verbindung selbst kommt zu stande, nur das Bestätigen des vorgezeigten Zertifikats schlägt fehl, trotz Konfiguration der ldap.conf unter Windows.

Jemand noch eine Idee?

Gruß,
Leeloo5e