|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #15637 if using URI, ldap_connect() returns resource ID when server does not exist
Submitted: 2002-02-19 20:05 UTC Modified: 2005-04-29 15:59 UTC
Avg. Score:4.4 ± 0.9
Reproduced:38 of 39 (97.4%)
Same Version:11 (28.9%)
Same OS:5 (13.2%)
From: cjm46543 at hotmail dot com Assigned:
Status: Closed Package: Documentation problem
PHP Version: 4.4.0-dev OS: Linux - RedHat 7.2
Private report: No CVE-ID: None
 [2002-02-19 20:05 UTC] cjm46543 at hotmail dot com
I'm running a very simple test script (see below) to test my ldap server connection.  According to the docs, ldap_connect() is supposed to return an LDAP resource id on successful connect, or FALSE on error.  When I run the code with a valid server URI ($ds = ldap_connect("ldap://")), everything works fine.  When I run it with a URI to a nonexistent LDAP server ($ds = ldap_connect("ldap://does.not.exist")), ldap_connect returns a resource ID anyway, so my script has no way of knowing anything is wrong until I try to bind or search.  If I simply give a nonexistent hostname rather than a URI ($ds = ldap_connect("does.not.exist")) the function returns FALSE as documented.

I built PHP 4.1.1 against the client libraries from OpenLDAP 2.0.21.  Here's the full code of my test script:

$ds = ldap_connect("ldap://");
echo "connect result is ".$ds."<p>";
if($ds) {
  echo "Bind result is ".$r."<p>";
  $sr=ldap_search($ds, "ou=users,dc=example,dc=com", "uid=carljm");
  echo "Search result is ".$sr."<p>";
  echo "Number of entires returned is ".ldap_count_entries($ds,$sr)."<p>";
  echo "Getting entries ...<p>";                             
  $info = ldap_get_entries($ds, $sr);                        
  echo "Data for ".$info["count"]." items returned:<p>";     
  for ($i=0; $i<$info["count"]; $i++) {
    echo "dn is: ". $info[$i]["dn"] ."<br>";
    echo "first cn entry is: ". $info[$i]["cn"][0] ."<br>";
    echo "first uidNumber entry is: ". $info[$i]["uidnumber"][0] ."<p>";
echo "Closing connection";


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2002-02-20 05:20 UTC]
This is not an PHP/ldap bug but a documentation problem it seems to me.

When using an URI to describe the connection, the (open)ldap library only parses the url and checks if it's valid, _no connection_ is established in that case.

Checking the return code of ldap_bind() would be the proper thing to do anyway.
 [2002-07-02 11:19 UTC]
Reverified during bughunt. From the user-comments:

"When using an URI to describe the connection, the (open)ldap library
only parses the url and checks if it's valid, _no connection_ is
established in that case."

 [2002-10-31 15:09 UTC] rattray at purdue dot edu suggests that "Checking the return code of ldap_bind() would be the proper thing to do anyway."  However, the act of calling ldap_bind generates an error message on the page, e.g.:

"Warning: LDAP: Unable to bind to server: Can't contact LDAP server in /home/shop/www/ldaps-1.php on line 8"

before any check can be made on the results of ldap_bind().  
We are trying to create our first secure ldap system, and the false-positive returns from ldap_connect() are making it difficult to track down problems.
 [2002-11-29 09:07 UTC] f dot labanvoye at cg70 dot fr

in php-4.30rcX, the ldap_connect doesn't perform the connection, so documentation should be updated.
But, the documention (on zend site) for ldap_connect is:

ldap_connect() establishes a connection to a LDAP server on a specified
hostname and port. Both the arguments are optional. --> If no arguments
are specified then the link identifier of the already opened link will
be returned. 

In my script i don't have any previous opened link, so i think the function would return FALSE. 
Or the documention is wrong and need correction.


$ds = ldap_connect ( );
echo $ds // return a valid ldap resource


 [2002-12-27 16:27 UTC] W dot Regenczuk at adbglobal dot com
I have observed something like this (in php-4.30rc3):
The whole script:

$ldaphost = "nonexistendserver";
$ldapport = 389;
$ldapconn = ldap_connect( $ldaphost, $ldapport ) 
          or die( "Could not connect to {$ldaphost}" );
echo $ldapconn; // display a valid ldap resource

 [2003-01-06 11:28 UTC] martin at kouba dot at
when using an ip address ldap_connect doesn't work as described.

$server = "";
$port = "389";
$ds = ldap_connect($server, $port);

the result is true even if the server does not exist or the service is not running.
 [2003-01-17 22:26 UTC]
I cannot get ldap_connect() to return false under ANY conditions, including with the examples provided in this bug report.  I find this behavior impossible to document, please have another look at this.  Reclassifying -> ldap related.

Shouldn't these return false?  They are not URI's:

I get resources with both.  apache1.3.26/php4.4/openldap2.0.23
 [2003-01-20 16:12 UTC]
Please try using this CVS snapshot:
For Windows:

With latest CVS it returns FALSE when appropriate, cannot replicate the problem.
 [2003-01-24 19:51 UTC]
Yes, I still get ldap resources everytime except when passing in "/" or a wrong parameter count.
 [2003-02-10 12:30 UTC]
When openldap 2.x is used, the ldap_connect() does not actually connect, it just initializes the connecting parameters. The actual connect happens with next calls
to ldap_* funcs, usually it is 'ldap_bind()'.

This is just documentation problem. Not any bug in code.

 [2003-02-28 03:52 UTC] korte-php at et dot rub dot de
Rather anoying though since ldap_bind also fails when using a wrong password... only looking at bind fails doen't neccessarily mean, that the ldap server is down :(
 [2003-04-01 11:04 UTC] egeczi at nospamplease dot dist113 dot org
This is not just a documentation problem.

Not only does 

  $ldap_connection = ldap_connect("does.not.exist")

return a resource id when it obviously shouldn't, but

  ldap_bind($ldap_connection, 'username', 'password')

also returns true.

If the actual connect occurs with ldap_bind(), why does it return true for a server that does not exist?

 [2003-05-04 05:17 UTC] gsivathanu at msn dot com
So, is there a way to find whether the LDAP server is valid or not ?

Gopalan Sivathanu
 [2003-06-27 08:17 UTC] iane at sussex dot ac dot uk
I can't get ldap_connect to return false, even when I 
pass an invalid URI or an invalid hostname. At least, I 
think ".*&%^$" is an invalid 
host name, and so is "4". They both return ldap 
connection resources, though.

It is important, because I need to be able to test the 
hostname validity so that i know whether the problem 
with the host is that (a) it doesn't exist (b) it is 
down (c) the ldap service is down.
 [2004-05-03 17:33 UTC] sanjay_ichalkaranje at yahoo dot com
I was trying to test my code which supposed to tell me whether a LDAP server is alive and rechable or not. But no matter what IP address I specified in ldap_connect it returned a valid resource.

I found a way out by first pinging the server to know whether its alive and then trying to bind to know whether it is running LDAP.
 [2004-07-06 14:31 UTC] mitteljc at e-i dot com
My solution was to go one step further by using 'ldap_bind' to test the connection :
      if ($r) {
         bla bla bla
      else die("LDAP server not accessed !");
The '@' before 'ldap_bind' disables Warning dysplay.
 [2004-08-05 07:58 UTC]
I added sniper's comments to the ldap_connect() docs but am leaving this bug report open until a doc member more familiar with LDAP can close out this bug.  Here's the commit:

 [2004-11-30 22:41 UTC] nigel at cofa dot unsw dot edu dot au
So there is no way if we are using OpenLDAP to 
distinguish betweeen:

* server is up and pingable
* LDAP server is running

 [2004-11-30 23:02 UTC] nigel at cofa dot unsw dot edu dot au
Please delete my comment above.

I found the best solution for me was that I could test 
whether I could do ldap_start_tls($myconnection), and 
although this isn't perfect, works well enough for me 
and is almost equivalent to testing whether the server 
is available.
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Sun Jun 26 00:05:48 2022 UTC