14.7. Searching with Specified Controls
supportedControlsattribute in its DSE. Some of these define server operations like replication; other are allowed extended operations like get effective rights or dereferencing controls which clients can pass through LDAP operations to the server.
-Eoption by giving the control OID, its criticality for the
ldapsearch, and any information required for the control operation.
14.7.1. Retrieving Effective User Rights
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -b "dc=example,dc=com" -s sub -x -E '!18.104.22.168.22.214.171.124.126.96.36.199=:dn:uid=jsmith,ou=people,dc=example,dc=com' "(objectclass=*)"
14.7.2. Using Server-Side Sorting
-Eflag and the
ssscontrol alias. The structure of the operation sets the attribute by which to sort the results and, optionally, the sort order and ordering rule.
-) is an optional flag that reverses the sort order, which naturally runs descending. The matching rule tables in Section 14.4.4, “Using Matching Rules” contain the ordering rules supported by the Directory Server.
# ldapsearch -D "cn=Directory Manager" -W -p 389 -h server.example.com -b "dc=example,dc=com" -s sub -x -E sss=-uidNumber:188.8.131.52 "(objectclass=*)"
14.7.3. Performing Dereferencing Searches
Figure 14.3. Simple Dereferencing Search Command
memberattribute in the search target entry (the Engineers group) as the deref_attribute. It then returns the locality attribute for each member.
# ldapsearch -x -D "cn=Directory Manager" -W -b "cn=Example,ou=Groups,dc=example,dc=com" -E 'deref=member:mail,cn' "(objectclass=*)" # Engineers, Groups, example.com dn: cn=Engineers,ou=Groups,dc=example,dc=com control: 184.108.40.206.4.1.4203.666.5.16 false MIQAAADNMIQAAAA1BAZtZW1iZXIEK2NuPURld mVsb3BlcnMsIG91PUdyb3VwcywgZGM9ZXhhbXBsZSxkYz1jb20whAAAADIEBm1lbWJlcgQoY249VG VzdGVycywgb3U9R3JvdXBzLCBkYz1leGFtcGxlLGRjPWNvbTCEAAAAVAQGbWVtYmVyBCp1aWQ9ZW5 nLCBvdT1lbmdpbmVlcmluZywgZGM9ZXhhbXBsZSxkYz1jb22ghAAAABowhAAAABQEAWwxhAAAAAsE CUNhbWJyaWRnZQ== # member: <firstname.lastname@example.org><cn=John Smith>;uid=jsmith,ou=people,dc=example,dc=com objectClass: top objectClass: inetuser objectClass: groupofnames cn: Engineers member: uid=jsmith,ou=people,dc=example,dc=com
14.7.4. Using Simple Paged Results
When you start a simple paged results search:
- The client sends the search to the server, together with the paged results control and with how many records to return in the first page.
- Before Directory Server starts returning data, the server generates an estimate how many records can be returned in total.The estimate of records is not an exact number. The total number of records returned can be lower than the estimate. The reasons for such a scenario include
After generating the estimate, the server sends the first set of results, a cookie, and the estimated number of records.
- attributes used in the search filter do not exist in the index. For an optimal result, all queried attributes must be indexed.
- before an entry is send to the client, access control lists (ACL) are validated. Insufficient permissions can prevent the entry from being returned.
- The returned records are displayed in the client. The user can now enter how many records should be returned in the next request. The requested number is now sent, together with the cookie, to the server.
- The server retrieves the requested number of records from the database and sends them together with a cookie to the client.
- The previous two steps are repeated until all records are sent or the search is cancelled.
The format of the simple paged result search option with
ldapsearch -x -D "cn=Directory Manager" -W -b "ou=Engineers,ou=People,dc=example,dc=com" -E pg=3 "(objectclass=*)" cn dn: uid=jsmith,ou=Engineers,ou=People,dc=example,dc=com cn: John Smith dn: uid=bjensen,ou=Engineers,ou=People,dc=example,dc=com cn: Barbara Jensen dn: uid=hmartin,ou=Engineers,ou=People,dc=example,dc=com cn: Henry Martin Results are sorted. next page size (3): 5
5as shown would open the next page of results with five entries.
Simple paged results can be used together with server-side sorting. Server-side sorting is a control which performs the sort process on the server rather than in a client; this is usually done for a search which uses a particular matching rule. (This behavior is defined in RFC 2891.) The OpenLDAP client tools do not support server-side sort with the simple paged results control, but other LDAP utilities such as Perl Net::LDAP do support both.
Some clients may open a single connection to the Directory Server, but send multiple operation requests, including multiple search requests using the simple paged results extension.
VLV indexes are similar to simple paged results in that they also return a usable browsing list of results. The main difference is in how that list is generated. Simple paged results are calculated per search, while VLV indexes are a permanent list. Overall, VLV indexes are faster for searches, but do require some server-side configuration and overhead for the server to maintain.
14.7.5. Pre- and Post-read Entry Response Controls
descriptionattribute and display the value before and after the modification:
ldapmodify -D "cn=Directory Manager" -W -x \
-e \!preread=description -e \!postread=descriptiondn: uid=user,ou=People,dc=example,dc=com changetype: modify replace: description description: new description modifying entry "uid=user,ou=People,dc=example,dc=com" control: 220.127.116.11.1.13.1 false ZCkEJXVpZD1qdXNlcixvdT1QZW9wbGUsZGM9ZXhhbXBsZSxk Yz1jb20wAA== # ==> preread dn: uid=user,ou=People,dc=example,dc=com description: old description # <== preread control: 18.104.22.168.1.13.2 false ZEsEJXVpZD1qdXNlcixvdT1QZW9wbGUsZGM9ZXhhbXBsZSxk Yz1jb20wIjAgBAtkZXNjcmlwdGlvbjERBA9uZXcgZGVzY3JpcHRpb24= # ==> postread dn: uid=user,ou=People,dc=example,dc=com description: new description # <== postread