07-12-2012 08:27 AM
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...
Solved! Go to Solution.
07-13-2012 09:31 AM
Hi Robert,
Yes - it is just like Active Directory. The Bind Success response is coming back with length-of-length encoding in the ASN.1 stream.
You need to change the bit of the script that looks for the response to read:
# read string back from server
ace_debug "receiving ldap bind result"
set line [read $sock 20]
binary scan $line H* res
binary scan $line @15H6 code
That is read more bytes and look at a different offset. Make that change and you'll find it works.
BTW: The correct approach when defining the probe was to use the port=3389 rather than specifying it as an argument unless you have made more substantial changes to the Cisco code.
If you need more background then check out some of my other LDAP probe postings.
HTH
Cathy
07-12-2012 11:28 AM
...any way to look on the ACE or the server to see what the true issue is?
07-13-2012 01:24 AM
Hi Robert,
A packet capture from the switchport to which the server is connected would be useful - then we can see exactly what we're dealing with.
If by chance you're using a Microsoft AD/LDAP server then you need to be aware that the script as supplied will not work. MS use the length-of-length coding in the response whereas the scipt expects the definite form of length specification.
HTH
Cathy
07-13-2012 05:08 AM
Cathy,
Thanks for your reply. I know the server is not Microsoft, I can find out exactly what it is. I can't get in the dc to do a capture from the network side, but I can get a tcpdump from the server if that helps.
07-13-2012 05:27 AM
> but I can get a tcpdump from the server if that helps
It can't hurt. The 30002 means than the script didn't like what it saw in the reply.
Cathy
07-13-2012 05:54 AM
Cathy,
I agree, the Script didn't like the reponse, but my only resource at the time was the application folks and they didn't have much insight other than the log files. I am getting the other teams involved now. What I read on the Wikki for health Monitoring pointed this issue at the Script configuration. So I worked the config every which way but correct, so that's the reason I opened this up.
07-13-2012 06:53 AM
Just an FYI on the server...this is an AIX box.
07-13-2012 09:02 AM
What is the eaiest way to show the capture here?
07-13-2012 09:09 AM
Reply using the "Use advanced editor" option (top rh corner)
This brings up an option at the bottom of the window to attach a file.
Cathy
07-13-2012 09:13 AM
Uploaded, the flow to look for is 10.220.31.217 to 10.220.31.73, we have several LDAP probes running on different ports, none are working....
07-13-2012 09:31 AM
Hi Robert,
Yes - it is just like Active Directory. The Bind Success response is coming back with length-of-length encoding in the ASN.1 stream.
You need to change the bit of the script that looks for the response to read:
# read string back from server
ace_debug "receiving ldap bind result"
set line [read $sock 20]
binary scan $line H* res
binary scan $line @15H6 code
That is read more bytes and look at a different offset. Make that change and you'll find it works.
BTW: The correct approach when defining the probe was to use the port=3389 rather than specifying it as an argument unless you have made more substantial changes to the Cisco code.
If you need more background then check out some of my other LDAP probe postings.
HTH
Cathy
07-13-2012 09:43 AM
Cathy,
I was trying everything i could think of that may have been inaccurate. I will remove that argument. Now to re-write the script..do I just paste the code into wordpad and change the variable and save it as a .tcl file?
How did you figure out the off-set or length was wrong?
07-16-2012 01:12 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide