LDAP test will not use nonstandard port
list Scot Kreienkamp
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. However, a command line search works: ldapsearch -vh oud1.example.com:1389 -x -D "cn=admin" -w password -b "dc=example,dc=com" -s sub '(objectclass=*)' When I look at the traffic with tcpdump it shows that Xymon is connecting to the standard port instead of the custom port specified in the test: [root at retv6100 ~]# tcpdump host oud1 14:50:44.204908 IP xymon.example.com.53584 > oud1.example.com.ldap: S 3493937027:3493937027(0) win 5840 <mss 1460,sackOK,timestamp 2001931626 0,nop,wscale 7> 14:50:44.205311 IP oud1.example.com.ldap > xymon.example.com.53584: R 0:0(0) ack 3493937028 win 0 I saw someone else posted this question some time ago on the list but I couldn't find any resolution. ./xymonnet --version output: xymonnet version 4.3.21 SSL library : OpenSSL 0.9.8e-rhel5 01 Jul 2008 LDAP library: OpenLDAP 20343 Thanks! Scot Kreienkamp | Senior Systems Engineer | La-Z-Boy Corporate One La-Z-Boy Drive | Monroe, Michigan 48162 | * XXX-XXX-XXXX | | * 7349151444 | * user-9678697f1438@xymon.invalid<mailto:%7BE-mail%7D> www<http://www.la-z-boy.com/>.la-z-boy.com<http://www.la-z-boy.com/>; | facebook.<https://www.facebook.com/lazboy>com<https://www.facebook.com/lazboy>/<https://www.facebook.com/lazboy>lazboy<http://facebook.com/lazboy>; | twitter.com/lazboy<https://twitter.com/lazboy>; | youtube.com/<https://www.youtube.com/user/lazboy>lazboy<https://www.youtube.com/user/lazboy>; [cid:lzbVertical_hres.jpg] This message is intended only for the individual or entity to which it is addressed. It may contain privileged, confidential information which is exempt from disclosure under applicable laws. If you are not the intended recipient, you are strictly prohibited from disseminating or distributing this information (other than to the intended recipient) or copying this information. If you have received this communication in error, please notify us immediately by e-mail or by telephone at the above number. Thank you.
Attachments (1)
attachment.jpglist John Thurston
▸
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?
--
Do things because you should, not just because you can.
John Thurston XXX-XXX-XXXX
user-ce4d79d99bab@xymon.invalid
Enterprise Technology Services
Department of Administration
State of Alaska
list Scot Kreienkamp
Hi John,
Scot Kreienkamp | Senior Systems Engineer | La-Z-Boy Corporate One La-Z-Boy Drive | Monroe, Michigan 48162 | Office: XXX-XXX-XXXX | | Mobile: XXXXXXXXXX | Email: user-9678697f1438@xymon.invalid
▸
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?baseBroken 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.
▸
This message is intended only for the individual or entity to which it is addressed. It may contain privileged, confidential information which is exempt from disclosure under applicable laws. If you are not the intended recipient, you are strictly prohibited from disseminating or distributing this information (other than to the intended recipient) or copying this information. If you have received this communication in error, please notify us immediately by e-mail or by telephone at the above number. Thank you.
list Japheth Cleaver
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?baseBroken 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
Attachments (1)
list Scot Kreienkamp
▸
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
Sure, send it over.
▸
Scot Kreienkamp | Senior Systems Engineer | La-Z-Boy Corporate
One La-Z-Boy Drive | Monroe, Michigan 48162 | Office: XXX-XXX-XXXX | | Mobile: XXXXXXXXXX | Email: user-9678697f1438@xymon.invalid
This message is intended only for the individual or entity to which it is addressed. It may contain privileged, confidential information which is exempt from disclosure under applicable laws. If you are not the intended recipient, you are strictly prohibited from disseminating or distributing this information (other than to the intended recipient) or copying this information. If you have received this communication in error, please notify us immediately by e-mail or by telephone at the above number. Thank you.
list John Thurston
On 9/17/2015 12:11 PM, Scot Kreienkamp wrote: - snip -
▸
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.
a'write then. What if you ask for this test to be performed interactively in debug mode? Try the following, substituting the hostname from hosts.cfg for foo.bar.com. xymoncmd xymonnet --noping --debug foo.bar.com It should spill everything xymonnet is trying to do and give you an idea where the problem is. When I try it, I see (among the debris) the following interesting lines:
Adding tcp test IP=10.2.3.4, port=389, service=ldap, silent=0 . . . Initiating LDAP session for host foo.bar.com port 389
▸
--
Do things because you should, not just because you can.
John Thurston XXX-XXX-XXXX
user-ce4d79d99bab@xymon.invalid
Enterprise Technology Services
Department of Administration
State of Alaska
list Scot Kreienkamp
xymoncmd xymonnet --noping --debug foo.bar.com
Here's what I get: 10361 2015-09-17 16:36:55.593770 Adding tcp test IP=0.0.0.0, port=389, service=ldap, silent=0 10361 2015-09-17 16:36:55.593780 Concurrency evaluation: rlim_cur=1024, FD_SETSIZE=0, absmax=1024, initial=1014 10361 2015-09-17 16:36:55.593784 About to do 1 TCP tests running 256 in parallel, abs.max 1014 10361 2015-09-17 16:36:55.593813 1 tests pending - 1 active tests, 0 slow tests 10361 2015-09-17 16:36:55.593816 Doing select with maxfd=3 10361 2015-09-17 16:36:55.593820 select returned 1 10361 2015-09-17 16:36:55.593830 TCP tests completed normally Address=0.0.0.0:389, open=0, res=111, err=2, connecttime=0.000030, totaltime=0.000030, URL : ldap://oud1:1389/DC=example,DC=com Time spent : 0.00 LDAP output: Cannot connect to server
▸
Scot Kreienkamp | Senior Systems Engineer | La-Z-Boy Corporate
One La-Z-Boy Drive | Monroe, Michigan 48162 | Office: XXX-XXX-XXXX | | Mobile: XXXXXXXXXX | Email: user-9678697f1438@xymon.invalid
This message is intended only for the individual or entity to which it is addressed. It may contain privileged, confidential information which is exempt from disclosure under applicable laws. If you are not the intended recipient, you are strictly prohibited from disseminating or distributing this information (other than to the intended recipient) or copying this information. If you have received this communication in error, please notify us immediately by e-mail or by telephone at the above number. Thank you.
list Japheth Cleaver
▸
On Thu, September 17, 2015 1:32 pm, Scot Kreienkamp wrote:
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? -jcSure, send it over.
T'was attached, but here's a direct link: http://lists.xymon.com/pipermail/xymon/attachments/20150917/9f8c945c/attachment.obj -jc
list Scot Kreienkamp
▸
Scot Kreienkamp | Senior Systems Engineer | La-Z-Boy Corporate One La-Z-Boy Drive | Monroe, Michigan 48162 | Office: XXX-XXX-XXXX | | Mobile: XXXXXXXXXX | Email: user-9678697f1438@xymon.invalid
▸
On Thu, September 17, 2015 1:32 pm, Scot Kreienkamp wrote: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? -jcSure, send it over.T'was attached, but here's a direct link:
http://lists.xymon.com/pipermail/xymon/attachments/20150917/9f8c945c/a ttachment.obj -jc
Sorry, brain was in setting up the load balancer and never noticed the attachment. That fixed the ldap test that was not working and the regular port tests are still working, so I'd say you squashed that bug. Thanks JC!
▸
This message is intended only for the individual or entity to which it is addressed. It may contain privileged, confidential information which is exempt from disclosure under applicable laws. If you are not the intended recipient, you are strictly prohibited from disseminating or distributing this information (other than to the intended recipient) or copying this information. If you have received this communication in error, please notify us immediately by e-mail or by telephone at the above number. Thank you.