Copyright © 2011-2012 ForgeRock AS
Last updated: February 21, 2012
Hands-on guide to developing applications with the OpenDJ SDK. The OpenDJ project offers open source LDAP directory services in Java.
- Preface
- 1. Understanding LDAP
- 2. Best Practices For LDAP Application Developers
- 3. Getting OpenDJ LDAP SDK
- 4. Using the SDK
- 5. Authenticating To the Directory
- 6. Searching & Comparing Directory Data
- 7. Getting Information About the Directory Service
- 8. Updating Directory Data
- 9. Working With LDIF
- 10. Working With Controls
- 11. Working With Extended Operations
- 12. Writing Multithreaded Applications
- 13. Internationalizing Applications
- 14. Writing a Simple LDAP Proxy
- I. Tools Reference
- Index
This guide shows you how to work with OpenDJ SDK to create client applications in the Java language to connect to LDAP servers and perform LDAP operations.
This guide is written for Java developers who want to build directory client applications with OpenDJ SDK.
This guide starts by explaining LDAP directories briefly, and describing best practices for LDAP client applications. Then it demonstrates how to install and use OpenDJ SDK to build LDAP clients.
You do not need to be an LDAP wizard to learn something from this guide. You do need some background in writing Java 6 and client-server applications to get the most out of this guide. You can nevertheless get started with this guide, and then learn more as you go along.
Some items are formatted differently from other text, like
filenames, commands, and
literal values.
In many cases, sections pertaining to UNIX, GNU/Linux, Mac OS X, BSD,
and so forth are marked (UNIX). Sections pertaining to Microsoft Windows
might be marked (Windows). To avoid repetition, however, file system
directory names are often given only in UNIX format as in
/path/to/OpenDJ, even if the text applies to
C:\path\to\OpenDJ as well.
Core documentation, such as what you are now reading, aims to be technically accurate and complete with respect to the software documented. Core documentation therefore follows a three-phase review process designed to eliminate errors. The review process should slow authors down enough that documentation you get with a stable release has had time to bake fully.
Fully baked core documentation is available at docs.forgerock.org.
The OpenDJ Wiki regularly brings you more, fresh content. In addition, you are welcome to sign up and then edit the Wiki if you notice an error, or if you have something to share.
After you sign up at ForgeRock, you can also login to the Wiki and the issue database to follow what is happening with the project.
If you have questions regarding OpenDJ which are not answered by the documentation, there is a mailing list which can be found at https://lists.forgerock.org/mailman/listinfo/opendj where you are likely to find an answer.
You can join the IRC discussion in the #opendj room at irc.freenode.net.
The Wiki has information on how to check out OpenDJ source code. There is also a mailing list for OpenDJ development which can be found at https://lists.forgerock.org/mailman/listinfo/opendj-dev Should you want to contribute a patch, test, or feature, or want to author part of the core documentation, first have a look on the ForgeRock Community page at how to get involved.
A directory resembles a dictionary or a phone book. If you know a word, you can look it up its entry in the dictionary to learn its definition or its pronunciation. If you know a name, you can look it up its entry in the phone book to find the telephone number and street address associated with the name. If you are bored, curious, or have lots of time, you can also read through the dictionary, phone book, or directory, entry after entry.
Where a directory differs from a paper dictionary or phone book is in how entries are indexed. Dictionaries typically have one index: words in alphabetical order. Phone books, too: names in alphabetical order. Directories entries on the other hand are often indexed for multiple attributes, names, user identifiers, email addresses, telephone numbers. This means you can look up a directory entry by the name of the user the entry belongs to, but also by her user identifier, her email address, or her telephone number, for example.
Phone companies have been managing directories for many decades. The Internet itself has relied on distributed directory services like DNS since the mid 1980s.
It was not until the late 1980s, however, that experts from what is now the International Telecommunications Union brought forth the X.500 set of international standards, including Directory Access Protocol. The X.500 standards specify Open Systems Interconnect (OSI) protocols and data definitions for general-purpose directory services. The X.500 standards were design to meet the needs of systems built according to the X.400 standards, covering electronic mail services.
Lightweight Directory Access Protocol has been around since the early 1990s. LDAP was originally developed as an alternative protocol that would allow directory access over Internet protocols rather than OSI protocols, and be lightweight enough for desktop implementations. By the mid 1990, LDAP directory servers became generally available and widely used.
Until the late 1990s, LDAP directory servers were designed primarily with quick lookups and high availability for lookups in mind. LDAP directory servers replicate data, so when an update is made, that update gets pushed out to other peer directory servers. Thus if one directory server goes down lookups can continue on other servers. Furthermore, if a directory service needs to support more lookups, the administrator can simply add another directory server to replicate with its peers.
As organizations rolled out larger and larger directories serving more and more applications, they discovered that they needed high availability not only for lookups, but also for updates. Around 2000 directories began to support multi-master replication, that is replication with multiple read-write servers. Soon thereafter the organizations with the very largest directories started to need higher update performance as well as availability.
The OpenDJ code base began in the mid 2000s, when engineers solving the update performance issue decided the cost of adapting the existing C-based directory technology for high performance updates would be higher than the cost of building a next generation, high performance directory using Java technology.
LDAP directory data is organized into entries, similar to the entries for words in the dictionary, or for subscriber names in the phone book. A sample entry follows.
Barbara Jensen's entry has a number of attributes, such as
uid: bjensen,
telephoneNumber: +1 408 555 1862, and
objectClass: posixAccount[1]. When you lookup her entry
in the directory, you specify one or more attributes and values to match
in the entries that come back as the result of your search. Typically the
attributes you search for are indexed in the directory, so the directory
server can retrieve them more quickly.[2]
The entry also has a unique identifier, show at the top of the entry,
dn: uid=bjensen,ou=People,dc=example,dc=com. DN stands
for distinguished name. No two entries in the directory have the same
distinguished name.[3]
LDAP entries are arranged hierarchically in the directory. The
hierarchical organization resembles a file system on a PC or a web server,
often imagined as an upside-down tree structure, looking similar to a
pyramid.[4]The distinguished name consists of components
separated by commas,
uid=bjensen,ou=People,dc=example,dc=com. Those components
reflect the hierarchy of directory entries.
Barbara Jensen's entry is located under an entry with DN
ou=People,dc=example,dc=com, an organization unit and
parent entry for the people at Example.com. The
ou=People entry is located under the entry with DN
dc=example,dc=com, the root entry for Example.com.
DC stands for domain component. The directory has other root entries, such
as cn=config, under which the configuration is accessible
through LDAP, and potentially others such as
dc=mycompany,dc=com or o=myOrganization.
Thus when you lookup entries, you specify the parent entry to look under
in the same way you need to know whether to look in the New York, Paris,
or Tokyo phone book to find someone's telephone number.[5]
You may be used to web service client server communication, where each time the web client has something to request of the web server, a connection is set up and then torn down. LDAP has a different model. In LDAP the client application connects to the server and authenticates, then requests any number of operations perhaps processing results in between requests, and finally disconnects when done.
The standard operations are as follows.
Bind (authenticate). The first operation in an LDAP session involves the client binding to the LDAP server, with the server authenticating the client. Authentication identifies the client's identity in LDAP terms, the identity which is later used by the server to authorize (or not) access to directory data that the client wants to lookup or change.
Search (lookup). After binding, the client can request that the server return entries based on an LDAP filter, which is an expression that the server uses to find entries that match the request, and a base DN under which to search. For example, to lookup all entries for people with email address
bjensen@example.comin data for Example.com, you would specify a base DN such asou=People,dc=example,dc=comand the filter(mail=bjensen@example.com).Compare. After binding, the client can request that the server compare an attribute value the client specifies with the value stored on an entry in the directory.
Modify. After binding, the client can request that the server change one or more attribute values stored on one or more entries. Often administrators do not allow clients to change directory data, so request that your administrator set appropriate access rights for your client application if you want to update data.
Add. After binding, the client can request to add one or more new LDAP entries to the server.
Delete. After binding, the client can request that the server delete one or more entries. To delete and entry with other entries underneath, first delete the children, then then parent.
Modify DN. After binding, the client can request that the server change the distinguished name of the entry. For example, if Barbara changes her unique identifier from
bjensento something else, her DN would have to change. For another example, if you decide to consolidateou=Customersandou=Employeesunderou=Peopleinstead, all the entries underneath much change distinguished names. [6]Unbind. When done making requests, the client should request an unbind operation to release resources right away for other clients.
Abandon. When a request seems to be taking too long to complete, or when a search request returns many more matches than desired, the client can send an abandon request to the server to drop the operation in progress. The server then drops the connection without a reply to the client.
LDAP has standardized two mechanisms for extending the kinds of operations that directory servers can perform. One mechanism involves using LDAP controls. The other mechanism involves using LDAP extended operations.
LDAP controls are information added to an LDAP message to further specify how an LDAP operation should be processed. For example, the Server Side Sort Request Control modifies a search to request that the directory server return entries to the client in sorted order. The Subtree Delete Request Control modifies a delete to request that the server also remove child entries of the entry targeted for deletion.
LDAP extended operations are additional LDAP operations not included in the original standard list. For example, the Cancel Extended Operation works like an abandon operation, but finishes with a response from the server after the cancel is complete. The StartTLS Extended Operation allows a client to connect to a server on an unsecure port, but then start Transport Layer Security negotiations to protect communications.
Both LDAP controls and extended operations are demonstrated later in this guide. OpenDJ directory server supports many LDAP controls and a few LDAP extended operations, controls and extended operations matching those demonstrated in this guide.
[1] The
objectClass attribute type indicates which types of
attributes are allowed and optional for the entry. As the entries object
classes can be updated online, and even the definitions of object classes
and attributes are expressed as entries that can be updated online, directory
data is extensible on the fly.
[2] Attribute values do not have to be strings. The directory can use base64 encoding, however, to make binary attribute values, such as passwords, certificates, or photos, portable in text format.
[3] Sometimes your distinguished names include characters that you must escape. The following example shows an entry that includes escaped characters in the DN.
[4] Hence pyramid icons are associated with directory servers.
[5] The root entry for the directory, technically the entry with DN
"" (the empty string), is called the root DSE, and
contains information about what the server supports, including the other
root entries it serves.
[6] Renaming entire branches of entries can be a major operation for the directory, so avoid moving entire branches if you can.
Follow the advice in this chapter to write effective, maintainable, high performance directory client applications.
This chapter introduces OpenDJ LDAP SDK, demonstrating how to get the software and to build a first basic directory client application.
OpenDJ LDAP SDK provides a set of modern, developer-friendly Java APIs as part of the OpenDJ product suite. The product suite includes the client SDK alongside command-line tools and sample code, a 100% pure Java directory server, and more. You can use OpenDJ LDAP SDK to create client applications for use with any server that complies with the Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map, RFC 4510.
OpenDJ LDAP SDK brings you easy-to-use connection management, connection pooling, load balancing, and all the standard LDAP operations to read and write directory entries. OpenDJ LDAP SDK also lets you build applications with capabilities defined in additional draft and experimental RFCs that are supported by modern LDAP servers.
Install an LDAP server such as OpenDJ directory server that you can use to test the applications you develop. Also, load sample data into your server. The sample data used in this guide are available in LDIF form at http://mcraig.org/ldif/Example.ldif.
You can either install a build or build your own from source.
Before you either download a build of OpenDJ LDAP SDK, or get the source code to build your own SDK, make sure you have a Java Development Kit installed. OpenDJ LDAP SDK relies on Java 6 or later. You can check for Java 6 by running the following command.
Download the latest stable OpenDJ LDAP SDK and tools bundle.
Download the latest stable version of the OpenDJ LDAP SDK documentation (javadoc).
Unzip the bundle,
opendj-ldap-toolkit-3.0.0-SNAPSHOT.zip, where you want to install the SDK.$ unzip opendj-ldap-toolkit-3.0.0-SNAPSHOT.zipUnpack the OpenDJ LDAP SDK documentation,
opendj-ldap-sdk-3.0.0-SNAPSHOT-javadoc.jar, under the SDK install directory.$ mkdir opendj-ldap-toolkit-3.0.0-SNAPSHOT/javadoc $ cd opendj-ldap-toolkit-3.0.0-SNAPSHOT/javadoc $ jar -xf /path/to/opendj-ldap-sdk-3.0.0-SNAPSHOT-javadoc.jarAdd the tools to your PATH.
(UNIX) $ export PATH=/path/to/opendj-ldap-toolkit-3.0.0-SNAPSHOT/bin:$PATH(Windows) C:\>set PATH=\\path\to\opendj-ldap-toolkit-3.0.0-SNAPSHOT\bat:%PATH%Add the OpenDJ LDAP SDK for the APIs, the I18N core library, Grizzly I/O framework for the transport, and GlassFish management APIs to your CLASSPATH, typically found under
opendj-ldap-toolkit-3.0.0-SNAPSHOT/lib/.(UNIX) $ export CLASSPATH=/path/to/lib/gmbal-api-only-3.0.0-b023.jar:$CLASSPATH $ export CLASSPATH=/path/to/lib/grizzly-framework-2.1.7.jar:$CLASSPATH $ export CLASSPATH=/path/to/lib/i18n-core-1.4.0.jar:$CLASSPATH $ export CLASSPATH=/path/to/lib/management-api-3.0.0-b012.jar:$CLASSPATH $ export CLASSPATH=/path/to/lib/opendj-ldap-sdk-3.0.0-SNAPSHOT.jar:$CLASSPATH(Windows) C:\>set CLASSPATH=\\path\to\lib\gmbal-api-only-3.0.0-b023.jar:%CLASSPATH% C:\>set CLASSPATH=\\path\to\lib\grizzly-framework-2.1.7.jar:%CLASSPATH% C:\>set CLASSPATH=\\path\to\lib\i18n-core-1.4.0.jar:%CLASSPATH% C:\>set CLASSPATH=\\path\to\lib\management-api-3.0.0-b012.jar:%CLASSPATH% C:\>set CLASSPATH=\\path\to\lib\opendj-ldap-sdk-3.0.0-SNAPSHOT.jar:%CLASSPATH%
Make sure you have Subversion (svn) and Maven (mvn) installed.
Check out the source code.
$ svn co https://svn.forgerock.org/opendj/trunk/opendj3 Error validating server certificate for 'https://svn.forgerock.org:443': - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually! Certificate information: - Hostname: svn.forgerock.org - Valid: from Wed, 23 Feb 2011 00:30:37 GMT until Thu, 23 Feb 2012 21:00:01 GMT - Issuer: Secure Digital Certificate Signing, StartCom Ltd., IL - Fingerprint: 73:96:5c:68:2c:f3:57:0e:e9:ee:6d:74:08:1b:34:16:53:b8:bd:39 (R)eject, accept (t)emporarily or accept (p)ermanently? p ... A opendj3/README U opendj3 ... Checked out revision 6985.Build the modules and install them in the local repository.
$ cd opendj3/ $ mvn install [INFO] Scanning for projects... [INFO] ------------------------------------------------------------------------ [INFO] Reactor build order: [INFO] [INFO] OpenDJ Directory Services Project [INFO] OpenDJ Maven Build Tools [INFO] OpenDJ LDAP SDK [INFO] OpenDJ LDAP Toolkit [INFO] OpenDJ LDAP SDK Examples ... [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESSFUL [INFO] ------------------------------------------------------------------------ [INFO] Total time: 56.658s [INFO] Finished at: Wed Jun 08 09:19:57 CEST 2011 [INFO] Final Memory: 27M/87M [INFO] ------------------------------------------------------------------------Unzip the tools and libraries included in the file,
opendj3/opendj-ldap-toolkit/target/opendj-ldap-toolkit-3.0.0-SNAPSHOT.zip.Add the
opendj-ldap-toolkit-3.0.0-SNAPSHOT/bin(UNIX) oropendj-ldap-toolkit-3.0.0-SNAPSHOT\bat(Windows) directory to your PATH.Set your CLASSPATH to include the OpenDJ LDAP SDK library,
opendj-ldap-sdk-.jar, the I18N core library,i18n-core-1.4.0.jar, the Grizzly framework,grizzly-framework-2.1.7.jar, and the GlassFish management APIs,gmbal-api-only-3.0.0-b023.jar&management-api-3.0.0-b012.jarunderopendj-ldap-toolkit-3.0.0-SNAPSHOT/lib/.Find the OpenDJ LDAP SDK documentation under file:///path/to/opendj3/opendj-ldap-sdk/target/apidocs/index.html.
After you install OpenDJ LDAP SDK and configure your environment as described, if you have a directory server running import sample data, and test your configuration with a sample client application.
If all goes well, Test.java compiles without
errors. The test program displays Babs Jensen's entry in LDIF.
TODO
When your client application connects to the directory, the first operation to perform is a bind operation. The bind operation authenticates the client to the directory.
You perform simple authentication by binding with the distinguished name of a user's directory entry and the user's password. For this reason simple authentication over unsecure network connections should be done only in the lab. If your real end users are providing their passwords, your application must use simple authentication only if the network is secure.
To bind using Barbara Jensen's identity and simple authentication,
for example, your application would provide the DN
uid=bjensen,ou=People,dc=example,dc=com with the
password hifalutin. An example is provided with the
OpenDJ LDAP SDK examples in
org.forgerock.opendj.examples.SimpleAuth.java.
The directory stores the password value used for simple authentication
in binary form on the userPassword attribute of the entry.
In other words, for the purposes of your application the password is not a
string, but instead an array of bytes. Typically the directory is further
configured to store only hashed values of user passwords, rather than plain
text versions. Thus even if someone managed to read the stored password
values, they would still have to crack the hash in order to learn the
actual passwords. When your application performing simple authentication
sends the password value, the directory server therefore hashes the password
value, and then compares the hashed result with the value of the
userPassword on the user entry. If the values match,
then the directory authenticates the user. Once the user has authenticated,
the directory determines authorization for operations on the connection
based on the users identity.
If the password values do not match, a directory might nevertheless authenticate the client application. The LDAP specifications say that in this case, however, the directory authenticates the user as anonymous, therefore no doubt with fewer rights than the normal user, and surely fewer rights than an administrator.
Simple authentication involves sending a user name and password to the directory server. To avoid sending the user name and password in the clear, you can use SSL or Start TLS.
For both SSL and Start TLS, you pass LDAP options to the connection factory in order to set an SSL context, and set whether to use Start TLS. The SSL context lets you set a trust manager to check server certificates, and also set a key manager to provide keys when the server needs to check your client certificates. In the simplest, not-so-secure case, you can set up a trust manager that trusts all certificates.
The following example is an excerpt from the OpenDJ LDAP SDK example,
org.forgerock.opendj.examples.SimpleAuth.java.
A more secure and extensive SSL context would include a trust manager using a trust store and trust manager methods to check server certificates. If you also want to be able to authenticate to the server using your client certificate, you would need a key manager.
The authentication over SSL or using Start TLS in the trust-all case is
much like simple authentication over LDAP without connection-level security.
The primary differences are that you pass the LDAPOptions
to the LDAP connection factory, and that you handle the potential security
exception involved in setting up the SSL context.
Simple Authentication and Security Layer (SASL) provides a way to use other mechanisms for authentication such as Kerberos or Digest authentication, or even to define your own authentication mechanism. The directory server likely advertises supported SASL mechanisms in the root DSE. The follow example shows how to search OpenDJ for supported SASL mechanisms.
Notice that neither the Kerberos (GSSAPI SASL) nor the Anonymous mechanism is enabled by default, though OpenDJ implements both.
In order to use a SASL mechanism to bind, your program must set up
a SASLBindRequest and pass that to the
bind() method of the Connection.
This section shows an example using the SASL PLAIN mechanism, which
takes either a DN or a user ID to authenticate, with an optional DN or user
ID as the authorization ID that identifies the user who performs operations.
The SASL PLAIN mechanism itself does not secure the connection, so the
example uses StartTLS. The example is provided with the OpenDJ LDAP SDK
examples in org.forgerock.opendj.examples.SASLAuth.java.
The following excerpt shows the core of the bind process.
The implementation for getTrustAllOptions(), the
same as in the example above, sets up Start TLS. When you run this example
with both authorization and authentication IDs, authzid
and authcid, set to u:bjensen and
password hifalutin, the bind is successful, and the
program reaches the final line of the try block.
Behind the scenes, OpenDJ has the SASL PLAIN mechanism configured by
default to use the Exact Match Identity Mapper to look up user IDs as
uid values. If you use another directory server, you might
have to configure how it maps user IDs to user entries.
Traditionally directories excel at serving read requests. This chapter covers the read (search and compare) capabilities that OpenDJ LDAP Java SDK provides. The data used in examples here is available online.
An LDAP search looks up entries based on the following parameters.
A filter that indicates which attribute values to match
A base DN that specifies where in the directory information tree to look for matches
A scope that defines how far to go under the base DN
A list of attributes to fetch for an entry when a match is found
For example, imagine you must write an application where users login
using their email address and a password. After the user logs in, your
application displays the user's full name so it is obvious who is logged in.
Your application is supposed to go to the user directory both for
authentication, and also to read user profile information. You are told the
user directory stores user profile entries under base DN
ou=People,dc=example,dc=com, that email addresses are
stored on the standard mail attribute, and full names are
store on the standard cn attribute.
You figure out how to authenticate from the chapter on authentication, in which you learn you need a bind DN and a password to do simple authentication. But how do you find the bind DN given the email? How do you get the full name?
The answer to both questions is that you do an LDAP search for the
user's entry, which has the DN that you use to bind, and you have the server
fetch the cn attribute in the results. Your search uses
the following parameters.
The filter is
(mail=, whereemailAddress)emailAddressis the email address the user provided.The base DN is the one given to you,
ou=People,dc=example,dc=com.For the scope, you figure the user entry is somewhere under the base DN, so you opt to search the whole subtree.
The attribute to fetch is
cn.
TODO: Explain how to do this, either with code from http://opendj.forgerock.org/opendj-ldap-sdk-examples/xref/org/forgerock/opendj/examples/search/Main.html or writing some more directly relevant sample code. The other sections in this chapter can expand more on filters, building search requests, iterating through results, potentially abandoning, but this section should stay focused on the basic example to make the idea clear.
LDAP directories expose what their capabilities through the root DSE. They also expose their schema definitions, which define the sort of entries and attributes can be stored in a directory, over protocol. OpenDJ SDK allows you to look up that information in your client application.
The directory with distinguished name "" (empty
string) is called the root DSE. DSE stands for
DSA-Specific Entry. DSA stands for Directory Server Agent, a single
directory server.
The root DSE serves to expose information over LDAP about what the directory server supports in terms of LDAP controls, auth password schemes, SASL mechanisms, LDAP protocol versions, naming contexts, features, LDAP extended operations, and so forth. The root DSE holds all the information as values of LDAP attributes. OpenDJ defines these attributes as operational. In other words, OpenDJ only returns the attributes if you either request them specifically, or request all operational attributes.
To access the list of what an OpenDJ server supports, for example, get all operational attributes from the root DSE entry as in the following excerpt.
Notice that by default you can access the root DSE after authenticating anonymously. When you look at the entry in LDIF, you see that supported capabilities are generally identified by object identifier (OID).
Three key pieces of information in the entry shown above are attribute
values for namingContexts (showing the base DNs under
which your application can look for user data),
subschemaSubentry (indicating where the LDAP schema are
stored), and supportedLDAPVersion (with OpenDJ seen to
support both LDAPv2 and LDAPv3).
As shown in the previous section, you can check that the root DSE
attribute supportedLDAPVersion has a value of 3.
LDAPv3 has been available since 1997. Client applications built with OpenDJ SDK use LDAPv3.
The root DSE attribute subschemaSubentry shows
the DN of the entry holding LDAP schema definitions. LDAP schema defines the
object classes, attributes types, attribute value syntaxes, matching rules
and so on that constrain entries held by the LDAP server.
The org.forgerock.opendj.ldap.schema package
is devoted to constructing and querying LDAP schemas. The
Schema class for example lets you
readSchemaForEntry() to get the relevant schema from the
subschema subentry, and then validateEntry() to check
an entry your application has constructed before sending the entry to the
server.
TODO
OpenDJ SDK provides capabilities for working with LDAP Data Interchange Format content. This chapter demonstrates how to use those capabilities.
LDAP Data Interchange Format provides a mechanism for representing directory data in text format. LDIF data is typically used to initialize directory databases, but also may be used to move data between different directories that cannot replicate directly, or even as an alternative backup format.
This chapter demonstrates how to use LDAP controls.
Controls provide a mechanism whereby the semantics and arguments of existing LDAP operations may be extended. One or more controls may be attached to a single LDAP message. A control only affects the semantics of the message it is attached to. Controls sent by clients are termed request controls, and those sent by servers are termed response controls.
For OpenDJ, the controls supported are listed in the
Administration Guide appendix, LDAP
Controls. You can access the list of OIDs for
supported LDAP controls by reading the supportedControl
attribute of the root DSE.
The following excerpt shows the Java equivalent of the preceding command.
This chapter demonstrates how to use LDAP extended operations.
Extended operations allow additional operations to be defined for services not already available in the protocol
For OpenDJ, the extended operations supported are listed in the
Administration Guide appendix, LDAP Extended
Operations. You can access the list of OIDs for
supported LDAP controls by reading the supportedExtension
attribute of the root DSE.
The following excerpt shows the Java equivalent of the preceding command.
TODO
TODO
- authrate — measure bind throughput and response time
- ldapcompare — perform LDAP compare operations
- ldapmodify — perform LDAP modify, add, delete, mod DN operations
- ldappasswordmodify — perform LDAP password modifications
- ldapsearch — perform LDAP search operations
- ldifdiff — compare small LDIF files
- ldifmodify — apply LDIF changes to LDIF
- ldifsearch — search LDIF with LDAP filters
- modrate — measure modification throughput and response time
- searchrate — measure search throughput and response time
Name
authrate — measure bind throughput and response time
Synopsis
authrate {options} [filter format string] [attributes...]
Description
This utility can be used to measure bind throughput and response time of a directory service using user-defined bind or search-then-bind operations.
Format strings may be used in the bind DN option as well as the authid and authzid SASL bind options. A search operation may be used to retrieve the bind DN by specifying the base DN and a filter. The retrieved entry DN will be appended as the last argument in the argument list when evaluating format strings.
Options
The following options are supported.
-a, --dereferencePolicy {dereferencePolicy}Alias dereference policy ('never', 'always', 'search', or 'find')
Default value: never
-b, --baseDN {baseDN}Base DN format string
-c, --numConnections {numConnections}Number of connections
Default value: 1
-e, --percentile {percentile}Calculate max response time for a percentile of operations
-f, --keepConnectionsOpenKeep connections open
-g, --argument {generator function or static string}Argument used to evaluate the Java style format strings in program parameters (Base DN, Search Filter). The set of all arguments provided form the the argument list in order. Besides static string arguments, they can be generated per iteration with the following functions:
- "inc({filename})"
Consecutive, incremental line from file
- "inc({min},{max})"
Consecutive, incremental number
- "rand({filename})"
Random line from file
- "rand({min},{max})"
Random number
- "randstr({length},
charSet)" Random string of specified length and optionally from characters in the charSet string. A range of character can be specified with [start-end] charSet notation. If no charSet is specified, the default charSet of [A-Z][a-z][0-9] will be used.
-i, --statInterval {statInterval}Display results each specified number of seconds
Default value: 5
-I, --invalidPassword {invalidPassword}Percent of bind operations with simulated invalid password
Default value: 0
-m, --maxIterations {maxIterations}Max iterations, 0 for unlimited
Default value: 0
-M, --targetThroughput {targetThroughput}Target average throughput to achieve
Default value: 0
-s, --searchScope {searchScope}Search scope ('base', 'one', 'sub', or 'subordinate')
Default value: sub
-S, --scriptFriendlyUse script-friendly mode
LDAP Connection Options
-D, --bindDN {bindDN}DN to use to bind to the server
Default value: cn=Directory Manager
-E, --reportAuthzIDUse the authorization identity control
-h, --hostname {host}Directory server hostname or IP address
Default value: localhost.localdomain
-j, --bindPasswordFile {bindPasswordFile}Bind password file
-K, --keyStorePath {keyStorePath}Certificate key store path
-N, --certNickname {nickname}Nickname of certificate for SSL client authentication
-o, --saslOption {name=value}SASL bind options
-p, --port {port}Directory server port number
Default value: 389
-P, --trustStorePath {trustStorePath}Certificate trust store path
-q, --useStartTLSUse StartTLS to secure communication with the server
-T, --trustStorePassword {trustStorePassword}Certificate trust store PIN
-u, --keyStorePasswordFile {keyStorePasswordFile}Certificate key store PIN file
-U, --trustStorePasswordFile {path}Certificate trust store PIN file
--usePasswordPolicyControlUse the password policy request control
-w, --bindPassword {bindPassword}Password to use to bind to the server
-W, --keyStorePassword {keyStorePassword}Certificate key store PIN
-X, --trustAllTrust all server SSL certificates
-Z, --useSSLUse SSL for secure communication with the server
Exit Codes
- 0
The command completed successfully.
- 89
An error occurred while parsing the command-line arguments.
Examples
The following example demonstrates measuring simple bind performance.
The names.txt contains all the user IDs for the
sample suffix, and all user password values have been set to
password for this example.
Name
ldapcompare — perform LDAP compare operations
Synopsis
ldapcompare {options} [[attribute] | [:] | [value]] [DN...]
Options
The following options are supported.
--assertionFilter {filter}Use the LDAP assertion control with the provided filter
-c, --continueOnErrorContinue processing even if there are errors
-f, --filename {file}LDIF file containing one DN per line of entries to compare
-J, --control {controloid[:criticality[:value|::b64value|:<filePath]]}Use a request control with the provided information
-n, --dry-runShow what would be done but do not perform any operation
-Y, --proxyAs {authzID}Use the proxied authorization control with the given authorization ID
LDAP Connection Options
-D, --bindDN {bindDN}DN to use to bind to the server
Default value: cn=Directory Manager
-E, --reportAuthzIDUse the authorization identity control
-h, --hostname {host}Directory server hostname or IP address
Default value: localhost.localdomain
-j, --bindPasswordFile {bindPasswordFile}Bind password file
-K, --keyStorePath {keyStorePath}Certificate key store path
-N, --certNickname {nickname}Nickname of certificate for SSL client authentication
-o, --saslOption {name=value}SASL bind options
-p, --port {port}Directory server port number
Default value: 389
-P, --trustStorePath {trustStorePath}Certificate trust store path
-q, --useStartTLSUse StartTLS to secure communication with the server
-T, --trustStorePassword {trustStorePassword}Certificate trust store PIN
-u, --keyStorePasswordFile {keyStorePasswordFile}Certificate key store PIN file
-U, --trustStorePasswordFile {path}Certificate trust store PIN file
--usePasswordPolicyControlUse the password policy request control
-V, --ldapVersion {version}LDAP protocol version number
Default value: 3
-w, --bindPassword {bindPassword}Password to use to bind to the server
-W, --keyStorePassword {keyStorePassword}Certificate key store PIN
-X, --trustAllTrust all server SSL certificates
-Z, --useSSLUse SSL for secure communication with the server
Utility Input/Output Options
-i, --encoding {encoding}Use the specified character set for command-line input
--noPropertiesFileNo properties file will be used to get default command line argument values
--propertiesFilePath {propertiesFilePath}Path to the file containing default property values used for command line arguments
-v, --verboseUse verbose mode
Exit Codes
- 0
The command completed successfully.
ldap-errorAn LDAP error occurred while processing the operation.
LDAP result codes are described in RFC 4511. Also see the additional information for details.
- 89
An error occurred while parsing the command-line arguments.
Files
You can use ~/.opendj/tools.properties to set
the defaults for bind DN, host name, and port number as in the following
example.
Examples
The following examples demonstrate comparing Babs Jensen's UID.
The following example uses a matching UID value.
The following example uses a UID value that does not match.
Name
ldapmodify — perform LDAP modify, add, delete, mod DN operations
Synopsis
ldapmodify {options}
Description
This utility can be used to perform LDAP modify, add, delete, and modify DN operations in the directory.
When not using a file to specify modifications, end your input with EOF (Ctrl+D on UNIX, Ctrl+Z on Windows).
Options
The following options are supported.
-a, --defaultAddTreat records with no changetype as add operations
--assertionFilter {filter}Use the LDAP assertion control with the provided filter
-c, --continueOnErrorContinue processing even if there are errors
-f, --filename {file}LDIF file containing the changes to apply
-J, --control {controloid[:criticality[:value|::b64value|:<filePath]]}Use a request control with the provided information
-n, --dry-runShow what would be done but do not perform any operation
--postReadAttributes {attrList}Use the LDAP ReadEntry post-read control
--preReadAttributes {attrList}Use the LDAP ReadEntry pre-read control
-Y, --proxyAs {authzID}Use the proxied authorization control with the given authorization ID
LDAP Connection Options
-D, --bindDN {bindDN}DN to use to bind to the server
Default value: cn=Directory Manager
-E, --reportAuthzIDUse the authorization identity control
-h, --hostname {host}Directory server hostname or IP address
Default value: localhost.localdomain
-j, --bindPasswordFile {bindPasswordFile}Bind password file
-K, --keyStorePath {keyStorePath}Certificate key store path
-N, --certNickname {nickname}Nickname of certificate for SSL client authentication
-o, --saslOption {name=value}SASL bind options
-p, --port {port}Directory server port number
Default value: 389
-P, --trustStorePath {trustStorePath}Certificate trust store path
-q, --useStartTLSUse StartTLS to secure communication with the server
-T, --trustStorePassword {trustStorePassword}Certificate trust store PIN
-u, --keyStorePasswordFile {keyStorePasswordFile}Certificate key store PIN file
-U, --trustStorePasswordFile {path}Certificate trust store PIN file
--usePasswordPolicyControlUse the password policy request control
-V, --ldapVersion {version}LDAP protocol version number
Default value: 3
-w, --bindPassword {bindPassword}Password to use to bind to the server
-W, --keyStorePassword {keyStorePassword}Certificate key store PIN
-X, --trustAllTrust all server SSL certificates
-Z, --useSSLUse SSL for secure communication with the server
Utility Input/Output Options
-i, --encoding {encoding}Use the specified character set for command-line input
--noPropertiesFileNo properties file will be used to get default command line argument values
--propertiesFilePath {propertiesFilePath}Path to the file containing default property values used for command line arguments
-v, --verboseUse verbose mode
Exit Codes
- 0
The command completed successfully.
ldap-errorAn LDAP error occurred while processing the operation.
LDAP result codes are described in RFC 4511. Also see the additional information for details.
- 89
An error occurred while parsing the command-line arguments.
Files
You can use ~/.opendj/tools.properties to set
the defaults for bind DN, host name, and port number as in the following
example.
Examples
The following example demonstrates use of the command to add an entry to the directory.
The following example demonstrates adding a Description attribute to the new user's entry.
The following example demonstrates changing the Description attribute for the new user's entry.
The following example demonstrates deleting the new user's entry.
Name
ldappasswordmodify — perform LDAP password modifications
Synopsis
ldappasswordmodify {options}
Options
The following options are supported.
-a, --authzID {authzID}Authorization ID for the user entry whose password should be changed
The authorization ID is a string having either the prefix
dn:followed by the user's distinguished name, or the prefixu:followed by a user identifier that depends on the identity mapping used to match the user identifier to an entry in the directory. Examples includedn:uid=bjensen,ou=People,dc=example,dc=com, and, if we assume thatbjensenis mapped to Barbara Jensen's entry,u:bjensen.-A, --provideDNForAuthzIDUse the bind DN as the authorization ID for the password modify operation
-c, --currentPassword {currentPassword}Current password for the target user
-C, --currentPasswordFile {file}Path to a file containing the current password for the target user
-J, --control {controloid[:criticality[:value|::b64value|:<filePath]]}Use a request control with the provided information
-n, --newPassword {newPassword}New password to provide for the target user
-N, --newPasswordFile {file}Path to a file containing the new password to provide for the target user
LDAP Connection Options
--certNickname {nickname}Nickname of certificate for SSL client authentication
--connectTimeout {timeout}Maximum length of time (in milliseconds) that can be taken to establish a connection. Use '0' to specify no time out.
Default: 30000
-D, --bindDN {bindDN}DN to use to bind to the server
Default value: cn=Directory Manager
-h, --hostname {host}Directory server hostname or IP address
Default value: localhost.localdomain
-j, --bindPasswordFile {bindPasswordFile}Bind password file
-K, --keyStorePath {keyStorePath}Certificate key store path
-p, --port {port}Directory server port number
Default value: 389
-P, --trustStorePath {trustStorePath}Certificate trust store path
-q, --useStartTLSUse StartTLS to secure communication with the server
--trustStorePassword {trustStorePassword}Certificate trust store PIN
-u, --keyStorePasswordFile {keyStorePasswordFile}Certificate key store PIN file
-U, --trustStorePasswordFile {path}Certificate trust store PIN file
-w, --bindPassword {bindPassword}Password to use to bind to the server
-W, --keyStorePassword {keyStorePassword}Certificate key store PIN
-X, --trustAllTrust all server SSL certificates
-Z, --useSSLUse SSL for secure communication with the server
Utility Input/Output Options
--noPropertiesFileNo properties file will be used to get default command line argument values
--propertiesFilePath {propertiesFilePath}Path to the file containing default property values used for command line arguments
-?, -H, --helpDisplay usage information
-V, --versionDisplay directory server version information
Exit Codes
- 0
The command completed successfully.
ldap-errorAn LDAP error occurred while processing the operation.
LDAP result codes are described in RFC 4511. Also see the additional information for details.
- 89
An error occurred while parsing the command-line arguments.
Files
You can use ~/.opendj/tools.properties to set
the defaults for bind DN, host name, and port number as in the following
example.
Examples
The following example demonstrates a user changing the password for her entry.
Name
ldapsearch — perform LDAP search operations
Synopsis
ldapsearch {options} [filter] [attributes...]
Description
This utility can be used to perform LDAP search operations in the directory.
In the list of attributes to return, you can specify
* to return all user attributes, + to
return all operational attributes, and
@ to return
all attributes associated with the object-classobject-class
such as @person.
Options
The following options are supported.
-a, --dereferencePolicy {dereferencePolicy}Alias dereference policy ('never', 'always', 'search', or 'find')
Default value: never
-A, --typesOnlyOnly retrieve attribute names but not their values
--assertionFilter {filter}Use the LDAP assertion control with the provided filter
-b, --baseDN {baseDN}Base DN format string
-c, --continueOnErrorContinue processing even if there are errors
-C, --persistentSearch ps[:changetype[:changesonly[:entrychgcontrols]]]Use the persistent search control
--countEntriesCount the number of entries returned by the server
-e, --getEffectiveRightsAttribute {attribute}Specifies geteffectiverights control specific attribute list
-f, --filename {file}LDIF file containing the changes to apply
-g, --getEffectiveRightsAuthzid {authzID}Use geteffectiverights control with the provided authzid
-G, --virtualListView {before:after:index:count | before:after:value}Use the virtual list view control to retrieve the specified results page
-J, --control {controloid[:criticality[:value|::b64value|:<filePath]]}Use a request control with the provided information
-l, --timeLimit {timeLimit}Maximum length of time in seconds to allow for the search
Default value: 0
--matchedValuesFilter {filter}Use the LDAP matched values control with the provided filter
-n, --dry-runShow what would be done but do not perform any operation
-s, --searchScope {searchScope}Search scope ('base', 'one', 'sub', or 'subordinate')
Default value: sub
subordinateis an LDAP extension that might not work with all LDAP servers.-S, --sortOrder {sortOrder}Sort the results using the provided sort order
--simplePageSize {numEntries}Use the simple paged results control with the given page size
Default value: 1000
-Y, --proxyAs {authzID}Use the proxied authorization control with the given authorization ID
-z, --sizeLimit {sizeLimit}Maximum number of entries to return from the search
Default value: 0
LDAP Connection Options
-D, --bindDN {bindDN}DN to use to bind to the server
Default value: cn=Directory Manager
-E, --reportAuthzIDUse the authorization identity control
-h, --hostname {host}Directory server hostname or IP address
Default value: localhost.localdomain
-j, --bindPasswordFile {bindPasswordFile}Bind password file
-K, --keyStorePath {keyStorePath}Certificate key store path
-N, --certNickname {nickname}Nickname of certificate for SSL client authentication
-o, --saslOption {name=value}SASL bind options
-p, --port {port}Directory server port number
Default value: 389
-P, --trustStorePath {trustStorePath}Certificate trust store path
-q, --useStartTLSUse StartTLS to secure communication with the server
-T, --trustStorePassword {trustStorePassword}Certificate trust store PIN
-u, --keyStorePasswordFile {keyStorePasswordFile}Certificate key store PIN file
-U, --trustStorePasswordFile {path}Certificate trust store PIN file
--usePasswordPolicyControlUse the password policy request control
-V, --ldapVersion {version}LDAP protocol version number
Default value: 3
-w, --bindPassword {bindPassword}Password to use to bind to the server
-W, --keyStorePassword {keyStorePassword}Certificate key store PIN
-X, --trustAllTrust all server SSL certificates
-Z, --useSSLUse SSL for secure communication with the server
Utility Input/Output Options
-i, --encoding {encoding}Use the specified character set for command-line input
--noPropertiesFileNo properties file will be used to get default command line argument values
--propertiesFilePath {propertiesFilePath}Path to the file containing default property values used for command line arguments
-t, --dontWrapDo not wrap long lines
-v, --verboseUse verbose mode
Exit Codes
- 0
The command completed successfully.
ldap-errorAn LDAP error occurred while processing the operation.
LDAP result codes are described in RFC 4511. Also see the additional information for details.
- 89
An error occurred while parsing the command-line arguments.
Files
You can use ~/.opendj/tools.properties to set
the defaults for bind DN, host name, and port number as in the following
example.
Examples
The following example searches for entries with UID containing
jensen, returning only DNs and uid values.
Name
ldifdiff — compare small LDIF files
Synopsis
ldifdiff [options] source.ldif target.ldif
Description
This utility can be used to compare two LDIF files and report the differences in LDIF format.
Options
The following options are supported.
-a, --ignoreAttrs {file}File containing a list of attributes to ignore when computing the difference.
--checkSchemaTakes into account the syntax of the attributes as defined in the schema to make the value comparison. The provided LDIF files must conform to the server schema.
-e, --ignoreEntries {file}File containing a list of entries (DN) to ignore when computing the difference.
-S, --singleValueChangesEach attribute-level change should be written as a separate modification per attribute value rather than one modification per entry.
-V, --versionDisplay version information.
-?, -H, --helpDisplay usage information.
Examples
The following example demonstrates use of the command with two small LDIF files.
Name
ldifmodify — apply LDIF changes to LDIF
Synopsis
ldifmodify {options}
Description
This utility can be used to apply a set of modify, add, and delete operations against data in an LDIF file.
Options
The following options are supported.
-m, --changesLDIF {ldifFile}LDIF file containing the changes to apply.
-s, --sourceLDIF {ldifFile}LDIF file containing the data to be updated.
-t, --targetLDIF {ldifFile}File to which the updated data should be written.
-V, --versionDisplay version information.
-?, -H, --helpDisplay usage information.
Examples
The following example demonstrates use of the command.
Name
ldifsearch — search LDIF with LDAP filters
Synopsis
ldifsearch {options} [filter] [attribute...]
Options
The following options are supported.
-b, --baseDN {baseDN}The base DN for the search. Multiple base DNs may be specified by providing the option multiple times. If no base DN is provided, then the root DSE will be used.
-f, --filterFile {filterFile}The path to the file containing the search filter(s) to use. If this is not provided, then the filter must be provided on the command line after all configuration options.
-l, --ldifFile {ldifFile}LDIF file containing the data to search. Multiple files may be specified by providing the option multiple times. If no files are provided, the data will be read from standard input.
-o, --outputFile {outputFile}The path to the output file to which the matching entries should be written. If this is not provided, then the data will be written to standard output.
-O, --overwriteExistingAny existing output file should be overwritten rather than appending to it.
-s, --searchScope {scope}The scope for the search. It must be one of 'base', 'one', 'sub', or 'subordinate'. If it is not provided, then 'sub' will be used.
-t, --timeLimit {timeLimit}Maximum length of time (in seconds) to spend processing.
Default value: 0
-T, --dontWrapLong lines should not be wrapped.
-V, --versionDisplay version information.
-z, --sizeLimit {sizeLimit}Maximum number of matching entries to return.
Default value: 0
-?, -H, --helpDisplay usage information.
Examples
The following example demonstrates use of the command.
Name
modrate — measure modification throughput and response time
Synopsis
modrate {options} [[attribute] | [:] | [value format string]...]
Description
This utility can be used to measure modify throughput and response time of a directory service using user-defined modifications.
Options
The following options are supported.
-A, --asynchronousUse asynchronous mode and don't wait for results before sending the next request
-b, --baseDN {baseDN}Base DN format string
-c, --numConnections {numConnections}Number of connections
Default value: 1
-e, --percentile {percentile}Calculate max response time for a percentile of operations
-f, --keepConnectionsOpenKeep connections open
-F, --noRebindKeep connections open and don't rebind
-g, --argument {generator function or static string}Argument used to evaluate the Java style format strings in program parameters (Base DN, Search Filter). The set of all arguments provided form the the argument list in order. Besides static string arguments, they can be generated per iteration with the following functions:
- "inc({filename})"
Consecutive, incremental line from file
- "inc({min},{max})"
Consecutive, incremental number
- "rand({filename})"
Random line from file
- "rand({min},{max})"
Random number
- "randstr({length},
charSet)" Random string of specified length and optionally from characters in the charSet string. A range of character can be specified with [start-end] charSet notation. If no charSet is specified, the default charSet of [A-Z][a-z][0-9] will be used.
-i, --statInterval {statInterval}Display results each specified number of seconds
Default value: 5
-m, --maxIterations {maxIterations}Max iterations, 0 for unlimited
Default value: 0
-M, --targetThroughput {targetThroughput}Target average throughput to achieve
Default value: 0
-S, --scriptFriendlyUse script-friendly mode
-t, --numConcurrentTasks {numConcurrentTasks}Number of concurrent tasks per connection
Default value: 1
LDAP Connection Options
-D, --bindDN {bindDN}DN to use to bind to the server
Default value: cn=Directory Manager
-E, --reportAuthzIDUse the authorization identity control
-h, --hostname {host}Directory server hostname or IP address
Default value: localhost.localdomain
-j, --bindPasswordFile {bindPasswordFile}Bind password file
-K, --keyStorePath {keyStorePath}Certificate key store path
-N, --certNickname {nickname}Nickname of certificate for SSL client authentication
-o, --saslOption {name=value}SASL bind options
-p, --port {port}Directory server port number
Default value: 389
-P, --trustStorePath {trustStorePath}Certificate trust store path
-q, --useStartTLSUse StartTLS to secure communication with the server
-T, --trustStorePassword {trustStorePassword}Certificate trust store PIN
-u, --keyStorePasswordFile {keyStorePasswordFile}Certificate key store PIN file
-U, --trustStorePasswordFile {path}Certificate trust store PIN file
--usePasswordPolicyControlUse the password policy request control
-w, --bindPassword {bindPassword}Password to use to bind to the server
-W, --keyStorePassword {keyStorePassword}Certificate key store PIN
-X, --trustAllTrust all server SSL certificates
-Z, --useSSLUse SSL for secure communication with the server
Exit Codes
- 0
The command completed successfully.
- 89
An error occurred while parsing the command-line arguments.
Examples
The following example demonstrates testing directory performance by using the modrate command to write random 16-character description values to all entries in a sample file.
Name
searchrate — measure search throughput and response time
Synopsis
searchrate {options} [filter format string] [attributes...]
Description
This utility can be used to measure search throughput and response time of a directory service using user-defined searches.
Options
The following options are supported.
-a, --dereferencePolicy {dereferencePolicy}Alias dereference policy ('never', 'always', 'search', or 'find')
Default value: never
-A, --asynchronousUse asynchronous mode and don't wait for results before sending the next request
-b, --baseDN {baseDN}Base DN format string
-c, --numConnections {numConnections}Number of connections
Default value: 1
-e, --percentile {percentile}Calculate max response time for a percentile of operations
-f, --keepConnectionsOpenKeep connections open
-F, --noRebindKeep connections open and don't rebind
-g, --argument {generator function or static string}Argument used to evaluate the Java style format strings in program parameters (Base DN, Search Filter). The set of all arguments provided form the the argument list in order. Besides static string arguments, they can be generated per iteration with the following functions:
- "inc({filename})"
Consecutive, incremental line from file
- "inc({min},{max})"
Consecutive, incremental number
- "rand({filename})"
Random line from file
- "rand({min},{max})"
Random number
- "randstr({length},
charSet)" Random string of specified length and optionally from characters in the charSet string. A range of character can be specified with [start-end] charSet notation. If no charSet is specified, the default charSet of [A-Z][a-z][0-9] will be used.
-i, --statInterval {statInterval}Display results each specified number of seconds
Default value: 5
-m, --maxIterations {maxIterations}Max iterations, 0 for unlimited
Default value: 0
-M, --targetThroughput {targetThroughput}Target average throughput to achieve
Default value: 0
-s, --searchScope {searchScope}Search scope ('base', 'one', 'sub', or 'subordinate')
Default value: sub
-S, --scriptFriendlyUse script-friendly mode
-t, --numConcurrentTasks {numConcurrentTasks}Number of concurrent tasks per connection
Default value: 1
LDAP Connection Options
-D, --bindDN {bindDN}DN to use to bind to the server
Default value: cn=Directory Manager
-E, --reportAuthzIDUse the authorization identity control
-h, --hostname {host}Directory server hostname or IP address
Default value: localhost.localdomain
-j, --bindPasswordFile {bindPasswordFile}Bind password file
-K, --keyStorePath {keyStorePath}Certificate key store path
-N, --certNickname {nickname}Nickname of certificate for SSL client authentication
-o, --saslOption {name=value}SASL bind options
-p, --port {port}Directory server port number
Default value: 389
-P, --trustStorePath {trustStorePath}Certificate trust store path
-q, --useStartTLSUse StartTLS to secure communication with the server
-T, --trustStorePassword {trustStorePassword}Certificate trust store PIN
-u, --keyStorePasswordFile {keyStorePasswordFile}Certificate key store PIN file
-U, --trustStorePasswordFile {path}Certificate trust store PIN file
--usePasswordPolicyControlUse the password policy request control
-w, --bindPassword {bindPassword}Password to use to bind to the server
-W, --keyStorePassword {keyStorePassword}Certificate key store PIN
-X, --trustAllTrust all server SSL certificates
-Z, --useSSLUse SSL for secure communication with the server
Exit Codes
- 0
The command completed successfully.
- 89
An error occurred while parsing the command-line arguments.
Examples
The following example demonstrates measuring search performance.