Issue with Scripted Probe for LDAP

Answered Question
Jul 12th, 2012

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...

I have this problem too.
0 votes
Correct Answer by ciscocsoc about 1 year 9 months ago

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

  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 5 (1 ratings)
ciscocsoc Fri, 07/13/2012 - 01:24

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

robert.mcclain Fri, 07/13/2012 - 05:08

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.

ciscocsoc Fri, 07/13/2012 - 05:27

> 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

robert.mcclain Fri, 07/13/2012 - 05:54

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.

ciscocsoc Fri, 07/13/2012 - 09:09

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

robert.mcclain Fri, 07/13/2012 - 09:13

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....

Correct Answer
ciscocsoc Fri, 07/13/2012 - 09:31

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

robert.mcclain Fri, 07/13/2012 - 09:43

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?

ciscocsoc Mon, 07/16/2012 - 01:12

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

Actions

Login or Register to take actions

This Discussion

Posted July 12, 2012 at 8:27 AM
Stats:
Replies:12 Avg. Rating:5
Views:944 Votes:0
Shares:0
Tags: ldap, probe
+

Related Content

Discussions Leaderboard

Rank Username Points
1 1,551
2 369
3 333
4 228
5 212
Rank Username Points
5