Microsoft KB Archive/290732

= Third-Party Programs Receive 18003 (LDAP_RC_TIME_LIMIT_EXCEEDED) Response After an LDAP Search =

Article ID: 290732

Article Last Modified on 5/28/2003

-

APPLIES TO


 * Microsoft Metadirectory Services 2.1
 * Microsoft Metadirectory Services 2.2 Service Pack 1
 * Microsoft Metadirectory Services 2.2 Service Pack 1

-



This article was previously published under Q290732



SYMPTOMS
When third-party programs create Lightweight Directory Access Protocol (LDAP) search requests and submit them to the Microsoft Metadirectory Services (MMS) LDAP port, no search results may be returned. Instead, error code 18003 (LDAP_RC_TIME_LIMIT_EXCEEDED) may be sent as the return code.



CAUSE
This behavior occurs if one or more of the attributes in the search request is not hashed in the MMS database. Because there is no hash value to reference, a linear search of the database is the only method that the MMS server can use to calculate the search results. If the database is large enough, the time for this linear search can exceed the client computer's time-out limit. In this case, the search ends prematurely and the &quot;18003&quot; return code is sent back to the client.



RESOLUTION
To correct this issue, the search criteria must match the capabilities of the MMS database. In particular, the attributes in the search request must be hashed. You can find a complete description of how to configure MMS hashing in the online Microsoft Metadirectory Services: System Administration Manual document in appendix B (&quot;Attribute Hashing and Searching&quot;).

In the following example of an MMS LDAP trace, a compound search request is sent to the MMS server by a third-party program. The trace identifies two attributes that the program uses in its search request: member and uniqueMember. The search translates into:

&quot;Within the subtree which begins at ou=Customers,o=Microsoft,c=US, find all objects where

1) objectClass = groupOfNames AND member = cn=109879,ou=known,ou=customers,o=Microsoft,c=US, OR

2) objectClass = groupOfUniqueNames AND uniqueMember = cn=109879,ou=known,ou=customers,o=Microsoft,c=US, OR

3) objectClass = group AND member = cn=109879,ou=known,ou=customers,o=Microsoft,c=US

Microsoft does not recommend hashing objectClass (see the note later in this article). To ensure the successful completion of this request, both the member and uniqueMember attributes must be hashed.

Incoming Message

messageID->[4] protocolOp-> searchRequest-> baseObject->6f753d43 7573746f 6d657273 2c206f3d  [ou=Customers, o=] 4d696372 6f736f66 742c2063 3d5553    [Microsoft, c=US]

scope->[2] derefAliases->[0] sizeLimit->[0] timeLimit->[100] attrsOnly->[FALSE] [0] Filter-> or-> Filter-> and-> Filter-> equalityMatch-> attributeType->6f626a65 6374636c 617373   [objectclass] attributeValue->67726f75 704f664e 616d6573   [groupOfNames] Filter-> equalityMatch-> attributeType->6d656d62 6572   [member] attributeValue->636e3d31 30393837 392c6f75 3d6b6e6f   [cn=109879,ou=kno] 776e2c6f 753d6375 73746f6d 6572732c   [wn,ou=customers,] 6f3d4d69 63726f73 6f66742c 20633d55   [o=Microsoft,c=US] 53       [S] Filter-> and-> Filter-> equalityMatch-> attributeType->6f626a65 6374636c 617373   [objectclass] attributeValue->67726f75 704f6655 6e697175 654e616d   [groupOfUniqueNam] 6573   [es] Filter-> equalityMatch-> attributeType->756e6971 75654d65 6d626572   [uniqueMember] attributeValue->636e3d31 30393837 392c6f75 3d6b6e6f   [cn=109879,ou=kno] 776e2c6f 753d6375 73746f6d 6572732c   [wn,ou=customers,] 6f3d4d69 63726f73 6f66742c 20633d55   [o=Microsoft,c=US] 53       [S] Filter-> and-> Filter-> equalityMatch-> attributeType->6f626a65 6374636c 617373   [objectclass] attributeValue->67726f75 70   [group] Filter-> equalityMatch-> attributeType->6d656d62 6572   [member] attributeValue->636e3d31 30393837 392c6f75 3d6b6e6f   [cn=109879,ou=kno] 776e2c6f 753d6375 73746f6d 6572732c   [wn,ou=customers,] 6f3d4d69 63726f73 6f66742c 20633d55   [o=Microsoft,c=US] 53       [S] attributes-> OctetString->6f626a65 6374636c 617373   [objectclass] DBG_00 017e 01/08/09 13:45:47.014 (RM_sendLDAPResult) sending LDAP result: [18003][]

Outgoing Message

messageID->[4] protocolOp-> searchResponseResult-> resultCode->[3] matchedDN-> errorMessage->54696d65 206c696d 69742065 78636565   [Time limit excee] 646564   [ded]



MORE INFORMATION
For additional information about gathering LDAP traces on an MMS server, click the article number below to view the article in the Microsoft Knowledge Base:

306207 How to Configure an MMS Server for LDAP Tracing

NOTE: In the MMS schema, the number of defined object classes is typically small. In a live database, the number of objects that use a given class is large. For example, most objects in the database are person objects. All person objects are of type zcPerson. Because the hash tables are of a finite size and are intended to contain references to relatively unique values, if object class were hashed, the hash buckets would likely overflow. The design of the hash tables is to find relatively unique values quickly within the database.

If a search request references a non-hashed attribute, the sequential search of the database might return the expected results in the client-specified time limit. It is impossible to specify the exact criteria that cause the search not to succeed, because the criteria are a combination of the database size, processor and disk access speed, and the size of the subtree.

Additional query words: zoomit

Keywords: kberrmsg kbprb kb3rdparty KB290732

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.