LDAP Protocol in Load runner |

LDAP (Lightweight Directory Access Protocol) is a protocol used for accessing and maintaining directory information services over an IP network. LDAP, the Lightweight Directory Access Protocol, is a protocol used to access a directory listing. The LDAP directory is composed of many LDAP entries. Each LDAP entry is a collection of attributes with a name, called a distinguished name (DN). In LoadRunner, you can simulate LDAP traffic using the LDAP virtual user protocol to test the performance and scalability of LDAP-based applications. LDAP directory entries are arranged in a hierarchical structure that reflects political, geographic, and/or organisational boundaries. Entries representing countries appear at the top of the tree. Below them are entries representing states or national organisations. Below them might be entries representing people, organisational units, printers, documents, or just about anything else.

VuGen records communication over LDAP servers. It creates a script, with functions that emulate your actions. This includes logging in and out of the server, adding and deleting entries, and querying an entry

LDAP Protocol Example Script
All LDAP functions come in pairs—one for global sessions and one where you can indicate a specific session. To apply the action to all sessions, use the version without the ex suffix. To apply the action to a specific session, use the version with the session identifier with the ex suffix. For example, mldap_logon logs on to the LDAP server globally, while mldap_logon_ex logs on to the LDAP server for a specific session.
In the following example, the user logs on to an LDAP server, ldap1. It adds an entry and then renames the OU attribute from Sales to Marketing

Action()

{

    // Logon to the LDAP server

    mldap_logon("Login",

        "URL=ldap://easyloadrunner@ldap1:80",

        LAST);

    // Add an entry for JOJO. 

    mldap_add("LDAP Add",

        "DN=cn=JOJO.K Smith,OU=Sales, DC=com",

        "Name=givenName", "Value=JOJO", ENDITEM,

        "Name=initials", "Value=K", ENDITEM,

        "Name=sn", "Value=Smith", ENDITEM,

        "Name=objectClass", "Value=contact", ENDITEM,

        LAST);

    // Rename JOJO’s OU to Marketing

    mldap_rename("LDAP Rename",

        "DN=CN=JOJO. Smith,OU=Sales,DC=com",

        "NewDN=OU=Marketing",

        LAST);

    // Logout from the LDAP server

    mldap_logoff();

    return 0;

}

Defining Distinguished Name Entries:

In LDAP (Lightweight Directory Access Protocol), objects are referenced by their distinguished name (DN). A DN is a sequence of relative distinguished names (RDNs) separated by commas. Each RDN consists of an attribute with an associated value in the format attribute=value. The attribute names are not case-sensitive. Here are some commonly used RDN attribute types:

• cn (Common Name): Represents the common name of an object, typically used to identify an entity within a directory.
• ou (Organizational Unit): Denotes an organizational unit within a directory structure, used for organizing objects hierarchically.
• dc (Domain Component): Specifies a domain component, often used to define the domain name within the directory hierarchy.
• o (Organization): Represents an organization or company entity within the directory structure.
• uid (User ID): Identifies a user within the directory, often used for authentication purposes.

These RDN attribute types help in uniquely identifying and organizing objects within the LDAP directory. When constructing DNs for LDAP operations, it's essential to adhere to the syntax and format specified by the LDAP API to ensure accurate referencing and retrieval of directory entries. By following the LDAP standards and guidelines for constructing DNs, developers can ensure interoperability and compatibility across LDAP-compliant systems. Additionally, proper DN construction facilitates efficient searching, filtering, and manipulation of directory data, enhancing the overall performance and reliability of LDAP-based applications. Therefore, a clear understanding of the LDAP DN structure and attribute types is crucial for effectively managing directory resources and implementing LDAP operations with precision and consistency.

In LDAP (Lightweight Directory Access Protocol), certain characters have special significance and need to be properly escaped when used within distinguished names (DNs) or attribute values. These characters include:

1. Comma (,): Typically used to separate RDN components in a DN. It should be properly escaped if it's part of an attribute value.

2. Plus (+): Often used in attribute values. It should be escaped if used in DNs or filter expressions.

3. Semicolon (;): Sometimes used in attribute values. It should be escaped if used in DNs or filter expressions.

4. Backslash (\): Used as an escape character in LDAP to escape special characters. If a backslash is part of an attribute value, it should be escaped by another backslash (\\).

5. Left Angle Bracket (<) and Right Angle Bracket (>): These characters are not commonly used in DNs but should be escaped if necessary.

6. Double Quote ("): Sometimes used in attribute values. It should be escaped if used in DNs or filter expressions.

To incorporate a reserved character as part of an attribute value in LDAP, you must precede it with an escape character, represented by a backslash (\). Additionally, if an attribute value contains other reserved characters such as the equal sign (=) or non-UTF-8 characters, it should be encoded in hexadecimal format, indicated by a backslash followed by two hex digits. Below are examples of distinguished names (DNs) that include escaped characters:

1. Example of an organizational unit name with an embedded comma:

   OU=Sales\,Marketing,DC=example,DC=com

  

   In this example, the comma within "Sales\,Marketing" is escaped to denote that it is part of the organizational unit name.

2. Example of a value containing a carriage return:

 

   CN=John\0D\0ASmith,OU=Users,DC=example,DC=com

   Here, the carriage return character (represented in hexadecimal as \0D\0A) is escaped to ensure proper interpretation within the attribute value.

By adhering to these encoding and escaping conventions, LDAP clients and servers can accurately handle attribute values containing reserved characters, ensuring data integrity and consistency within the directory service.

LDAP Connection Options:

Controlling your login to the LDAP server is facilitated through the mldap_logon[_ex] function.

When specifying the URL of the LDAP server, you indicate the connection method and provide necessary credentials.

The format for specifying the server's URL is as follows:

ldap[s][username:[password]@][server[:port]]

Below are several examples illustrating connections to LDAP servers:

- ldap://a:b@server.com:389: This syntax connects to the LDAP server on port 389 and subsequently binds with the username "a" and password "b".

- ldap://:@server.com: This configuration connects to the LDAP server on the default unsecured port 389 and performs an anonymous bind.

- ldaps://a:@server.com: This format establishes a connection to the LDAP server on the default secured port 636 and then binds with the username "a".

- ldap://@server.com, ldap://server.com: These variations connect to the LDAP server without performing any binding.

- ldap://a:b@: With this syntax, the connection binds with the username "a" and password "b" on the existing session without reconnection.

- ldap://:@: This setup performs an anonymous bind with a NULL username and password on the existing session without reconnection.

Additional LDAP modes or SSL certificates can be specified using optional arguments such as:

- Mode: Specifies the LDAP call mode (Sync or Async)

- Timeout: Sets the maximum search time for the LDAP server

- Version: Specifies the LDAP protocol version (1, 2, or 3)

- SSLCertDir: Path to the SSL certificates database file (cert8.db)

- SSLKeysDir: Path to the SSL keys database file (key3.db)

- SSLKeyNickname: SSL key nickname in the keys database file

- SSLKeyCertNickname: SSL key's certificate nickname in the certificates database file

- SSLSecModule: Path to the SSL security module file (secmod.db)

- StartTLS: Requires issuing the StartTLS extension's specific command to switch the connection to TLS (SSL) mode