Authors: Neeraj Tiwari and Nishant SinghaiHere are some common ldap search commands. The next set of examples assumes the following:
- The server is located on a host named hostname.
- The server uses port number 389. Since this is the not default port, the port number will be sent in the search request.
- The suffix under which all data are stored is o=testdomain,c=internal.
- Returning All Entries
Given the previous information, the following call will return all entries in the directory (subject to the configured size and time resource limits): For example:
/opt/ibm/ldap/V6.4/bin/idsldapsearch -p 389 -h hostname -D cn=root -w password -b "o=testdomain,c=internal" -s sub “objectclass=*”
"objectclass=*" is a search filter that matches any entry in the directory. Since every entry must have an object class, and the objectclass attribute is always indexed, this is a useful search filter to return every entry.
cn=ngrp,cn=susers,o=testdomain,c=internal
objectclass=accessgroup
objectclass=top
cn=ngrp
member=cn=ais7,o=TESTDOMAIN,c=internal
cn=nestedGroupParent,o=testdomain,c=internal
objectclass=groupOfNames
objectclass=ibm-nestedGroup
objectclass=top
cn=nestedGroupParent
description=Group composed of static, and nested members.
ibm-memberGroup=cn=susers,o=testdomain,c=internal
member=cn=ais8,o=TESTDOMAIN,c=internal
- Specifying Search Filters on the Command Line
A search filter can be specified directly on the command line as long as the filter is enclosed in quotation marks ("filter"). If the filter is supplied with the command, do not specify the -f option. For example:
/opt/ibm/ldap/V6.4/bin/idsldapsearch -p 389 -h hostname -D cn=root -w password -b "o=testdomain,c=internal" -s sub "cn=ais11"
cn=ais11,o=TESTDOMAIN,c=internal
cn=ais11
objectclass=person
objectclass=top
sn=ti11
userpassword=object00
- Searching the Root DSE Entry
The root DSE is a special entry that contains a list of all the suffixes supported by the local Directory Server. This entry can be searched by supplying a search base of "", a search scope of base, and a filter of "objectclass=*". For example:
/opt/ibm/ldap/V6.4/bin/idsldapsearch -p 389 -h hostname -D cn=root -w password -b "" -s base "objectclass=*"
ibm-opAttrClasses=++ibmentry
ibm-opAttrClasses=+ibmpwdpolicy
ibm-opAttrClasses=++ibmpwdpolicy
ibm-opAttrClasses=+ibmrepl
ibm-opAttrClasses=++ibmrepl
ibm-slapdReplicateSecurityAttributes=false
ldapsearch to verify IBM LDAP Server started normal mode or configuration mode.
For example:
/opt/ibm/ldap/V6.4/bin/idsldapsearch -h hostname -p 389 -s base "(objectclass=*)" ibm-slapdisconfigurationmode
ibm-slapdisconfigurationmode=FALSE
- Searching the Schema Entry
Directory Server stores all directory server schema in the special cn=schema entry. This entry contains information on every object class and attribute defined for the Directory Server. The following command searches the contents of the cn=schema entry:
/opt/ibm/ldap/V6.4/bin/idsldapsearch -p 389 -h hostname -D cn=root -w password -b "cn=schema" -s base "objectclass=*"
matchingRules=( 2.5.13.6 NAME 'caseExactOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
matchingRules=( 2.5.13.7 NAME 'caseExactSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
matchingRules=( 2.5.13.8 NAME 'numericStringMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
matchingRules=( 2.5.13.9 NAME 'numericStringOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
- Using LDAP_BASEDN
To make searching easier, it is possible to set the search base using the LDAP_BASEDN environment variable. Doing this means that the search base does not have to be set with the -b option. For information on how to set environment variables, see the documentation for the operating system.
Typically, set LDAP_BASEDN to the directory's suffix value. Since the directory suffix is equal to the root, or topmost, entry in the directory, this causes all searches to begin from the directory's root entry.
For example, set LDAP_BASEDN to o=testdomain,c=internal and search for cn=babs jensen in the directory, use the following command-line call:
export LDAP_BASEDN="o=testdomain,c=internal"
/opt/ibm/ldap/V6.4/bin/idsldapsearch -p 389 -h hostname -D cn=root -w password "cn=ais11"
cn=ais11,o=TESTDOMAIN,c=internal
cn=ais11
objectclass=person
objectclass=top
sn=ti11
userpassword=object00
unset LDAP_BASEDN
In this example, the default scope of sub is used because the -s option was not used to specify the scope.
- Displaying Subsets of Attributes
The idsldapsearch command returns all search results in LDIF format. By default, idsldapsearch returns the entry's distinguished name and all of the attributes that a user is allowed to read. The directory access control can be set such that users are allowed to read only a subset of the attributes on any given directory entry. Only operational attributes are not returned. For operational attributes to be returned as a result of a search operation, explicitly specify them in the search command.
It may not be necessary to have all of the attributes for an entry returned in the search results. The returned attributes can be limited to just a few specific attributes by specifying the desired ones on the command line immediately after the search filter. For example, to show the cn and sn attributes for every entry in the directory, use the following command-line call:
/opt/ibm/ldap/V6.4/bin/idsldapsearch -p 389 -h hostname -D cn=root -w password -b "o=testdomain,c=internal" -s sub "objectclass=*" sn cn
cn=Jahn Dae,ou=Austin,o=testdomain,c=internal
cn=Jahn Dae
sn=Dae
cn=susers,o=testdomain,c=internal
cn=susers
cn=ngrp,cn=susers,o=testdomain,c=internal
cn=ngrp
cn=nestedGroupParent,o=testdomain,c=internal
cn=nestedGroupParent
- Searching for Operational Attributes
Operational attributes are special attributes set by the Directory Server itself that are used by the server to perform maintenance tasks, like processing access control instructions. They also show specific information about the entry, like the time it was initially created and the name of the user who created it. Operational attributes are available for use on every entry in the directory, regardless of whether the attribute is specifically defined for the object class of the entry.
Operational attributes are not returned in regular idsldapsearch, so to return operational attributes, they have to be explicitly specified in the idsldapsearch request.
/opt/ibm/ldap/V6.4/bin/idsldapsearch -p 389 -h hostname -D cn=root -w password -b "o=testdomain,c=internal" -s sub "objectclass=*" creatorsName createTimestamp modifiersName modifyTimestamp
cn=ngrp,cn=susers,o=testdomain,c=internal
modifiersName=CN=ROOT
modifyTimestamp=20200427125557.597828Z
creatorsName=CN=ROOT
createTimestamp=20200427125400.189339Z
cn=nestedGroupParent,o=testdomain,c=internal
modifiersName=CN=ROOT
modifyTimestamp=20200427131628.750250Z
creatorsName=CN=ROOT
createTimestamp=20200427131628.750250Z
/opt/ibm/ldap/V6.4/bin/idsldapsearch -h hostname -p 389 -D cn=root -w password -s sub -b "" "cn=ais11" +
ibm-replicationThisServerIsMaster=TRUE
ibm-replicationIsQuiesced=FALSE
ownerpropagate=TRUE
ownersource=default
aclpropagate=TRUE
aclsource=O=TESTDOMAIN,C=INTERNAL
entryowner=access-id:CN=ROOT
ibm-effectiveAcl=access-id:CN=THIS:at.userPassword:rwsc
aclentry=access-id:CN=THIS:at.userPassword:rwsc
/opt/ibm/ldap/V6.4/bin/idsldapsearch -h hostname -p 389 -D cn=root -w password -s sub -b "" objectclass=* +
** + A plus sign indicates that the operational attributes should be returned.
LDAP Search to get all attributes other than operational attribute:
/opt/ibm/ldap/V6.4/bin/idsldapsearch -h hostname -p 389 -D cn=root -w password -s sub -b "" "cn=ais11" *
/opt/ibm/ldap/V6.4/bin/idsldapsearch -h hostname -p 389 -D cn=root -w password -s sub -b "" objectclass=* *
cn=ais7,o=TESTDOMAIN,c=internal
cn=bis3,o=TESTDOMAIN,c=internal
cn=cis3,o=TESTDOMAIN,c=internal
cn=cis9,o=TESTDOMAIN,c=internal
cn=gp1,cn=grp1,cn=group1,o=testdomain,c=internal
** ‘*’ An asterisk in the list indicates all attribute types other than operational attributes should be returne
- Searching the ACL Entry
The effective ACI or entryOwner values can be retrieved by simply specifying the desired ACL or entryOwner attributes in a search.
idsldapsearch -h hostname -p port -D <admin_dn> -w <admin_dn_password> -s sub -b "" <filter> +ibmaci
Example: Below search gives the effective acl and all attached acl to matching entry where common name is ais11.
/opt/ibm/ldap/V6.4/bin/idsldapsearch -h hostname -p 389 -D cn=root -w password -s sub -b "" "cn=ais11" +ibmaci
cn=ais11,o=TESTDOMAIN,c=internal
ownerpropagate=TRUE
ownersource=default
aclpropagate=TRUE
aclsource=O=TESTDOMAIN,C=INTERNAL
entryowner=access-id:CN=ROOT
ibm-effectiveAcl=access-id:CN=THIS:at.userPassword:rwsc
aclentry=access-id:CN=THIS:at.userPassword:rwsc
In above commands we can use "++ibmaci" instead of "+ibmaci" to get ALL access control related operational attributes.
+ibmentry
Returns the operational attributes every entry contains, such as
creatorsName, create_Timestamp, and modifiersname to name a
few.
/opt/ibm/ldap/V6.4/bin/idsldapsearch -h hostname -p 389 -D cn=root -w password -s sub -b "" "cn=ais11" +ibmentry
cn=ais11,o=TESTDOMAIN,c=internal
ibm-entryuuid=61bc4bc0-0ece-103a-8394-b41f25d6dfb5
modifiersname=CN=ROOT
modifytimestamp=20200409165329.696067Z
creatorsname=CN=ROOT
createtimestamp=20200409165329.696067Z
subschemasubentry=cn=schema
ibm-capabilitiessubentry=cn=ibm-capabilities,o=TESTDOMAIN,c=internal
ibm-replicationThisServerIsMaster=TRUE
ibm-replicationIsQuiesced=FALSE
- Searching the password policy information
We can get password policy information using below ldap search for specific user and global policy details.
idsldapsearch -h hostname -p port -D <admin_dn> -w <admin_dn_password> -s base -b "<UserEntryDN>" objectclass=* +ibmpwdpolicy
/opt/ibm/ldap/V6.4/bin/idsldapsearch -h hostname -p 389 -D cn=root -w password -s base -b "cn=ais11,o=testdomain,c=internal" "objectclass=*" +ibmpwdpolicy
lass=*" +ibmpwdpolicy
cn=ais11,o=TESTDOMAIN,c=internal
+ibmpwdpolicy
Returns operational attributes related to password policy.
++ibmpwdpolicy
Includes ALL operational attributes related to password policy.
Getting Global password policy:
idsldapsearch -D <admin_dn> -w <admin_dn_password> -s base -b "cn=pwdpolicy,cn=ibmPolicies" objectclass=*
/opt/ibm/ldap/V6.4/bin/idsldapsearch -h hostname -p 389 -D cn=root -w password -s base -b "cn=pwdpolicy,cn=ibmPolicies" objectclass=*
passwordMinDiffChars=0
ibm-pwdPolicy=false
pwdLockout=false
pwdAllowUserChange=true
pwdMustChange=true
pwdSafeModify=false
ibm-pwdGroupAndIndividualEnabled=false
- Searching the Replication topology information
For replication topology information, we can use below search, which will provide all configuration for replication.
idsldapsearch -h hostname -p port -D <admin_dn> -w <admin_dn_password> -s sub -b "" objectclass=ibm-repl*
/opt/ibm/ldap/V6.4/bin/idsldapsearch -h hostname -p 389 -D cn=root -w password -s sub -b "" objectclass=ibm-repl*
IBM-REPLICAGROUP=DEFAULT,CN=IBMPOLICIES
objectclass=top
objectclass=ibm-replicaGroup
ibm-replicaGroup=default
CN=IBMPOLICIES
cn=IBMpolicies
objectclass=container
objectclass=top
objectclass=ibm-replicationContext
+ibmrepl
Returns operational attributes related to replication.
/opt/ibm/ldap/V6.4/bin/idsldapsearch -h hostname -p 389 -D cn=root -w password -s sub -b "" objectclass=* +ibm-repl
cn=bis3,o=TESTDOMAIN,c=internal
cn=cis3,o=TESTDOMAIN,c=internal
cn=cis9,o=TESTDOMAIN,c=internal
cn=gp1,cn=grp1,cn=group1,o=testdomain,c=internal
++ibmrepl
Includes ALL operational attributes related to replication.
- Searching the Users group information
Listing member information:
idsldapsearch -h hostname -p port -D <admin_dn> -w <admin_dn_password> -s sub -b "<group dn>" objectclass=* ibm-allmembers
Listing user group information:
idsldapsearch -h hostname -p port -D <admin_dn> -w <admin_dn_password> -s sub -b "<user dn>" objectclass=* ibm-allgroups
Examples: Listing all the members of group "demo":
idsldapsearch -p 389 -D cn=root -w root -s sub -b "cn=groups,o=ibm,c=in" objectclass=* ibm-allmembers
cn=groups,o=ibm,c=in
ibm-allmembers=secAuthority=Default
ibm-allmembers=cn=admin,o=ibm,c=in
ibm-allmembers=cn=nishant,o=ibm,c=in
Listing all groups belongs to user "nishant":
idsldapsearch -p 389 -D cn=root -w root -s sub -b "cn=nishant,o=ibm,c=in" objectclass=* ibm-allgroups
cn=nishant,o=ibm,c=in
ibm-allgroups=cn=groups,o=ibm,c=in
- Searching the enabled/supported Capabilities information
Below search provide enabled and supported capabilities information from installed LDAP server.
idsldapsearch -s base -b "" objectclass=* ibm-enabledcapabilities
/opt/ibm/ldap/V6.4/bin/idsldapsearch -h hostname -p 389 -D cn=root -w password -s base -b "" objectclass=* ibm-enabledcapabilities
ibm-enabledcapabilities=1.3.18.0.2.32.87
ibm-enabledcapabilities=1.3.18.0.2.32.92
ibm-enabledcapabilities=1.3.18.0.2.32.94
ibm-enabledcapabilities=1.3.18.0.2.32.102
ibm-enabledcapabilities=1.3.18.0.2.32.103
ibm-enabledcapabilities=1.3.18.0.2.32.104
To see the supported capabilities, one can issue following command:
idsldapsearch -s base -b "" objectclass=* ibm-supportedcapabilities
/opt/ibm/ldap/V6.4/bin/idsldapsearch -h hostname -p 389 -D cn=root -w password -s base -b "" objectclass=* ibm-supportedcapabilities
ibm-supportedcapabilities=1.3.18.0.2.32.102
ibm-supportedcapabilities=1.3.18.0.2.32.103
ibm-supportedcapabilities=1.3.18.0.2.32.104
ibm-supportedcapabilities=1.3.18.0.2.32.105
ibm-supportedcapabilities=1.3.18.0.2.32.106
ibm-supportedcapabilities=1.3.18.0.2.32.107
ibm-supportedcapabilities=1.3.18.0.2.32.108
- Searching the Server status information which help to monitor server performance
These searches are very helpful to get server status and performance status of LDAP server.
idsldapsearch -D <adminDN> -w <adminPW> -h <servername> -p <portnumber> -b cn=monitor -s base objectclass=*
Above command list details like totalconnections, livethreads, cache size, worker threads, connection status and more.
We can get specific details using below commands.
a> To view server connections, issue the command:
idsldapsearch -D <adminDN> -w <adminPW> -h <servername> -p <portnumber> -b cn=connections,cn=monitor -s base objectclass=*
Example:
/opt/ibm/ldap/V6.4/bin/idsldapsearch -h hostname -p 389 -D cn=root -w password -b cn=monitor -s base objectclass=*
auditinfo=record_sent_server:0, record_sent_session:0, ibm-slapdLog:/home/ldapinst/idsslapd-ldapinst/logs/audit.log, ibm-auditVersion:3, ibm-audit:false, ibm-auditFailedOPonly:false, ibm-auditBind:true, ibm-auditUnbind:true, ibm-auditSearch:true, ibm-auditAdd:true, ibm-auditModify:true, ibm-auditDelete:true, ibm-auditModifyDN:true, ibm-auditExtOPEvent:true, ibm-auditExtOp:true, ibm-auditAttributesOnGroupEvalOp:true, ibm-auditCompare:true, ibm-auditGroupsOnGroupControl:true, ibm-auditPerformance:true, ibm-auditPTABindInfo:true
en_currentregs=0
en_notificationssent=0
currentpersistentsearches=0
persistentsearchpendingchanges=0
persistentsearchprocessedchanges=0
lostpersistentsearchconns=0
bypass_deref_aliases=true
available_workers=14
current_workqueue_size=0
largest_workqueue_size=4
idle_connections_closed=0
auto_connection_cleaner_run=0
idsldapsearch -D <adminDN> -w <adminPW> -h <servername> -p <portnumber> -b cn=workers,cn=monitor -s base objectclass=*
Example:
/opt/ibm/ldap/V6.4/bin/idsldapsearch -h hostname -p 389 -D cn=root -w password -s base -b cn=workers,cn=monitor objectclass=*
cn=workers,cn=monitor
cn=workers
objectclass=container
cn=thread140640930944768,cn=workers,cn=monitor
thread=140640930944768
c> To view the changelog information
idsldapsearch -D <adminDN> -w <adminPW> -h <servername> -p <portnumber> -b “cn=changelog,cn=monitor” -s base objectclass=*
Example:
/opt/ibm/ldap/V6.4/bin/idsldapsearch -h hostname -p 389 -D cn=root -w password -s base -b “cn=monitor” objectclass=*
en_currentregs=0
en_notificationssent=0
currentpersistentsearches=0
persistentsearchpendingchanges=0
persistentsearchprocessedchanges=0
lostpersistentsearchconns=0
bypass_deref_aliases=true
available_workers=14
current_workqueue_size=0
largest_workqueue_size=4
idle_connections_closed=0
auto_connection_cleaner_run=0