556 lines
30 KiB
HTML
556 lines
30 KiB
HTML
|
<?xml version="1.0" encoding="utf-8"?>
|
||
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
||
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
|
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US" xml:lang="en-us">
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
|
<meta name="dc.language" scheme="rfc1766" content="en-us" />
|
||
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
|
<!-- US Government Users Restricted Rights -->
|
||
|
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
|
<meta name="dc.date" scheme="iso8601" content="2005-09-06" />
|
||
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 1998, 2006" />
|
||
|
|
<meta name="security" content="public" />
|
||
|
|
<meta name="Robots" content="index,follow"/>
|
||
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
|
<title>Directory Server (LDAP) - ldapsearch</title>
|
||
|
|
<link rel="stylesheet" type="text/css" href="ibmidwb.css" />
|
||
|
|
<link rel="stylesheet" type="text/css" href="ic.css" />
|
||
|
|
</head>
|
||
|
|
<body>
|
||
|
|
<a id="Top_Of_Page" name="Top_Of_Page"></a><!-- Java sync-link -->
|
||
|
|
<script language = "Javascript" src = "../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
|
||
|
|
|
||
|
|
<a name="rzahyldapsrch"></a>
|
||
|
|
<h3 id="rzahyldapsrch">ldapsearch</h3>
|
||
|
|
<p>The LDAP search tool and sample program</p>
|
||
|
|
<p><span class="bold">Synopsis</span></p>
|
||
|
|
<pre class="xmp">ldapsearch [-a deref] [-A] [-b searchbase] [-B] [-C charset] [-d debuglevel]
|
||
|
|
[-D binddn] [-e] [-f file] [-F sep] [-G realm] [-h ldaphost] [-i file] [-K keyfile]
|
||
|
|
[-l timelimit] [-L] [-m mechanism] [-M] [-n] [-N certificatename]
|
||
|
|
[-o attr_type] [-O maxhops] [-p ldapport] [-P keyfilepw] [-q pagesize]
|
||
|
|
[-R] [-s scope ] [-t] [-T seconds] [-U username] [-v] [-V version]
|
||
|
|
[-w passwd | ?] [-z sizelimit] [-y proxydn] [-Y] [-Z]
|
||
|
|
filter [-9 p] [-9 s] [attrs...]</pre>
|
||
|
|
<p><span class="bold">Description</span></p>
|
||
|
|
<p><span class="bold">ldapsearch</span> is a command-line interface to the
|
||
|
|
ldap_search application programming interface (API).</p>
|
||
|
|
<p><span class="bold">ldapsearch</span> opens a connection to
|
||
|
|
an LDAP server, binds, and performs a search using the filter. The filter
|
||
|
|
should conform to the string representation for LDAP filters (see ldap_search
|
||
|
|
in the <a href="../apis/dirserv1.htm">Directory Server APIs</a> for more information
|
||
|
|
about filters).</p>
|
||
|
|
<p>If <span class="bold">ldapsearch</span> finds one or more entries,
|
||
|
|
the attributes specified by attrs are retrieved and the entries and values
|
||
|
|
are printed to standard output. If no attrs are listed, all attributes are
|
||
|
|
returned.</p>
|
||
|
|
<p>To display syntax help for <span class="bold">ldapsearch</span>, type <tt class="xph">ldapsearch -?</tt>.</p>
|
||
|
|
<p><span class="bold">Options</span></p>
|
||
|
|
<dl>
|
||
|
|
<dt class="bold">-a deref</dt>
|
||
|
|
<dd>Specify how aliases dereferencing is done. deref should be one of never,
|
||
|
|
always, search, or find to specify that aliases are never dereferenced, always
|
||
|
|
dereferenced, dereferenced when searching, or dereferenced only when locating
|
||
|
|
the base object for the search. The default is to never dereference aliases.
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-A</dt>
|
||
|
|
<dd>Retrieve attributes only (no values). This is useful when you just want
|
||
|
|
to see if an attribute is present in an entry and are not interested in the
|
||
|
|
specific values.
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-b searchbase</dt>
|
||
|
|
<dd>Use searchbase as the starting point for the search instead
|
||
|
|
of the default. If <span class="bold">-b</span> is not specified,
|
||
|
|
this utility will examine the LDAP_BASEDN environment variable for a searchbase
|
||
|
|
definition. If neither is set, the default base is set to "".
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-B</dt>
|
||
|
|
<dd>Do not suppress display of non-ASCII values. This is useful
|
||
|
|
when dealing with values that appear in alternate character sets such as ISO-8859.1.
|
||
|
|
This option is implied by the <span class="bold">-L</span> option.
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-C charset </dt>
|
||
|
|
<dd>Specifies that strings supplied as input to the ldapsearch utility are
|
||
|
|
represented in a local character set (as specified by charset). String input
|
||
|
|
includes the filter, the bind DN and the base DN. Similarly, when displaying
|
||
|
|
data, <span class="bold">ldapsearch</span> converts data received
|
||
|
|
from the LDAP server to the specified character set. Use the <span class="bold">-C <span class="italic">charset</span></span> option if the input string
|
||
|
|
codepage is different from the job codepage value. Refer to the <a href="../apis/ldap_set_iconv_local_charset.htm">ldap_set_iconv_local_charset()</a> API to see supported charset values. Also,
|
||
|
|
if the <span class="bold">-C</span> option and the <span class="bold">-L</span> option are both specified, input is assumed to be in the specified
|
||
|
|
character set, but output from <span class="bold">ldapsearch</span> is always preserved in its UTF-8 representation, or a base-64 encoded
|
||
|
|
representation of the data when non-printable characters are detected. This
|
||
|
|
is the case because standard LDIF files only contain UTF-8 (or base-64 encoded
|
||
|
|
UTF-8) representations of string data. Note that the supported values for
|
||
|
|
charset are the same values supported for the charset tag that is optionally
|
||
|
|
defined in Version 1 LDIF files.
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-d debuglevel </dt>
|
||
|
|
<dd>Set the LDAP debugging level to debuglevel.
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-D binddn</dt>
|
||
|
|
<dd>Use binddn to bind to the LDAP directory. <span class="bold-italic">binddn</span> should be a string-represented DN (see LDAP Distinguished Names). When
|
||
|
|
used with -m DIGEST-MD5, it is used to specify the authorization ID. It can
|
||
|
|
either be a DN, or an authzId string starting with "u:" or "dn:".
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-e</dt>
|
||
|
|
<dd>Display the LDAP library version information and exit.
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-F sep</dt>
|
||
|
|
<dd>Use sep as the field separator between attribute names and values. The
|
||
|
|
default separator is `=', unless the <span class="bold">-L</span> flag
|
||
|
|
has been specified, in which case this option is ignored.
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-G <span class="italic">realm</span></dt>
|
||
|
|
<dd>Specify the realm. This parameter is optional. When used with -m DIGEST-MD5,
|
||
|
|
the value is passed to the server during the bind.
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-h ldaphost</dt>
|
||
|
|
<dd>Specify an alternate host on which the ldap server is running.
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-i file</dt>
|
||
|
|
<dd>Read a series of lines from file, performing one LDAP search for each
|
||
|
|
line. In this case, the filter given on the command line is treated as a pattern
|
||
|
|
where the first occurrence of %s is replaced with a line from file.
|
||
|
|
If file is a single "-" character, then the lines are read from standard input.
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-K keyfile</dt>
|
||
|
|
<dd>Specify the name of the SSL key database file. If the key database file
|
||
|
|
is not in the current directory, specify the fully-qualified key database
|
||
|
|
filename.
|
||
|
|
<p>If the utility cannot locate a key database, it will
|
||
|
|
use a hard-coded set of default trusted certificate authority roots. The key
|
||
|
|
database file typically contains one or more certificates of certification
|
||
|
|
authorities (CAs) that are trusted by the client. These types of X.509 certificates
|
||
|
|
are also known as trusted roots.</p>
|
||
|
|
<p>This parameter effectively enables
|
||
|
|
the <span class="bold">-Z</span> switch. For Directory Server
|
||
|
|
on i5/OS if you use -Z and do not use -K or -N, the certificate associated
|
||
|
|
with the Directory Services Client application ID will be used.</p>
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-l timelimit</dt>
|
||
|
|
<dd>Wait at most timelimit seconds for a search to complete.
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-L</dt>
|
||
|
|
<dd>Display search results in LDIF format. This option also turns
|
||
|
|
on the <span class="bold">-B</span> option, and causes the <span class="bold">-F</span> option to be ignored.
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-m <span class="italic">mechanism</span></dt>
|
||
|
|
<dd>Use <span class="bold-italic">mechanism</span> to specify the
|
||
|
|
SASL mechanism to be used to bind to the server. The <a href="../apis/ldap_sasl_bind_s.htm">ldap_sasl_bind_s()</a> API is used. The <span class="bold">-m</span> parameter is ignored if <span class="bold">-V 2</span> is
|
||
|
|
set. If <span class="bold">-m</span> is not specified, simple
|
||
|
|
authentication is used. Valid mechanisms are:
|
||
|
|
<ul>
|
||
|
|
<li>CRAM-MD5 - protects the password sent to the server.</li>
|
||
|
|
<li>EXTERNAL - uses the SSL certificate. Requires -Z.</li>
|
||
|
|
<li>GSSAPI - uses the user's Kerberos credentials</li>
|
||
|
|
<li><img src="delta.gif" alt="Start of change" />DIGEST-MD5 - requires that the client send a username value
|
||
|
|
to the server. Requires -U. The -D parameter (usually the bind DN) is used
|
||
|
|
to specify the authorization ID. It can be a DN, or an authzId string starting
|
||
|
|
with u: or dn:.<img src="deltaend.gif" alt="End of change" /></li>
|
||
|
|
<li><img src="delta.gif" alt="Start of change" />OS400_PRFTKN - authenticates to the local LDAP server as the
|
||
|
|
current i5/OS user using the DN of the user in the system projected backend.
|
||
|
|
The -D (bind DN) and -w (password) parameters should not be specified.<img src="deltaend.gif" alt="End of change" /></li></ul>
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-M</dt>
|
||
|
|
<dd>Manage referral objects as regular entries.
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-n</dt>
|
||
|
|
<dd>Show what would be done, but don't actually change entries. Useful for
|
||
|
|
debugging in conjunction with <span class="bold">-v</span>.
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-N certificatename</dt>
|
||
|
|
<dd>Specify the label associated with the client certificate in the key
|
||
|
|
database file.
|
||
|
|
<a name="wq384"></a>
|
||
|
|
<div class="notetitle" id="wq384">Note:</div>
|
||
|
|
<div class="notebody">If the LDAP server is configured
|
||
|
|
to perform server authentication only, a client certificate is not required.
|
||
|
|
If the LDAP server is configured to perform client and server authentication,
|
||
|
|
a client certificate might be required. <span class="italic">certificatename</span> is not required if a default certificate/private key pair has been designated
|
||
|
|
as the default. Similarly, <span class="italic">certificatename</span> is
|
||
|
|
not required if there is a single certificate/private key pair in the designated
|
||
|
|
key database file. This parameter is ignored if neither <span class="bold">-Z</span> nor <span class="bold">-K</span> is specified.</div>For Directory Server on i5/OS if you use -Z and do not use -K or -N,
|
||
|
|
the certificate associated with the Directory Services Client application
|
||
|
|
ID will be used.
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-o <span class="italic">attr_type</span></dt>
|
||
|
|
<dd>To specify an attribute to use for sort criteria of search results,
|
||
|
|
you can use the -o (order) parameter. You can use multiple -o parameters to
|
||
|
|
further define the sort order. In the following example, the search results
|
||
|
|
are sorted first by surname (sn), then by given name, with the given name
|
||
|
|
(givenname) being sorted in reverse (descending) order as specified by the
|
||
|
|
prefixed minus sign ( - ):
|
||
|
|
<pre class="xmp">-o sn -o -givenname</pre>Thus, the
|
||
|
|
syntax of the sort parameter is as follows:
|
||
|
|
<pre class="xmp"> [-]<attribute name>[:<matching rule OID>]</pre>where
|
||
|
|
<ul>
|
||
|
|
<li><tt class="xph">attribute name</tt> is the name of the attribute
|
||
|
|
you want to sort by.</li>
|
||
|
|
<li><tt class="xph">matching rule OID</tt> is the optional OID of a matching
|
||
|
|
rule that you want to use for sorting. The matching rule OID attribute is
|
||
|
|
not supported by the Directory Server, however other LDAP servers might support
|
||
|
|
this attribute.</li>
|
||
|
|
<li>The minus sign ( - ) indicates that the results must be sorted
|
||
|
|
in reverse order.</li>
|
||
|
|
<li>The criticality is always critical.</li></ul>The default ldapsearch operation is not to sort the returned results.
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-O maxhops</dt>
|
||
|
|
<dd>Specify maxhops to set the maximum number of hops that the
|
||
|
|
client library takes when chasing referrals. The default hopcount is 10.
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-p ldapport </dt>
|
||
|
|
<dd>Specify an alternate TCP port where the ldap server is listening.
|
||
|
|
The default LDAP port is 389. If not specified and -Z is specified, the default
|
||
|
|
LDAP SSL port 636 is used.
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-P keyfilepw</dt>
|
||
|
|
<dd>Specify the key database password. This password is required to access
|
||
|
|
the encrypted information in the key database file (which can include one
|
||
|
|
or more private keys). If a password stash file is associated with the key
|
||
|
|
database file, the password is obtained from the password stash file,
|
||
|
|
and the <span class="bold">-P</span> parameter is not required.
|
||
|
|
This parameter is ignored if neither <span class="bold">-Z</span> nor <span class="bold">-K</span> is specified.
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-q <span class="italic">pagesize</span></dt>
|
||
|
|
<dd>To specify paging of search results, two parameters can be used: -q
|
||
|
|
(query page size), and -T (time between searches in seconds). In the following
|
||
|
|
example, the search results return a page (25 entries) at a time, every 15
|
||
|
|
seconds, until all the results for that search are returned. The ldapsearch
|
||
|
|
client handles all connection continuation for each paged results request
|
||
|
|
for the life of the search operation.
|
||
|
|
<p>These parameters can be
|
||
|
|
useful when the client has limited resources or when it is connected through
|
||
|
|
a low-bandwidth connection. In general, it allows you to control the rate
|
||
|
|
at which data is returned from a search request. Instead of receiving all
|
||
|
|
of the results at once, you can get them a few entries (a page) at a time.
|
||
|
|
In addition, you can control the duration of the delay taken between each
|
||
|
|
page request, giving the client time to process the results.</p>
|
||
|
|
<pre class="xmp"> -q 25 -T 15</pre>If the -v (verbose) parameter is specified, ldapsearch
|
||
|
|
lists how many entries have been returned so far, after each page of entries
|
||
|
|
returned from the server, for example, <span class="bold">30 total
|
||
|
|
entries have been returned.</span>
|
||
|
|
<p>Multiple -q parameters are enabled
|
||
|
|
such that you can specify different page sizes throughout the life of a single
|
||
|
|
search operation. In the following example, the first page is 15 entries,
|
||
|
|
the second page is 20 entries, and the third parameter ends the paged result/search
|
||
|
|
operation:</p>
|
||
|
|
<pre class="xmp">-q 15 -q 20 -q 0</pre><p class="indatacontent">In the following example, the
|
||
|
|
first page is 15 entries, and all the rest of the pages are 20 entries, continuing
|
||
|
|
with the last specified <span class="bold">-q</span> value until the
|
||
|
|
search operation completes: </p>
|
||
|
|
<pre class="xmp">-q 15 -q 20</pre><p class="indatacontent">The default ldapsearch
|
||
|
|
operation is to return all entries in a single request. No paging is done
|
||
|
|
for the default ldapsearch operation.</p>
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-R</dt>
|
||
|
|
<dd>Specifies that referrals are not to be automatically followed.
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-s scope</dt>
|
||
|
|
<dd>Specify the scope of the search. scope should be one of base, one, or
|
||
|
|
sub to specify a base object, one-level, or subtree search. The default is
|
||
|
|
sub.
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-t</dt>
|
||
|
|
<dd>Write retrieved values to a set of temporary files. This is useful for
|
||
|
|
dealing with non-ASCII values such as jpegPhoto or audio.
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-T <span class="italic">seconds</span></dt>
|
||
|
|
<dd>Time between searches (in seconds). The <span class="bold">-T</span> option is only supported when the <span class="bold">-q</span> option
|
||
|
|
is specified.
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-U <span class="italic">username</span></dt>
|
||
|
|
<dd>Specify the username. Required with -m DIGEST-MD5 and ignored with any
|
||
|
|
other mechanism.
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-v</dt>
|
||
|
|
<dd>Use verbose mode, with many diagnostics written to standard output.
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-V</dt>
|
||
|
|
<dd>Specifies the LDAP version to be used by ldapmodify when it binds to
|
||
|
|
the LDAP server. By default, an LDAP V3 connection is established. To explicitly
|
||
|
|
select LDAP V3, specify "-V 3". Specify "-V 2" to run as an LDAP V2 application.
|
||
|
|
An application, like ldapmodify, selects LDAP V3 as the preferred protocol
|
||
|
|
by using ldap_init instead of ldap_open.
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-w <span class="italic">passwd</span> | ?</dt>
|
||
|
|
<dd>Use <span class="bold-italic">passwd</span> as the password for
|
||
|
|
authentication. Use the ? to generate a password prompt. .
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-y proxydn</dt>
|
||
|
|
<dd>Set proxied ID for proxied authorization operation.
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-Y</dt>
|
||
|
|
<dd>Use a secure LDAP connection (TLS).
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-z sizelimit</dt>
|
||
|
|
<dd>Limit the results of the search to at most sizelimit entries. This makes
|
||
|
|
it possible to place an upper bound on the number of entries that are returned
|
||
|
|
for a search operation.
|
||
|
|
</dd>
|
||
|
|
<dt class="bold">-Z</dt>
|
||
|
|
<dd>Use a secure SSL connection to communicate with the LDAP server. For
|
||
|
|
Directory Server on i5/OS if you use -Z and do not use -K or -N, the certificate
|
||
|
|
associated with the Directory Services Client application ID will be used.
|
||
|
|
</dd>
|
||
|
|
<dt class="bold"><a id="filterdef" name="filterdef"></a>filter</dt>
|
||
|
|
<dd>Specifies a string representation of the filter to apply in the search.
|
||
|
|
Simple filters can be specified as attributetype=attributevalue. More complex
|
||
|
|
filters are specified using a prefix notation according to the following Backus
|
||
|
|
Naur Form (BNF):
|
||
|
|
<pre class="xmp"><<var class="pv">filter</var>> ::='('<<var class="pv">filtercomp</var>>')'
|
||
|
|
<<var class="pv">filtercomp</var>> ::= <<var class="pv">and</var>>|<<var class="pv">or</var>>|<<var class="pv">not</var>>|<<var class="pv">simple</var>>
|
||
|
|
<<var class="pv">and</var>> ::= '&' <<var class="pv">filterlist</var>>
|
||
|
|
<<var class="pv">or</var>> ::= '|' <<var class="pv">filterlist</var>>
|
||
|
|
<<var class="pv">not</var>> ::= '!' <<var class="pv">filter</var>>
|
||
|
|
<<var class="pv">filterlist</var>> ::= <<var class="pv">filter</var>>|<<var class="pv">filter</var>><<var class="pv">filterlist</var>>
|
||
|
|
<<var class="pv">simple</var>> ::= <<var class="pv">attributetype</var>><<var class="pv">filtertype</var>>
|
||
|
|
<<var class="pv">attributevalue</var>>
|
||
|
|
<<var class="pv">filtertype</var>> ::= '='|'~='|'<='|'>='</pre>The '~=' construct is used to specify approximate matching.
|
||
|
|
The representation for <<var class="pv">attributetype</var>> and <<var class="pv">attributevalue</var>> are as described in <a href="http://www.ietf.org/rfc/rfc2252.txt" target="_blank">"RFC 2252, LDAP V3 Attribute Syntax Definitions"</a>
|
||
|
|
<img src="www.gif" alt="Link outside the Information Center" />. In addition, if the filtertype is '=' then <<var class="pv">attributevalue</var>> can be a single * to achieve an attribute existence test,
|
||
|
|
or can contain text and asterisks ( * ) interspersed to achieve substring
|
||
|
|
matching.
|
||
|
|
<p>For example, the filter "mail=*" finds any
|
||
|
|
entries that have a mail attribute. The filter "mail=*@student.of.life.edu"
|
||
|
|
finds any entries that have a mail attribute ending in the specified string.
|
||
|
|
To put parentheses in a filter, escape them with a backslash (\) character. </p>
|
||
|
|
<a name="wq385"></a>
|
||
|
|
<div class="notetitle" id="wq385">Note:</div>
|
||
|
|
<div class="notebody">A filter like <tt class="xph">"cn=Bob *"</tt>, where there
|
||
|
|
is a space between Bob and the asterisk ( * ), matches "Bob Carter" but not
|
||
|
|
"Bobby Carter" in IBM Directory. The space between "Bob" and the wildcard
|
||
|
|
character ( * ) affects the outcome of a search using filters.</div>
|
||
|
|
<p>See <a href="http://www.ietf.org/rfc/rfc2254.txt" target="_blank">"RFC 2254,
|
||
|
|
A String Representation of LDAP Search Filters"</a>
|
||
|
|
<img src="www.gif" alt="Link outside the Information Center" /> for a more complete description of allowable filters.</p>
|
||
|
|
</dd>
|
||
|
|
</dl>
|
||
|
|
<p><span class="bold">Output format</span></p>
|
||
|
|
<p>If one or more entries are found, each entry is written to standard output
|
||
|
|
in the form: </p>
|
||
|
|
<pre class="xmp"> Distinguished Name (DN)
|
||
|
|
|
||
|
|
attributename=value
|
||
|
|
|
||
|
|
attributename=value
|
||
|
|
|
||
|
|
attributename=value
|
||
|
|
|
||
|
|
...</pre><p class="indatacontent">Multiple entries are separated with a single blank line.
|
||
|
|
If the <span class="bold">-F</span> option is used to specify
|
||
|
|
a separator character, it will be used instead of the `=' character. If the <span class="bold">-t</span> option is used, the name of a temporary
|
||
|
|
file is used in place of the actual value. If the <span class="bold">-A</span> option is given, only the "attributename" part is written.</p>
|
||
|
|
<p><span class="bold">Examples</span></p>
|
||
|
|
<p>The following command: </p><blockquote>
|
||
|
|
<pre class="xmp"> ldapsearch "cn=john doe" cn telephoneNumber</pre> performs a subtree search (using the default search base) for entries
|
||
|
|
with a commonName of "john doe". The commonName and telephoneNumber values
|
||
|
|
are retrieved and printed to standard output. The output might look something
|
||
|
|
like this if two entries are found:
|
||
|
|
<pre class="xmp"> cn=John E Doe, ou="College of Literature, Science, and the Arts",
|
||
|
|
ou=Students, ou=People, o=University of Higher Learning, c=US
|
||
|
|
|
||
|
|
cn=John Doe
|
||
|
|
|
||
|
|
cn=John Edward Doe
|
||
|
|
|
||
|
|
cn=John E Doe 1
|
||
|
|
|
||
|
|
cn=John E Doe
|
||
|
|
|
||
|
|
telephoneNumber=+1 313 555-5432
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
cn=John B Doe, ou=Information Technology Division,
|
||
|
|
ou=Faculty and Staff, ou=People, o=University of Higher Learning, c=US
|
||
|
|
|
||
|
|
cn=John Doe
|
||
|
|
|
||
|
|
cn=John B Doe 1
|
||
|
|
|
||
|
|
cn=John B Doe
|
||
|
|
|
||
|
|
telephoneNumber=+1 313 555-1111
|
||
|
|
|
||
|
|
</pre></blockquote>
|
||
|
|
<p>The command: </p><blockquote>
|
||
|
|
<pre class="xmp">ldapsearch -t "uid=jed" jpegPhoto audio</pre>performs
|
||
|
|
a subtree search using the default search base for entries with user id of
|
||
|
|
"jed". The jpegPhoto and audio values are retrieved and written to temporary
|
||
|
|
files. The output might look like this if one entry with one value for each
|
||
|
|
of the requested attributes is found:
|
||
|
|
<pre class="xmp">cn=John E Doe, ou=Information Technology Division,
|
||
|
|
|
||
|
|
ou=Faculty and Staff,
|
||
|
|
|
||
|
|
ou=People, o=University of Higher Learning, c=US
|
||
|
|
|
||
|
|
audio=/tmp/ldapsearch-audio-a19924
|
||
|
|
|
||
|
|
jpegPhoto=/tmp/ldapsearch-jpegPhoto-a19924
|
||
|
|
|
||
|
|
</pre></blockquote>
|
||
|
|
<p>The command: </p><blockquote>
|
||
|
|
<pre class="xmp">ldapsearch -L -s one -b "c=US" "o=university*" o description</pre>performs a one-level search at the c=US level for all organizations
|
||
|
|
whose organizationName begins with university. Search results will be displayed
|
||
|
|
in the LDIF format (see LDAP Data Interchange Format). The organizationName
|
||
|
|
and description attribute values will be retrieved and printed to standard
|
||
|
|
output, resulting in output similar to this:
|
||
|
|
<pre class="xmp">dn: o=University of Alaska Fairbanks, c=US
|
||
|
|
|
||
|
|
o: University of Alaska Fairbanks
|
||
|
|
|
||
|
|
description: Preparing Alaska for a brave new tomorrow
|
||
|
|
|
||
|
|
description: leaf node only
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
dn: o=University of Colorado at Boulder, c=US
|
||
|
|
|
||
|
|
o: University of Colorado at Boulder
|
||
|
|
|
||
|
|
description: No personnel information
|
||
|
|
|
||
|
|
description: Institution of education and research
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
dn: o=University of Colorado at Denver, c=US
|
||
|
|
|
||
|
|
o: University of Colorado at Denver
|
||
|
|
|
||
|
|
o: UCD
|
||
|
|
|
||
|
|
o: CU/Denver
|
||
|
|
|
||
|
|
o: CU-Denver
|
||
|
|
|
||
|
|
description: Institute for Higher Learning and Research
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
dn: o=University of Florida, c=US
|
||
|
|
|
||
|
|
o: University of Florida
|
||
|
|
|
||
|
|
o: UFl
|
||
|
|
|
||
|
|
description: Shaper of young minds
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
...</pre></blockquote>
|
||
|
|
<p>The command: </p><blockquote>
|
||
|
|
<pre class="xmp">ldapsearch -b "c=US" -o ibm-slapdDN "objectclass=person" ibm-slapdDN</pre>performs a subtree level search at the c=US level for all persons. This
|
||
|
|
special attribute (ibm-slapdDN), when used for sorted searches, sorts the
|
||
|
|
search results by the string representation of the Distinguished Name (DN).
|
||
|
|
The output might look something like this:
|
||
|
|
<pre class="xmp">cn=Al Edwards,ou=Widget Division,ou=Austin,o=IBM,c=US
|
||
|
|
|
||
|
|
cn=Al Garcia,ou=Home Entertainment,ou=Austin,o=IBM,c=US
|
||
|
|
|
||
|
|
cn=Amy Nguyen,ou=In Flight Systems,ou=Austin,o=IBM,c=US
|
||
|
|
|
||
|
|
cn=Arthur Edwards,ou=Widget Division,ou=Austin,o=IBM,c=US
|
||
|
|
|
||
|
|
cn=Becky Garcia,ou=In Flight Systems,ou=Austin,o=IBM,c=US
|
||
|
|
|
||
|
|
cn=Ben Catu,ou=In Flight Systems,ou=Austin,o=IBM,c=US
|
||
|
|
|
||
|
|
cn=Ben Garcia Jr,ou=Home Entertainment,ou=Austin,o=IBM,c=US
|
||
|
|
|
||
|
|
cn=Bill Keller Jr.,ou=In Flight Systems,ou=Austin,o=IBM,c=US
|
||
|
|
|
||
|
|
cn=Bob Campbell,ou=In Flight Systems,ou=Austin,o=IBM,c=US</pre></blockquote>
|
||
|
|
<p>The command:</p><blockquote>
|
||
|
|
<pre class="xmp">ldapsearch –h hostname –o sn –b "o=ibm,c=us" "title=engineer"</pre>returns all entries in an IBM employee directory whose title is "engineer",
|
||
|
|
with the results sorted by surname.</blockquote>
|
||
|
|
<p>The command:</p><blockquote>
|
||
|
|
<pre class="xmp">ldapsearch –h hostname –o -sn –o cn –b "o=ibm,c=us" "title=engineer"</pre>returns all entries in an IBM employee directory whose title is "engineer",
|
||
|
|
with the results sorted by surname (in descending order) and then by common
|
||
|
|
name (in ascending order).</blockquote>
|
||
|
|
<p>The command:</p><blockquote>
|
||
|
|
<pre class="xmp">ldapsearch –h hostname –q 5 –T 3 –b o=ibm,c=us "title=engineer"</pre>returns five entries per page, with a delay of 3 seconds between pages
|
||
|
|
for all entries in an IBM employee directory whose title is "engineer".</blockquote>
|
||
|
|
<p>This example demonstrates searches where a referral object is involved.
|
||
|
|
As discussed in <a href="rzahyref-co.htm#rzahyref-co">LDAP directory referrals</a>, Directory Server LDAP directories can
|
||
|
|
contain referral objects, provided that they contain only the following:</p>
|
||
|
|
<ul>
|
||
|
|
<li>A distinguished name (<tt class="xph">dn</tt>).</li>
|
||
|
|
<li>An objectClass (<tt class="xph">objectClass</tt>).</li>
|
||
|
|
<li>A referral (<tt class="xph">ref</tt>) attribute.</li></ul><blockquote>
|
||
|
|
<p> Assume that 'System_A' holds the referral entry: </p>
|
||
|
|
<pre class="xmp">dn: cn=Barb Jensen, ou=Rochester, o=Big Company, c=US
|
||
|
|
ref: ldap://System_B:389/cn=Barb Jensen,
|
||
|
|
ou=Rochester, o=Big Company, c=US
|
||
|
|
objectclass: referral</pre><p class="indatacontent"> All attributes associated with the entry should
|
||
|
|
reside on 'System_B'.</p>
|
||
|
|
<p>System_B contains an entry:</p>
|
||
|
|
<pre class="xmp">dn: cn=Barb Jensen, ou=Rochester, o=Big Company, c=US
|
||
|
|
cn: Barb Jensen
|
||
|
|
objectclass: organizationalPerson
|
||
|
|
sn: Jensen
|
||
|
|
telephonenumber: (800) 555 1212</pre>
|
||
|
|
<p>When a client issues a request
|
||
|
|
to 'System_A', the LDAP server on System_A responds to the client with the
|
||
|
|
URL: </p>
|
||
|
|
<pre class="xmp">ldap://System_B:389/cn=Barb Jensen,
|
||
|
|
ou=Rochester, o=Big Company, c=US </pre><p class="indatacontent">The
|
||
|
|
client uses this information to issue a request to System_B. If the entry
|
||
|
|
on System_A contains attributes in addition to <tt class="xph">dn</tt>, <tt class="xph">objectclass</tt>, and <tt class="xph">ref</tt>, the server ignores those attributes
|
||
|
|
(unless you specify the <span class="bold">-R</span> flag to indicate not to chase
|
||
|
|
referrals).</p>
|
||
|
|
<p>When the client receives a referral response from a server,
|
||
|
|
it issues the request again, this time to the server to which the returned
|
||
|
|
URL refers. The new request has the same scope as the original request. The
|
||
|
|
results of this search vary depending on the value you specify for the scope
|
||
|
|
of the search (<span class="bold">-b</span>).</p>
|
||
|
|
<p>If you specify <tt class="xph">-s base</tt>, as shown here: </p>
|
||
|
|
<pre class="xmp">ldapsearch -h System_A -b 'ou=Rochester, o=Big Company, c=US'
|
||
|
|
-s base 'sn=Jensen' </pre><p class="indatacontent">the
|
||
|
|
search returns all attributes for all entries with 'sn=Jensen' that reside
|
||
|
|
in <tt class="xph">'ou=Rochester, o=Big Company, c=US'</tt> on both System_A and System_B.</p>
|
||
|
|
<p><img src="delta.gif" alt="Start of change" />If you specify <tt class="xph">-s sub</tt>, as shown here:
|
||
|
|
</p>
|
||
|
|
<pre class="xmp">ldapsearch -s sub "cn=John" </pre><p class="indatacontent">the server would search all suffixes and return all entries with "cn=John".
|
||
|
|
This is known as a subtree search on a null base. The entire directory is
|
||
|
|
searched with one search operation instead of doing multiple searches each
|
||
|
|
with a different suffix as the search base. This type of search operation
|
||
|
|
takes longer and consumes more system resources because it is searching the
|
||
|
|
entire directory (all suffixes).</p>
|
||
|
|
<a name="wq386"></a>
|
||
|
|
<div class="notetitle" id="wq386">Note:</div>
|
||
|
|
<div class="notebody">A subtree search on a null
|
||
|
|
base does not return schema information, change log information, nor anything
|
||
|
|
from the system-projected backend.</div><img src="deltaend.gif" alt="End of change" />
|
||
|
|
<p>If you specify <tt class="xph">-s sub</tt>, as shown here: </p>
|
||
|
|
<pre class="xmp">ldapsearch -h System_A -b 'ou=Rochester, o=Big Company, c=US'
|
||
|
|
-s sub 'sn=Jensen' </pre><p class="indatacontent">the
|
||
|
|
search returns all attributes for all entries with 'sn=Jensen' that reside
|
||
|
|
in or below <tt class="xph">'ou=Rochester, o=Big Company, c=US'</tt> on both System_A
|
||
|
|
and System_B.</p>
|
||
|
|
<p>If you specify <tt class="xph">-s one</tt>, as shown here:
|
||
|
|
</p>
|
||
|
|
<pre class="xmp">ldapsearch -h System_A -b 'ou=Rochester, o=Big Company, c=US'
|
||
|
|
-s one 'sn=Jensen' </pre><p class="indatacontent">the
|
||
|
|
search returns no entries on either system. Instead, the server returns the
|
||
|
|
referral URL to the client:</p>
|
||
|
|
<pre class="xmp">ldap://System_B:389/cn=Barb Jensen,
|
||
|
|
ou=Rochester, o=Big Company, c=US </pre><p class="indatacontent">The client in turn submits a request:</p>
|
||
|
|
<pre class="xmp"> ldapsearch -h System_B -b 'ou=Rochester, o=Big Company, c=US'
|
||
|
|
-s one 'sn=Jensen' </pre><p class="indatacontent">This does not give any results
|
||
|
|
either, because the entry</p>
|
||
|
|
<pre class="xmp">dn: cn=Barb Jensen, ou=Rochester, o=Big Company, c=US</pre><p class="indatacontent">resides at </p>
|
||
|
|
<pre class="xmp">ou=Rochester, o=Big Company, c=US</pre><p class="indatacontent">A search
|
||
|
|
with <tt class="xph">-s one</tt> attempts to find entries in the level immediately below</p>
|
||
|
|
<pre class="xmp">ou=Rochester, o=Big Company, c=US</pre></blockquote>
|
||
|
|
<p><span class="bold">Diagnostics</span></p>
|
||
|
|
<p>Exit status is 0 if no errors occur. Errors result in a non-zero
|
||
|
|
exit status and a diagnostic message being written to standard error.</p>
|
||
|
|
<a id="Bot_Of_Page" name="Bot_Of_Page"></a>
|
||
|
|
</body>
|
||
|
|
</html>
|