IBM Security Verify

 View Only

Examples of Common LDAP search

By Nishant Singhai posted Thu May 14, 2020 06:39 AM

  
IAM.jpg
Authors: Neeraj Tiwari and Nishant Singhai

Here 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.

  1. 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

 

  1. 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

  1. 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

 

 

  1. 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 )

  1. 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.


  1. 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

  1. 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

 

  1. 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

 

  1. 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

 

  1. 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.

 

  1. 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

 

 

  1. 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

 

  1. 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

0 comments
37 views

Permalink