In this section, you will learn how to create a basic Test Plan to test an LDAP server.

As the Extended LDAP Sampler is highly configurable, this also means that it takes some time to build a correct testplan. You can however tune it exactly up to your needs.

You will create four users that send requests for four tests on the LDAP server.Also, you will tell the users to run their tests twice. So, the total number of requests is (4 users) x (4 requests) x repeat 2 times) = 32 LDAP requests. To construct the Test Plan, you will use the following elements: Thread Group , LDAP Request , LDAP Request Defaults , and View Results in Table .

This example assumes that the LDAP Server is installed in your Local machine.

For the less experienced LDAP users, I build a small LDAP tutorial which shortly explains the several LDAP operations that can be used in building a complex testplan

The first step you want to do with every JMeter Test Plan is to add a Thread Group element. The Thread Group tells JMeter the number of users you want to simulate, how often the users should send requests, and the how many requests they should send.

Go ahead and add the ThreadGroup element by first selecting the Test Plan, clicking your right mouse button to get the Add menu, and then select Add-->ThreadGroup. You should now see the Thread Group element under Test Plan. If you do not see the element, then "expand" the Test Plan tree by clicking on the Test Plan element.

Figure 9.1. Thread Group with Default Values

Begin by selecting the Thread Group element. Click your right mouse button to get the Add menu, and then select Add --> Config Element -->LDAP Extended Request Defaults. Then, select this new element to view its Control Panel.

Like most JMeter elements, the LDAP Extended Request Defaults Control Panel has a name field that you can modify. In this example, leave this field with the default value.

Figure 9.3 LDAP Defaults for our Test Plan

For each of the different operations, some default values can be filled in. In All cases, when a default is filled in, this is used for the LDAP extended requests.

For each requst, you can override the defaults by filling in the values in the LDAP extended request sampler.

When no valueis entered which is necesarry for a test, the test will fail in an unpredictable way!

We will not enter any default values here, as we will build a very small testplan, so we will explain all the diffrent files when we add the LDAP Extended samplers.

In our Test Plan, we want to use all 8 LDAP requests.

1. Thread bind
2. Search Test
3. Compare Test
4. Single bind/unbind Test
5. Add Test
6. Modify Test
7. Delete Test
8. Rename entry (moddn)
9. Thread unbind

JMeter sends requests in the order that you add them to the tree.

Adding a requests always start by:
Adding the LDAP Extended Request to the Thread Group element (Add --> Sampler --> LDAP Ext Request). Then, select the LDAP Ext Request element in the tree and edit the following properties.

9.4.1 Adding a Thread bind Request

1. Select the "Thread bind" button.
2. enter the hostname value from the LDAP server in the Servername field
3. Enter the portnumber from the LDAP server (389) in the port field
4. (optional) enter the baseDN in the DN field, this baseDN will be used as thestarting point for searches, add, deletes etc.
   take care that this must be the uppermost shared level for all your request, eg When all information is stored under ou=people, dc=siemens, dc=com, you can use this value in the basedn.
   You cannot search or rename anymore in the subtree ou=users,dc=siemens,dc=com!
   If you need to search or rename objects in both subtrees, use the common denominator (dc=siemens,dc=com) as the baseDN.
5. (Optional) enter the distinghuised name from the user you want to use for authentication. When this field is kept empty, an anonymous bind will be established.
6. (optional) Enter the password for the user you want to authenticate with, an empty password will also lead to an anonymous bind.

Figure 9.4.1. Thread Bind example

9.4.2 Adding a search Request

1. Select the "Search Test" button.
2. (Optional) enter the searchbase under which you want to perform the search, relative to the basedn, used in the thread bind request.
   When left empty, the basedn is used as a search base, this files is important if you want to use a "base-entry" or "one-level" search (see below)
3. Enter the searchfilter, any decent LDAP serach filter will do, but for now, use something simple, like cn=john doe
4. (optional) enter the scope in the scope field, it has three options:
   1. Base level, Enter the value 0
      only the given searchbase is used, only for checking attributes or existence.
   2. One level, Enter the value 1
      Only search in one level below given searchbase is used
   3. Subtree, Enter the value 2
      Searches for object at any point below the given basedn
5. (Optional) Sizelimit, specifies the maximun number of returned entries,
6. (optional) Timelimit, psecifies the maximum number of miliseconds, the SERVER can use for performing the search. it is NOT the maximun time the application will wait!
   When a very large returnset is returned, from a very fast server, over a very slow line, you may have to wait for ages for the completion of the search request, but this parameter will not influence this.
7. (Optional) Attributes you want in the search answer. This can be used to limit the size of the answer, especially when an onject has very large attributes (like jpegPhoto). There are three possibilities:
   1. Leave empty (the defaultsetting 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, seperated by a semi-colon. It will return only the requested attributes
8. (Optional) Return object, possible values are "true" and "false". True will return all java-object attributes, it will add these to the requested attributes, as specified above.
   false will mean no java-object attributes will be returned.
9. (Optional) Dereference aliases. possible values "true" and "false". True will mean it will follow references, false says it will not.

Figure 9.4.2. search request example

9.4.3 Adding a Compare Request

1. Select the "Compare" button.
2. enter the entryname form the object on which you want the compare operation to work, relative to the basedn, eg "cn=john doe,ou=people"
3. Enter the compare filter, this must be in the form "attribute=value", eg "mail=John.doe@siemens.com"

Figure 9.4.3. Compare example

9.4.4 Adding a Single bind/unbind

1. Select the "Single bind/unbind" button.
2. Enter the FULL distinghuised name from the user you want to use for authentication.
   eg. cn=john doe,ou=people,dc=siemens,dc=com When this field is kept empty, an anonymous bind will be established.
3. Enter the password for the user you want to authenticate with, an empty password will also lead to an anonymous bind.
4. Take care: This single bind/unbind is in reality two seperate operations but cannot easily be split!

Figure 9.4.4. Single Bind/unbind example

9.4.5 Adding a Add Request

1. Select the "Add" button.
2. Enter the distinghuised name for the object to add, relative to the basedn.
3. Add a line in the "add test" table, fill in the attribute and value.
   When you need the same attribute more than once, just add a new line, add the attribute again, and a different value.
   All necessary attributes and values must be specified to pass the test, see picture!
   (sometimes the server add the attribute "objectClass=top", this might give a problem.

Figure 9.4.5. Add example

9.4.6 Adding a Modify Request

1. Select the "Modify test" button.
2. Enter the distinghuised name for the object to modify, relative to the basedn.
3. Add a line in the "modify test" table, with the "add" button.
4. You need to enter the attribute you want to modify, (optional) a value, and the opcode. The meaning of this opcode:
   1. add
      this will mean that the attribute value (not optional in this case) willbe added to the attribute.
      When the attribute is not existing, it will be created and the value added
      When it is existing, and defined multi-valued, the new value is added.
      when it is existing, but single valued, it will fail.
   2. replace
      This will overwrite the attribute with the given new value (not optional here)
      When the attribute is not existing, it will be created and the value added
      When it is existing, old values are removed, the new value is added.
   3. delete
      When no value is given, all values will be removed
      When a value is given, only that value will be removed
      when the given value is not existing, the test will fail
5. (Optional) Add more modifications in the "modify test" table.
   All modifications which are specified must succeed, to let the modification test pass. When one modification fails, NO modifications at all will be made and the entry will remain unchanged.

Figure 9.4.6. Modify example

9.4.7 Adding a Delete Request

1. Select the "Delete" button.
2. enter the name of the entry, relative to the baseDN, in the Delete-Field.
   that is, if you want to remove "cn=john doe,ou=people,dc=siemens,dc=com", and you set the baseDN to "dc=siemens,dc=com", you need to enter "cn=john doe,ou=people" in the Delete-field.

Figure 9.4.7. Delete example

9.4.8 Adding a Rename Request (moddn)

1. Select the "Rename Entry" button.
2. enter the name of the entry, relative to the baseDN, in the "old entry name-Field".
   that is, if you want to remove "cn=john doe,ou=people,dc=siemens,dc=com", and you set the baseDN to "dc=siemens,dc=com", you need to enter "cn=john doe,ou=people" in the Delete-field.
3. enter the new name of the entry, relative to the baseDN, in the "new distinghuised name-Field".
   whne you only change the RDN, it will simply rename the entry
   when you also add a differten subtree, eg you change from cn=john doe,ou=people to cn=john doe,ou=users, it will move the entry. You can also move a complete subtree (If your LDAP server supports this!!!!), eg ou=people,ou=retired, to ou=oldusers,ou=users, this will move the complete subtee, plus all retired people in the subtree to the new place in the tree.

Figure 9.4.8. Rename example

9.4.9 Adding an unbind Request

1. Select the "Thread unbind" button. This will be enough as it just closes the current connection. The information which is needed is already known by the system

Figure 9.4.9. Thread unbind example

The final element you need to add to your Test Plan is a Listener. This element is responsible for storing all of the results of your LDAP requests in a file and presenting a visual model of the data.Select the Thread group element and add a View Results in Table (Add --> Listener -->View Results in Table)

Figure 9.5 View result in Table Listener

Although it is not required, we recommend that you save the Test Plan to a file before running it. To save the Test Plan, select Save Test Plan from the File menu (with the latest release, it is no longer necessary to select the Test Plan element first).

JMeter allows you to save the entire Test Plan tree or only a portion of it. To save only the elements located in a particular "branch" of the Test Plan tree, select the Test Plan element in the tree from which to start the "branch", and then click your right mouse button to access the Save As menu item. Alternatively, select the appropriate Test Plan element and then select Save As from the Edit menu.

From the Run menu, select Run.

JMeter lights up a green square in the upper-right-hand corner to indicate if a test is currently running. The square is turned gray when all tests stop. Even after you select "stop", the green light will stay on until all test threads have exited.