How to Do an LDAP Test

LDAP is a useful protocol 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. But how do we test these systems?

This blog will give a step-by-step tutorial on how to create simple LDAP tests to make sure you are effectively validating your LDAP systems. 

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, and defines and describes how data is presented in the directory service (Data Model or Information Model).

Plus, LDAP 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 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 eight 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.

Running an LDAP Test 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 an LDAP Request.

Right click on “LDAP Example” → Add → Sampler → LDAP Extended Request

3. You can see nine 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.

LDAP Test Request Types

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

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

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 LDAP 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

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 LDAP test, we are adding a 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

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

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

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

Single bind/unbind

This bind is used for user authentication verification. An 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 its own separate connection to the LDAP server, performs a bind operation, and ends the connection again (by sending an unbind).

In this LDAP 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

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 LDAP test looks like this:

Now, when running an LDAP test we are able to see information about all our requests.

For example, this is the information about the Thread Bind request:

Bottom Line

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

You can also take your JMX file and test it with BlazeMeter to achieve cloud coverage and more thorough analysis options. to try out BlazeMeter, request a demo or put your URL or jmx file in the box:

START TESTING NOW
 

This blog was originally published on April 12, 2017, and has since been updated for accuracy and relevance.