cn=Directory Manager

cn=Directory Manager
All about Directory Server

All | Personal | Sun

« Little-known perform... | Main | The role Directory... »

Friday December 09, 2005

Decoding LDAP communication

If you work with directory servers or directory-enabled applications long enough, chances are you'll run into cases in which you need to see exactly what the client is sending to the server, or vice versa. You could look in the server's access and/or audit logs, and they will often provide you with all the information that you need. However, they don't include all details of the requests and responses, and there are times that you need more in-depth information than the logs can provide.

The next place that you can turn is to use a network sniffer. While this may be able to meet your needs, it still won't work in all cases. For example, if the communication is encrypted using SSL, or if the client and server are on the same system and the underlying OS won't let you snoop over the loopback interface, then you won't be able to get anything useful. And even if you do capture the clear-text information, how will you be able to interpret it? Some tools (like Solaris snoop and Ethereal) can even try to decode some of the communication but they are often lacking in some areas, particularly when it comes to things like controls and extended operations.

Fortunately, even if the logs aren't helpful and it isn't feasible to use a network sniffer (or the sniffer doesn't provide the level of detail you would like), then there is another option: the LDAPDecoder tool, which is provided with the SLAMD Distributed Load Generation Engine, in the tools/LDAPDecoder directory. This is a very useful tool that can help give you a better understanding of exactly what is going on between the client and the server, and as a bonus it can even help you with your performance testing. More on that later.

The LDAPDecoder has two primary modes of operation. The first is proxy mode, in which you configure it to operate as a very simple LDAP proxy. You point it at the Directory Server you want to target, and then you point your client(s) at the LDAPDecoder. Whenever the LDAPDecoder receives a request from the client, it will print it to standard output or write it to a file and then forward it on to the Directory Server. When it receives the response message(s) from the server, it will write them out before sending them on to the client. It has the intelligence to be able to decode all types of LDAP operations, and even has special support for several kinds of controls so it can decode them as well. In this mode, it offers support for several things you can't get with a sniffer, including:

It can handle SSL-based communication (using server authentication only -- client authentication is not available).
It can handle cases where the client and server are on the same machine and the underlying OS does not allow packet captures over the loopback interface.
It does not require root or otherwise privileged access to the machine if you configure the proxy to listen on a port greater than 1024. Packet captures virtually always require root access.
It is easier to handle cases in which the payload of the network packets does not contain exactly one complete LDAP message. If an LDAP message is split into multiple packets, or if multiple complete or partial messages are placed into the same packet, then it can be more difficult to interpret them.

In order to start the LDAPDecoder in proxy mode, the basic usage is:

java -jar LDAPDecoder.jar -h {serverAddress} -p {serverPort} -L {listenPort}

This will start listening for requests on the specified listen port, and will decode any communication that it receives before forwarding to or from the directory server. There are a number of other options that can be used as well -- see the documentation either online or in the tools/LDAPDecoder directory under the SLAMD server installation, or you can simply invoke the tool as above but adding the "-H" argument for usage information.

The second mode of operation is called offline mode. In this case, the LDAPDecoder isn't directly involved with the communication between the client and the server, but rather is provided with a binary capture file in the format used by either snoop or tcpdump. It will parse the capture and attempt to identify and decode any LDAP communication contained in it and either display it to the terminal or send it to a file. Running in offline mode, it can't interpret SSL-encrypted communication and it can't deal with packets that are fragmented or contain multiple LDAP messages or message fragments, but otherwise functionality should be identical.

To start the LDAPDecoder in offline mode, the basic usage is:

java -jar LDAPDecoder.jar -p {serverPort} -i {captureFile}

This will read the capture file and pick out any packets with a source or destination port equal to the specified server port and attempt to decode them as LDAP. As with proxy mode, other options exist, so check the documentation for details.

So how can the LDAPDecoder help you with your performance testing? There are a couple of ways. The first is that it can simply let you see exactly what's going on between the client and the server. Once you know what the client is requesting and how the server is responding, you may be able to see ways that you can better tune the server to handle those requests. Another possibility is that you can take the information that you learned about what the client is doing and use it to write a SLAMD job or script to simulate that workload so that you can use it to stress the directory server.

It is this last use case where another very useful LDAPDecoder feature comes into play: it can automatically write a SLAMD job script for you based on the LDAP communication that it captures. If you add the "-F {scriptFile}" argument when running in either proxy or offline mode, then the LDAPDecoder will write information about any requests that it receives from the client into a SLAMD job script that you can use to help reproduce the same load against the server. Note that you will probably want to edit the resulting script to make it more generic (e.g., to target a range of users rather than always using the exact details that were captured), and also that the SLAMD scripting language doesn't currently include support for more advanced components of the language like controls or SASL binds or extended operations. However, it is still capable of handling many of the most common cases to make your job a little easier.

Posted by cn_equals_directory_manager ( Dec 09 2005, 08:42:57 AM CST ) Permalink

Comments: