LDAP test will not use nonstandard port

On Thu, September 17, 2015 1:11 pm, Scot Kreienkamp wrote:

Hi John,

On 9/17/2015 10:57 AM, Scot Kreienkamp wrote:

Hi all,


I’m running an LDAP test against an Oracle LDAP server from xymon
using
this configuration:

ldap://oud1.example.com:1389/DC=example,DC=com

"ldaplogin=cn=admin:password"

That test is failing with the error that it cannot contact the
server.

I have the following line in my hosts:

0.0.0.0  foo.bar.com   #
ldap://foo.bar.com:399/uid=someone,ou=people,o=bar.com?mail?base
ldap://foo.bar.com:389/uid=someone,ou=people,o=bar.com?mail?base
ldaps://foo.bar.com:636/uid=someone,ou=people,o=bar.com?mail?base

Broken up for easier reading:
0.0.0.0  foo.bar.com   #
ldap://foo.bar.com:399/uid=someone,ou=people,o=bar.com?mail?base
ldap://foo.bar.com:389/uid=someone,ou=people,o=bar.com?mail?base
ldaps://foo.bar.com:636/uid=someone,ou=people,o=bar.com?mail?base

My server is listening on ports 389 and 636. I have added the 399 test
for diagnostics. The result is: 399 fails, 389, and 636 continue to
work. In this instance, I'd say my ldap test is able to test against
non-standard ports.

(Solaris 10 with Xymon 4.3.21)

Does yours behave any differently if:
A) you attempt an anonymous bind?
B) you wrap your entire "ldap...=com" portion in double-quotes?
C) you replace your bind attempt with a simple port check?

The test results say:
ldap://lzbvidmdvoud1.na.lzb.hq:1389/DC=example,DC=com - failed

So it seems to be picking up the entire LDAP URL without it in quotes.  I
have two to test; the first is now surrounded by double quotes, the second
is not.  Neither are working.  A simple port check works just fine.  I
tried the anonymous bind also, which results in failure also.  Anonymous
bind from command line works fine.

The LDAP check is a little bit special-cased by default. Openldap's API
for bind checking tends to hang if the service is down, so it's checked
via a TCP hit first.

Looking through my records, this patch from Terabithia wasn't upstreamed
yet due to its changing of the default behavior, but I think it might be
the actual root of this problem. (Honestly, I haven't altered an LDAP
check in a while, so I might be remembering things wrong.) Would you mind
trying it out?


-jc