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