LDAP Search Concepts / Parameters / Elements

(Last modified: 09Sep2002)

This document (10062361) is provided subject to the disclaimer at the end of this document.

goal

Elements to an LDAP Search Request

fact

Novell Directory Services

Novell LDAP

fix

Searching is probably the most common use of LDAP. Like a phone book, many more users are interested in GETTING information from the directory than are interested in CHANGING information in the directory. LDAP search tools are powerful and are easy to manipulate. The syntax of the elements shown below may be different based on the tool being used for the query. However, the concept of these elements is consistent throughout any LDAP search requests.

NOTE: *****Much of this material is excerpted from an excellent resource manual for the configuration, testing, and development of LDAP for NDS. This information can be found in Novell's LDAP Developer's Guide by Roger G. Harrison, Jim Sermersheim, and Steve Trottier; published 2000 (ISBN 0-7645-4720-8). Page numbers below reference corresponding pages from excerpts.*****

Search Concepts

'An LDAP search request originates from the client and is sent on the network to the LDAP server. If the server is able to successfully perform the search, it sends the search results, along with a result code that indicates success, back to the client. The search results consist of the DNs of each entry that matched your search criteria, along with their attributes and values if requested. If the search was not successful, a result code indicating the type of error encountered is returned to the client.' (p114) Every LDAP search request involves four parameters: Search Base, Search Scope, Search Filter, and Attributes to Return.

Search Elements

Consider the following questions. The elements shown above will provide the information necessary to answer them.
What types of entries are you looking for?
Where in the tree structure do you want to look?
Do you want to see only entries that match a certain condition or criterion?
Do you want to limit the number of returned entries in case your search criteria is too broad?
How long are you willing to wait for the server to finish processing the request?
Do you want to see all of the attributes of the entries that get returned or only certain ones?
Do you want to see the attribute values?

Search Base (p115)
'The search base is the distinguished name, or DN, of the entry in the tree where you would like the search to begin. For example, if you want to do a subtree search beginning at sales.acme, then provide ou=sales,o=acme as the base DN. If you want the search to begin at the root of the tree, then you provide the empty string as the search base.'

Search Scope (p115)
'The scope defines how deep the search extends from the base DN. You can choose to search just the entry specified by the base DN (SCOPE_BASE), all of the entries immediately subordinate to the base DN (SCOPE_ONE), or the entire subtree beginning with the base DN (SCOPE_SUB).

Search Filter (p117)
'The filter defines which entries within the scope you want the server to return to you. If you are doing a subtree search, looking for all of the people who have a first name that begins with Deb, your filter would be givenName=Deb*. The filter syntax is quite flexible but can also be complex. RFC 2254 specifies the syntax for search filters.

Attributes to Return (p118)
'The attribute list specifies which attributes you want returned with each of the entries. You can specify that you want all attributes (the default), that you want no attributes (just the DNs), or that you want a specific list of attributes (if they exist) on the entries. For example, if you are only interested in telephone numbers and e-mail addresses you would supply telephoneNumber and mail in the attribute list.

Filter Types (p137)
Presence Matching.
'At times it may be useful to search for entries that have a specified attribute, regardless of what the attribute is. If you want to test for the presence of an attribute, use the following filter syntax, where <attrname> is replaced with the LDAP name of the desired attribute.
<attrname>=*

Equality Matching.
'Equality matching is similar to presence matching, except you are looking for an exact value for a given attribute. In order for an entry to match this filter, it must contain the named attribute, and one of that attribute's values must be the same as the value in the filter.'
<attrname>=value

Substring Matching.
'Substring matching uses the same syntax as equality matching, but has at least one asterisk character in the value field. A value matches if it is in the same pattern specified in the filter, where zero, one, or multiple chargers would replace the position of the asterisk. For example, the filter cn=*mary* would match cn=mary, cn=maryjane, cn=rosemary, and cn=summary judgment.

Greater Than or Equal, Less Than or Equal.
If an attributes uses a schema type that has defined a way to compare whether one value is greater than another, then you can use greater than or equals, and less than or equals in your filter.
attrname>=value

Compound Filters (p140)
The filter syntax enables the use of AND and OR operators for joining filter elements together. These are prefix operators and can be followed by one or more filter elements. Each of the inner elements and the whole filter must be enclosed in parentheses.

AND.
The AND operator is indicated by the & character and is usually used to further restrict search results. If I wanted to list only inetOrgPerson entries that had telephone numbers I could use this filter: (&(objectClass=inetOrgPerson)(telephoneNumber=*)). All inetOrgPerson objects which also have a telephoneNumber attribute will be listed. Notice that in this example (as with all compound LDAP search filters) the operator comes before the filter elements rather than between them. This is referred to as a preordered expression or a prefixed expression.

OR.
The OR operator is indicated by the | character and is normally used to make a filter less restrictive. If you wanted to find the entry for Jim but couldn't remember if the common name began with Him or James, you could use the filter: (|(cn=jim*)(cn=james*)). Both and AND and the OR operators can have multiple filter elements following them. Additional examples of possible filters are: (&(objectClass=inetOrgPerson)(mail=*acme.com)(cn=mary*)) (|(cn=larry)(cn=moe)(cn=curley)). You will probably find reasons to mix the AND and OR operator in the same filter. Use parenthesis nesting to accomplish this. If you wanted to find inetOrgPerson objects which had a telephoneNumber beginning with either 555 or 556 you could use the filter: (&(objectClass=inetOrgPerson)(|(telephoneNumber=555*)(telephoneNumber=556*))).

NOT.
The NOT operator is represented by the ! Character. It can precede just a single filter element. Here's an example of the NOT operator used in an inner filter element. If you wanted to find all of the Marys except Mary Jones you would try: (&(cn=mary*)(!(sn=jones))). This filter would find everyone whose name is not Mary Jones: (!(&(cn=mary)(sn=jones)).

**LDAP Filters are defined in RFC 2254

document

Document Title:	LDAP Search Concepts / Parameters / Elements
Document ID:	10062361
Solution ID:	NOVL47784
Creation Date:	10May2001
Modified Date:	09Sep2002
Novell Product Class:	Novell eDirectory

disclaimer

The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information.
Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.