How to load test LDAP with JMeter
We are going to discuss how we can test the Lightweight Directory Access Protocol (LDAP) using JMeter, the principles of LDAP can be quite complicated as their origins come from the X500 specification which documents a suite of protocols developed by the International Telecommunication Union in the 1980’s.
It is likely that you have heard of LDAP as the directory protocol used to underpin Active Directory (AD) which is a directory service for Microsoft and normally is used by many organisations to support user authentication and role profiles for company networks.
It is important to understand that LDAP is not exclusive to Microsoft but does allow users to query AD and authenticate access to it.
In order to demonstrate how we can test LDAP using JMeter we are going to use an Online Test Server provided by Forumsystems which means that should you wish to follow this tutorial but don’t have access to a LDAP server you can. If you need to look at the solution, the JMeter project can be found here.
A limitation of using this online LDAP test server is that we only have read-only access meaning we can only test the following functions:
- Bind
- Unbind
- Search
- Compare
But JMeter also offers the ability to:
- Rename
- Add
- Delete
- Modify
The LDAP entries which we will be unable to demonstrate using this service but nonetheless we will provide some examples of these test types.
Test service and LDAP principles¶
We are going to discuss LDAP in the context of the test service as this will allow us to discuss how we write a JMeter test.
Your organisations LDAP server, whatever its purpose, may be more complex and have more layers, it is worth reading up more on LDAP if you want to gain a greater understanding of the subject.
The test service is available here and basically provides this LDAP connection details:
- Server: ldap.forumsys.com
- Port: 389
- Bind DN: cn=read-only-admin,dc=example,dc=com
- Bind Password: All user passwords are password.
And this directory structure:
ou=mathematicians,dc=example,dc=com - riemann - gauss - euler - euclid
ou=scientists,dc=example,dc=com - einstein - newton - galieleo - tesla
In order to further understand the above we need to understand some of the common LDAP conventions and example of LDAP bindings can be found here.
But in essence:
| Term | Meaning |
|---|---|
| dc | domain component |
| cn | common name or relative distinguished name |
| dn | distinguished name |
| ou | organisational unit |
Within this directory structure each entity has a set of attributes so let’s look at one to see what each of the entries above contains.
We will use newton as an example, the LDAP entry looks like this:
{
"0": "sn",
"1": "objectclass",
"2": "uid",
"3": "mail",
"4": "cn",
"sn": {
"0": "Newton",
"count": 1
},
"objectclass": {
"0": "inetOrgPerson",
"1": "organizationalPerson",
"2": "person",
"3": "top",
"count": 4
},
"uid": {
"0": "newton",
"count": 1
},
"mail": {
"0": "newton@ldap.forumsys.com",
"count": 1
},
"cn": {
"0": "Isaac Newton",
"count": 1
},
"count": 5,
"dn": "uid=newton,dc=example,dc=com"
}
Where we can see that each entry contains 5 attributes:
"0": "sn",
"1": "objectclass",
"2": "uid",
"3": "mail",
"4": "cn",
Each of which contains information about the entity.
We will also have a look at the scientist organisational entities:
{
"0": "uniquemember",
"1": "ou",
"2": "cn",
"3": "objectclass",
"uniquemember": {
"0": "uid=einstein,dc=example,dc=com",
"1": "uid=galieleo,dc=example,dc=com",
"2": "uid=tesla,dc=example,dc=com",
"3": "uid=newton,dc=example,dc=com",
"4": "uid=training,dc=example,dc=com",
"5": "uid=jmacy,dc=example,dc=com",
"count": 6
},
"ou": {
"0": "scientists",
"count": 1
},
"cn": {
"0": "Scientists",
"count": 1
},
"objectclass": {
"0": "groupOfUniqueNames",
"1": "top",
"count": 2
},
"count": 4,
"dn": "ou=scientists,dc=example,dc=com"
}
Each entry contains 4 attributes:
"0": "uniquemember",
"1": "ou",
"2": "cn",
"3": "objectclass",
JMeter tests¶
We have a broad understanding of LDAP now and we have also looked at the test LDAP server that we are going to write our tests against which will help us in our understanding of the results we see from our JMeter tests.
Bind/Unbind¶
Let’s start by looking how we bind to our test LDAP server.
We have added an LDAP Extended Request and selected the Thread Bind option.
We have entered the distinguished name (DN) being the domain components (dc).
And the username being the common name (cn) of the read-only user plus the domain components (dc).
The password is password as per the Forumsystems information we have discussed above.
Before we run this test, we will add a Thread Unbind request to the Test Plan.
The Thread Unbind request does not require any values.
If we run the test and look at the results.
We can see that we have successfully connected to and unconnected from the LDAP server.
Search Test¶
We are now going to look at running a test where we search for entries in the LDAP structure.
We have already discussed the structure of the test server so let’s use this knowledge to run a search test.
We add another LDAP Extended Request to the Test Plan and select search test.
We will start with the selection boxes at the bottom of the sampler where the JMeter documentation states:
(Optional) Return object. Checked will return all java-object attributes, it will add these to the requested attributes, as specified above. Unchecked will mean no java-object attributes will be returned.
(Optional) Dereference aliases. Checked will mean it will follow references, Unchecked says it will not.
(Optional) Parse the search results?. Checked will mean it gets all results in response data, Unchecked says it will not.
These are all optional and the first two have no impact on the test server we are using, they may for the LDAP instance you are testing so it’s worth checking with your development teams.
We will select the last selection box as this will allow us to see the results in the View Results Tree.
The only mandatory field for searching is the Search Filter field and the Scope field so this is where we will start.
From the JMeter documentation.
Enter the searchfilter, any decent LDAP search filter will do, but for now, use something simple, like (sn=Doe) or (cn=*)
(Optional) Enter the scope in the scope field, it has three options: 1. baseobject search only the given searchbase is used, only for checking attributes or existence. 2. onelevel search Only search in one level below given searchbase is used. 3. subtree search Searches for object at any point below the given basedn
Even though the scope field is marked as optional it cannot be blank because it’s a drop-down list, so you need to pick a value.
We can start by searching for (uid=*) as this will give us a set of results with all the uid’s contained in it and we will leave the scope as Perform subtree search:
If we run this test and look at the results:
We can see that all uid’s are returned with all the values defined in the LDAP directory, we have expanded Pasteur below to see the results returned.
If we were to change the scope to Perform one level search, we would still get the same results as the uid’s are one level below the distinguished name of the user we selected to bind to LDAP with.
If we select Perform base object search, we will not get any matching results at all.
Before we move on, we can look at search by the organisational units and enter a Search Filter of (ou=*)
If we run this test, we can see that we have returned all the ou grouping and the entries they contain.
Before we move on and look at some of the other options we can specify a particular organisational unit to search, if we change our Search Filter to (ou=scientists).
And re-run the test we just get the users associated with the scientist’s organisational unit.
Before we move on from the search test lets just look at the Attributes field which lets us just return specific attributes from our search.
From the JMeter documentation.
(Optional) Attributes you want in the search answer. This can be used to limit the size of the answer, especially when an object has very large attributes (like jpegPhoto). There are three possibilities: 1. Leave empty (the default setting must also be empty) This will return all attributes. 2. Put in one empty value (""), it will request a non-existent attributes, so in reality it returns no attributes 3. Put in the attributes, separated by a semi-colon. It will return only the requested attributes
If we leave the same Search Field but only select dn as the Attribute we want to return then we only retrieve a single entry as all the values returned belong to the same Distinguished Name, that being ou=scientists,dc=example,dc=com.
And if we run the test
The remainder of the options on this page will not make any difference to our tests but may to yours but it’s worth reading up on them from the JMeter documentation.
Compare Test¶
The Compare Test allows us to check a value from the directory structure.
For the purposes of our Blog Post, we will perform a simple search against one of the uid’s and check if the email address is correct.
The Entry DN (distinguished name) we set to newton as this matches the example from the test LDAP server we have already discussed earlier in this post.
We are going to check that the email address is as we expect.
If we run the test:
We can see that we have a Success response indicating that the value matched.
Let’s look at another Compare Test before we move on.
We are looking to check the organisational unit of scientists to see if Einstein exists, if we run the test.
We can see that again we have a Success response indicating that the value matched.
Search summary¶
Both the above tests involve searching LDAP which is another topic that is far too wide and varied for this blog post.
There is a significant amount of data available on this subject and all the patterns widely discussed on this subject can be used in JMeter to support your performance testing, here is an example.
The response is returned in XML, and we are now going to briefly discuss how we will set up an assertion for the results so we can check the response.
We could use either a XPath Assertion or a Response Assertion to check the response.
An example of both is below.
In both cases we have checked for the string Success but you could obviously change this to be whatever you want.
Other test types¶
As we discussed earlier there are also these type of Test:
- Add
- Modify
- Rename
- Delete
That we cannot build and run tests for due to the limitations of the test server.
There is comprehensive documentation on the JMeter web site explaining how you would go about modifying LDAP as part of your tests.
These can be found here: Add,Modify, Rename and Delete
Conclusion¶
The post has all been run with a single user as it’s focus has been on demonstrating how to write JMeter tests against LDAP.
Clearly you will need to ensure you run these tests under the correct level of load and concurrency to support the performance testing of your LDAP servers.
Hopefully this post has given you an insight into how you would write tests for LDAP performance testing and gives you enough information to start building tests against you own internal test instance or against the test service that we have used in this post.
We would encourage you to read up on LDAP should you need to write performance tests for this protocol as this will help you with some of the more complex aspects of navigating the directory against which you will be testing.