Because the above search visits (and returns in the results) all 20,000 user objects the DC has to work hard to process the search and this is why it is considered expensive.

An inefficient search is one that visits a number of directory entries but returns only a small percentage in the results.  The default threshold is less than 10%.   As an example, the following search of the directory containing 20,000 user objects is likely to be considered inefficient. 

I use the words “likely to be considered inefficient” because it is highly unlikely for there to be 10% of users (2,000) in the directory with a surname of “Zwicki”.  Well, not unless you live in a town in the Swiss Alps.

One thing to bear in mind is that there is a threshold of 1,000 objects before the percentage calculation comes into effect.  In other words if the directory in the example above contained just 50 user objects the search would not be considered inefficient, even if only 2 entries (4%) were returned in the results.

All this is great, but you won’t actually see anything in the event log until you have enabled diagnostics logging by modifying the registry.  Set the following key value to 4 or 5.

On a DC:

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\15 Field Engineering

On a server running an ADAM instance:

HKLM\SYSTEM\CurrentControlSet\Services\<ADAM_Instance_Name>\Diagnostics\15 Field Engineering
 
With the value of 15 Field Engineering set to 4 you will receive a summary report at intervals, which will look similar to the following.
 

Event Type:            Information
Event Source:         NTDS General
Event Category:      Field Engineering
Event ID:                1643
Date:                      4/04/2006
Time:                     12:35:26 p.m.
User:                      NT AUTHORITY\ANONYMOUS LOGON
Computer:              DC1
Description:

Internal event: Active Directory performed the following number of search operations within this time interval.

Time interval (hours):
12

Number of search operations:
30937

 
During this time interval, the following number of search operations were characterized as either expensive or inefficient.

 
Expensive search operations:0

Inefficient search operations:0

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

 
In contrast, if you set the value to 5 you will see an event entry for each search against the directory that breaches the inexpensive and/or inefficient search thresholds.  When I tried this in my lab environment the directory event log quickly starting filling with events (mostly from Exchange searches, as it happens), so you would typically only enable this setting for short periods of time (e.g. when troubleshooting).  The events look similar to this:

Event Type:           Information
Event Source:       NTDS General
Event Category:    Field Engineering
Event ID:                1644
Date:                      5/04/2006
Time:                      9:06:25 a.m.
User:                      TM\Administrator
Computer:             DC1
Description:
Internal event: A client issued a search operation with the following options.

Client:
192.168.21.3

Starting node:
DC=tm,DC=com

Filter: ( &  (objectClass=user)  (objectCategory=CN=Person,CN=Schema,CN=Configuration,DC=tm,DC=com)  (sn=z*) ) 

Search scope:

subtree

Attribute selection:

sAMAccountName

Server controls:

 Visited entries:

24579

Returned entries:

25

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

You can modify the default expensive and inefficient search result thresholds by modifying the registry to include the following DWORD values.  The values do not appear by default, so you will need to create them.

On a DC:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\

Expensive Search Results Threshold

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\

Inefficient Search Results Threshold

If you have a large number of DCs for which you would like to set new values, consider using a GPO linked to the Domain Controllers OU.

On a server running an ADAM instance:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<ADAM_Instance_Name>\Parameters\Expensive Search Results Threshold

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<ADAM_Instance_Name>\Parameters\Inefficient Search Results Threshold

Now that we’ve covered the general concepts of logging expensive and inefficient searches, let’s look at how to log all LDAP searches.  Actually, this involves two simple steps.  The first is to set the value for 15 Field Engineering mentioned earlier to 5.  The second is to set the value for Expensive Search Results Threshold to 1, which has the effect of treating all searches as expensive.

Note that some sources (including the Active Directory Cookbook from O’Reilly) suggest setting the Expensive Search Results Threshold to 0 to log all searches.  When I tried this on Windows 2003 (both ADAM and DC) I wasn’t able to generate any log events.  This may be simply a mistake or possibly because the behaviour has changed between Windows 2000 and 2003.

So why would you want to log all LDAP searches?  Well, sometimes you just want to know what LDAP queries a particular application is throwing out.  I’ve also found it useful for identifying applications that have badly formed LDAP queries.  The event log entry returns the credentials of the account used to run the query as well as the IP address of the client, which provides you with enough information to track down the culprit.