You are on page 1of 9

How to Load Test LDAP with Apache JMeter™

What is LDAP?
 LDAP (Lightweight Directory Access Protocol) is a lightweight protocol for accessing
directory services. LDAP defines the methods by which to access the catalog data, defines
and describes how data is presented in the directory service (Data Model or Information
Model), and determines how the data is loaded (imported) and unloaded (exported) from
the directory service. To import and export, LDAP uses LDIF - LDAP Data Interchange
Format.
 
LDAP is useful for services that utilize a large number of system requests based on attributes
(name: value), and is oriented primarily on reading. For example: the address book, e-mail
address list, and mail server configuration.
 
LDAP does not define how data is stored and manipulated. According to the standard, the
store and access methods are a black box for which back-end modules (data manipulation
mechanisms) are usually responsible for a particular implementation of LDAP. Usually they
use some form of a transactional database.
 
Let’s get to know some Basics Terms:
 The LDAP directory is a data tree in the form of records that are hierarchical in
nature, called the Directory Information Tree (DIT).
 The entry consists of a set of attributes.
 The attribute has a type (name / description) and one or more values.
 Each attribute must be defined in at least one object class (objectClass).
 Attributes and object classes are defined in schemas (the object class is actually
treated as a special attribute type).
 Every entry has a unique ID, called Distinguished Name (DN / dn). DN includes a
Relative Distinguished Name (RDN) and the parent entry's DN.
 The DN of a record is not an attribute. It is not part of the actual recording.
 CN = common name; DC = domain component; SN = SurName

Look at the example below. Here we can see an entry that consists of 8 different
attributes
dn: cn=Blaze Meter,dc=example,dc=com
cn: Blaze Meter
givenName: Blaze
sn: Meter
telephoneNumber: +4 985 888 333 33
mail: blaze@meter.com
manager: cn=John Black, dc=example, dc=com
objectClass: person
objectClass: customer
 
The above entry is a basic example of LDIF format. Any information that you put into your
DIT should be in this format.
 Testing a LDAP server with Apache JMeter™
 
To test LDAP we need to use Apache JMeter’s LDAP Sampler. Before describing our test
implementation we should mention our working environment:
 Ubuntu 16.04 x64
 JMeter™ v.3.1
 OpenLDAP v.2.4.44
 We’ve already created an LDAP Server test.com:
 Server name is “LDAP Server”
 Distinguished name: dc=test,dc=com
 Working on port : 389
 User: admin, password: 1234
 
Let’s create and run a JMeter™ test via LDAP server:
 
1. First of all we need to create a Thread Group. Right Click -> Add-> Thread Group
 
Here we defined “Number of Threads = 50” and “Loop Count = 5”. This allows us to
simulate 50 different requests for 5 times.  I named the Thread Group “LDAP Example”.
 

 
2. Now let’s create a LDAP Request.
  Right click on “LDAP Example” → Add → Sampler → LDAP Extended Request
3. You can see 9 radio buttons. Each of them defines different kinds of requests.
 
Usually we do not need to create requests for each kind of test configuration. Rather,
we should choose depending on our project and its requirements. But now let’s look at
all of them.
 
a) Thread Bind
This request establishes a connection between our JMeter™ and the LDAP Server.
Before starting any work with LDAP, we must connect our JMeter™ to the server.
Add a new LDAP Extended Request Sampler. Choose the “Thread Bind” option
from the menu. Edit the following properties:
 Name: Thread Bind
 Test: Thread Bind
 Servername: test.com
 Port: 389
 DN: dc=test,dc=com
 Username: cn=admin,dc=test,dc=com
 Password: 1234
 

 
b) Search Request
This request allows us to search for any information within all server entries,
according to different fields. This is very useful when we have a large number of
entries. By using this request we verify searches for all entries with “objectClass=*”.
That means “with any objectClass”.
 Add a new LDAP Extended Request Sampler. Choose the “Search Test” option
from the menu. Edit the following properties:
 Name: Search Request
 Test: Search Test
 Search base: cn=TestGroup,cn=Groups, dn=test, dn=com
 Search Filter: (objectClass=*)
 Scope: Perform subtree search
 Attributes: uniquemember
 
c) Compare Test
 
A compare request may be used to determine whether a specified entry has a
particular attribute value. The elements contained in a compare request include:
 The entry DN for which the determination is to be made.
 The attribute description (the attribute type name and zero or more
attribute options) of the attribute for which to make the determination.
 The assertion value for which to make the determination.
 In this test we are going to compare if the “Blaze Meter” entry has an email
attribute equal to “blazemeter@test.com”.
 Add a new LDAP Extended Request Sampler. Choose the “Compare” option
from the menu. Edit the following properties:
 Name: Compare
 Test: Compare
 Entry DN: cn=Blaze Meter, ou=users
 Compare Filter: mail=blazemeter@test.com
 

 
d) Add Test
An Add request can be used for the creation of any new entry in the DIT. This
request includes the DN of the entry that we are creating and the attributes that
must be included in this entry. The set of attributes must include the objectClass
attribute to specify the object classes to include in the entry, and any attributes
required by those object classes and any associated DIT content rule.
 
In this test we are adding new entry, “More Blaze Meter”. This will test the extended
request parametrized with different fields:
 objectClass = person
 password = password
 etc.
 Add a new LDAP Extended Request Sampler. Choose the “Add test” option
from the menu. Edit the following properties:
 Name: Add
 Test: Add test
 Entry DN: cn=More Blaze Meter, ou=users
 Add test: Here we should add different attributes with their values
 

 
e) Modify Test
 A modify request can be used to change the contents of an existing entry in the LDAP
server. This request can include changes that affect multiple attributes (if those attributes
are all in the same entry), and all of those changes will be processed atomically, so they will
either all succeed or will all fail as a unit.
 
In this scenario we test that we can modify values of some attributes from the “More Blaze
Meter” entry.
 Add a new LDAP Extended Request Sampler. Choose the “Modification test” option
from the menu. Edit the following properties:
 Name: Modify
 Test: Modification test
 Entry DN: cn=More Blaze Meter, ou=users
 Modification test: Here we should mention all attributes that we want to add,
replace or delete.
 

 
f) Rename
 
A rename request allows us to change the DN of any existing entry.
 
In this scenario we test that we can change a distinguished entry name “More Blaze Meter”
to “Little More Blaze Meter”
 
Add a new LDAP Extended Request Sampler. Choose the “Rename entry” option from
the menu. Edit the following properties:
 Name: Rename
 Test: Rename entry
 Old entry name: cn=More Blaze Meter, ou=users
 New distinguished name: cn=Little More Blaze Meter, ou=users
 

 
g) Delete
 
A delete request provides us an opportunity to delete any existing entry by its DN.
 
Our scenario will verify that we can delete the entry with DN equals to “Little More Blaze
Meter”.
 
Add a new LDAP Extended Request Sampler. Choose the “Deletion test” option from
the menu. Edit the following properties:
 Name: Delete
 Test: Deletion test
 Delete:  cn=Little More Blaze Meter, ou=users
 

 
h) Single bind/unbind
 
This bind is used for user authentication verification. A LDAP client performs a bind with a
given distinguished name and a password for an authenticated user. This Single bind/unbind
operation is for this purpose. It builds it own separate connection to the LDAP server,
performs a bind operation, and ends the connection again (by sending an unbind).
 
In this test we check if the connection to the test.com server was established, and then if it
was successfully closed.
 
Add a new LDAP Extended Request Sampler. Choose the “Single bind/unbind” option
from the menu. Edit the following properties:
 Name: Single bind/unbind
 Test: Single bind/unbind
 Servername: test.com
 Port: 389
 DN: dc=test,dc=com
 Username: cn=admin,dc=test,dc=com
 Password: 1234
 
 
i) Thread Unbind
 
This request is a signal to our server that we are going to close our connection.
 
In this example we verify if our connection to the server was successfully closed.
 
Add a new LDAP Extended Request Sampler. Choose the “Thread Unbind” option from
the menu. Edit the following properties:
 Name: Thread Unbind
 Test: Thread Unbind
 

 
4. Finally we should add a listener to view the results.
 
Add → Listener → View Results Tree
 
And now our test looks like this:
 
 
Now, when running a test we are able to see information about all our requests.
 
For example, this is the information about the Thread Bind request:
 

 
Congratulations! Here we are - able to create simple tests for LDAP systems.

http://jmeter.apache.org/usermanual/build-ldap-test-plan.html

You might also like