2.2.2 - More search options
There are many parameters we haven’t explained in the previous chapter.
When you send a SearchRequest to the server, you may be anonymous, or you may have been bound before the search is done. Binding on a server creates an LDAP session, which stores the credentials. This is used by the authorization system to filter the requests and the returned data, depending on the server settings.
Not all the server allow an anonymous search : Apache Directory Server default to not enabling such anonymous searches (this is for security questions).
Generally speaking, users do bind before sending a search request.
The LDAP filters can be quite complex. Although they aren’t even close to what SQL provide : there is no way you can do a Join on a LDAP server.
A filter is a set of nodes connected with operators like and, or, not…
Here is the list of possible connectors :
|And||All the nodes should be evaluated to true||(&(objectClass=person)(cn=acme))|
|Or||At least one of the node should be evaluated to true||(|(objectClass=person)(cn=acme))|
|Not||Select the entries that does not evaluate to true for this filter||(!(objectClass=person))|
Each node proceeds a check on the attributeType and value provided in the filter. For instance, the "(o=sevenseas)" filter tells the server to look for all the entries which have an “organization” attribute with a value of “sevenseas”. Here are the various kind of filters you can use :
A Search can span across the whole DIT, or just a subset of it. In LDAP, you can use three different scopes :
- OBJECT : the Object itself, none of its children
- ONELEVEL : all of the base direct children, but not it’s children’s children not the base object
- SUBLEVEL : everything
A search can also list the attributes to be returned. This can be :
- ‘*’ for all the user attributes
- ‘+’ for all the operational attributes
- a list of attributes name
- 1.1 if we don’t want the attributes values to be returned, but we want the entries’ DN that match the filter