Description

Performs the search for a specified filter on the directory with the scope
of LDAP_SCOPE_SUBTREE. This is equivalent to searching
the entire directory.

From 4.0.5 on it's also possible to do parallel searches. To do this
you use an array of link identifiers, rather than a single identifier,
as the first argument. If you don't want the same base DN and the
same filter for all the searches, you can also use an array of base DNs
and/or an array of filters. Those arrays must be of the same size as
the link identifier array since the first entries of the arrays are
used for one search, the second entries are used for another, and so
on. When doing parallel searches an array of search result
identifiers is returned, except in case of error, then the entry
corresponding to the search will be FALSE. This is very much like
the value normally returned, except that a result identifier is always
returned when a search was made. There are some rare cases where the
normal search returns FALSE while the parallel search returns an
identifier.

Parameters

The search filter can be simple or advanced, using boolean operators in
the format described in the LDAP documentation (see the » Netscape Directory SDK or
» RFC4515 for full
information on filters).

attributes

An array of the required attributes, e.g. array("mail", "sn", "cn").
Note that the "dn" is always returned irrespective of which attributes
types are requested.

Using this parameter is much more efficient than the default action
(which is to return all attributes and their associated values).
The use of this parameter should therefore be considered good
practice.

attrsonly

Should be set to 1 if only attribute types are wanted. If set to 0
both attributes types and attribute values are fetched which is the
default behaviour.

sizelimit

Enables you to limit the count of entries fetched. Setting this to 0
means no limit.

Note:

This parameter can NOT override server-side preset sizelimit. You can
set it lower though.

Some directory server hosts will be configured to return no more than
a preset number of entries. If this occurs, the server will indicate
that it has only returned a partial results set. This also occurs if
you use this parameter to limit the count of fetched entries.

timelimit

Sets the number of seconds how long is spend on the search. Setting
this to 0 means no limit.

Note:

This parameter can NOT override server-side preset timelimit. You can
set it lower though.

deref

Specifies how aliases should be handled during the search. It can be
one of the following:

LDAP_DEREF_NEVER - (default) aliases are never
dereferenced.

LDAP_DEREF_SEARCHING - aliases should be
dereferenced during the search but not when locating the base object
of the search.

LDAP_DEREF_FINDING - aliases should be
dereferenced when locating the base object but not during the search.

LDAP_DEREF_ALWAYS - aliases should be dereferenced
always.

Return Values

Returns a search result identifier or FALSE on error.

Examples

The example below retrieves the organizational unit, surname,
given name and email address for all people in "My Company" where
the surname or given name contains the substring $person. This
example uses a boolean filter to tell the server to look for
information in more than one attribute.

Try to use ldap_list(), if possible. It is much faster. ldap_search searches a scope of LDAP_SCOPE_SUBTREE, but ldap_list searches a scope of just LDAP_SCOPE_ONELEVEL. This made a big difference on Novell eDirectory 8.6.1, even for a query that only returned 130 objects. Using an attribute list, the 4th function parameter (of either function), also made queries faster.

I just posted on the ldap_bind, but I figured it couldn't hurt here since this was the first place I stopped when trying to figure out my problem. My error pointed to ldap_search, but specifying the ldap_connect port was the fix.

When you want to search the entire directory for MS AD, you must specify port 3268 in your bind. This is also true for apache auth_ldap.

I have been working on a script where I needed to get all the users who were member of a specific MS AD group. Because of PHP bug #42060 ( http://bugs.php.net/bug.php?id=42060 ) I could not get all the users back who were member of the group.
After googling for a day I found an article and a patch but it required that I downloaded the source code for php 5.1.6 or 5.2.10 run the patch and than recompile the code to fix the problem.
Problem was
1) I am not a Linux goeroe so I was not very comfortable doing this....
2) I am running the script on a production machine with other code using PHP and did not know what the consequence would bee for that code.
3) I could not update PHP anymore because in newer versions this patch would probably not work any more.

But yesterday I saw the light and wrote some code to get around this problem, maybe other people can use it that have the same problem.

IF($countResult == 1000 OR $countResult == 1500)
{
// loop trough the number 97-122 (ASCII number for the characters a-z)
For($a=97;$a<=122;$a++)
{
// translate the number to a character
$character = chr($a);
// the new search filter withs returns all users with a last name starting with $character
$filter = "(&(sn=$character*)(memberOf=$ADGroup))";
$results = ldap_search($ldapconnect, $userBase, $filter, $attr);
$countResult2 = ldap_count_entries($ldapconnect,$results);

// See if the search for all users starting with a specific character still hits the search limit
// if so than do a new search to find all the users where the last name starts with "aa" and
// than with "ab", "ac" etc. etc
// In the best case we can now find 675.324 users per group when the search limit is 1000
// ((26 * 999 for the fist character) * 26 for the second character)
// and 1.013.324 when the search limit is 1500
If($countResult2 == 1000 or $countResult2 == 1500)
{
For($b=97;$b<=122;$b++)
{
$character2 = chr($b);
$filter2 = "(&(sn=$character$character2*)(memberOf=$ADGroup))";
$results2 = ldap_search($ldapconnect, $userBase, $filter2, $attr);
$count2 = ldap_count_entries($ldapconnect,$results2);
$entries2 = ldap_get_entries($ldapconnect,$results2);

Following from my note of 11-Nov-2009 06:56 regarding DN issues when using LDAP instead of the Global Catalog when querying AD, further investigation was showing that although the results were in the packet, I was getting an error instead:

It appears that the Netscape Directory SDK (developer.netscape.com) referenced for LDAP filter information is no longer accepting connections. The A copy of RFC 2254 which defines the standard for string representations of LDAP filters can be found at http://www.ietf.org/rfc/rfc2254.txt

FYI, for those doing LDAP searches on Exchange servers, there seems to be some preference in Exchange to disallow searches that aren't initial searches (i.e. only x* will work, not * or *x). I'd been going nuts trying to figure out why I kept getting errors doing * searches.

When I tried to search with empty base DN on OpenLDAP server which had "" namingContext I got result "no such object". In the log file there was query for dn: dc=example,dc=com (!).As a workaround, it seems it's enough to feed it with space (' ') as base DN - ldap_search($ds, ' ', '(...filter...)', ...