In an Enterprise Domain, principals(users/groups) are synched to LiveCycle from an LDAP server via Directory Providers.
In an Enterprise or Hybrid Domain, the LiveCycle users might be authenticated using an LDAP server.
In both the above cases, it becomes necessary to sniff the traffic if one of the principal hasn’t reached LiveCycle or the sync has broken in between for some unexplained reason.
Or let say authenticating a user through an LDAP server is failing.
The server logs of an Application server detail only the issue occurring at it’s own end,
but can’t trace the issue occurred during the transfer of data or the issue occurred at LDAP server end.
In such cases capturing the log details right from the start of fetching principal to transporting it to LiveCycle server, gives a clear insight into the working of LDAP protocol and the issue occurred.
There are many ways of capturing LDAP traffic
- Wireshark is a great tool for capturing the LDAP traffic between an LDAP server and LiveCycle server.
- Snoop is a utility used for capturing traffic on a Solaris machine.
- TCPDump can be used to capture the LDAP traffic on a Linux machine.
- LDAPDecoder can be used to capture the traffic by acting as a proxy between the LiveCycle server and the LDAP server.
I prefer using LDAPDecoder because of the following reasons,
- It’s not always possible to install a Wireshark on customer’s production system.
Also using a Wireshark needs root access else the LDAP traffic can’t be captured.
Wireshark doesn’t work on headless unix/linux servers.
- Snoop and TCPDump help in capturing traffic on headless unix/linux servers but they capture all of the traffic while one may be interested in only the LDAP traffic.
- LDAPDecoder works well on both UI and non-UI systems.
On Non-UI systems the LDAPDecoder can work independently as well as in tandem with Snoop and TCPDump.
The data captured from Snoop and TCPDump can be given the LDAPDecoder in order to interpret LDAP information in specific.
- LDAPDecoder can be used to capture LDAP traffic between a remote LiveCycle server and remote LDAP server.
LDAPDecoder acts as a proxy between both the LDAP Server and LiveCycle server.
So, the client forwards the request to LDAPDecoder which decodes the request and then forwards it to the server.
Once it gets a response from the LDAP server it decodes it and passes on the LiveCycle server thereby completing the whole flow of LDAP communication.
Okay, enough of theory, let’s get to some practical now,
1. Extract the LDAPDecoder.jar from LDAPDecoder.
2. Start the LDAPDecoder as follows on command line,
java -jar LDAPDecoder.jar -h ldapserver -p 389 -L 390 -f output.log
-h ldapserver -> the host name or ip address of the LDAP server
-p 389 -> the port of the LDAP server
-L 390 -> the port of the LDAPDecoder server which the LiveCycle server should send requests to.
-f output.log -> the file in which the LDAP traffic will be captured, i.e. the request from the LiveCycle server and response from the LDAP server.
Additionally one can specify -s parameter to make communication between LDAP Server and LiveCycle server in SSL mode.
For more such options just type, java -jar LDAPDecoder.jar
3. Open the Enterprise or Hybrid domain in Edit mode.
4. In the server field, mention the hostname or the IPaddress of the machine on which the LDAPDecoder server is running.
5. In the port field, mention the port to which the LDAPDecoder server is listening, i.e. the port specified with -L parameter, e.g. 390.
6. Save the domain.
7. Sync the Domain in case of Enterprise or make authentication calls in case of either Enterprise or Hybrid domain.
8. Check the details of LDAP request response flowing between LiveCycle server and LDAP server in the log file, i.e. the file specified with the -f parameter, e.g. output.log
For more information on LDAPDecoder and how to interpret Snoop and TCMPDump data, refer the following doc,