Issue with Scripted Probe for LDAP

Question

I have the script LDAP_PROBE loaded into memory on my ACE 4710 (A4(2.0)) and th Probe is name is configured for the LDAP port the servers are listening on. So here is th econfiguration.
probe scripted LDAP_PROBE_3389
  port 3389
  interval 5
  passdetect interval 5
  passdetect count 2
  receive 5
  script LDAP_PROBE 3389
I have tried removing the argument of 3389 at the bottom as well but I continue to get the result:
real      : LDAP02[3389]
                10.220.31.81    3389  PROBE    2491     2491     0        FAILED
   Socket state        : RESET
   No. Passed states   : 0         No. Failed states : 1
   No. Probes skipped  : 0         Last status code  : 30002
   No. Out of Sockets  : 0         No. Internal error: 0
   Last disconnect err : Probe error: Server did not respond as expected
   Last probe time     : Thu Jul 12 16:24:41 2012
   Last fail time      : Thu Jul 12 12:56:59 2012
   Last active time    : Never
The server log states this was successful however...
Admin Acct Status: Not Locked
AuditV3--2012-07-11-14:18:21.428+00:00DST--V3 anonymous Bind--bindDN: <*CN=NULLDN*>--client: 10.220.31.217:56908--connectionID: 8--received: 2012-07-11-14:18:21.428+00:00DST--Success
name: <*CN=NULLDN*>
authenticationChoice: simple
Admin Acct Status: Not Locked
Am I missing an argument? I have run debug on LDAP but really don't know what I am looking at...

Answer 1

To update the script
==============
Extract the Cisco-supplied LDAP script from the tar.gz or zip file. Rename it to something unique. Update it to use the
new length and offset.
Import the script into the LDAP contexts on both ACEs. Remember, scripts are not replicated and having mismatched scripts will cause replication to fail.
ACE1/ldap# copy tftp: disk0:
Enter source filename[]? UoN-LDAP_PROBE-iLDAP2
Enter the destination filename[]? [UoN-LDAP_PROBE-iLDAP2]
Address of remote host[]? [redacted]
Trying to connect to tftp server......
TFTP get operation was successful
ACE2/ldap# copy tftp: disk0:
Enter source filename[]? UoN-LDAP_PROBE-iLDAP2
Enter the destination filename[]? [UoN-LDAP_PROBE-iLDAP2]
Address of remote host[]? [redacted]
Trying to connect to tftp server......
TFTP get operation was successful
script file 13 UoN-LDAP_PROBE-iLDAP2
If you look at (for example) packet 651 in the capture in wireshark you'll see a
successful bind response. You will need to tell wireshark to decode the packet as LDAP.
The payload is:
30 84 00 00 00 10 02 01 01 61 84 00 00 00 07 0a 01 00 04 00 04 00
You need to have a basic understanding of ASN.1 and something called Basic Encoding Rules (BER) - whicj comes down to TLV format structures.
The key to understanding this output is that there are three ways of specifying a length in ASN.1. The first way we have already seen in the Cisco script is to use a single byte. This known as the "definite" form and can be used for lengths of 127 bytes or less. Otherwise if the high bit is set to one, the low seven bits define the length of length. The length is then encoded in that many bytes. This is the "length of the length field" form. It looks like Microsoft Active Directory uses the indefinite form for all length encoding. The third form (for completeness is "indefinite" where the length is coded as x'80' and the end of the content is marked by x'0000'. Deconstructing the data:
0x30    The start of a universal constructed sequence
0x84    The length of the sequence in "length of the length" format. The next 4 bytes give the length.
0x00000010    sequence length of 16 bytes
0x02    Integer
0x01    The length of the next field (1 byte)
0x01    Value (this is the message ID which agrees with the ID in the BIND Request)
0x61    Application, number 0, use RFC2251 to decode. This is a Bind Response
0x84    The length of the sequence in "length of the length" format. The next 4 bytes give the length.
0x00000007    bind response length of 7 bytes   
0x0a    Enumeration
0x01    Length 1
0x03    0 - Success
0x04    String
0x00    Length 0 (null string)
0x04    String
0x00    Length 0 (null string)
The patch given takes in 20 bytes from the bitstream,converts it into a hexadecimal string  and finds the 6 hexadecimal characters from the 16th byte onwards   (Tcl uses zero-based arrays). This is the response code.
Kind Regards
Cathy