php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #34482 LDAP Searches cause Access Violation when connecting via LDAPS
Submitted: 2005-09-12 18:49 UTC Modified: 2006-01-03 15:46 UTC
Votes:7
Avg. Score:4.7 ± 0.5
Reproduced:7 of 7 (100.0%)
Same Version:4 (57.1%)
Same OS:3 (42.9%)
From: zbowden at vt dot edu Assigned: edink (profile)
Status: Closed Package: LDAP related
PHP Version: 5.1.1, 4.4.1 OS: Windows 2003
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: zbowden at vt dot edu
New email:
PHP Version: OS:

 

 [2005-09-12 18:49 UTC] zbowden at vt dot edu 
Description:
------------
After moving to 5.0.5 from 5.0.4 I can no longer do ldap searches when connecting via LDAPS URI -> ldap_connect(ldaps://server.com). I'm only using Windows 2003/IIS6/ISAPI but it might occur on other platforms. 

Replacing the libeay32.dll and ssleay32.dll with the versions distributed with 5.0.4 fix the problem. 

On the LDAP Server side I've tested against a Windows 2000 Active Directory LDAP server and an OpenLDAP server and get the same results.




Reproduce code:
---------------
$host = "ldaps://server.com";
$ldap = ldap_connect($host);
$baseDn = "ou=accounts,dc=com";

// access violation will occur here
$result = ldap_search($ldap, $baseDn, "name=user", array('dn'));

Expected result:
----------------
PHP has encountered an Access Violation at _____

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-09-12 19:41 UTC] sniper@php.net 
Someone updated some libs..assigned to that someone. :)
 [2005-10-24 01:14 UTC] edink@php.net 
Please try using this CVS snapshot:

  http://snaps.php.net/php5-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.0-win32-latest.zip
 [2005-10-27 17:25 UTC] zbowden at vt dot edu 
tried the latest snapshot; I not longer get the access violation, however I cannot connect to any ldap server via LDAPS URI (says it can't contact server).

I did use ntfilemon to make sure the ldap.conf (and ldaprc) files were being read and they are. Not sure where the problem is though? I rolled back to the release version of 5.0.4 just to be sure it would still work and I can connect & bind to the ldap servers via LDAPS (& start_tls).
 [2005-10-31 20:30 UTC] zbowden at vt dot edu 
Just an additional idea/comment. If I go to 5.0.5 and replace the libeay32.dll and ssleay32.dll files with the ones included with the 5.0.4 release everything works fine.
 [2005-11-28 20:22 UTC] zbowden at vt dot edu 
Just a brief update: in 5.1.1 LDAPS URI's still don't work; the workaround I had for 5.0.5 doesn't work any longer either as we saw in the recent snapshots. I no longer get an access violation, however I cannot get a connection. 

Bbuie is correct, the problem doesn't actually present itself on the ldap_connect function, rather on the subsequent bind, search, etc.

I think the problem may be in the newer versions of openssl. What's leading me to this is that when I do a filemon trace as I execute a php script I can see it reading the conf file however it will never try to read or create the c:\.rnd file like it used to .. according to the openssl changelog I see this:
"In versions up to 0.9.6, RAND_file_name() resorted to file ".rnd" in the current directory if neither $RANDFILE nor $HOME was set. RAND_file_name() in 0.9.6a returned NULL in this case. This has caused some confusion to Windows users who haven't defined $HOME.Thus RAND_file_name() is changed again: e_os.h can define a DEFAULT_HOME, which will be used if $HOME is not set. For Windows, we use "C:"; on other platforms, we still require environment variables.
"

I've tried setting a RANDFILE env variable and that didn't help; I've also tried setting the TLS_RANDFILE in the ldap.conf file but that didn't seem to have any effect either.
 [2005-11-28 22:13 UTC] zbowden at vt dot edu 
just some additional information: if I try to use the ldap_start_tls() function I now get 
"Unable to start TLS: Not Supported"

maybe an error in the build process (i.e. not turning on TLS and or LDAPS)?
 [2005-12-19 17:31 UTC] pbarabe at paddyworks dot com 
I've been experiencing essentially the same problems as zbowden when upgrading from PHP 5.0.4 to 5.1.1 on Win2003/Apache 2.0.49/ISAPI.  ldap_bind() breaks (returns message "Can't contact LDAP server".  Replacing libeay32.dll and ssleay32.dll with those distributed with 5.1.1 does not fix the problem, though I can confirm that ldap_bind in PHP 5.0.4 still works with the new dlls.
 [2005-12-22 16:55 UTC] zbowden at vt dot edu 
just tested this in 4.4.1 and I see the same behavior that I see in 5.1.1 (i.e. can't connect to server via ldaps).
 [2005-12-27 15:47 UTC] bcline at gptruck dot com 
I'm experiencing all of the exact problems zbowden mentions above. Running PHP 5.1.0 with Win2003/IIS6/ISAPI.
 [2005-12-30 23:15 UTC] edink@php.net 
Please try using this CVS snapshot:

  http://snaps.php.net/php5.1-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.1-win32-latest.zip

Or for the inpatient the dll that should work with 5.1.x:

http://pecl4win.php.net/misc/php_ldap.dll

(Upgrading openssl in PHP distro is always troublesome)
 [2006-01-03 15:07 UTC] zbowden at vt dot edu 
The latest snapshot works for me (both ldaps and ldap w/ tls).

Thanks!
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Apr 25 19:01:33 2024 UTC